MFCInputFile refactor & input file-defined tests

[henryleberre]

Description

See title. Upstream from Chemfc.

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

Scope

• This PR comprises a set of related changes with a common goal

How Has This Been Tested?

• Test Suite

Checklist

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

[sbryngelson]

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]

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]

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

[sbryngelson]

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

[sbryngelson]

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]

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".