Reflectivity/helicity diagnostic differences between ufs-community and MPAS-Dev code

[clark-evans]

The MPAS-Dev regression tests all show differences in the updraft helicity diagnostics, no matter the physics configuration (mesoscale_reference, convection_permitting, and mesoscale_reference_noahmp). They also show differences in the refl10cm_1km_max diagnostic, but only for mesoscale_reference and mesoscale_reference_noahmp. These characteristics appear in the action logs for #146, #161, #163, and #164.

The updraft helicity diagnostic differences (core_atmosphere/diagnostics/mpas_convective_diagnostics.F) likely stem from the smoothing factor added in our code vs. the MPAS-Dev code. This is something we inherited from NSSL at the start of our MPAS journey, so I do not consider this to be a bug -- just something for users to be aware of.

As noted above, the refl10cm_1km_max diagnostics only differ for the mesoscale_reference tests, which use WSM6. For this scheme, there is one difference in core_atmosphere/physics/mpas_atmphys_driver_microphysics.F between ufs-community and MPAS-Dev -- our code (lines 1397-1400) includes an extra case statement applicable to WSM6 and TEMPO:

    case ("mp_wsm6","mp_tempo")
       do i = its,ite
          refl10cm_1km_max(i) = max(refl10cm_1km_max(i),refl10cm_1km(i))
       enddo

The regression comparison script produces output like the following:

DIFFER : VARIABLE : refl10cm_1km_max : POSITION : [0,14] : VALUES : 13.2455 <> 0

Since it compares the baseline against the feature, I think the baseline (here, MPAS-Dev) is the non-zero value and 0 is the feature (based on ufs-community) value. That's kind of the opposite of what I would've expected from the code differences above, so perhaps I'm interpreting the comparison incorrectly or there's another code difference I didn't catch.

Tagging @barlage and @dustinswales on this for their awareness.

[clark-evans]

Digging into the refl10cm_1km_max-related code we inherited from NSSL (the NSSL_realtime branch), there's something like it in the microphysics driver:

refl10cm_1km_max(i) = max(refl10cm_1km_max(i),dBZ1d(17)) (see here)

This code was changed with #39, changing it to something like its current version (albeit with mp_thompson then instead of mp_tempo now). Thus, I assume this is something we inherited from NSSL, and the diagnostic differences are to be expected.

[barlage]

@clark-evans @dustinswales I can't remember my motivation now, but I did purposely omit the diag file comparison from my scripts (probably because it wasn't changing the state answers and that is what I was primarily concerned with). Clearly it is good to have it so we know there are these differences.

[dustinswales]

@clark-evans It looks like in #39 that the wsm6 diagnostic calculations were removed and replaced by using the same diagnostic calculations for thompson. (wsm6 previously used its own procedure for reflectivity calculation.)
Also, I wonder if #39 might be something that is needed by MPAS-Dev?

[clark-evans]

@clark-evans It looks like in #39 that the wsm6 diagnostic calculations were removed and replaced by using the same diagnostic calculations for thompson. (wsm6 previously used its own procedure for reflectivity calculation.) Also, I wonder if #39 might be something that is needed by MPAS-Dev?

The reflectivity calculations in the microphysics driver could use some cleaning up. MPAS-Dev doesn't have a compute_hourly_max_radar_reflectivity subroutine in the microphysics driver, instead doing it inside of the primary compute_radar_reflectivity subroutine. Even with the added subroutine in our code base, the non-TEMPO Thompson schemes still do the max calculation in compute_radar_reflectivity. It's a bit of a jumble.

FWIW, the NSSL_realtime branch in our repo has this compute_hourly_max_radar_reflectivity subroutine. MPAS-Dev does not, even dating back to their ancient atmosphere/v6.x-openacc branch. It's something NSSL added but I'm not sure why, nor am I sure if it's really needed. Most of the code in ours is commented out, and versions of that which isn't are in compute_radar_reflectivity (just commented out there). This might be something we can clean up, which could help @AndersJensen-NOAA with translating TEMPO to MPAS-Dev in the next few weeks.

Also FWIW, MPAS-Dev does have the i-loop and max statement for refl10cm_1km_max for WSM6 -- just in the compute_radar_reflectivity subroutine. I'm not sure if having it in different subroutines would lead to output differences, though.

Agree with @barlage that it is good to have the comparison. We'll just want developers to be aware that differences vs. MPAS-Dev for refl10cm_1km_max and updraft_helicity_max are to be expected.

[dustinswales]

@clark-evans Thanks for the explanation.
It's always good to know where changes to results crept in. I added a new label "answer changing" and attached it to #39.