Current state of the project

[CsatiZoltan]

I see that the latest commit is from September 2021, setting the version to 0.2.
According to the plans, the in-situ components and the visualization will come in later releases.
Are there any plans to continue this project?

[v-dobrev]

Which of the planned additions is of interest to you?

If you are interested in visualization, there is initial support for FMS in VisIt: https://visit.llnl.gov.

Are you are interested in contributing or collaborating on some of the planned features?

The near future plan is first to extend the data structures to handle inter-processor connectivities, and also, to extend the file I/O to save and read this data -- in other words, to implement parallel data formats.

[CsatiZoltan]

I am looking for a mesh format that can represent high-order solutions of various kinds:

• discontinous Galerkin spectral element method, where the node distribution is non-uniform on the reference element
• spectral difference method, where the nodes are not Lobatto type, so the geometry of the element is decoupled from the function approximation
• possibly other discretization methods that may arise in the future

Based on this mesh format, I have the following requirements (or rather a wish-list).

1. Ideally, the mesh format would be flexible enough so that I can define the Lagrange basis on custom node distributions (equidistant, Gauss-Legendre, Gauss-Lobatto, etc.). This would allow me to avoid interpolation to a fixed basis (e.g. the equidistant node distribution of VTK Lagrange cells). It would be a plus if the node ordering could be defined so that I could use the ordering convention of the simulation mesh. These two features would guarantee that I can move from the simulation mesh (or the lack of a "true" mesh, as in the spectral difference method) to the visualization mesh without creating new data (see item 3).
2. Transfer the solution coming from the solver to a visualization mesh data structure in-memory: I/O must be avoided due to the huge problem sizes we deal with (that is why I am interested in the upcoming in-situ capabilities of FMS).
3. During the solution transfer of the previous point, I want to avoid making copies if possible: i.e. the visualization data structure can accept pointers to the memory address of the solution of the simulation.
4. The mesh format should support common operations (slicing, adaptive subdivision of cells for the sake of visualization, etc.), or at least make it simple to implement them.
5. In-memory interoperability with conventional VTK cells or high-order VTK Lagrange cells. This is useful because VTK/ParaView has tons of useful filters.
6. Distributed parallelism due to the large problem sizes we work on.

I have been investigating several projects, but each has certain drawbacks, which enforced me continue searching for new ones:

• Conduit
  Actively maintained, has integrations with mature projects (ParaView Catalyst, MFEM, Ascent, VisIt, etc.). However, its existing mesh data structures (blueprints) are not flexible enough to be used with our high-order meshes.
• MFEM
  While MFEM supports high-order meshes, GLVis cannot handle mixed VTK Lagrange meshes. GLVis is nice for visualizing fields, but I also need various processing pipelines (making slices, extracting isocontours, etc.) for which I either use a dedicated tool (e.g. VTK/ParaView) or use our in-house processing tools. In other words, if I adopt MFEM's high-order mesh format, I must stick to GLVis. This means that all the desired processing algorithms (slices, etc.) must be reimplemented, which is a lot of work.
• FMS
  Actually, I found this library based on a GLVis issue. Until now, I don't know whether FMS could be adapted to my needs listed above.

Concerning the collaboration, I need to discuss it with my employer whether he allows me to allocate time on working on it. First, I must carefully select a framework (FMS, MFEM format, or something else that you are aware of) that has the future potential:

• providing help to me if I have a question
• actively maintained

[v-dobrev]

Hi @CsatiZoltan,

Based on your wish-list, I don't know a library that supports all the points. And, certainly, FMS lacks support for some of these features: 2 and 3 depend a lot on the format used by the solver that provides the data and if it is compatible with FMS (this will probably be a problem for most mesh libraries); and for 4 and 5 there is currently no support.

Ultimately, the goal for FMS is to provide means for connecting the various components of a simulation pipeline: mesh generation and manipulation libraries, discretization and solver libraries, visualization libraries, etc. Also, the idea for the FMS query component is to provide functionality for interpreting the data (e.g. evaluation of values and gradients of the fields at points) from visualization/post-processing libraries. However, developing these features is still in the future.

From what I know, at this time, one suitable choice for you may be to use Conduit blueprint with input coming from MFEM (this is supported by Conduit without deep-copying data). Then from Conduit, the data can be used directly in Ascent for in-situ visualization. In the current state, there will be limitations with respect to your wish-list, however, I think there is a path forward for adding missing features.

[eliasboegel]

I'm interested in this too, for similar purposes (DG-SEM solutions). I'm wondering about the following:

1. Is the FMS format in active use with any other project? As far as I can tell, none of even the CEED projects use FMS as the primary format. Are there any? I'm also wondering about the reason this has not really been adopted within CEED, e. g. MFEM/GLVis.
2. I see that the last commit was in Sept 2021. Are there any concrete plans to continue development and possibly adopt FMS as the primary format for any major project?