Currently the configuration for CMAQ is specified inside setupCMAQinputs.py. This is very inflexible to supporting different targets (nci/docker) which differ substantially.
We want to be able to maintain support for NCI for both CMAQ and WRF run scripts. The configuration is currently unstructured (i.e. there isn't a schema) which can lead to bugs where the NCI/Docker configurations diverge in schema. Some validation is performed in the WRF scripts and this functionality should be available for the new system.
The configuration management for WRF is currently performed using the "config" file. There is some code at the top of the file that supports parameter expansion using other configuration values (perhaps useful, but not a hard requirement - I'm not sure how extensively it is used). This config file uses non-standard JSON as the format to store results. The config file acts as the "documentation".
[x] Implement a module to provide consistent configuration across both tools
[x] Add to setup_for_cmaq
[x] Add to setup_for_wrf
[x] Add NCI specific configuration
[x] Update test to capture both NCI/docker config
Additional context
This should probably be built on top of #14 (clean-up branch) which has migrated to use a src directory and split out the WRF vs CMAQ code.
We may need to split what is provided as semi-static target-specific configuration vs run configuration (e.g. the run start/end times is decoupled from the paths to the WRF executable in the docker container). This problem is out of scope of this issue
The motivation
Currently the configuration for CMAQ is specified inside
setupCMAQinputs.py
. This is very inflexible to supporting different targets (nci/docker) which differ substantially.We want to be able to maintain support for NCI for both CMAQ and WRF run scripts. The configuration is currently unstructured (i.e. there isn't a schema) which can lead to bugs where the NCI/Docker configurations diverge in schema. Some validation is performed in the WRF scripts and this functionality should be available for the new system.
The configuration management for WRF is currently performed using the "config" file. There is some code at the top of the file that supports parameter expansion using other configuration values (perhaps useful, but not a hard requirement - I'm not sure how extensively it is used). This config file uses non-standard JSON as the format to store results. The config file acts as the "documentation".
Definition of "done"
Additional context
This should probably be built on top of #14 (clean-up branch) which has migrated to use a
src
directory and split out the WRF vs CMAQ code.We may need to split what is provided as semi-static target-specific configuration vs run configuration (e.g. the run start/end times is decoupled from the paths to the WRF executable in the docker container). This problem is out of scope of this issue