Input/Output for a PIC-based inhomogeneity strategy in walker
This page collects some ideas and requirements for software design of file-based input and output of large field data in Walker, using a particle-in-cell (PIC) strategy. For more details, advantages and disadvantages, on PIC-, and SPH-based inhomogeneity strategies, see the page on Strategies for inhomogeneous problems in walker.
An algorithm based on a PIC-based inhomogeneity strategy in walker would require an Eulerian mesh. At this time, the plan is to keep it simple, and only support a Cartesian mesh for structured grid-applications and pure-tetrahedron unstructured meshes. Examples of supported mesh generators:
- Gmsh, http:/
/ www.geuz.org/ gmsh
- Netgen, https:/
/ sourceforge.net/ projects/ netgen-mesher
- Cubit, https:/
- HyperMesh, http:/
/ www.altairhyperworks.com/ product/ HyperMesh
- HEXPRESS/Hybrid, https:/
/ www.numeca.com/ product/ hexpresshybrid
- Any other generator that outputs the input formats supported by a MeshConv reader
See the page on MeshConv.
- Checkpoint-Restart (particle and/or field, should be combined with existing support in Charm++)
- Diagnostics (small text of integral data)
- Probability density functions (PDF), joint PDFs, marginal PDFs, conditional PDFs, etc.
- New time step overwrites existing file
- Multiple files for multiple time step data
- Store time evolution in single file
- Fields I/O:
- For large binary fields I/O we use ExodusII HDF5 (single file and multiple files), and Quinoa's native mesh format could be based on an ADIOS schema and .bp format.
- For Exodus I/O we use the Seacas/ExodusII library in Trilinos.
- Particles I/O:
- For large binary particle I/O we have interfaced with H5Part, a particle-centric I/O format based on HDF5.
- We may also develop a native particles format based on an ADIOS schema and .bp format.
- Fields + Particles I/O:
- For large binary field + particle I/O (same or separate file) a potential solution is to use the ADIOS library, which facilitates both file-based and stream-based I/O.
- The stream-based ADIOS I/O API can then be used for both file-based and stream-based I/O, the latter facilitating staging and in-situ visualization (and debugging), e.g., via DataSpaces, NSSI, DataTap, DIMES, FlexPath, and/or ParaView/Catalyst.
- We could develop our native fields + particles format based on ADIOS schema and .bp format.
- Using an ADIOS visualization schema (or pulling our own) we could write our own ParaView reader plugin.