-
Notifications
You must be signed in to change notification settings - Fork 3
Setting up a new model
All of the code specific to the model is stored in the directory "src/model_specific". To implement a new model, create a new directory in src/model_specific using the name of the model you want to add. Copy a set of files to use as a template, e.g. from the mom6 directory.
These files perform basic interfaces with the numerical model:
-
common_<modelname>.f90 :: contains all of the I/O for interfacing with the model restart and history/diagnostic files
-
common_obs_<modelname>.f90 :: contains all of the model-specific logic used to apply the observation operator, as well as observation I/O
-
model_params.f90 :: contains the parameters like model prognostic variables, restart file naming convention, etc. You will have to update this to fit your default experiment scenario.
-
model_vars.f90 :: contains variables for defining model grid and other static parameters. This may need to be updated if you are not using an ocean-like model
-
input_nml_<modelname>.f90 :: this should not need to be updated, but is available in case new input parameters are needed
-
common_mpi_<modelname>.f90 :: this contains the logic for parallelizing the execution of letkf with this model. This does not need to be changed, but may be updated if you would like to modify the parallelization strategy or if you want to eliminate some variables that are not needed in your model (this will most likely only be in the "set_common_mpi_oceanmodel" routine).
-
gdas_diagfile_io.f90 :: this is a work in progress, no need to use this file
This file contains the model I/O. It is separated into 5 key routines:
- set_common_oceanmodel :: set up the required model grid information. This can be achieved most generically by inputting a netcdf or other descriptive file that you can map to the lon2d/lat2d/lev grid definitions. The "kmt" variable indicated the integer depth of the domain (e.g. ocean water) in the model grid. If you don't need this, then you can set all values to the maximum depth (nlev).
- read_diag :: read the diagnostic/history output from the model, used by the observation operator (obs/obsop_XXX.f90)
- write_diag :: write a file in the format of the diagnostic/history file, usually not needed
- read_restart :: read the model restart file that will be updated to initialize the model forecast, used by letkf.f90
- write_restart :: write the model restart file that has been updated to initialize the model forecast, used by letkf.f90
If you plan to just use restart files for everything (obs operator and da), then inside read_diag you can have it simply call read_restart. This is to maintain interoperability with the observation operators across all models with minimal modification.
The advantage to having a separate call to read_diag for the obs operator is that you only have to output the observed model data at a greater frequency. The full restarts typically only have to be output once per model at the time of the analysis. For example, in the ocean one may only have to output hourly temperature, salinity and SSH fields at single precision from the model to assimilate T, S, SST, and SSH observations. These can then be matched closely to the observations at the time of measurement for application of the 4D-LETKF.
SUBROUTINE set_common_oceanmodel
Sets up the grid structure for your model.
Can read in from a file here.
Provide lon2d, lat2d, lev
Prvide "kmt" which is depth of grid cells to be assimilated (0 for no assimilation)
No longer needed: dx, dy
2 types of input files supported:
'diagnostic' and 'restart'
read_diag (input data from diagnostic/history files for computing OMFs)
read_restart (input data that contains variables to be updated by DA)
write_restart (output data that has variables that have been updated by DA)
This will need to be edited if you need a more sophisticated operation in the "H" operator other than a simple interpolation, or if you have operations that are specific to a particular variable.
Otherwise, this will probably not need to be edited unless you want to change the default binary format of the intermediate observation data (that transfers data between the obs operator and letkf).
This file will need the most adjustments, to match your model grid, and all of the specific variable names, and formats you want to use for your data assimilation experiment.
Other model-specific files can be added as needed as long as they are encapsulated to interface only via the files in this directory.
In the build/ directory, create make_letkf.<modelname>.sh and make_obsop.<modelname>.sh and if necessary, update the lnkcommon.sh and lnkcommon_obsop.sh to ensure you copy the needed files for compilation.