Remove excessive auto-inserted use statements

[mark-petersen]

This commit removes four "use" statements that are auto-inserted into
inc/namelist_defines.inc 86 times. This file is included in
mpas_$CORE_core_interface.F. The ocean, sea ice, and land ice
components have these four use statements at the top as well, which
causes a compile bug for intel 17 in the ocean. Martyn Corden, an intel
compiler developer, recommended single use statements before "contains"
to speed up compilation time.

[mark-petersen]

Here is an example of the reduction of "use" statements. Compiling with "GEN_F90=true", this is:

before this PR

wf-fe2.lanl.gov> grep 'use mpas_dmpar' src/core_ocean/driver/mpas_ocn_core_interface.f90 |wc
     86     172    1803

after this PR

wf-fe2.lanl.gov> grep 'use mpas_dmpar' src/core_ocean/driver/mpas_ocn_core_interface.f90 |wc
      1       2      18

This is because of the auto-generated code at the end of the interface file. All cores have this line:

wf-fe2.lanl.gov> tail -n 4 src/core_ocean/driver/mpas_ocn_core_interface.F
#include "../inc/namelist_defines.inc"

[mark-petersen]

This is a PR into framework, but I tested this commit in all four CORE/develop branches:

ocean, sea ice, land ice

• already have the needed use statements at the top of mpas_CORE_core_interface.F, before contains.
• this is a bug, and causes compile errors for intel 17 in the ocean model.
• I tested this commit and compiled on all three cores without trouble.

atmosphere

• grep 'use mpas_dmpar' src/core_atmosphere/inc/namelist_defines.inc|wc shows 9 instances
• does not have use statements at the top of mpas_CORE_core_interface.F, before contains
• I made a PR Add use statements to top of core interface file #1209 to add these to the top.
• I test compiled this commit with PR Add use statements to top of core interface file #1209 without trouble.

[mgduda]

This PR looks fine to me. I'm generally in favor of having subroutines be "self-contained" insofar as they include all modules that they need. But, I think in the interest of fixing this for ACME as soon as possible, I have no objections.

As I mentioned in the comments for PR #1209 I think we should merge that PR before this one so that we don't have a merge where the atmosphere cores don't build.

[mark-petersen]

@mgduda on your comments of order of commits: Do you mean that #1209 would need to be merged into atmosphere/develop, and then atmosphere/develop moved into develop before this PR is merged in? You mean if we merged this one first, then the atmosphere would not build on develop for that commit, right?

[matthewhoffman]

This looks good to me too. I think these auto-generated routines are a special situation, so if we have to violate the preferred self-contained approach for subroutines, that is a reasonable concession.

[mgduda]

@mark-petersen Apologies for the slow reply. My concern is that if we merge this PR into develop, then the atmosphere and init_atmosphere cores will have a point on develop at which they don't compile. So, I was thinking to merge #1209 onto develop in advance of this PR; alternatively, we could just include the commits from #1209 in this PR.

[mark-petersen]

@mgduda I will add the commits from #1209 to this PR right now, and then close #1209.

[mark-petersen]

@mgduda everything is in this PR now - the changes needed for the atmosphere core can be merged directly into develop. I did a test compile using

make ifort CORE=atmosphere GEN_F90=true DEBUG=true

and it compiled to completion. @mgduda if you give us an "OK", one of us can merge it in.

[mgduda]

This PR looks good to me. Both the init_atmosphere and atmosphere cores compile after merging to 'develop'.