Refactor loops that use max_patch_per_col?

[glemieux]

Per our discussion during the ctsm software meeting today, here is the list of locations in which max_patch_per_col is being used as an upper bound in different loop structures. I came upon this variable when troubleshooting an issue with the elm-fates integration for NGEET/fates#1040, in which the number of patches that fates needs was not being updated. This turns out not to be a problem for clm-fates, but it did lead to a discussion in which @rgknox and I asked the ctsm software team if this looping structure was out-of-date and could use a refactor, particularly since the use of max_patch_per_col seems fairly limited.

Definition of max_patch_per_col:

CTSM/src/main/clm_varpar.F90

Line 203 in 5df6c98

max_patch_per_col= max(maxsoil_patches, surf_numcft, maxpatch_urb)

Locations of use:

CTSM/src/biogeophys/SoilWaterPlantSinkMod.F90

Line 202 in 5df6c98

do pi = 1,max_patch_per_col

CTSM/src/biogeophys/SoilWaterPlantSinkMod.F90

Line 311 in 5df6c98

do pi = 1,max_patch_per_col

CTSM/src/biogeophys/SoilWaterPlantSinkMod.F90

Line 402 in 5df6c98

do pi = 1,max_patch_per_col

CTSM/src/biogeochem/CNPhenologyMod.F90

Line 3442 in 5df6c98

do pi = 1,max_patch_per_col

CTSM/src/biogeochem/CNCIsoFluxMod.F90

Line 1279 in 5df6c98

do pi = 1,max_patch_per_col

CTSM/src/biogeophys/SoilTemperatureMod.F90

Line 1553 in 5df6c98

do pi = 1,max_patch_per_col

CTSM/src/biogeophys/SoilTemperatureMod.F90

Line 1642 in 5df6c98

do pi = 1,max_patch_per_col

[ekluzek]

I want to highlight the note from @billsacks in clm_varpar that notes that max_patch_per_col is in itself a problem...

    ! TODO(wjs, 2015-10-04, bugz 2227) Using surf_numcft in this 'max' gives a significant
    ! overestimate of max_patch_per_col when use_crop is true. This should be reworked -
    ! or, better, removed from the code entirely (because it is a maintenance problem, and
    ! I can't imagine that looping idioms that use it help performance that much, and
    ! likely they hurt performance.)

@billsacks do you have more to say on this?

[billsacks]

I'll just add / reiterate that I would whole-heartedly endorse refactoring these looping structures to avoid the need for max_patch_per_col, if possible.

[slevis-lmwg]

Refactored CNPhenology and this test passed:
./create_test SMS_D_Ld3.f10_f10_mg37.I1850Clm50BgcCrop.cheyenne_intel.clm-default -c /glade/p/cgd/tss/ctsm_baselines/ctsm5.1.dev130

Refactored CNCIsoFlux (though I plan to do more) and the test passed.

[slevis-lmwg]

In CNCIsoFlux, I also refactored cases similar to the above but with do pi = 1, maxsoil_patches and the same test passed.

TODO (adding to the orig. list)
src/soilbiogeochem/SoilBiogeochemVerticalProfileMod.F90: do pi = 1,maxsoil_patches
src/dyn_subgrid/dynHarvestMod.F90: do pi = 1,maxsoil_patches
src/dyn_subgrid/dynGrossUnrepMod.F90: do pi = 1,maxsoil_patches
src/biogeochem/CNGapMortalityMod.F90: do pi = 1,maxsoil_patches