CliMA / CliMA/ParameterEstimocean.jl

Utility for rebuilding `InverseProblem` with new `times`

Open
#190 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

🤥 enhancement 🚰 user experience
Dominant language
Julia
Stars
22
Forks
6
PR merge metrics
No merged PRs in 30d

Description

It's often useful to start a calibration problem by focusing on a narrow range of times at first to identify generally useful parameter ranges because

  1. It's cheaper and
  2. There are fewer particle failures / we can afford very small time-steps when integrating over a short time window.

Then as the calibration proceeds we might want to gradually expand / shift the range of times considered to inform parameters with more data.

Right now my current method is to update the priors manually and re-run the script. This is sort of necessary anyways, because I need to provide manual input into the priors update (ie I might want to ensure that certain regions of parameter space for certain parameters continue to be explored, despite that the current ensemble has collapsed to exclude it). This method has the downside that it involves a bit of sweat and manual labor.

In the future when we have better methods for controlling the rate at which the ensembles collapse, we might be able to design automated "schedules" for systematically adjusting the time window of the physical experiments that are being used for calibration.

I think a simple way to achieve this without changing any existing code is to design a utility like

update_times!(inverse_problem, new_times)

This utility will re-build the Observations and time_series_collector with a new_times vector, using the existing inverse_problem.observations (and leaving the existing simulation untouched, which will become important as our simulations get more and more complicated). This is hopefully fairly simple as we can use the original constructors, and cheap because our Observations concern a relatively small amount of data. We also have to make InverseProblem mutable, which is probably a good idea anyways.

cc @adelinehillier I think this might help with some of the stuff you planned to do too.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the definitions and constructors for InverseProblem, Observations, and time_series_collector, then trace how observations are built from times. Implementing update_times! is done when it rebuilds the observations and collector from new_times while leaving simulation untouched; the issue does not name a test, so add or run the relevant existing inverse-problem tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
julia
Domain
backend-api-design
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.