Deflation?

[kdraeder]

Use case

Eliminate spurious increments from ensemble members,
to avoid confusing users and send better model states back to the model.

Is your feature request related to a problem?

Ben Gaubert has pointed out that examining the assimilation increments
in the members is tricky, at least in large models like cam-fv.
The problem stems from an interaction between inflation and an unsteady obs network.
Inflation values may change slowly relative to the network.
For example, the common or default inflation damping value of 0.9
reduces inflation values by 10% at each assimilation,
while some kinds of observations can disappear between daylight and night;
a 100% reduction.

Inflation can change member state variables so that they look nothing like
the physical system. If there are plenty of obs, the assimilation
pulls those values back to reality before the next hindcast.
Those increments represent the effect of the observations.
If the obs suddenly stop, then the increments may just look like the inflation.
Those incorrect state values persist and are used by the next hindcast,
which will at least degrade it, and might cause it to fail.

This may not be visible in the mean, since the inflation is designed
to preserve the mean, but at some level it's happening in many assimilations.

Describe the your prefered solution

Do we need and can we create a more nimble form of inflation damping. Deflation?
This would look at the obs distribution at the current time, recognize when a sudden change had happened
and adjust the ensemble (or inflation values from the previous time) to reflect that.
The recognition might need to come from comparing the inflation value with the current
density of obs to see if they are consistent. There are complications, like when chemistry
restricts interactions between obs and state variables.

Describe any alternatives you have considered

Choosing the "right" combination of stages to calculate the increment
is not the solution, because one choice (e.g. analysis - forecast)
will show spurious increments in the unobserved regions,
while the other (e.g. analysis - preassim) choice
will have them in the observed regions.
(Pictures needed?)

We could just warn users about this, and leave it to them to filter out spurious increments
(Gaubert is doing this, others may not be aware of it).

This is related to #90 .

[jlaucar]

I'm not sure this is really something that should be a Github issue.

This describes a fundamental limitation of the adaptive inflation algorithms that are core to DART. They assume that the observing network is uniform in time. The damping is an ad hoc extension to try to address the issue of "orphaned" inflation when observation density changes. I've been working sporadically on this issue for two decades and there are no obvious straightforward solutions. Kevin's proposal is actually a smoother for inflation in that it makes use of observations from two different (or more) time levels to make a Bayesian type modification. Even if we had an idea how to do the statistics (which I don't) it would not readily fit into the DART infrastructure. The most straightfoward solution is to go to a form of inflation that does not have adaptive memory, like relaxation to prior spread. Maybe Ben should consider trying that.

Moha should jump in and comment on this because he may have better ideas.

[mgharamti]

Kevin, what kind of flavor is Ben doing; 2 or 5?
If it's 5, then I'd highly recommend setting the inf-lower-bound to 0 in order to allow for deflation.

Having a smoothing option for inflation might help the performance in these scenarios (when obs density suddenly changes) but it could also degrade the performance in cases when a rapid change in the model happens. For instance, when a flood starts (wrf-hydro) or when a bloom happens (biogeochemistry). Because we are adding effects of inflation from previous cycles, the inflation would not be able to respond quickly to such dynamic changes. I personally wouldn't prefer this kind of solution. In fact, because our algorithm has a memory consistent with Bayesian filtering, it really makes it unique in the DA field when compared to other inflation approaches.

One way to allow the inflation to move quicker between cycles is to make its prior pdf more uncertain (make the curve fat). This can be done by increasing inf-sd from 0.6 to some larger number. I don't know what that number is. This requires sensitivity testing. This strategy might be effective for chemical tracers. (Again, I'm assuming that deflation is allowed).

[kdraeder]

I was doubtful that a smoother solution would fit,
which is why I suggested that maybe the current inflation value
could be compared with the current obs density. I don't know how that would work.
It might not have a firm theoretical basis, but could be useful.

Ben is using flavor 5, with
inf_lower_bound = 0.0,
inf_upper_bound = 5.0, (we've discussed this a bit)
inf_sd_lower_bound = 0.6, 0.6
inf_sd_max_change = 1.03, 1.05
inf_damping = 0.9,

This seems to imply that inf_sd can increase, and in Ben's case it does, to at least as large as 30.0(!)
The inf_mean values seem to stay in the range of 1-3.

[mgharamti]

If inf_sd is increasing then he must've started from inf_sd_initial (or through fill_inflation_restart) with a value that is different from 0.6. I wouldn't allow the inf_sd to increase to 30! I'm not sure if he already tested starting with 0.6 (i.e., the same as sd_lower_bound so sd won't change in time just like your reanalysis), but I'd start from there. It's hard to diagnose the issue when there are many things changing at the same time.

[jlaucar]

Just a reminder that the issue here is that there are no observations. Changing the parameters of the core inflation algorithms won't change anything because they are not being activated.

…

On Thu, Jun 3, 2021 at 4:43 PM Moha Gharamti ***@***.***> wrote: If inf_sd is increasing then he must've started from inf_sd_initial (or through fill_inflation_restart) with a value that is different from 0.6. I wouldn't allow the inf_sd to increase to 30! I'm not sure if he already tested starting with 0.6 (i.e., the same as sd_lower_bound so sd won't change in time just like your reanalysis), but I'd start from there. It's hard to diagnose the issue when there are many things changing at the same time. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANDHUITZ6RO5HGYHFGYUOMLTRAAPVANCNFSM46BQAXSA> .

[kdraeder]

In his input.nml both inf_sd_initial and _lower_bound are 0.6.
I'll ask him whether he imported an inflation restart file that had different values.
If inf_sd_max_change is 1.03, and something wants it to be larger, why would it be stuck at 0.6?

To clarify, there are none of this kind of ob at this time, but there were 12 hours earlier.
There's a diurnal cycle the builds up the inflation mean values.

[mgharamti]

If inf_sd_initial and inf_sd_lower_bound are equal, then sd won't be updated (that's a feature, introduced to be consistent with flavor 2 implementation). inf_sd will ONLY change if starting sd and its lower bound are different.

I'm a bit confused about the issue. If there are no observations then nothing will be inflated until some observation is assimilated, right?

[kdraeder]

Thanks for the 0.6 clarification.

To be more specific, there are no observations at this time in some regions,
but there were observations in those regions at earlier times, so the inflation values are non-0 there
and the ensemble members end up with increments in those regions, even though there are no obs there.
The ensemble mean increment is 0 there, confirming that the increments are due to inflation (I believe).