Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

Register Log in
  • Congratulations waross on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Universal FE format 3

Status
Not open for further replies.
meshparts

meshparts

Mechanical
Feb 17, 2005
490
DE
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


MESHPARTS
Tuning Your Simulation
 
Replies continue below

Recommended for you

Sort by date Sort by votes
Thank you Greg, "neutral" sounds better than "universal".

I have done some research on UNV but didn't found any documentation. Instead I found a thread ( 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
 
Upvote 0 Downvote
Thank you very much for these links.

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: 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
 
Upvote 0 Downvote
I had a look at FEMML years ago but it didn't have enough specific details to get anywhere. It was also started in the heyday of XML which can be horribly inefficient for large data sets. I think a project like this needs participation from several FEA vendors, and they're probably all comfortable with their own lock-in. I wonder why at least the open source projects don't support each other's formats. I notice Calculix uses the ABAQUS format, but it's still a proprietary format so it might have some kind of IP protection.

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.

 
Upvote 0 Downvote
I agree with you MacEd: There are lots of features, that are software specific. But still, most of the times formats could be converted with success, ignoring some very fine differences.

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
 
Upvote 0 Downvote
I just don't see a real need for that. While there are ample reasons for propagating CAD files, particularly between buyer/seller or members of the same team. I don't really see much of a need for sharing FEA input files, other than possibly comparing results. But, that's not going to be a routine thing, unlike sharing CAD files.

TTFN
faq731-376
7ofakss

Need help writing a question or understanding a reply? forum1529
 
Upvote 0 Downvote
Why not? For example: I create my models with Ansys and my partner/customer would like to have that model in order to perform the solution and postprocessing by himself. The only problem: the customer/parter works with Abaqus... Having an universal/neutral format would solve so many problems, make FEA so much barrier-free.



MESHPARTS
Tuning Your Simulation
 
Upvote 0 Downvote
One quick check for funny answers would be to switch solvers. Admittedly that implies integrity of the open source file format, but at least if it runs on both with the same files with the same result it shows it is a modelling error.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376
 
Upvote 0 Downvote
Perhaps it could be created as an independent program to convert files with. Then there's no need for buy-in from any vendors. If it does need to be incorporated into other software, it should be fairly simple to do, either being programmed in, or a library with a permissive open source license. Look at the wild success of the STL format. It's nothing more than a list of triangles but nearly every meshing program supports it. I'd be willing to contribute what I can, which is mostly programming and general awareness of the ugliness of this problem. Expert system sounds interesting but I don't quite see how it would work. A single internal representation that it converts to/from using rules? Or many rules to convert between each pair of formats?

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
 
Upvote 0 Downvote
Thank you MacEd for the post. It gives a very good summary of the reasons, why an universal FE format is needed.

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
 
Upvote 0 Downvote
Hi

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
 
Upvote 0 Downvote
Hi Thomas,

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
 
Upvote 0 Downvote
Hi meshparts

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

 
Upvote 0 Downvote
This high level data about geometry won't be necessary in some of the use cases. Imagine you create a model using an integrated CAD FEA program, with tightly integrated geometry, parts, coordinate systems, material definitions, etc. then each time you solve it, you could put it through the converter into a simple "dead" format, where the surface loads are applied to the elements, etc. Even that level of compatibility still doesn't exist AFAIK.

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
 
Upvote 0 Downvote
Hi MacEd and ThomasH

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
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

Jb2024
  • Locked
  • Question
FE modelling of three-edge supported plate under simply-support 1
Replies
11
Views
60
jhardy1
jhardy1
struclearner
  • Locked
  • Question
G Loads for Half Symmetric FE Model
Replies
5
Views
29
Denial
Denial
Searc
  • Locked
  • Question
Choosing FE Simulation Type for Dynamics and Impact/Force Data into FE 1
Replies
7
Views
53
IceBreakerSours
IceBreakerSours
uzi210
  • Locked
  • Question
FEA results verification
Replies
8
Views
87
Stress_Eng
Stress_Eng
reutov_tv
  • Locked
  • Question
Lighting mounted on a pole in Catia FEM
Replies
5
Views
42
rb1957
rb1957

Part and Inventory Search

Sponsor

Back
Top