Currently, some applications parse the list of expected Myna output files in the input file to determine which cases to run.
For example:
|
def parse_mynafile_path_to_dict(self, mynafile): |
|
"""Parses the path of the output Myna file into a dictionary containing the |
|
build, part, and layer names as strings and the case_dir and mynafile as Path |
|
objects. |
|
The path to the Myna file is expected to be in the format: |
|
`working_dir/build/part/layer/stepname/mynafile` |
|
""" |
|
dir_parts = Path(mynafile).parent.parts |
|
case_dict = { |
|
"build": dir_parts[-4], |
|
"part": dir_parts[-3], |
|
"layer": dir_parts[-2], |
|
"stepname": dir_parts[-1], |
|
"case_dir": Path(mynafile).parent, |
|
"mynafile": Path(mynafile), |
|
} |
Instead of each application handling this separately, a centralized method for loading the case specifications (parts, layers, regions, etc.) should be defined in the Myna core functionality to have self-consistent behavior, avoid needing to validate paths from settings file, and reduce code duplication.
Currently, some applications parse the list of expected Myna output files in the input file to determine which cases to run.
For example:
Myna/src/myna/application/adamantine/temperature_part_pvd/app.py
Lines 51 to 66 in 04c35ab
Instead of each application handling this separately, a centralized method for loading the case specifications (parts, layers, regions, etc.) should be defined in the Myna core functionality to have self-consistent behavior, avoid needing to validate paths from settings file, and reduce code duplication.