Universal FE format
Universal FE format
(OP)
Hi,
universal file formats are well known in the CAD world (e.g. iges).
What about FEA?
Why we don't already have well established universal file formats for finite element models?
Possible answers:
1) Too complex data
2) No need for an universal file format in FEM
3) ... what is your opinion?
Best regards
Alex
universal file formats are well known in the CAD world (e.g. iges).
What about FEA?
Why we don't already have well established universal file formats for finite element models?
Possible answers:
1) Too complex data
2) No need for an universal file format in FEM
3) ... what is your opinion?
Best regards
Alex
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de





RE: Universal FE format
Cheers
Greg Locock
New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?
RE: Universal FE format
I have done some research on UNV but didn't found any documentation. Instead I found a thread (forum2: Aircraft engineering/viewtopic.php?id=11033" target="_blank">http://www.code-aster.org/forum2: Aircraft engineering/viewtopic.php?id=...) where one guy writes:
"Just for information, I-deas is now in one of its last versions, I-deas 13, and the new I-deas as you might know is called NX.
UGS is today in version 5 of NX, and the thing is that the UNV format is no longer supported by NX ..."
Nevertheless unv seems to be a proprietary file format. I think it's also not supporting everything, so it needs to be extended. But that will be difficult since: a) it's proprietary, b) no longer supported by the owner.
So what about some smart, extendable, open source/specification file format for FEM? Are there some projects running?
I think there is a need for that. I had often problems by exporting/importing models from e.g. Ansys to Abaqus, that had more than just a volume mesh. I mean stuff like surface based constraints, constraint equations, matrix elements, joint elements, MPC elements...
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
The link is forum2: Aircraft engineering/viewtopic.php?id=11033" target="_blank">http://www.code-aster.org/forum2: Aircraft engineering/viewtopic.php?id=...
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
http://femml.sourceforge.net/
Don't know if any of the bigger commercial FE-codes support it though.
/PB
RE: Universal FE format
Cheers
Greg Locock
New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?
RE: Universal FE format
The link posted by petb is what I was loking for. Nevertheless the website also describes the issues they have in making FEMML a standard. This is why FEMML specifications are by far not complete. But I think FEMML is a good starting point.
The link posted by Greg is also very interesting. I found the complete description of the UFF here: http://www.sdrl.uc.edu/universal-file-formats-for-.... This format is less suitable for FEM. It is a format developed for modal testing data. For example it ignores the nodal coordinate systems when defining nodes (only positions are defined). Another missing point is the material definition.
I think there is a need for a fresh development of an universal file format for FEM. If this is going to work it is also has to address data mapping problems between the main FE software formats.
A very good example is the Ansys Matrix element. It can be used for defining a general stiffness element with two nodes and six DOF at each node. If I want to map such an element to Abaqus I have a problem: there is no such element in Abaqus. So the matrix element has to be mapped to six different spring elements, one for each DOF. As far as I know there is no commercial Software that can solve this isue (take ANSA or HYPERMESH).
I think neutral or universal file formats for FEM must be more intelligent than simply storring some data in data sets. The format mut be more explicit an help me easy solve the mapping problems.
Any thoughts on that?
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
Any software reading the format would have to detect features it doesn't support and can't convert then perhaps warn the user which might become quite excessive. This is distinct from many other interchange formats where a program reading the file can ignore whatever information it doesn't know how to handle. Since every FEA software has its own unique set of features, you'd likely often be encountering these problems all the time. Some might not be obviously a problem and require the user to inspect it to make sure, for example, some shell elements have drilling DOFs while others don't. If you transfer a file with the former to a software that only supports the latter, it might work perfectly well or it might give slightly worse results, or it might be entirely unsolvable (underconstrained). Some programs have special element formulations that others don't. To what extend can these be ignored without causing results to go bad?
Another type of problem would be the different levels of abstraction that are used for the same features. For example, you can impose a prescribed displacement on a node, or of some other "entity" that has the effect of prescribing the displacements of all the nodes in it. Does the interchange format use the lowest level representation (nodes) or a higher one (faces/node sets/etc)? If its the lower, then many models would become very bloated after converting. If it's the higher then there would be less compatibility between software. Perhaps it would need to duplicate the information in several different forms so the software reading it can choose whatever the highest level form it supports.
RE: Universal FE format
The conversion problems enumerated by you line-up with those written by me. Probably XML is not the solution of all problems. Perhaps a rule based expert system (see Wikipedia) could solve those problems. An expert system need a knowledge base in order to solve problems or find answers to questions such as "how to convert this element from Ansys to Abaqus?".
I don't think we need the software vendors to help creating an universal format. Not for defining the format specification. They are important when it comes to support the format.
Meanwhile I truely think that an open source project could solve the problem.
The Big question: Who ould like to participate? The project needs some experts in different software packages such as Ansys, Abaqus, Nastran etc. I am offering my self for Ansys :)
Best regards
Alex
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
TTFN

