Refactor IO in `M2ulPhyS` #244

trevilo · 2024-01-31T15:08:28Z

A large portion of IO code currently lives in the M2ulPhyS class, making it impossible to reuse for other solvers. We need refactor this code to 1) extract the parts that are reusable into a more generic capability and 2) isolate the parts that are M2ulPhyS specific.

The text was updated successfully, but these errors were encountered:

On the path to making the IO capabilities more reusable, in this commit we extract 5 functions out of M2ulPhyS and into standalone functions. The refactored functions are write_soln_data read_partitioned_soln_data read_serialized_soln_data partitioning_file_hdf5 serialize_soln_for_write

This is an intermediate commit. The idea is to extract the most of the read and write functionality from M2ulPhyS::restart_files_hdf5 into separate functions. In the previous state the read and write code were intertwined, which made it difficult to understand. The eventual goal is to move the parts that are generic into IODataOrganizer (and related classes), in order to minimize the restart read/write code within M2ulPhyS, which should make it easier to reuse these capabilities for other Solver types down the road.

This involves 3 functions that now perform the bulk of the work. First, the (previously standalone) function serialize_soln_for_write is moved into the IOFamily class, as serializeForWrite. Second, two new functions (IODataOrganizer::write and IODataOrganizer::writeSerial) are introduced to handle writing field data that has been registered through the IODataOrganizer class. At the moment these functions are separate b/c they require different input data (i.e., writeSerial needs information, such as the partitioning array, that write does not). They could be unified, potentially by extending IODataOrganizer::initializeSerial to obtain this extra information rather than passing it directly to writeSerial. But, this refactor is left for later.

This is mostly analogous to the write support from the previous commit, with new read functions being added to IODataOrganizer. But, in addition we have to support the option to read data from a different order solution (to support restarting from lower order fields). This is facilitated by adding "aux" objects (FiniteElementCollection FiniteElementSpace, and ParGridFunction) to the IOFamily class. In the previous implementation, these were instantiated directly within the read function and were specific to the DG discretization used by M2ulPhyS. The new implementation should be generic (although that generality is not yet tested).

) The distinctions between write and writeSerial are small, so it is better to handle both cases through a single function, which we do now through IODataOrganizer::write. The IODataOrganizer::writeSerial function is no longer necessary and is therefore eliminated.

Refactor functions in IODataOrganizer so that capabilities previously distributed between read, readSerial, and readChangeOrder are all now handled by a single read function.

The logic in IODataOrganizer::read is hard to follow in big chunks, so move those big chunks into the IOFamily class, which is where they belong. Also, move IOVar vector into IOFamily, which simplifies the code slightly, and just makes more sense than storing the info in IODataOrganizer where we have to map from the family name to the variables.

Now the methods IOFamily::writePartitioned and IOFamily::writeSerial handle the data write, making the logic in IODataOrganizer::write easier to follow.

And rename to readDistributeSerializedVariable. This function needed the IOFamily info, so makes more sense as a class method.

To reduce duplicated code in size consistency checks. Also, some other minor cleaning up.

Plus a couple name changes to be a tiny bit more descriptive