Reading in CMISS Data Using MeshData

    We are trying to recreate a CMISS example with varying field parameters in libMesh.  This page describes our strategy and progress.

Exporting Grid from CMISS into a LibMesh Format

Note that there are several mesh/data formats within libMesh but we are focusing on two of them: UNV and **XDA**.

Note that it is VERY difficult to find useful documentation on UNV (I-DEAS-UNIVERSAL) mesh file format. Many people on the internet have posted questions to mail lists about documentation and no one gives a response. Maybe that is why people would prefer not to use UNV. On the other hand, I had an easy time using it with libMesh - both reading in mesh and data.

What I've done so far is edited cm/source/fe26/EXGRID.f so that we can export the grid file (an exelem file) and the node file and then use two different scripts to create a mesh.xda and mesh.unv file. The new file is here

An example of a dot-com file for producing the necessary exelem/exnode files can be found here.

The following two commands allow you to create new xda and unv meshes from the exelem/exnode files:

      ./CreateXDAmesh.pl new.exnode new.exelem mynewmesh.xda 10

      ./CreateUNVmesh.pl new.exnode new.exelem mynewmesh.unv

See CreateXDA and CreateUNV for the two perl scripts.

Exporting Data (at Nodes) on Grid from CMISS into a LibMesh Format

There are two strategies that we are going for here. One is to use MeshData with the UNV file format. We are unable to use MeshData with xda (i.e., creating an xta file) because of the following reasons:

      The problem is in xdr_io.C, subroutine read_mesh.  In particular, look
      at lines 2099-2131, which is supposed to add foreign_ids to nodes.  This
      actually never happens which causes the code to crash when you try to
      read in data to those nodes.

      This never happens because mesh_data is null because it is supposed to
      be passed in as an argument but in the call to read_mesh (line 1924 or
      1947) mesh_data is not passed in.  Fixing this is not as easy as it
      looks.

      There is more to it if you want to investigate.  Try it for a simple
      example (ex12) and see what happens for you.  Hopefully I've made a
      mistake and I'm wrong.  I've also found this problem crops up with example 2
      if you read in an xda mesh and then try to export that mesh as unv.

The second strategy is to create auxiliary EquationSystems and read in vectors and solution variables into this EquationSystems variable. The advantage is that it provides interpolation. The disadvantage is that it is ugly and may produce too much overhead.

For both strategies we will get data from cmiss (for the time being). There are two ways that this can be done. One is to place data into an ipnode file and then export it onto the grid. This is not clean, obviously, but it is simple. Using a perl script we can create the necessary files for libMesh. Two is to use and ipmatc file and export with command fem export point;cell_type grid material offset 0, for example.

The following describes our approach within the context of MeshData/UNV and EquationSystems/XDA.

Using MeshData with UNV

• My strategy right now consists of two options.
  • The first is to use fem export point;NAME grid offset 0 where on my ipnode file I have placed field values (conductivities, etc.) that I want interpolated to grid points once fem update grid geometry is called. This works well but is limited. I have a script that I can use to convert the exnode file to a MeshData UNV file. See this example
  • The second is based on exporting cell material information. I define an ipcell file (currently based on a USER_FILE.f) and an ipmatc file. I can create integer values and real values at a group of grid points. This is much more flexible and probably preferable for now. I use the command fem export point;NAME grid material offset 0 to do this and (still need to do) have a script that converts to libMesh format. In the future, this will be effectively done with CellML for easier use with a wide variety of cell models. See this example
• I can read in a UNV data file created from cm and a perl script (CreateUNVdata.pl). For this approach I have created a simple diffusion problem that uses, e.g., varying diffusion coefficient.
• I can read in a UNV data file created from cm and a perl script (CreateUNVcell.pl). For this approach I have created a monodomain problem that uses the Aliev cell model (modified FHN model)

Using EquationSystems

• At the moment I've seen how to do it and it shouldn't be too hard.
• EquationSystems::write/read() supports input and output to xdr binary and xda ascii formats. (gzstream support is only implemented in unv and ucd formats).
  • How similar is the format of these Xda/r files to the mesh file format?
  • The file format appears to change depending on whether LibMesh is built with the preprocessor symbol ENABLE_INFINITE_ELEMENTS defined. See System::write/read().
• It may be possible to use System::write/read() and System::write/read_data() to enable I/O of only one System. See EquationSystems::write/read() for how these can be used.
  • Could derive a class from System (or change System) to add functionality for reading and writing subsets of variables or vectors. Does turning off read_header allow adding variables to an existing System?
• add_variable seems to provide only scalar variables (but many can be added).
• add_vector will provide another vector similar to the solution vector for all the variables, which can be interpolated with the same interpolation as the solution vector.