Add MMM-physics as a git submodule

[islas]

TYPE: no impact

KEYWORDS: git, submodule, manage_externals

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
MMM-physics (under phys/physics_mmm) is currently the only external repository tracked with only manage_externals. This makes manage_externals and git two failure points for a proper clone of WRF to succeed.

Solution:
Add MMM-physics as a git submodule using the original path of phys/physics_mmm). To avoid confusion in managing two locations of the submodule (one in .gitmodules and the other in arch/Externals.cfg) the MMM-physics repo is removed from manage_externals. From a user perspective, no change to the build process is evident.

TESTS CONDUCTED:

1. Build proceeds as normal from a fresh clone.

[dudhia]

Can we put this above MYNN-EDMF in order?

[islas]

We could, but I don't think I understand why we would want to do that. Is there any particular reason to change the order?

[dudhia]

Currently it is between two MYNN packages, and also other new ones may be put after MYNN PBL. I already resolved one conflict for TEMPO being put there.

[islas]

I don't see that fix for TEMPO as it still between the two MYNN packages. Regardless, this is a metadata file for git to use where order should not matter.

[mgduda]

I think it comes down to a desire to keep the MYNN schemes together in the list of submodules (and similarly in the Makefile logic, I would assume). This seems reasonable enough to me.

[dudhia]

TEMPO is not merged yet, but I resolved that conflict. It was added to older code that didn't have MYNNSFC yet.

[islas]

@dudhia For #2270, even after the merge conflict being resolved it looks like it will place the submodule between the two MYNN submodules.

And very well, I'll make the changes to the .gitmodules and Makefile to ensure MYNN colocality.

[dudhia]

Yes, the conflict resolution didn't allow me to swap them just allow both.

[mgduda]

@islas Is this PR meant to address the build failures that we were seeing in the WRF "coop" container?

[islas]

Yes. This should resolve the issues as this will take the same logic path that our remaining external repos use.

[weiwangncar]

The regression test results:

Test Type              | Expected  | Received |  Failed
= = = = = = = = = = = = = = = = = = = = = = = =  = = = =
Number of Tests        : 23           24
Number of Builds       : 60           57
Number of Simulations  : 158           150        0
Number of Comparisons  : 95           86        0

Failed Simulations are: 
None
Which comparisons are not bit-for-bit: 
None

[mgduda]

Will there be any problems if a contributor updates only the git submodule or the Externals.cfg file (i.e., one, but not both)?

[islas]

@mgduda Yes, sort of. Since manage_externals runs last of two, it will have priority when working. Although we don't often update this submodule, this could become confusing in the future.

[mgduda]

Perhaps it would be better overall if there were just one way of incorporating external repositories.

[islas]

Agreed. This proposed change was based on the assumption that we wanted to keep manage_externals in some capacity and avoid wholly switching the repo reference over. However, maybe the potential headache it could cause down the road is worth just addressing now.