Happy Cinco the Mayo!
Benjamin Menetrier presented on SABER.
Slides
Slide notes
Slide 5: Background error: ensemble B
- L = localization matrix
Slide 6: Background error: hybrid B
- Need to specify weight for each component in yaml
Slide 11-14:
- First specify central block, last specify linear variable change
Slide 16: Block types
- Variable change: can be implemented in SABER now, but eventually want VADER to do this and create a SABER block to wrap around it
Slide 17:
- SPECTRALB: will use spectral covariance coming from atlas
Q&A
Sergey Frolov: Can weight be a field or only a scalar?
Benjamin Menetrier: Right now it can be both, but current implementation for field is not correct. Bug fix will be coming soon. Infrastructure is here to have both.
Ting Lei: Can the linear change deal with interpolation (and adjoint) between different grids?
Benjamin Menetrier: Yes, but interpolation will be implemented in a separate SABER block
Chris Snyder: Will SPECTRALB and GSI be implemented as single block?
Benjamin Menetrier: SPECTRALB will be one block with different options (covariance or correlation)
Marek Wlasak: Currently dual of cubed sphere mesh or regular structured lon-lat geometry supported in SPECTRALB;
in principle with additional changes to atlas could be extended to point clouds - then would work with any grid;
in any case will have interpolators as separate SABER blocks
Benjamin Menetrier: GSI - may want to start with single block, then split it
Yannick Tremolet: We have the capability to do interpolation outside of atlas already
Youhua Tang: How to use the variational length scale besides STD?
Benjamin Menetrier: Could be used in the smoother NICAS of BUMP and maybe in other operators later.
Steve Vahl presented on VADER
Slides
Slide notes
Slide 5:
- Must implement set/to/fromAtlas, currently in the Increment class of the State class
Slide 6:
- changeVar method similar to variable change in oops
- model passes field set to vader, must contain the input variables as well as the desired allocated fields for the output
Slide 7:
- VADER also passes back a list of variables that it was unable to produce (model will need to handle those)
- Existing code in model can remain almost unchanged, just need to insert call to VADER first and let the model handle the rest
- Allows to transition gradually from doing everything in model to more and more in VADER
Slide 8:
- Feedback from UK MetOffice: not the best design to send pointer to field set - will be changed to passing a reference instead
Slide 9:
- Recursion - capability to produce missing ingredients (try known recipes)
- There may be possibilities for infinite recursion loops right now, will be fixed soon
Slide 13:
- Methods for setup (thinking of recipes that have expensive setup that we only want to perform once). Currently not used by any recipe
Slide 14:
- Names of variables produced are all in a header file, this will be re-designed in the future
Slide 15:
- VADER design principle is to be able to use it without knowing what is going on behind the scenes
Slide 18:
- In-repository ctest harness: will probably adapt the variable change tests in oops
Q&A
Neill Bowler: Slight side question: At points the ufo needs to implement a variable change. Since the ufo is not a model, I assume that it can't use vader. So, is a parallel library of variable change functions planned for the ufo to use?
Marek Wlasak: I think that because it is using an atlas FieldSet it could in principle be extended to ufo variable changes.
Anna Shlyaeva: If there is an infrastructure in ufo to go to the atlas field set, then it should be possible (VADER only operates on and cares about atlas field sets)
Marek Wlasak: One consequence of this [incomplete capabilties] is that we will still need a factory of variable changes in the model interface until VADER does it all?
Steve Vahl: Most models already have a factory, that method will continue to work; if model wants to get rid of factory and do it differently, then that can be done, too
Marek Wlasak: Not sure how to implement variable change class in model on top of/after VADER without if tests
Steve Vahl: Last year's changes forced models to use a single variable change class that oops sees. At that single level is where the call to VADER might go in, underneath is the logic to implement concrete instantiation of the factory
Tom Auligne: Main advantage of VADER? Greatly simplify model interfaces once VADER can do it all (i.e. when all the recipes are there)?
Steve Vahl: Cookbook is organization of recipes. If VADER was complete, one could get rid of changeofvariable in model interface; but even before that there is an advantage of using VADER, because variable changes that are in VADER don't need to be in the model (can remove the code)
Chris Snyder: VADER seems pretty useful for static B
Dan Holdaway: Does it make sense to have a code sprint to add all the recipes?
Anna Shlyaeva: This is a good idea, but do we need to have the linear variable change implemented in VADER before the sprint or work on the non-linear ones?
Yannick Tremolet: Would go for linear variable changes first
Dan Holdaway: In FV3, far more lines of code in non-linear variable changes
Marek Wlasak: Would be useful to have a variable change code sprint would stress-test the system, there will be lessons learned from non-linear variable changes (which are less complex than liner variable changes)
Anna Shlyaeva: Anybody interested in code sprint to ping Anna or Steve V to express interest