Ufo_geovals_get_var

JEDI
1

Hello!
I’d like to read a geoval with
CALL ufo_geovals_get_var(geovals, varname, geoval)
and upon failure if varname not available try a substitute varname
How should I do that?
(I know about a way around with variable change in e.g. fv3-jedi
but it still could be sometimes easier to put it in ufo)
Thanks,
Mariusz

2

@mpagowski: one option would be to add an if statement and check if variable exists, using ufo_vars_getindex with geovals%variables.
Here’s an example of checking if variable exists (similar to some code in crtm):

if (ufo_vars_getindex(geovals%variables, "name of variable") < 0) then
  ! do something when variable doesn't exist
else
  ! do something else when variable exists
endif
3

Yes, but that only checks if varname is in the list of geovals, not if it is present in the file.

4

@mpagowski: I think I didn’t understand your question, could you clarify where and how you plan to use ufo_geoval_get_var?. My understanding is that when ufo_geovals_get_var gets called, geovals are usually already filled in. For example, most of the times ufo_geovals_get_var gets called in the obs operators; and obs operators get the geovals with all variables in geovals%variables already filled in by model’s getvalues.

5

@shlyaeva : e.g.
various models have different ways of calculating rh. For a test against the GSI we would want to use their rh since ufo which calculates rh like e.g. in fv3 would not pass. So we would rather read rh from the file than calculate it. But in a general case if rh is not output from the model,
not being a prognostic variable, we would have to calculate it for ufo. Upon testing if rh is in a model output file we could either read it or calculate it.

6

@mpagowski: I see, thank you for the clarification.
I think there are two parts to it:

  1. Specifying variables that are requested from model. One option is to control this through yaml. For your example, there could be something like:
obs operator:
  moisture variable: relative_humidity

that users would use for models that have relative humidity and

obs operator:
  moisture variable: something else

for other models.
Then the observation operator would either request relative_humidity from the model, or other variables that would help it compute relative humidity based on this yaml option.
2. In the observation operator computation part, there would need to be an if based either on the moisture variable option or on what’s available in the geovals.

Also, I think @danholdaway and @tremolet were planning on doing some refactoring of variable transforms, and maybe they plan something for your use case.

7

@shlyaeva: thanks, I understand how things work now. I think the issue is of priority: whether to read from a file or to calculate from other variables. In some cases reading from a file could be preferred. Returning to rh - in ufo would we rather have it interpolated from the model grid or calculated from q,T,p interpolated from the model.