FEA Inter-operability
17 years 7 months ago #630
by admin
Replied by admin on topic Re:FEA Inter-operability
@JMB: sorry but this old translator was from Abaqus 5.8 format to a specific \"custom\" FE solver format... so not very interesting for the needs of the community...
@Massimo:
Your idea for the translation with Exclude list is great and would be the most powerfull option, but may be difficult to implement...
Another idea:
as the problem of the 1D/2D elements is specific to Salome, one option would be to delete selectively the elements in Salome before the export to UNV format... With the powerfull \"filter based\" selection of Salome (like \"Element Family = 1D OR Element Family = 2D\"), one could easily implement this in a custom python command in Salome.
Some general thoughts on the subject:
Concerning the translator algorithm, I think that the simplest and most efficient way is to use a parser to convert datasets from the input file into a \"neutral\" object data structure and then write this datastructure into the correct format.
The use of a parser function should be the following:
1) init a blank FE datastructure (object model) for the input format
2) look for a new dataset & identify its type
3) if this dataset is supported by the code, call a specific routine to read and store this particular dataset.
if the dataset is not supported, go to 2)
4) goto 2) until the end of file.
5) create another FE datastructure for output format
6) convert the datasets from datastructure 1 to datastructure 2
7) write the output file in the desired format
I have used this scheme in a very rough translator from UNV to matlab data structure (for modal analysis results... not FEM sorry) and i have to say that this scheme is the most efficient I ever found for this kind of task.
In fact the key feature of such scheme is to be able to read only a specific typse of datasets (can add progressively new features to the converter) even when they are stored out of the logical order (You don't need to manually clean the file before running the translator...). To have an \"expandable\" code, a list of supported datasets and corresponding functions that read the data should be initialized at the beginning of the code and then used in the parser to selectivelly call the subroutines (generic code).
When the code that reads & store the input file in a \"neutral\" object database is written, it can be reused for whatever output format too!! No need to completely rewrite the translator... writing a code framework for UNV2Whatever would be much more reusable than plenty of dedicated translators without a common denominator. But I know, time is money... and coding time is also less free time
.
For this task, a simple platform-independant object oriented language would be the best choice and I would recommend using python for these typically non-performance oriented tasks.
unfortunately I do not have enough time to write this \"framework code\" to read UNV to neutral object database... but if someone is willing to create such base code for other translators it would be absolutely great !!
I hope these thoughts can help you all to find a nice answer to the recurrent problem of datafile translation...
@Massimo:
Your idea for the translation with Exclude list is great and would be the most powerfull option, but may be difficult to implement...
Another idea:
as the problem of the 1D/2D elements is specific to Salome, one option would be to delete selectively the elements in Salome before the export to UNV format... With the powerfull \"filter based\" selection of Salome (like \"Element Family = 1D OR Element Family = 2D\"), one could easily implement this in a custom python command in Salome.
Some general thoughts on the subject:
Concerning the translator algorithm, I think that the simplest and most efficient way is to use a parser to convert datasets from the input file into a \"neutral\" object data structure and then write this datastructure into the correct format.
The use of a parser function should be the following:
1) init a blank FE datastructure (object model) for the input format
2) look for a new dataset & identify its type
3) if this dataset is supported by the code, call a specific routine to read and store this particular dataset.
if the dataset is not supported, go to 2)
4) goto 2) until the end of file.
5) create another FE datastructure for output format
6) convert the datasets from datastructure 1 to datastructure 2
7) write the output file in the desired format
I have used this scheme in a very rough translator from UNV to matlab data structure (for modal analysis results... not FEM sorry) and i have to say that this scheme is the most efficient I ever found for this kind of task.
In fact the key feature of such scheme is to be able to read only a specific typse of datasets (can add progressively new features to the converter) even when they are stored out of the logical order (You don't need to manually clean the file before running the translator...). To have an \"expandable\" code, a list of supported datasets and corresponding functions that read the data should be initialized at the beginning of the code and then used in the parser to selectivelly call the subroutines (generic code).
When the code that reads & store the input file in a \"neutral\" object database is written, it can be reused for whatever output format too!! No need to completely rewrite the translator... writing a code framework for UNV2Whatever would be much more reusable than plenty of dedicated translators without a common denominator. But I know, time is money... and coding time is also less free time
.For this task, a simple platform-independant object oriented language would be the best choice and I would recommend using python for these typically non-performance oriented tasks.
unfortunately I do not have enough time to write this \"framework code\" to read UNV to neutral object database... but if someone is willing to create such base code for other translators it would be absolutely great !!
I hope these thoughts can help you all to find a nice answer to the recurrent problem of datafile translation...
Please Log in or Create an account to join the conversation.
Moderators: catux
Time to create page: 0.135 seconds