Add perfect SCM calibration#4516
Conversation
| # This is where we would do preprocessing and minibatching before creating the | ||
| # EKP.Observation |
There was a problem hiding this comment.
I was not sure what preprocessing is desired here.
| plot_constrained_params_and_errors(output_dir, ekp, prior) | ||
| return nothing |
There was a problem hiding this comment.
Is there any specific plotting that need to happen here?
nefrathenrici
left a comment
There was a problem hiding this comment.
This looks clean, we still need to decide on the priors and observation details.
d185e69 to
d22bf34
Compare
28d7259 to
e06f6df
Compare
|
I ran the calibration again on the latest commit and it seems to work now. Some of the parameters are not identifiable though.
|
The cloud ice terminal velocity parameter doesn't seem to be informed by the data, I think we can remove it from the calibration. |
b78bb05 to
7c5d2ad
Compare
|
📖 Docs preview for this PR: https://clima.github.io/ClimaAtmos.jl/previews/PR4516/ |
e28c0f2 to
f4eaf43
Compare
There was a problem hiding this comment.
Thanks! I have a few comments to add finishing touches:
- Delete the now-unused test files in
calibration/test/. I think the entire folder can be removed. - Delete
experiments/perfect_scm/run_calibration.shif it is not run anywhere. - Update the base
calibration/README.mdto reference the nice README you already wrote. - Update the artifact path in the pipeline so that plots can be seen directly from buildkite.
9217047 to
23de47c
Compare
There was a problem hiding this comment.
Hi @ph-kev This looks nice!
I think my points are essentially of one theme: over-wrapping. Currently we have really nicely contained a lot of the boilerplate - but at times I think this will come to the detriment to what a future user might want to use this for. (I understand by default it is fed into a test pipeline) but it should not be written as if it will not be run by a user.
With that in mind, I would urge exposing a couple of items to the run_calibration.jl top-level script:
- The true parameter values should be accessible
- The true processed data should be accessible (before creating the observations)
- The observation recipe should be changeable.
- Perhaps add at the end of a script a function that gets the iterations from the eki, and builds them with the outputVar
In this way we are giving users a similar degree of freedom as you do with the prior - which is easily modifiable at the top level!
Update: Created Issue CliMA/ClimaCalibrate.jl#328 for the user-defined covariances, that are beyond the scope of the PR
| include(model_interface_filepath) | ||
|
|
||
| # Set up model interface | ||
| config = joinpath("config", "model_configs", "prognostic_edmfx_trmm_column.yml") |
There was a problem hiding this comment.
It is not clear what the true parameters are - I would obtain these for the user - extracted from the simulation, or at least direct them to their location (e.g. ClimaParams.jl defaults?), else explicitly overwrite them locally with fixed values so they do not change
There was a problem hiding this comment.
I don't think there is an easy way of querying for the parameters of a simulation after it is created, so I ended up letting the user specify their TOML file that can be used to overwrite the parameters of the simulation.
|
|
||
| # Set priors for parameters of interest | ||
| means = [5.0, 1.0, 0.01, 0.01] | ||
| mean_std_dev_lub(m) = (m + 0.05 * m, m * 0.2, 0.0, m + 4 * m * 0.2) |
There was a problem hiding this comment.
Just checking if the upper bound here is justified? (hard to tell as the user does not easily know the "true" params here
There was a problem hiding this comment.
I typically would not place hard bounds unless they are needed (e.g. the 0.0 likely is)
There was a problem hiding this comment.
I am going to put Inf as the upper bound, but @trontrytel would know.
| n_iterations, | ||
| prior, | ||
| interface.output_dir, | ||
| ) |
There was a problem hiding this comment.
It might be helpful for a user looking at this script, for them to see how to obtain the final u_ens and g_ens and reconstructed_g_ens ( via reconstruct_g_ens). Just to demonstrate the functionality at the top level?
There was a problem hiding this comment.
I think it would be better to have a section for this in ClimaCalibrate (see CliMA/ClimaCalibrate.jl#330).


closes #4506
This PR adds a perfect SCM calibration using ClimaCalibrate v0.3 which should be similar to the calibration pipeline in ClimaCoupler and ClimaLand.
The entry point to the calibration is
run_calibration.jlwhich will generate data from a simulation and run the calibration to fit against the data.TODO
Ability to run multiple simulations from multiple configurations for a single calibration(This feature will be added in another PR)calibration/test/pipeline.ymlOptional