Add hydrometeors

[rtodling]

Description

This adds hydrometeors and changes to the linear obs operators necessary to account for sensitivity of all-sky MW to such fields.

Dependencies

• [https://github.com/JCSDA-internal/fv3-jedi/pull/1257 ] waiting on fv3-jedi
• [ https://github.com/JCSDA-internal/saber/pull/939] waiting on saber

Impact

Enhanced features and corrections and consistency w/ GSI

Issues

[#418] this is associated w/ the issue marked here.

Required Change in Static Files

This will require a change to the cli_* and hyb_* gsibec 'nml' : all qr/qs references in these files must be uncommented.

[rtodling]

Look around to try to understand some - unrelated to this - I came across the fact that by default, the hydrometeors radii is set to use GFDL's numbers ... the GSI numbers are an option ... The yaml's for GMI and AMRS2 in swell are using the fv3-jedi default which is not what we want - I believe.

I ran a little test w/ GMI obs only to see what difference we get from these two schemes in comparison to GSI: I find that the difference between the two schemes is considerable smaller than the difference of either scheme w/ the actual GSI. Here is an illustration of the differences: top: GSI-minus-fv3-jedi using GSI radii; bottom: diff of JEDI increments when using either GSI or GFDF radii ...

The differences in the temperature are unnoticeable either way - GSI and JEDI are quite good match to each other regardless of which scheme is used - no need to show.

In any case, the consistent choice of radii is also being introduced in the changes presented here.

[rtodling]

The PRs from JEDI mentioned above have been merged. I believe the changes here could now make it into SWELL

[Dooruk]

@rtodling Can you set the environment LOG_INFO variable to 1 and run swell test code_tests with this branch please? There is a code testing issue.

https://geos-esm.github.io/swell/#/code_tests/code_tests

[Dooruk]

This will be on-hold until a JEDI build post ~September 20th.

[rtodling]

@Dooruk All tests seem to have passed for this - can we take this in? If not, can we chat?

[Dooruk]

@Dooruk All tests seem to have passed for this - can we take this in? If not, can we chat?

Did you run t1tests? I will fire it up in github actions now

[rtodling]

@Dooruk All tests seem to have passed for this - can we take this in? If not, can we chat?

Did you run t1tests? I will fire it up in github actions now

I was looking in the doc how as I user I can fire up the tier-1 test ... but it's not quite clear to me.

[Dooruk]

Doesn't this require the new JEDI build by the way?

[Dooruk]

So overall, there are issues regarding get_values and file permissions were changed. These changes are breaking ocean 3dvar and hofx.

[Dooruk]

When you put anything in the OOPS part of SWELL this will impact the marine side as well if it's a generic application. So for this, we don't have a corresponding get_values.yaml on the geos_ocean side and 3dvar is complaining. One option is that I can create an dummy get_values.yaml which is fine.

However when I searched for this get values key in the SWELL source code I see sections that modifies that behavior, see below, so we have to be careful with this:

swell/src/swell/tasks/run_jedi_ufo_tests_executable.py

Lines 87 to 93 in 2b0f03b

	# Remove the LinObsOperator and Insert the GeoVaLs section
	# ---------------------------------------------------------
	# Loop over the observations
	for index in range(len(observations)):
	# Remove GetValues if present
	if 'get values' in jedi_config_dict['observations'][index]:
	del jedi_config_dict['observations'][index]['get values']

[Dooruk]

Same above^

[Dooruk]

Same above^

[Dooruk]

Same above^

[Dooruk]

Did you accidentally changed the file permissions here?

[Dooruk]

permission

[Dooruk]

permission

[Dooruk]

permission

[Dooruk]

permission

[Dooruk]

permission