.med file format

[sgrogan]

Hey everyone.

Can anyone explain the utility of the .med file format?

My understanding is that libmed(c) is/can be a dependency of SMESH (internal or external)

I'm not suggesting to remove this dependency, I would just like to understand how it is/will be utilized.

[bernd]

Yet another mesh file format.

If one works with med mesh format, he needs to be able to import and export med in FreeCAD to be able to work with FreeCAD. If one does not work with med, med is not needed.

I do not work with med. User vejmarie (he has not been seen for a while) works with med. He did the integration of med.

Would it help if we eould make it an optional depency ?

[kkremitzki]

Hey everyone.

Can anyone explain the utility of the .med file format?

My understanding is that libmed(c) is/can be a dependency of SMESH (internal or external)

I'm not suggesting to remove this dependency, I would just like to understand how it is/will be utilized.

MED is an optional dependency for SMESH and Gmsh both. The package (med-fichier is what it's called) needs a bit of work (and if you look at the history it has been getting a bit of work) because although it supports being built with cmake, it isn't currently, and thus the cmake files needed to get things working automatically are missing.

[sgrogan]

Would it help if we eould make it an optional depency ?

I guess that is what I am trying to figure out.
For the win builds we use libmed(c) (compiled using CMake ) + FreeCAD's internal SMESH, same for the PPA only we use the standard Ubuntu libmedc package.

For the conda builds @looo uses a newer "External SMESH" that does not support .med (I'm sure SMESH itself supports .med but the provided binaries do not)

I am trying to use @looo's work to make daily PY3/QT5 win builds. I had this working, then broke it, and now almost have it working again.

So my 2 interests are;
1) How much to worry about this support, at this time. I guess are any FEM users/developers using this?
2) What is the .med file's "claim to fame"? Google tells me it allows better exchange format between FEA/FEM softwares?

I didn't know of the optional dependency for Gmsh so thanks Kurt for the info.

[UR_]

"Summary of Software Using HDF5"

https://support.hdfgroup.org/products/h ... byType.htm

"Hot hundred" looks different

[looo]

Trevor Laughlin has annanced to work on med-file support for the next release of external smesh, which is maybe based on smesh8.4 sources. But I guess this won't happen very soon...

[joha2]

2) What is the .med file's "claim to fame"? Google tells me it allows better exchange format between FEA/FEM softwares?

ping pong

Sorry for the late response to this thread. In the last days I played around a bit with MED due to the discussion in https://forum.freecadweb.org/viewtopic.php?f=18&t=35480 (the goal for me was to see if it is possible to create a very large mesh with gmsh and then import it into FreeCAD via the MED file format, because UNV export and import is maybe slower due to its text file nature where you cannot parallelize the reading process which the underlying HDF5 format for MED is designed for). Seems indeed that MED comes from the dependency hell, but I would suggest not to get rid of it, because it seems to be a solution for mesh exchange (or GMSH <-> FreeCAD mesh transfer) for large meshs in a parallel manner. That is maybe also a small answer to srogan's "claim to fame".

Anyway, I did not manage to create a MED file with gmsh and read it back into FreeCAD maybe due to binary incompatibilities between the version with which gmsh was compiled and the one for FreeCAD. I also tried to compile a new libmed from the SALOME website (to link gmsh and maybe FreeCAD against it), but this did not work due to HDF5 library on my Linux Mint 18.3 which seems to be too old.

Unfortunately I have no solution for these dependency issues I don't know whether it is possible to find out the library version which FC was compiled against and then use a gmsh version where the MED support somehow "matches".

I think my response also does not help with your packaging/Py3/Qt5 problems, but I wanted to vote for continuing support for MED files.

Best wishes
Johannes

[vocx]

2) What is the .med file's "claim to fame"? Google tells me it allows better exchange format between FEA/FEM softwares?

I guess its claim to fame is that it

• is used by Salome,
• is based on HDF5.

Salome is an important platform for preprocessing and postprocessing simulation results, so they using MED gives recognition to the format.

HDF5 is a data format developed to store and organize large amounts of data. If you have ever worked in a laboratory capturing lots of data points (electrical voltages, radio signals, vibration information, etc.) you find yourself with the question of storing data either in text files, or in something like Matlab binary .mat files. It all depends on what your machines output as data. The HDF5 format is supposed to help you work with enormous amounts of data in a "better" way than you typically would do. When I was looking into this format, I remember reading that astronomers were using it to store radio signals from stars over the course of a year. That's massive data in the order of terabytes.

So, HDF5 intends to become sort of a standard for storing (and sharing) scientific information.

So, my conclusion is that MED intends to be the same, a standardized way to store mesh information, based on HDF5. If you are working on simple mechanical parts that you can mesh inside FreeCAD, you probably need "only" like a million finite elements. However, if you are going to be working in something extremely complex, that you need a supercomputer to mesh and solve, you probably are going to be working with several bajillion finite elements, so maybe this is where MED is useful, that is, for massive meshes.

[joha2]

If you are working on simple mechanical parts that you can mesh inside FreeCAD, you probably need "only" like a million finite elements. However, if you are going to be working in something extremely complex, that you need a supercomputer to mesh and solve, you probably are going to be working with several bajillion finite elements, so maybe this is where MED is useful, that is, for massive meshes.

@vocx, nice summary. Thank you!

Now the question for all of us is: How to continue with .MED format?

Best wishes
Johannes

[vocx]

Now the question for all of us is: How to continue with .MED format?

Best wishes
Johannes

How to continue what? Is support for MED not currently implemented? Does libmed not compile-link? Can FEM not read nor write in this format? By reading your other thread it is not clear to me what is missing and what needs to be done.

I checked the information on the FEM Workbench on the wiki, and it seems to me the meshes in FEM are already based on the MED format. That's kind of what Bernd wrote, or maybe he was just referring to the images. See FEM Element Types. The wiki points to this https://hammi.extra.cea.fr/static/MED/w ... ees.html#3.