FEA Inter-operability

More
14 years 7 months ago #437 by Joël Cugnoni
Replied by Joël Cugnoni on topic Re:FEA Inter-operability
Hi,

I fully understand concerning french, but the good thing with this format description in HTML is that you can easily use Google online translation tool to get a decent english version. I have tried it yet and it seems to be good enough to start with.

On the other hand, I agree that using a C library in JAVA to read and HDF binary file (another library too!!) is not easy at all.

So in your present case, it is far better to use an ASCII file format like UNV for input & output. I can give you a complete description of the UNV file format by EMAIL (it is a part of I-Deas help files = not open source !!).

The next step is to define a subset of datasets that we all should be able to read / write to exchange the minimum required data for analysis.

I suggest to look around to see which datasets are actually being used by most of the softwares, but for sure we will need:

Dataset 15 and/or 2411: nodes (+ group number & color number => group definitions)

Dataset 780 and/or 2412: element connectivities (+ physical property table + material id + color => group definitions)

Dataset 55 and/or 2414: analysis data (at nodes or else, scalar, vector, tensors, real/double)

and maybe more.... (header, coordinate systems, units...)

see for example :
1) http://www.sdtools.com/help/ufread.html to have an idea of what SDToolbox reads as an example (reads both analysis & experimental data from, UNV/UFF files)
2) http://www.sdrl.uc.edu/uff2/uff2.html for a summary of some the datasets used for experimental modal analysis (if someone needs to correlate models with experiment...)
3) see attached PDF file

Attachment PRE_IDEAS_EN.pdf not found

: a rough (google) translation of Code-Aster Mesh interface for IDEAS UNV files
4) send me an email so I can give you the full description of UNV file format in a ZIP archive.

I hope this will help you.

J.Cugnoni
www.caelinux.com

Post edited by: admin, at: 2006/06/22 21:43

Joël Cugnoni - a.k.a admin
www.caelinux.com
Attachments:

Please Log in or Create an account to join the conversation.

  • JonasForssell
  • Topic Author
  • Visitor
  • Visitor
14 years 6 months ago #489 by JonasForssell
Replied by JonasForssell on topic Re:FEA Inter-operability
Thanks for the feedback. I'll have a look at the PDF.

Currently Impact supports NASTRAN file format. This seems to be the common file format used to port models between the programs at my work (a company in the automotive industry).

Models are ported between different preprocessors and different solvers, both implicit and explicit.

Could it not be an issue to use a file format (UNV) which is closed source. Would this not mean that we would need a license for the format before implementing it?

I'm not sure about the Nastran file format. Just that it is old (NASA origins) and that several programs use it today.

/Jonas

Please Log in or Create an account to join the conversation.

  • JonasForssell
  • Topic Author
  • Visitor
  • Visitor
14 years 6 months ago #490 by JonasForssell
Replied by JonasForssell on topic Re:FEA Inter-operability
Thanks for the feedback. I'll have a look at the PDF.

Currently Impact supports NASTRAN file format. This seems to be the common file format used to port models between the programs at my work (a company in the automotive industry).

Models are ported between different preprocessors and different solvers, both implicit and explicit.

Could it not be an issue to use a file format (UNV) which is closed source. Would this not mean that we would need a license for the format before implementing it?

I'm not sure about the Nastran file format. Just that it is old (NASA origins) and that several programs use it today.

/Jonas

Please Log in or Create an account to join the conversation.

  • JMB
  • Topic Author
  • Visitor
  • Visitor
14 years 4 months ago #622 by JMB
Replied by JMB on topic Re:FEA Inter-operability
Joel,

You mentioned some time ago having written an ABAQUS translator. Is this something you are willing to put in the public domain? If so could you post / attach it here?

Thanks
JMB

Please Log in or Create an account to join the conversation.

  • Massimo
  • Topic Author
  • Visitor
  • Visitor
14 years 4 months ago #628 by Massimo
Replied by Massimo on topic Re:FEA Inter-operability
Hi I was trying to implement a simple unv to Abaqus (calculix) translator.
Unfortunately I am on a busy schedule, and the projects is crawling. Anyway I found a couple of issues about the translation. Is someone can suggest a solution...
For each element salome node definition is different with respect to the one used in Calculix. So every element employed must be remapped.
When exporting a mesh from salome there are a lot of elements that are not used in calculix (a meshed 3D geometry will have also shells and beams). I was thinking to use a filter on the group names. For instance every group name starting with \"X_\" will be excluded. Creating those groups in salome will allow to rapidly remesh the geometry, keeping group names, simplifying the procedure.
I was planning to convert only nodes, elements (not in the X_ groups), and group names. BC will be applied in the calculix input file. The mesh can be easily included with the *INCLUDE card.
The traslator would be a perl script called with the file names traslator.pl < mesh_from_salome.unv > mesh_to_calculix.mesh
Suggestions are very welcome...

Massimo

Please Log in or Create an account to join the conversation.

  • admin
  • Topic Author
  • Visitor
  • Visitor
14 years 4 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...

Please Log in or Create an account to join the conversation.

Moderators: catux
Time to create page: 0.134 seconds
Powered by Kunena Forum