MFCInputFile refactor & input file-defined tests

MFlowCode / MFC

Exascale simulation of multiphase/physics fluid dynamics

https://mflowcode.github.io

MIT License

132 stars 56 forks source link

MFCInputFile refactor & input file-defined tests #410

Closed henryleberre closed 1 month ago

henryleberre commented 1 month ago

Description

See title. Upstream from Chemfc.

Type of change

Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)

Scope

[x] This PR comprises a set of related changes with a common goal

How Has This Been Tested?

[x] Test Suite

Checklist

[x] I have added comments for the new code
[x] I added Doxygen docstrings to the new code
[x] I have made corresponding changes to the documentation (docs/)

sbryngelson commented 1 month ago

Can you describe in more detail what this does?

Also, for the input file tests, how does it get the goldenfile, again? Or does it just check that the case executes?

henryleberre commented 1 month ago

Apologies, here is a better description: There currently are many classes that represent different types or instances of MFC cases (e.g. one for its file and another for a test case). Some code that should have been in a base class wasn't. This is a refactor that makes the code nicer to use. I realized this was necessary when adding the ability to define a test case using an existing case file. Currently, we can only programmatically alter a case defined in code. For some feature (like chemistry), it could be very useful to run a validation example case for a few timesteps instead of heavily altering a base case configuration to test the same behavior.

To answer your question: The test suite generates a hash for each case using its trace (e.g. 7EFBCDAE). This behavior remains the same for these new kinds of test cases. It will therefore still generate a golden file in the tests/ folder.

henryleberre commented 1 month ago

@sbryngelson This PR is ready on my end. I am not sure if the Frontier runner is active.

sbryngelson commented 1 month ago

Frontier runner is back up but Frontier and other OLCF servers are going down for maintenance sometime today or tomorrow.

sbryngelson commented 1 month ago

To answer your question: The test suite generates a hash for each case using its trace (e.g. 7EFBCDAE). This behavior remains the same for these new kinds of test cases. It will therefore still generate a golden file in the tests/ folder.

I don't understand how this works. If there is no goldenfile stored already, then how will it generate one and test against it (in the same run) to make sure the solution is correct? The current workflow only works because we store goldenfiles in version control.

henryleberre commented 1 month ago

To answer your question: The test suite generates a hash for each case using its trace (e.g. 7EFBCDAE). This behavior remains the same for these new kinds of test cases. It will therefore still generate a golden file in the tests/ folder.

I don't understand how this works. If there is no goldenfile stored already, then how will it generate one and test against it (in the same run) to make sure the solution is correct? The current workflow only works because we store goldenfiles in version control.

Golden files are created just as they are now, in the tests/ folder. It just pulls the case dictionary, at run-time, from a case.py file you specify, instead of by programmatically altering a base test dictionnary. Since you define these types of cases in cases.py, we are able to generate a hash for it using its "trace name".