Closed mjs2369 closed 11 months ago
@mjs2369 do you have any developer tests for reading the qcf table?
Code to be removed:
models/cam-fv/work/algorithm_info_mod.f90
assimilation_code/modules/assimilation/all_eakf_algorithm_info_mod
assimilation_code/modules/assimilation/neg_algorithm_info_mod
assimilation_code/modules/assimilation/state_eakf_tracer_bnrhf_algorithm_info_mod
assimilation_code/modules/assimilation/one_above_algorithm_info_mod
obs_kind is outdated terminology. qty (quantity) is the term that has replaced kind. I'll go ahead and switch this out.
@hkershaw-brown great suggestions. I'll commit them after we change the author on the previous commits
Note on:
RESULT: 10 models/cam-fv/work/ finished
Possibly the local algorithm_info_mod.f90 was removed for your test but not committed, because the branch as-is the cam-fv build fails because there is an algorithm_info_mod.f90 in cam-fv/work
/Users/hkershaw/DART/pull_requests/pull_545/assimilation_code/modules/assimilation/filter_mod.f90(93): error #6580: Name in only-list does not exist or is not accessible. [INIT_ALGORITHM_INFO_MOD]
use algorithm_info_mod, only : probit_dist_info, init_algorithm_info_mod, end_algorithm_info_mod
-------------------------------------------------^
/Users/hkershaw/DART/pull_requests/pull_545/assimilation_code/modules/assimilation/filter_mod.f90(93): error #6580: Name in only-list does not exist or is not accessible. [END_ALGORITHM_INFO_MOD]
use algorithm_info_mod, only : probit_dist_info, init_algorithm_info_mod, end_algorithm_info_mod
--------------------------------------------------------------------------^
compilation aborted for /Users/hkershaw/DART/pull_requests/pull_545/assimilation_code/modules/assimilation/filter_mod.f90 (code 1)
make: *** [filter_mod.o] Error 1
Note on:
RESULT: 10 models/cam-fv/work/ finished
Possibly the local algorithm_info_mod.f90 was removed for your test but not committed, because the branch as-is the cam-fv build fails because there is an algorithm_info_mod.f90 in cam-fv/work
/Users/hkershaw/DART/pull_requests/pull_545/assimilation_code/modules/assimilation/filter_mod.f90(93): error #6580: Name in only-list does not exist or is not accessible. [INIT_ALGORITHM_INFO_MOD] use algorithm_info_mod, only : probit_dist_info, init_algorithm_info_mod, end_algorithm_info_mod -------------------------------------------------^ /Users/hkershaw/DART/pull_requests/pull_545/assimilation_code/modules/assimilation/filter_mod.f90(93): error #6580: Name in only-list does not exist or is not accessible. [END_ALGORITHM_INFO_MOD] use algorithm_info_mod, only : probit_dist_info, init_algorithm_info_mod, end_algorithm_info_mod --------------------------------------------------------------------------^ compilation aborted for /Users/hkershaw/DART/pull_requests/pull_545/assimilation_code/modules/assimilation/filter_mod.f90 (code 1) make: *** [filter_mod.o] Error 1
@hkershaw-brown yes, cam-fv finished for me because I removed the algorithm_info_mod in work locally, but forgot to commit and push this change.
This has now been pushed to the remote qcf_table branch.
closing this pull request in favour of https://github.com/NCAR/DART/pull/553 which this request, but with commits correctly attributed to Marlee.
Do not merge this use #553
Description:
Previously the QCF code required an algorithm_info_mod specific to the model, which meant editing algorithm_info_mod.f90 to specify which distribution should be used for which quantity.
This code implements a QCF input table, which reads in the algorithm info choices (QCF options) at runtime and stores them in algorithm_info_mod module storage.
This replaces the former functionality of algorithm_info_mod if statements with the table information.
The observation, state, and inflation variables are read in from a single table. Each field keeps its own column, having 28 total in the table.
The full list of QCF input options and information of the structure of the table can be found in the documentation at DART/guide/qcf_table.rst
More info on the background of the issue can be read in the specification here: https://docs.google.com/document/d/1MnvEFfgj5SfFbnIahGHwjy1XJ5IWBvPS8NB1nrIjc8k/edit
Fixes issue
Fixes #503
Types of changes
Documentation changes needed?
While I have included new documentation on how to use the input table at DART/guide/qcf_table.rst , we may want to edit Jeff’s documentation at https://docs.dart.ucar.edu/en/quantile_methods/models/lorenz_96_tracer_advection/work/readme.html to reflect the difference in workflow for the tests listed. I think we should also add to this page the need to include the &probit_transform_nml when running on quantile_methods.
Tests
Compiled and ran filter with full debugging flags with Intel, CCE, gfortran Bitwise identical to quantile_methods, tested with Intel
Information on how to use the QCF input table with the quantile code is in the documentation at DART/guide/qcf_table.rst
build_everything now passes for all models:
A developer test for the table read is in progress.
Checklist for merging
Checklist for release
Testing Datasets
Open Issues/Questions
There are two input options for obs_inc_info (rectangular_quadrature and gaussian_likelihood_tails) that are only compatible with the original RHF implementation. Currently, these variables are unused in algorithm_info_mod.f90. These could either be removed from alg_info_mod and the namelist, or we can implement a conditional: if (filter_kind == RHF) then rectangular_quadrature: .true. gaussian_likelihood_tails: .false. https://github.com/NCAR/DART/blob/fc48d9d8cca1dce1b4e4fafe4983dac66bd6c5e8/assimilation_code/modules/assimilation/algorithm_info_mod.f90#L233
Currently, the only check on the bounds that is implemented is a simple check to ensure that the lower bound is not less than the upper bound. Do we know if we want to put more explicit limits on the bounds?
There are differences in the formatting of log_qcf_info to dart_log.out with the cce compiler. This PR https://github.com/NCAR/DART/pull/491 describes this general issue with cce.
Currently, I am logging the headers of the QCF table to dart_log.out. Do we want these in the log? Similarly, is writing the data straight to the dart_log sufficient, or do we want to format this more cleanly (i.e. make it look like a table)?