FEA Inter-operability

Dear Admin:

Yes, when I applied unv2ElmerUNV.py to a small mesh, it worked very well, however, for a larger mesh (> 200,000 elements), it took several hours to complete.

phsieh2005

Hi,

i have optimized the unv2Elmerunv.py script, it is now really much faster!

Here is the code: www.caelinux.com/downloads/tools/unv2ElmerUNV.py

To give you an idea, it now takes approx 5 seconds to convert a mesh containing 2 bodies and 25'000 tetra elements... it was just one stupid line which was slowing the code before.

Hi all,

I am really happy to see this discussion regarding the FEA file interoperability. I was pondering this for a quite sometime but never started to work on that.
I was seriously considering the XML based format, but I was worried because of the input file size increase due to tags.
I work on huge models where the pre-processors struggle to cope with even the plain text format.
One of my friend suggested Binary XML, but I couldn't get to understand what is it. [ I do not understand binary stuff well]
After reading all these posts I think HDF may well be the good choice.

I would like to hear few comments from everybody.
Do you ever heard of Binary XML do you understand it, if so what do you think of it compared to HDF format.
In case if I start to work on that, what format would you guys like to to be first.

----

Currently I am trying to create various translators, as of now I have created a simple Nastran-to-LSDYNA tranlator
please see www.geocities.com/rajsekarann where you can download that.
I was also planning to work on NASTRAN-UNV,Dyna-UNV, ABAQUS-UNV. But now I am wondering whether I should work on a inary format like HDF, any thoughts would be appreciated.

Hello Rajasn and all others

For Binary XML I sugest you look at
www.w3.org/XML/Binary

I am very interested in this Free CAE Format thread and I would like to highlight a few points.
The first one is about the license of the Universal format : the problem have been raised but I personally don't know what I can do and what I can't. Maybe Joël will have the answer in the I-Deas Doc ? If it is proprietary, I hardly imagine that all the CAE software can rely on something they cannot use/modify/update the way they want.
The second one is that I guess most of the people having posted something on this thread is looking for something usable at once while many others (like me until now) have just read the posts for looking at a possible Free Standard. Maybe could we organize a two step effort : starting with Joël's code and Universal format for a quick and efficient way of interchanging data right now while discussing about what we would like to see in a \"perfect interchange format\".
The last one is about the text/binary orientation : I suggest we don't forget a converter between these two formats as it is often useful for debugging purposes.

In the hope these small ideas will help the community of the free CAE users,
Olivier

I was looking for some general file format for FEA and I came across this very interesting thread. It seems that 4 years after starting this discussion, there is still the need for an open and general file format for FEA.

I have not yet studied the documentation of the hdf and med formats but I have experience with the following formats:
Nastran
Ansys
Gmsh
GetFem++ native mesh format
vtk

My suggestion would be to try to implement a standard which would wrap the most common formats available. This standard could provide alternative ways for accessing mesh, materials, boundary conditions and loading data. Let me better describe it through an example:
[code:1]
material 1:
format: embedded
E: 206000
nu: 0.3
material 2:
format: nastran
file: mesh_from_john.bdf
id: 4002

submesh 1:
format: gmsh
file: mesh_from_bob.gmsh
filter: elements in the physical group 17
material: material 1
submesh 2:
format: nastran
file: mesh_from_john.bdf
filter: elements with material id equal 4001
material: material 1
submesh 3:
format: nastran
file: mesh_from_john.bdf
filter: elements with material id equal 4002
material: material 2
submesh 4:
format: gmsh
file: mesh_from_bob.gmsh
filter: elements of type hexa
material: material 1
submesh 5:
format: embedded
nodes:
node1 0., 0., 0.
node2 ............
elements:
elm1 type0 node2 node3 node1
..........
material: material 1

boundary condition 1:
format: embedded
type: dirichlet
region: submesh 3
val_vector: 0., 0., 0., ......
boundary condition 2:
format: nastran
file: mesh_from_john.bdf
filter: BC group 55
boundary condition 3:
format: embedded
type: unilateral contact condition
regions: submesh 2, submesh 3

loading 1:
format: nastran
file: mesh_from_john.bdf
filter: LOAD groups 31 and 32
loading 2:
format: embedded
region: submesh 4
val_vector: 10., 10., 10., ....

requested result 1:
content: displacements, von mises
format: vtk
filter: submesh 1, 2, 3
requested result 2:
content: reaction forces
format: op2
filter: submesh 5
[/code:1]
The data in this example don't make a lot of sense but the idea is to create a description containing information about combining data provided in different formats. A FEA application could support only a subset of the alternatives foreseen in such a standard.

Post edited by: logari81, at: 2010/09/01 14:13<br /><br />Post edited by: logari81, at: 2010/09/01 14:16