Universal FE format 3

[meshparts]

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

http://www.meshparts.de

 

[meshparts]

Hi Greg,

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

 

[MacEd]

XML is a bit out of fashion now. Though I don't quite understand why. Maybe because it gets bloated, maybe because JSON is popular for web programming, or maybe because it's hard to whip up a quick program to read or generate it. Anyone can process CSV files easily with a spreadsheet or the basic tools of any programming language but XML needs a library and a whole new learning curve to parse it. This is especially troublesome to scientist types who're more familiar with CSV and writing parsing tools from scratch. Anyway, the details of the format are probably secondary to the nature of the information itself.

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

 

[GregLocock]

Yup for big, regularly formatted, datasets, xml inflates your file size, reduces human readability, and adds complexity and reduces robustness.



Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[meshparts]

Hi Greg and MacED,

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.

 

[GregLocock]

Syntax errors that break xml files are less obvious than those that break csv files, and so far as I am aware there are no general purpose xml editors that do much more than display the xml as text, often in no particularly readable form (enormously long lines etc). I don't know whether I have just been unlucky with xml, but that is my impression.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[meshparts]

Okay, I get it now. Thanks.

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:

{
   "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

 

[MacEd]

Something like that would be fantastic. Maybe we just need a rough plan then start coding converters and hone it as problems arise. I'd rather build it up from necessity than trying to allow for every possibility and ending up with something too hard to get your head around.

A few things that might be difficult. Any thoughts?:
[ol 1]
[li]Units - some software allows a different unit on every value, so it'll need to accommodate that but hopefully not use it when they're all the same.[/li]
[li]Units - there are thousands of them. One way to deal with it is like STEP and include the exponent of each base unit, for example acceleration would be length:1, time:-2. Then you just have to specify the base units. Very hard to read but it seems quite flexible without needing to make a standard list of thousands of special strings like "MegaPascal", etc.[/li]
[li]Units - converting between software that has them and units-agnostic software will create some difficulties for the user. Either manual intervention to specify units or just remembering what they should be.[/li]
[li]Load steps - all sorts of things can change in load steps, so these might include almost the whole model again within them.[/li]
[li]Input styles like ANSYS ADPL which are a sequence of instructions rather than a "snapshot" or static representation of a model and can do things that a static database couldn't represent.[/li]
[/ol]


FEA software feature chart

http://feacompare.com

 

[meshparts]

I'm very happy that other people, especially MacEd also like this idea good.

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

 

[MacEd]

I don't have much of an idea how to start building this unfortunately. The structure of the information is so complicated that I suspect that plain old programming might be the simplest way to represent it. Perhaps we could build a library of frequently needed conversion tools for transforming individual features - eg converters for spring <-> matrix, face pressure <-> node force, etc. that various file format converter programs (if they are programs) would use as needed.

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

 

[AnyCAD]

Improved integration & communication between formats would be great but one of the major challenges developing a standard is that it requires some support from the SENDING format. Either they need to write to the standard or at least provide some development support. The people making the sending application don't have much interest in helping data/customers LEAVE their product.
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.