Phase 2 validation: sonde (adpupa 120/220)

[delippi]

Description

Finished phase 2 (FV3-JEDI vs GSI) testing of sonde (adpupa 120/220). Most of each yaml was inherited from the mesonet yamls. The main difference was using the ObsErrorFactorConventional which also required the use of pre-sorting via obsgrouping in the obs space. All tests were shown to run successfully using the online domain check. Phase 2 doesn't guarantee each yaml will fully work with MPAS-JEDI (due to certain features not being ready in MPAS-JEDI and not due to issues with the yamls themselves).

I also want to note that in GSI I used ext_sonde=.false. and time_window_max=0.99. We should not be using the ext_sonde in GSI which has since been fixed in the latest ctest GSI case. I'm not sure why time_window_max=1.0 still gave more obs than expected. The correct setting should be time_window_max=1.5, but some more work is needed to extend the assimilation window for JEDI. This difference in settings should not affect results.

Issue(s) addressed

Resolves/Results are documented in Issue

• Incorporate Sonde DA into JEDI for RRFS #232

Checklist

• I have performed a self-review of my own code.

[guoqing-noaa]

@delippi Regarding due to certain features not being ready in MPAS-JEDI, could you list what features are missed? Do we have issues created for those? Thanks!

[delippi]

@delippi Regarding due to certain features not being ready in MPAS-JEDI, could you list what features are missed? Do we have issues created for those? Thanks!

It has been a little while since I last tried running MPAS-JEDI and those could have already been fixed. The one that comes to mind was issues with specificHumidity when it tries to create the GeoVaLs/saturation_specific_humidity (I think it is called something else now). I haven't opened an issue with this yet since I haven't investigated too much and it could have been user error. My temporary solution was to just comment out those parts of the yaml. I have a feeling there was something else too, but I don't remember. Now might actually be a good time for me to start digging into some phase 3 tests and opening such issues.

[JingCheng-NOAA]

@delippi Nice job on updating the airTemperature, wind, and specificHumidity YAMLs. Will there be a plan to work on phase 2 of stationPressure for sondes data?

[delippi]

@delippi Nice job on updating the airTemperature, wind, and specificHumidity YAMLs. Will there be a plan to work on phase 2 of stationPressure for sondes data?

Yes, I plan to. I'm not sure if that one needs would require using the python converter to create the IODA data or not. I need to look into it more. Have you tried sonde stationPressure yet?

[JingCheng-NOAA]

@delippi Nice job on updating the airTemperature, wind, and specificHumidity YAMLs. Will there be a plan to work on phase 2 of stationPressure for sondes data?

Yes, I plan to. I'm not sure if that one needs would require using the python converter to create the IODA data or not. I need to look into it more. Have you tried sonde stationPressure yet?

not with phase 2 yet.

[delippi]

@delippi Regarding due to certain features not being ready in MPAS-JEDI, could you list what features are missed? Do we have issues created for those? Thanks!

It has been a little while since I last tried running MPAS-JEDI and those could have already been fixed. The one that comes to mind was issues with specificHumidity when it tries to create the GeoVaLs/saturation_specific_humidity (I think it is called something else now). I haven't opened an issue with this yet since I haven't investigated too much and it could have been user error. My temporary solution was to just comment out those parts of the yaml. I have a feeling there was something else too, but I don't remember. Now might actually be a good time for me to start digging into some phase 3 tests and opening such issues.

@guoqing-noaa, I tried all of these yamls in our MPAS-JEDI case. They all worked except specificHumidity. Here was the error message:

  0:  --> vars_nlevels: saturation_water_vapor_mixing_ratio_wrt_moist_air not available in MPAS domain or self % templated_fields

Is this because VADER is not in MPAS-JEDI? At least it doesn't seem to be. https://github.com/JCSDA-internal/mpas-jedi/issues/947
My temporary solution is to just comment the ObsErrorFactorPressureCheck.

[delippi]

Are there any additional comments to be made on this PR? I've already got Phase 3 updates close to being ready for PR so I want to get this in soon, if possible.

[hu5970]

looks good to me.