GetValues unit test for ocean fields

JEDI
1

I implemented the GetValues class for ROMS, but I get the following error when running the unit tests:

ufo_geovals_analytic_init: pressure coordinate not defined

It seems that the GeoVaLs test is only designed for atmospheric models (like FV3). I implemented my analytical functions for ROMS state fields:

ana_fields (field_name, mask, lon, lat, z, h, value)

where z is the depth (meters; negative) and h is the bathymetry. It returns the value for the requested state field name. It also needs to know the land/sea mask at the (lon, lat) location. Ocean models do not use pressure coordinates. My analytical function can be used to get values at the GeoVaLs locations (lon, lat, z). ROMS is a different class of ocean models from the ones used previously in JEDI (like MOM6). It is a terrain-following coordinate model where the level thickness is a function of the vertical stretching parameters and the bathymetry. The figure below shows an example of a grid application cross-section:

roms_grid_section
roms_grid_section879×974 23.9 KB

I don’t know if this kind of configuration is currently possible when testing the GeoVaLs since we will need the depths of the discretized water column at (lon, lat). Recall that the GeoVaLs are interpolated at the full water column. The depths, bathymetry, and land/sea mask needed for my analytical function can be easily interpolated from the geometry object at the requested (lon, lat).

I coded my own analytical function into GetValues.cc but I don’t know how to overwrite the one in the UFO operator (ufo/src/ufo/ufo_geovals_mod.F90) to test the interpolations.

void GetValues::AnalyticInit(const Geometry & geom,
const eckit::Configuration & config,
const ufo::Locations & locs,
ufo::GeoVaLs & geovals) const {
oops::Log::trace() << “GetValues::analytic_init starting” << std::endl;
if (config.has(“analytic_init”)) {
roms_getvalues_analytic_init_f90(keyGetValues_,
geom_->toFortran(),
locs,
geovals.toFortran());
}
oops::Log::trace() << “AnalyticInit::analytic_init done” << std::endl;
}

I haven’t found the specific keyword and value parameters in the YAML file to overwrite the current behavior about pressure levels. I checkout soca but it seems that the analytical test was bypassed. I think that changes are needed in UFO, oops/src//interface/GetValues., and maybe in other places for this test to work for me. I think that I am in good shape from the ROMS-JEDI implementation. I am learning lots of stuff. However, currently, my skills and privileges are limited and I will need some help from the JEDI developers to solve the issues that I am having.

Sorry for the long posting. Thank you!

My current implementation of the GetValues object is in the branch feature/getvalues of roms-jedi repository.

2

Have you been able to look to see what the SOCA interface is doing for this test?

3

I think we’re skipping that test in soca.

4

I’ll try to have a look later today Hernan. You are able to submit issues and PR’s in all the internal JCSDA repository, so I suggest you do that if you find an issue somewhere.

5

Have a look here Hernan:

https://github.com/JCSDA-internal/ufo/blob/b4642801abeb849286e92e7143bee9b77c1ebdb1/src/ufo/ufo_geovals_mod.F90#L657

If you really want to implement that test for roms-jedi, you will have to modify the above file in UFO. I suggest you skip it for now for the sake of making progress. But do create an issue in UFO so you/we remember to get back to it. Did you create an issue in oops for the geometry cloning that is not tested?

6

I think that there is a need for a generic interface to

typedef oops::AnalyticInit<OBS> AnalyticInit_;

that can be used in any geophysical modeling system to be used in the GetValues unit test. Right now, the UFO namespace is coded primarily from the point of view of the atmospheric model. I have not been able to overwrite that behavior. Maybe some of you have ideas on how to do this elegantly. It will be messy to have keywords like analytic_init_atm, analytic_init_ocn, analytic_init_ice, and so on for other geophysical systems in the YAML file. It involves changes in several places that will affect backward compatibility. Is this is something that every geophysical model needs to code in their namespace? If so, how one can interface with the generic methods.

I think that I am computing the GeoVaLs correctly. I checked offline in Matlab but it is not a full test of the system. I have to include the level depths and the bathymetry in the GeoVaLs, so they are completely independent.

The other thing that comes to mind is the ordering of the GeoVaLs. In ROMS, we have N vertical levels with level N being the surface cell with the free surface moving on its top edge. The bottom level is 1 and the bathymetry lies at the cell bottom edge. In some coastal applications, the bathymetry is time-dependent when sediment morphology is activated. We have a consistent vertical coordinate system (in meters) with positive altitude values in the atmosphere and negative values in the ocean with zero at the mean sea level.

I didn’t find documentation of what is the order that it is expected in:

geovals%geovals%vals(1:nval, :)

It will be trivial to invert the ordering if I know what index 1 represents in the UFO vertical coordinate system.