Logging with current default parameter values is crashing with #1116

[glemieux]

During testing of #1116 using the update ctsm api from ESCOMP/CTSM#2507, I'm finding that the update fates logging regression test is currently failing with the following error output:

  1  Nan values for pftareafrac. dumping site info.
  2  ----------------------------------------
  3   Site Coordinates
  4  ----------------------------------------
  5  latitude                    =   -78.0000000000000
  6  longitude                   =    345.000000000000
  7  ----------------------------------------
  8  profile tolerance is too big, this shouldnt happen.
  9  probably this means there are too many distinct categorical
 10  patch types for the maximum number of patches
 11  ----------------------------------------
 12   Site Coordinates
 13  ----------------------------------------
 14  latitude                    =    22.0000000000000
 15  longitude                   =    290.000000000000
 16  ----------------------------------------
 17  currentSite%area_bareground  0.213030526566912
 18  i, currentSite%area_pft(:,i)           1  0.173217834410892
 19   6.608295341127601E-002  0.000000000000000E+000  0.000000000000000E+000
 20   1.522512761932222E-002  0.000000000000000E+000  0.000000000000000E+000
 21   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 22   0.000000000000000E+000  0.745474084558510
 23  i, currentSite%area_pft(:,i)           2  0.173217834410892
 24   6.608295341127601E-002  0.000000000000000E+000  0.000000000000000E+000
 25   1.522512761932222E-002  0.000000000000000E+000  0.000000000000000E+000
 26   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 27   0.000000000000000E+000  0.745474084558510
 28  i, currentSite%area_pft(:,i)           3  0.000000000000000E+000
 29   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 30   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 31   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 32   0.000000000000000E+000   1.00000000000000
 33  i, currentSite%area_pft(:,i)           4  0.000000000000000E+000
 34   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 35   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 36   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 37   0.000000000000000E+000   1.00000000000000
 38  i, currentSite%area_pft(:,i)           5  0.000000000000000E+000
 39   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 40   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 41   0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 42    1.00000000000000       0.000000000000000E+000
 43   2.928918333004281E-003          11           5
 44   5.981851861821862E-005          11           5
 45   2.596355497186480E-004          11           5
 46   6.805614055783362E-004          11           5
 47    354.797949290645               11           5
 48   0.930813331389729               11           2
 49    5601.46397524511               12           2
 50    114.401031027993                5           2
 51    496.544803606800                2           2
 52    1301.55223289514                1           2
 53    2130.30526566912                0           0
 54  ENDRUN:
 55  ERROR in EDPatchDynamicsMod.F90 at line 3183

Note that this regression test has been updated via ESCOMP/CTSM#2507 as the mode to engage logging has changed from use_fates_logging to fates_harvest_mode = 'event_code'. The regression test has also been increased from 30 to 60 days to more appropriately capture the default parameter file logging event time of -30 (i.e. on the 30th timestep).

[glemieux]

It turns out this was due to an issue that cropped up in the development of CTSM#2507, which has been addressed via ESCOMP/CTSM@a486e86