search

NCAR / DART

Data Assimilation Research Testbed
https://dart.ucar.edu/
Apache License 2.0
196 stars 145 forks source link

bug: program perturb_single_instance does not do any perturbation if interf_provided = .false #397

Closed hkershaw-brown closed 2 years ago

hkershaw-brown commented 2 years ago

:bug: 🐘

Describe the bug

  1. List the steps someone needs to take to reproduce the bug.
    Run perturb_single_instance with a model that does not have a pert_model_copies routine, that is any model_mod that uses default_model_mod::pert_model_copies.
  2. What was the expected outcome? An ensemble is created from perturbing the single instance.
  3. What actually happened?
    All ensemble members are the same

Error Message

No errors

Which model(s) are you working with?

User discovered this bug when running ROMS.

Version of DART

v10.3.2 came in commit 4c51a255e25812ccccc6e1a6e58503aec605893a (2018)

Have you modified the DART code?

No - but reproducer with wrf incoming shortly (force interf_provided = .false.) perturb_single_instance only works on a netcdf file with a single member, so I can not reproduce with out-of-the-box lorenz_96.

Suggested solution

perturb_single_instance should exit with error if interf_provided=.false.

nancycollins commented 2 years ago

sorry, i'm out of the loop here. why can't the standalone perturb program add a small amount of noise to the entire state if the model doesn't provide a more specific perturb routine? is it simply broken right now and this is the quickest fix? or is there something more fundamentally wrong going on?

hkershaw-brown commented 2 years ago

Nancy you got to start coming to standup!

There is a ROMS specific perturb routine incoming from Ben J. There is zero perturb at the moment in the standalone perturb program (so broken), and advice from Jeff was to error out if there is no model specific perturb.

johnsonbk commented 2 years ago

Commit 8048d0c contains the definition of pert_model_copies within ROMS' model_mod.f90. When a model_mod uses pert_model_copies from DART/models/utilities/default_model_mod.f90, the imported subroutine just sets interf_provided = .false. and ./perturb_single_instance runs without error, but creates identical "perturbed" files.

nancycollins commented 2 years ago

sorry - i should start coming to the standup or stop asking questions!!

the eventual fix sounds like the default_model_mod.f90 pert routine should change to actually perturb the data instead of doing nothing. but for now it's better to error out rather than return an invalid initial ensemble? makes sense.

hkershaw-brown commented 2 years ago

the eventual fix sounds like the default_model_mod.f90 pert routine should change to actually perturb the data instead of doing nothing. but for now it's better to error out rather than return an invalid initial ensemble? makes sense.

I'd be hesitant to have a general perturb in default_model_mod.f90 because the pert_model_copies interface at the moment is 'if there is no model specific perturb, the calling code decides what to do'. filter does a perturb that does not depend on the number of tasks, other code may choose to do something else (e.g. fail gracefully).

So for this issue, fail gracefully if there is no model_mod perturb, and leave for future discussion if we should provide general perturbing (science!).

jlaucar commented 2 years ago

While a generic perturb routine used to seem desirable to me, I'm no longer feeling so good about it. Maybe doing a literal bitwise perturb is okay. However, I think that users should probably be alerted to the fact that a default perturbation will be done and then have to opt in. In the short-term, having something that does nothing but should seems the worst of both worlds.

On Tue, Sep 20, 2022 at 1:28 PM hkershaw-brown @.***> wrote:

the eventual fix sounds like the default_model_mod.f90 pert routine should change to actually perturb the data instead of doing nothing. but for now it's better to error out rather than return an invalid initial ensemble? makes sense.

I'd be hesitant to have a general perturb in default_model_mod.f90 because the pert_model_copies interface at the moment is 'if there is no model specific perturb, the calling code decides what to do'. filter does a perturb that does not depend on the number of tasks, other code may choose to do something else (e.g. fail gracefully).

So for this issue, fail gracefully if there is no model_mod perturb, and leave for future discussion if we should provide general perturbing ( science!).

— Reply to this email directly, view it on GitHub https://github.com/NCAR/DART/issues/397#issuecomment-1252810285, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANDHUIVIZJMB4YM2L7SHXNTV7IF37ANCNFSM6AAAAAAQRJEUXA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

nancycollins commented 2 years ago

i chatted with helen about this. i agree most big models should do something smarter than perturb the entire state uniformly. however, a default routine can be useful for testing. in any case, whatever the standalone program does, the built-in routine in filter should do the same.

the history of these executables -- perturb_single_instance and fill_inflation_restart -- was to try to make the first cycle of a long assimilation be the same as all the subsequent cycles with no namelist changes needed. it was too easy to forget to change the 'start inflation from a file' or 'perturb single instance' namelist items after the first cycle.