OQ configuration from nzhsm-model

[chrisdicaprio]

Latest nzshm-model (0.13.0, currently in pre-release) supports defining the OpenQuake configuration as part of a Model object. We want to update runzi to use the new features of nzshm-model

Notes

• Do hazard first. disagg will be seperate ticket

Steps

• Currently reading a config from a file is not supported (OpenquakeConfig has no serialization / deserialization). Start by using default from nzshm-model
• remove iterate over parameters
• user defines location, vs30
• user defines sites with ss vs30s
• user defines IMTs, IMTLs
• helper funs to to serialize/deserialize OpenquakeConfig needed to pass as job argument (port to nzshm-model later)
• check if hazard config is complete before generating jobs

Future

• once helper funs are ported, allow user to define config in seperate file
• allow user to overwrite config parameters with master hazard input file?
• allow user to define params to iterate over in master hazard input file?

Questions

• What if the user wants to use a logic tree from a pre-defined model, but a different hazard config (or GMGM LT, etc.)? We should let the user ovewrite the default components of a model
• What if the user specifies a file for the sites rather than using a pre-set site name or list?
• how do we represent the model in the argument list passed to toshiAPI for the general task? Is it ok just to use model name and version? Do we need complete read of of logic trees and config?

Doing a lot of work to unpack, pack, and unpack the parameters from the master config. Better if we can get the task to handle most of that. Any parameters that are being broken up (e.g. SRM logic tree) or swept over can be passed as parameters in the job task and implicitly taken to over write what is in the config.

• The master config (MS) is a dict (from toml) and easily serialized/deserialized when passing to the hazard task
• A new SRM logic tree can be passed as an additional parameter (match the naming convention in the toml to overwrite whatever is there. will need to allow GMCM LT from a complete model and SRM seperatly)
• What if the user specifies SRM LT, GMCM LT, and HazardConfig as files in the MS?
  • store them as files in cloud w/ toshAPI. This is similar to how we used to do configs
  • serialise them and pass as job arguments. This is currently done with the LTs. What about the config? Advantage is we don't depend on cloud or toshiAPI

Be sure to pass any files specified by user:

• location lists
• gmcm logic tree
• hazard config

Scenarios

• model version only
• model version + any of (gmcm lt, srm_lt, hazard_config)
• gmcm_lt, srm_lt, hazard_config
• uniform vs30
• site specific vs30
• uniform vs30, z1.0, z2.25
• site specific vs30, z1.0, z2.25