Fix NSSL MP init issue when initialized from other microphysics schemes

[JiliDong-NOAA]

Description

This is the fix from Ted Mansell @MicroTed on NSSL MP initialization to check if there is missing number of concentration for any non-zero hydrometers mixing ratio. NSSL MP will calculate N from mixing ratio in the first timestep if missing value is found. This fix will guarantee that NSSL MP enters the correct warm/cold start initializations.

Issue(s) addressed

Link the issues to be closed with this PR, whether in this repository, or in another repository.
(Remember, issues should always be created before starting work on a PR branch!)

• fixes #<issue_number>
• fixes noaa-emc/fv3atm/issues/<issue_number>

Testing

How were these changes tested?

• Tested on Hera. This fix removes the initial reflectivity surge with NSSL MP when warm starting from Thompson MP initial conditions.

What compilers / HPCs was it tested with?

• intel on Hera.

Are the changes covered by regression tests? (If not, why? Do new tests need to be added?)

• No change on regression tests as no RT is warm starting with NSSL MP from Thompson MP initial conditions

Have the ufs-weather-model regression test been run? On what platform?

• Yes. On Hera

• Will the code updates change regression test baseline? If yes, why? Please show the baseline directory below.

• No

• Please commit the regression test log files in your ufs-weather-model branch

Dependencies

ufs-community/ccpp-physics#157

If testing this branch requires non-default branches in other repositories, list them.
Those branches should have matching names (ideally)

Do PRs in upstream repositories need to be merged first?
If so add the "waiting for other repos" label and list the upstream PRs

• waiting on noaa-emc/nems/pull/<pr_number>
• waiting on noaa-emc/fv3atm/pull/<pr_number>

[MicroTed]

I'll just add a note about why this sets a flag for use by the run routine instead of setting values directly in the init routine. As far as I can find, changing the values of 3D tracer variables in the mp_init routine has no effect on the actual initial condition from FV3. One can check that the values do indeed come back from the init call in atmos_model.F90, but the arrays that then come to mp_run on the first time step are unchanged. (On the other hand, other variables do carry over, like the 2D surface aerosol values set in mp_thompson_init, but the 3D values it sets remain zero.)

It would be great if somebody knows how to fix this initial 3D state variable problem. It appears that atmos_model.F90 is just passing a copy to the init routines that doesn't update the 'q' array in atmos_cubed_sphere?

[DusanJovic-NOAA]

Please list the corresponding ccpp physics PR in the Dependencies section of the PR template

[JiliDong-NOAA]

Please list the corresponding ccpp physics PR in the Dependencies section of the PR template

ccpp-physics PR is already there in the Dependencies section. Do you mean somewhere else?

[DusanJovic-NOAA]

Please list the corresponding ccpp physics PR in the Dependencies section of the PR template

ccpp-physics PR is already there in the Dependencies section. Do you mean somewhere else?

Ok, I see it. Sorry I missed it somehow.

[BrianCurtis-NOAA]

EPIC will start on the UFSWM PR this is attached to Today/Tomorrow.

[BrianCurtis-NOAA]

Forgot to mention, make sure you're ready to sync up to auth repo once the current UFSWM PR is merged later today. This includes updating the hash once the CCPP-Physics PR is updated.

[jkbk2004]

This PR is ready to merge. ufs-community/ccpp-physics#157 was merged.