Post-process visualization

[dreamer2368]

tps now supports a post-process visualization mode, which generates paraview files from a list of solution restart files.

Basic command for this visualization mode is tps -visual -run your_input_file.ini.

When running in the visualization mode, it requires the following input options in the input file:

[post-process/visualization]
prefix = mms.ternary_2d
start-iter = 100 
end-iter = 500 
frequency = 100

tps will try to access to the files names as "%s-%08d.h5" % (prefix, iter), with iter iterating from start-iter to end-iter at the frequency of frequency. Note that tps currently uses a fixed filename for the restart file: "restart_%s.sol.h5" % config.outputFile, where config.outputFile is read from the input file with option io/outdirBase. Because tps does not specify the time-step in the filename, and also because tps will overwrite every time it saves the restart file, the users must manually rename the restart files with the time-step specified whenever they are created, in order to use this post-process visualization mode. Note that the iter specified in the restart-file names do not have to correspond the actual time-step of the solution.

The I/O mechanism still follows the options specified as io/restartMode in the input file. If it is either "singleFileRead" or "singleFileReadWrite", a single solution file will be required at each iter, however many processors tps is run on. If it is "standard", the number of restart files at each iter must match the number of processors, and must respect the format "%s-%08d.%d.h5" % (prefix, iter, rank) with mpi rank.

For each restart file, it computes and saves the following auxiliary variables:

• Species primitives: mole/mass fraction and number density
• Transport properties listed in FluxTrns, SrcTrns, and SpeciesTrns.
• Diffusion velocity of each species
• Reaction rates with indexes as listed in the input file

TODO:

• Currently only cpu path is implemented for visualization mode. However, most part of it is written in a gpu-compatible way, and only the loop in M2ulPhyS::updateVisualizationVariables() will need a minor revision of adding a gpu-loop wrapper with #ifdef _GPU_.
• In the future, it will be good if the user can specify what variables to be visualized.