MPAS-JEDI VarBC initialization: offline fit versus UFO cold start

JEDI
1

Hello,

I am initializing AMSU-A VarBC in MPAS-JEDI (mpas-bundle 4.0.0, UFO 1.13.0). With zero initial coefficients, the first-guess check rejects most of the biased radiances, leaving too few observations to estimate the bias.

To address this, I fitted initial coefficients offline using one week of HofX on MPAS backgrounds, with weighted least squares for all eight configured predictors. In addition to the QC-passed observations, I included observations rejected only by the first-guess check. This is the last filter in my configuration, and I retained all preceding QC decisions.

The resulting correction agrees closely with our earlier scan-position bias table (channel 6: mean difference (offline fit minus table) of +0.036 K, correlation 0.994). However, this is a consistency check rather than an independent validation: the backgrounds came from an LGETKF experiment that assimilated channels 6 and 7 corrected with that table.

I noticed the constant-only, histogram-mode cold start added to UFO in commit 2353a695 [1]. I would appreciate clarification on the following points:

  1. Offline initialization versus cold start

Is the cold-start option intended mainly to provide an initial constant offset, with the remaining predictor coefficients estimated subsequently by VarBC? Are there implementation constraints or recommended practices that would favor this option over reading an externally fitted initial coefficient file?

  1. OOPS compatibility and QC timing

Which matching OOPS change, or minimum compatible version, is required? At what stage relative to the QC filters are the flags used to select observations for the cold-start histogram evaluated?

  1. Passive-channel coefficient estimation

For passive AMSU-A channels 1-4 and 15, whose bias corrections are needed by the cloud detection, I found the use passive_bc: true option in ChannelUseflagCheckRad, which allows channels with use_flag = -1 to pass the use-flag check [2]. Is this option applicable to estimating their VarBC coefficients in MPAS-JEDI while preventing these radiances from updating the MPAS state? Specifically, would allowing them through this check also include them in J_o and the state update, or is there a separate mechanism that prevents this? If this option is not intended for that purpose, would a separate HofX training run without use-flag rejection, but retaining the other applicable QC checks, be an appropriate approach?

Any MPAS-specific experience with passive-channel initialization would also be welcome.

Many thanks,

[1] Add VarBC cold start for coefficients with no prior value (#4298) · JCSDA/ufo@2353a69 · GitHub
[2] ufo/src/ufo/filters/obsfunctions/ChannelUseflagCheckRad.cc at 1.13.0 · JCSDA/ufo · GitHub

2

Thank you for your questions. Please find my replies below, and I hope they are helpful.

Question 1:

Yes. The cold start seeds only the constant coefficient, using the mode of the histogram of uncorrected y − H(x). The other predictor coefficients stay at zero and are then estimated by VarBC.

It is mainly a convenience for new instruments or channels that have no prior coefficients. A good externally fitted coefficient file that covers all predictors is a better starting point. The two approaches can also be combined: with force: false, channels with fitted coefficients are left untouched, and only channels still missing from the file are cold-started.

Note that I have not yet tested this new option myself; @cmgas, please correct me if I have misunderstood anything.

Question 2:

You can start from mpas-bundle 4.0.1 and update UFO to commit 2353a695 and OOPS to commit 4dcaba30. Note that this combination has not been tested with the other 4.0.1 components (SABER, VADER, IODA, mpas-jedi), so some may need updating if the build fails.

coldStart is called inside ObsOperator::simulateObs, after the forward operator and before the bias correction is applied. It uses observations with QC flag = 0 at that point.

In other words, the histogram reflects the pre and prior filters only. Post filters, including the background (first-guess) check, have not yet run.

This was recently developed and we have not used it before. Our current practices are described in the tutorial: Section 2.3 of our August 2026 tutorial (using GSI files):

Question 3:

No. use passive_bc: true only flips the sign of use_flag = −1 in ChannelUseflagCheckRad, so those channels pass the check exactly like active channels. If they also pass the other QC, they enter J_o and update both the MPAS state and their own bias coefficients.

I am not aware of a mechanism that updates a channel’s bias coefficients without also updating the state.

Your proposed approach is appropriate.