FAQ731-376: Eng-Tips.com Forum Policies
Need help writing a question or understanding a reply? forum1529: Translation Assistance for Engineers
RE: Universal FE format
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
Cheers
Greg Locock
New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?
RE: Universal FE format
So uses include:
- Checking results in other programs
- Sharing models
- Using the modeller from one program with the solver from another. Often a good modeller and powerful solver don't appear in the same program.
FEA feature chart http://feacompare.com
RE: Universal FE format
Nice to know that you would contribute to such an project.
The thing with the expert system is also for me not completely clear. But it seems to be a good solution. Why I think that?
An expert system consists of two things:
1) A knowledge base
2) A logical machine, that can answer questions regarding the knowledge base.
The first thing - the knowledge base - is needed in order to store all the needed information about element type and material model definition of each specific FEA software.
The second thing - the logical machine - can answer typical questions related to a format conversion task such as: "If a have a structural volume element with quadratic shape function in Ansys, what element type is equivalent in Abaqus?"
One nice thing about expert systems is: It also works if there is no 1-to-1 mapping from one software to the other.
But I have to do more research on that in order to be sure what the best approach would be. Any other ideas are very welcome.
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
A few thoughts on the subject.
If I had to work with several different solvers I would use a pre/post solution designed to do that. I rarely encounter the problem but in my experience, the bulk data files usually works. It is often a huge amount of data, but fairly simple data like node coordinates and element connections.
I think the problem comes from load or constraints associated to geometry. Simply because different software have different approaches internally. A concentrated load on a node, simple. A pressure on a plate element, also simple. A pressure on a surface associated to several plates, how do you describe that to fit the requirements of "everybody".
I think it would be an interesting project but, on the other hand, I can't see any big driving force in the industry.
But going back to the original statement. Universal formats in the CAD world.
I read an article recently where this was tested. Model the plate on one software, the bolts in another and the washers in a third and so on. Didn't work out.
Sure, you could see a figure of a solid that looked like a bolt but the intelligence was not there. The bolt was a "dead" and not a bolt so the material lists and specifications functionality was useless.
I have colleagues who work with this on a daily basis. Playing with formats like ifc, step, iges, etc etc. It works but I would not say that the geometry universal format is solved. You can "see" the object and do a collision test. But nobody has a complete model with all the information for a structure and the equipment.
I don't want to be discouraging, but be realistic. In a FEM format you need the geometry and the object "intelligence".
But I wish you luck. You may not solve it entirely but a partial solution can also be valuable.
To use an old cliche. Rome was not built in a day either
Thomas
RE: Universal FE format
I have also worked with two commercial pre/post software (HyperMesh and Ansa) and you are wright: Simple models consisting of solid or shell elements are normally no problem. But I have to problems with that:
1) If I only have simple models I don't want to pay that amount of money for another software license that just converts nodes and element formats.
2) HyperMesh and Ansa and I suppose others always need time (1 release at least) in order to update to new element definitions
Further more: I work with FE models that are more than just volume or surface meshes. I have plenty of discrete springs and dampers, surface based constraints (contact with one target pilot node) and beam elements. I always have problems exporting that kind of models.
You are wright about CAD universal formats: They can't convert all the data from a native CAD format. I'm aware about that. If I think more about that I can reformulate my original statement: CAD conversion works because everybody supports that universal format. I don't have to buy onother software just in order to export from SolidWorks to Creo (ProEngineer).
So let us develop an open source converter for finite element models, that:
1) realy works
2) is always up to date
3) does not cost a thing
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
What I meant was that the data based on the mesh can usually be handled. In my experience the data based on geometry is more difficult. On the other hand, I usually don't move models between different software so for me this is usually not an issue.
One question though, does the software you are looking for exist today? You mentioned price and "does not cost a thing". Is price or functionality the primary concern?
As I understand your comment about cad, you mean that they at least try. If that is what you mean I agree, they do. If they succseed or not is another story
In this discussion I can't help to thing of a discussion I had with a software vendor some years ago. It was at a seminar where they proudly presented one of the softwares new features. They wera able to read and convert one of their competitors data files into their own software.
When I asked if they could also export data from their software into the other one their market manager looked at le like if I was stupid. "What would be the point of that function?".
From his point of view, import meant that they would take over and "own" the information and secure their own sales. Export meant sharing and he was not interested in that at all. This was not a vendor of any real importance but the filosophy struck me as strange.
But it will be interesting to see if you make any progress. Maybe we'll see someting in the future.
Good Luck
Thomas
RE: Universal FE format
Of course actually being able to move to a different program and continue working on the same models would be ideal but might be something to give lower priority to. MeshParts, is this your goal?
Expert systems feel more deterministic than other types of AI but anything fuzzy is going to be a bit worrying for this job. Hopefully it would be able to alert the user to any changes in physical meaning while also providing a "best guess" conversion.
FEA software feature chart http://feacompare.com
RE: Universal FE format
the goal of the universal FE file format is not primary to maintain the geometry-FE associativity. Although that could also be implemented in the latter stage of development.
Meanwhile after talking with an programming and open source expert I think that XML, XSLT and XPATH is the simplest way to start developing an open source FE file format. Simpy google XSLT to get an idea bout what I mean. Expert systems are nice but somehow the programming languages such as Prolog are very old and finding people that can work with Prolog is very hard.
But that's another story. The really first starting point would be to provide an platform for the FE community that enables us to work together (collaborative) on a very general classification of the common FE data. I'm thinking about a simple web site that stores FE knowledge of different FE software in a structured (tree, graph) way. The web site can be edited by everybody working on the project. Similar to Wikipedia but concentrated on FEM.
Now this online collaborative database could be XML based. It is the basis for the universal file format. Actually it is the universal file format. Pretty simple.
Converting from an commercial file format to this XML database or from the XML database to an commercial file format is done by programs written in XSLT.
The complicated task will be to feed the XML data base with data and making sure the data base is well structured. But that will be the task of many co-workers with specialized knowledge from different commercial software packages.
Another nice effect of this work will be that comparison of commercial and open source FE software will be possible on a very detailed an technical level.
So far to the new ideas that came to me during the last days. I think we should keep this discussion alive as long as possible and needed. On the other hand I hope I will be able to provide soon something, wherewith we can really start to do something practical.
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
really?
Cheers
Greg Locock
New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?
RE: Universal FE format
I guess from your short post, that you don't think XML is a viable solution.
Could you please elaborate?
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
I'd be surprised if XSLT would be capable of doing all the complicated things the conversion might require, for example, changing a spring into a stiffness matrix for programs that don't have spring elements. I guess it would have to do several steps: From program A's native format to a format-specific XML, from the format-specific XML to the universal XML, then the same in reverse to eventually end up in program B's native format. Personally I'd prefer to just build a collection of individual programs that each convert between the universal format and a native format. They could use XSLT or any other method the authors prefer. These could be consolidated into a convenient tool as a lower priority project.
This could really be a fantastic thing. Those times I've tried to compare results with different programs have meant days of work so usually I just don't.
FEA software feature chart http://feacompare.com
RE: Universal FE format
Cheers
Greg Locock
New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?
RE: Universal FE format
okay, the problem with the file size is known to me too.
The issues you named about readability and complexity. I think I understand what you mean, after I took a look at following example from MatML:
http://www.matml.org/downloads/MatML3e1.xml
But why is robustness an issue?
@MacED: Good point with JSON. I like the JSON format.
But no matter how the universal FE format is represented, the starting point must be an universal FE knowledge data base, that can be edited by us. For example, the structure of the data base could look like that (written in JSON format):
{
"FE": {
"Node": {
"ID",
"Coordinates": [x, y, z],
"CoordinateSystemByID": ID,
"CoordinateSystemByEulerAngles": [xy yz zx]
}
"Element": {
"ID"
"ElementTypeID"
"MaterialID",
"GeometricPropertyID"
}
"ElementType": {
"Dimension": {
"3D": {
"Geometry": {
"Point",
"Line",
"Area",
"Volume"
}
}
"2D": {
"Geometry": {
}
}
}
"Physics": {
"Strucutral",
"Fluid"
}
"Midnodes": "1"
}
"CoordinateSystem": {
"ID": ID,
"EulerAngles": [xy yz zx]
}
}
}
This is just a quick example, that I wrote in few minutes. I think there are some logical errors in the structure. For example, I don't know how to specify in JSON that the value of a property "Geometry" can have one of the values Point, Line, Area, Volume.
But the idea matters. Perhaps now is more clear what the universal FE data base should be in my opinion. You can see that the programming language is not that important. The structure is.
So that's why I'm wondering what collaborative tools are there in order to create and maintain that in an collaborative manner.
RE: Universal FE format
Cheers
Greg Locock
New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?
RE: Universal FE format
Perhaps I shoul make this point: The FE knowledge data base is one thing, and the format in which a specific FE model is saved is another thing. The FE model is just an instance of the knowledge data base and can be formated in any format thinkable.
JSON with Javascript and XML with XSLT have both the advantage that the code can directly be interpreted by the browser. Even if we don't use JSON or XML, the FE knowledge database must appear in the browser as a structured tree or graph. So what is the best way to do that?
Sorry for the bad formating of the JSON code in my previous post. Here is it again:
CODE
{ "FE": { "Node": { "ID", "Coordinates": [x, y, z], "CoordinateSystemByID": ID, "CoordinateSystemByEulerAngles": [xy yz zx] } "Element": { "ID" "ElementTypeID" "MaterialID", "GeometricPropertyID" } "ElementType": { "Dimension": { "3D": { "Geometry": { "Point", "Line", "Area", "Volume" } } "2D": { "Geometry": { } } } "Physics": { "Strucutral", "Fluid" } "Midnodes": "1" } "CoordinateSystem": { "ID": ID, "EulerAngles": [xy yz zx] } } }MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
A few things that might be difficult. Any thoughts?:
FEA software feature chart http://feacompare.com
RE: Universal FE format
Specifying units is a good point. For me this just another property in JSON or XML. The knowledge database can also specify how to convert between them.
I don't really understand what MacEd meand with point 4 (load steps)
Input scripts like Ansys APDL or in Abaqus JavaScript are not part of the universal file format and must be be interpreted. Ansys can write pure CDB-Format (meaning no higher level APDL commands). Also Abaqus has its own file format, that also does not include any JavaScript commands.
I must ask again: Are there any tools that can allow us to start building the knowledge data base? The best thing would be a collaborative tool.
MESHPARTS
Tuning Your Simulation
http://www.meshparts.de
RE: Universal FE format
I'm probably biased in having that idea just because I don't know any better way. When your only tool is a hammer ...
I'm wary of something so advanced that people can't begin to contribute to it without learning a lot. I think it should be accessible to an academic who just wants to make his single-purpose software accept input files made with an existing preprocessor.
My point 4 about load steps is perhaps not a major difficulty. Just that some software allows a sequence of load steps that not not only have different loads, but also different kinds of solver (buckling/linear/nonlinear/etc) and different meshes. The converter would need the ability to represent changes in almost any feature of the model for each load step, environment, configuration, load case, or whatever it's called, as well as possibly taking solution values from one step and using them as input to subsequent steps. That gets more like scripting which I agree should be out of scope.
FEA software feature chart http://feacompare.com
RE: Universal FE format
If your focus is a one-time import of a file a standard may be the only seamless option. However if the focus is on managing re-work over many revisions of the same part across formats their is an approach that can be used by the receiving application to make any data look like a standard. For later revisions just protecting the identifiers can achieve most of what you are looking for in a standard.