By way of the following globally-scoped code within the definition of the shell subcommand, calling any subcommand under prognostic_run_diags causes network / authentication access to try and load grid data from our default vcm data catalog (even if we are not trying to use shell):
This is problematic on machines that do not have network access, e.g. nodes on HPC systems. As we've done in this context before, it is best to enable providing a path to a local custom catalog, which has entries that point to local rather than remote data.
Here the natural solution appears to be to add an optional catalog_path argument to the shell subcommand and State class constructor. When initializing the State we could then load the grid (once we know the catalog), rather than load the grid when initializing the module (making an assumption about the catalog).
By way of the following globally-scoped code within the definition of the
shellsubcommand, calling any subcommand underprognostic_run_diagscauses network / authentication access to try and load grid data from our defaultvcmdata catalog (even if we are not trying to useshell):https://github.com/ai2cm/fv3net/blob/cf4706703531eaa2f5b6a222547609820d6b9f7d/workflows/diagnostics/fv3net/diagnostics/prognostic_run/shell.py#L111-L113
This is problematic on machines that do not have network access, e.g. nodes on HPC systems. As we've done in this context before, it is best to enable providing a path to a local custom catalog, which has entries that point to local rather than remote data.
Here the natural solution appears to be to add an optional
catalog_pathargument to theshellsubcommand andStateclass constructor. When initializing theStatewe could then load the grid (once we know the catalog), rather than load the grid when initializing the module (making an assumption about the catalog).