Add mmm physics as submobule.

[dustinswales]

This adds mmm_physics as a submodule to the repository.
This is an alternate solution to #231

Future updates to mmm_physics will be handled by updating the submodule hash., just as all other physics submodules. This removes the need for Manage_externals in our fork.

Mandatory Questions

• Does this PR include any additions or changes to external inputs (e.g., microphysics lookup tables, static data for gravity-wave drag -- things like that)?
  No
• Does this PR require updating one or more baselines for the CI tests? If so, what?
  No

Priority Reviewers

@guoqing-noaa

[guoqing-noaa]

@dustinswales @clark-evans
NCAR is working on another route to include checkout_externals inside CMakeLists.txt:
MPAS-Dev#1421

It will be great if we can start the talk about how to efficiently manage the submodules as early as possible. Thanks!

[dustinswales]

@guoqing-noaa Thanks for sharing this.
I worry about having the code checkout step as part of the CMake process (i.e. buildtime).
If the external is not to be developed (e.g., NetCDF), then this is fine from a workflow perspective, but still problematic for operational systems since it's not self-contained.

Using Git submodules gets around all of this, but I will leave it to NCAR.

[clark-evans]

@dustinswales @clark-evans NCAR is working on another route to include checkout_externals inside CMakeLists.txt: MPAS-Dev#1421

It will be great if we can start the talk about how to efficiently manage the submodules as early as possible. Thanks!

Thanks for pointing us to that new PR, @guoqing-noaa. I'd advocate that we adopt their approach for now. That will reduce merge conflicts when we sync with MPAS-Dev releases and also minimize the amount of additional code we have to manage. I agree that a larger discussion about managing external submodules is warranted in short order. There are many methods for doing so, each with their strengths and weaknesses. I'll be interested in hearing more about their perceptions and needs.

[guoqing-noaa]

I think we can close PR #231 but pursue the git submodule way in this PR.
And it will not conflict with NCAR's method.

(IMHO, checking out repos at the CMake runtime is not a good way forward).

[guoqing-noaa]

I suggest we include UGWP as a submodule as well in this PR. Although it does not give us problems at this moment, but always checking out the latest UGWP is NOT what we want and it may cause similar build failures unexpectedly in the future.

[dustinswales]

@guoqing-noaa We have two flavors of UGWP. One is already an MPAS submodule for the ufs-community usage, but is also part of Externals.cfg
Both use the same hash/tag, MPAS_20241223

That's just to say that we don't need to add UGWP submodule, the mmm-physics was the last one not "submodulized".

[guoqing-noaa]

@guoqing-noaa We have two flavors of UGWP. One is already an MPAS submodule for the ufs-community usage, but is also part of Externals.cfg Both use the same hash/tag, MPAS_20241223

That's just to say that we don't need to add UGWP submodule, the mmm-physics was the last one not "submodulized".

@dustinswales I did not notice this part. Thanks for the information!

[guoqing-noaa]

LGTM. Thanks, @dustinswales

[clark-evans]

If @AndersJensen-NOAA is OK with it, let's merge so that that Cmake CI tests stop failing because of the updated MMM-Physics version.

[clark-evans]

@dustinswales can you go ahead and update the version number to v8.3.1-2.20? I don't have write access to your commit/associated fork to do so.