FEA Inter-operability

I ever worked on some project - translating from FEM format A to format B directly. This approach was OK for that particular project. However if there are multiple formats (say A, B, C, D...), the direct translation approach would be very inefficient - as the number of translators would be too large (A<->B, A<->C , B<->C , ...).

Ideally using a neutral format X would greatly simplify the translation work, as for any FEM format we would only need to implement two translators (from-X and into-X). I expect this will work well if we only translate some very general contents: mesh, grids etc. However if we want to translate more complicated content (e.g. nonlinear material properties, contact definition etc), it would require the 'neutral format' to be flexible enough to cover all such definitions.

After some thoughts, I feel we don't have to have a format at all, but we could have some universal data structural and APIs in the parser/translator code. For each FEM format, we could implement a 'native' reader and writer, plus APIs for query any information - no need to worry about how to translate with other formats. Then on top of such 'native' data structure and APIs, we build a wrapper (or called adapter in the programming term), which provides common/universal APIs to query model information (even APIs for manipulating/editing the model).

I feel the API approach is more flexible than 'neutral format' approach. As I mentioned, the neutral format has to be very very flexible to cover all definitions. I am afraid the design would never be perfect, and we would have to 'patch' the format design whenever we found any definition is not well covered (as some commercial FEM codes are doing today). However with API approach, we could be more flexible at the code level - the data structural could be adjusted relatively easily, at the meanwhile, we could keep the public APIs quite stable.

Another advantage with the API approach is that, once we have some common/universal APIs, besides translation, many algorithms could be reused - built on top of such common APIs. E.g. if someone implements an algorithm for optimizing the mesh quality, it could be applied to any FEM format.

Well, I might have moved too far away from the original translation topic. Anyway, the API approach is what I personally feel more promising, which I am actually working on. I hope I would have something to share soon.

In case if anybody is still interested in this discussion, here are some updates.

1. After some study and experiments, I found JSON -like format is quite promising as a 'netural' format for FEA definition.

Some advantages with JSON:

- ASCII format with simple syntax rules, open standard, and human-readable;
- Flexible and expressive (support array-like and map-like data structures);
- Very good support from computer world (supported by most programming languages, and friendly to NoSQL database like MongoDB);

Interestingly, I found OpenForm (a famous open source CFD code) happens to choose a format very similar as JSON.
( OpenForm's format )

Well, if JSON format had been invented before OpenForm invented its own format, the OpenForm team might have chosen JSON directly.


2. A FEA model translator/converter is not a small project. Here is a blog explaining the reasons:

www.simhub.xyz/blog/an-online-finite-ele...onverter-translator/

This blog also introduced an online FEM model converter, which supports Nastran, Abaqus and Ansys formats for now.
www.simhub.xyz/apps/model_converter