NCAR
Documentation: Precomputed (external) Forward operator documentation is missing from docs.dart.ucar.edu
What's the issue?
:books: Please describe the problem you’ve noticed in the documentation.
Precomputed Forward operator documentation is missing from docs.dart.ucar.edu
There is some information on this wiki page: https://github.com/NCAR/DART/wiki/Precomputed-Forward-Observations-(FOs)
obs_kind_mod.html has the namelist option use_precomputed_FOs_these_obs_types: https://docs.dart.ucar.edu/en/latest/assimilation_code/modules/observations/obs_kind_mod.html#namelist but hard to find unless you already know the namelist option.
the forward operator page of guide, mentions precomputed fields, but not really external forward operators. https://docs.dart.ucar.edu/en/latest/guide/forward_operator.html#optional-precomputed-fields
Where did you find the issue?
Provide the location(s) of the issue:
user emailed, doc is missing.
What needs to be fixed?
How to use external (precomputed) FOs. How to create the obs_seq, Which namelist options to use in when running filter.
I know the documentation needs to be updated, but I am confused by the obs_kind_mod documentation for precomputed forward operators. Nowhere does it say the observations that use precomputed forward operators are assimilated (e.g. radiance). Aren't the key differences between the &obs_kind_nml classifications as follows:
-
assimilate_these_obs_types: The forward operators are internally calculated using DART and the observations are assimilated. -
evaluate_these_obs_types: The forward operators are internally calculated using DART, but the observations are not assimilated. -
use_precomputed_FOs_these_obs_types: External forward operators (non-DART) are used, and the observations are assimilated.
Was this just an oversight, or do I not understand how this works?
The fwd operator code looks like this:
pseudo code:
if (assimilate_these_obs_types or evaluate_these_obs_types) then
! do the fwd operator
if (use_precomputed_FOs_these_obs_types) then
fwd_op = externally calculated value
else
dart calculates the fwd operator
else
! don't do the fwd operator
endid
actual code: https://github.com/NCAR/DART/blob/bddda57a7df96b4b956db33cec5238b9850fc825/observations/forward_operators/DEFAULT_obs_def_mod.F90#L530-L618
I think the obs_kind_mod documentation is misleading as it is:
"Controls what observation types are to be assimilated, evaluated, or ignored."
when what is does is
"Controls what observation types are to be assimilated, evaluated, or ignored."
AND controls whether or not to use an externally calculated forward operator for a given observation type.
assim or eval is encoded in the qc value, but not whether the FO was external or not is not recorded. Which I think is weird because external_FO always "fail" the posterior fwd op.
I have a separate 'conceptual or theoretical' question about using external forward operators for a 'mixed' setup where a subset of observations uses external operators and the rest use internal (DART) operators. How does the user know how to properly align the ensemble members (consisting of expected observations and model states) generated between the external forward operators and the internal forward operators? It's possible that the perturbation method which generates the ensemble internally and externally can be completely different, so, in that case, it would be completely unclear to me of how to match up ensemble members. It would seem the user would have to use a similar perturbation method or some other unifying methodology such as using identical perturbed external boundary conditions such that the ensemble members generated between the internal/external forward operators aligned correctly and were physically related as a prerequisite for a mixed setup to work. Is that others understanding or am I completely out to lunch ?
The externally computed forward operators are each associated with a particular ensemble member. The idea is that ensemble members 1-N get passed out of DART. Someone uses them to compute forward operators. Those are each associated with one of the ensemble members. They are then passed back to DART with that same ordering. Could you clarify your concerns about perturbation methods?
On Tue, Jan 7, 2025 at 12:01 PM Brett Raczka @.***> wrote:
I have a separate 'conceptual or theoretical' question about using external forward operators for a 'mixed' setup where a subset of observations uses external operators and the rest use internal (DART) operators. How does the user know how to properly align the ensemble members (consisting of expected observations and model states) generated between the external forward operators and the internal forward operators? It's possible that the perturbation method which generates the ensemble internally and externally can be completely different, so, in that case, it would be completely unclear to me of how to match up ensemble members. It would seem the user would have to use a similar perturbation method or some other unifying methodology such as using identical perturbed external boundary conditions such that the ensemble members generated between the internal/external forward operators aligned correctly and were physically related as a prerequisite for a mixed setup to work. Is that others understanding or am I completely out to lunch ?
— Reply to this email directly, view it on GitHub https://github.com/NCAR/DART/issues/724#issuecomment-2576019756, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANDHUIRB4TGCR2RAF2RK4FD2JQP7XAVCNFSM6AAAAABNK266QWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZWGAYTSNZVGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
@jlaucar That clears up my confusion -- thanks. The step where the ensemble is passed out of DART, then the forward operators are externally calculated, but still using the same model ensemble, then passed back in, was lost on me. I misinterpreted the concept where I thought both the ensemble and the forward operation calculation was externally generated. Maybe the documentation already covers the passing back and forth part, but I missed it.