ExtData updates fixing #61

[LiamBindle]

ExtDataGridComp fixes for:

• exports with nonconstant frequencies (i.e. months or years)
• GCHP crashing when stepping into a leap day

@jmoch1214, could you confirm if this fixes the problem for you?

Related:

• [BUG/ISSUE] GCHP crash on reading in lightning NOx when trying to start a simulation in February 2016 and crash when trying to do a leap day #61

[LiamBindle]

@msulprizio I think this will fix the error you ran into in spinning up the 1-year benchmark. Once this is merged, I think we're good to go on that.

[LiamBindle]

The RRTMG simulation still throws an error when the simulation steps onto a leap day. It looks like this does fix stepping into a leap day for standard simulations though.

@sdeastham Do you have any ideas of what could cause RRTMG to crash on a leap day, but not the standard simulation?

[LiamBindle]

I'm going to merge this to avoid holding up the benchmark

[sdeastham]

Hmm. Not sure - where is the error thrown from?

[LiamBindle]

It's an error in CheckUpdate() (line 4341) where it calls timestamp_(). The simulation crashes in timestamp_() (on line 2013) when it gets to the ESMF_TimeSet() in the following

           ! apply the timestamp template
           call ESMF_TimeGet(time, yy=yy, mm=mm, dd=dd, h=hs, m=ms, s=ss, __RC__)

           i = scan(str_yy, '%'); if (i == 0) read (str_yy, '(I4)') yy
           i = scan(str_mm, '%'); if (i == 0) read (str_mm, '(I2)') mm
           i = scan(str_dd, '%'); if (i == 0) read (str_dd, '(I2)') dd
           i = scan(str_hs, '%'); if (i == 0) read (str_hs, '(I2)') hs
           i = scan(str_ms, '%'); if (i == 0) read (str_ms, '(I2)') ms
           i = scan(str_ss, '%'); if (i == 0) read (str_ss, '(I2)') ss

           call ESMF_TimeSet(timestamp_, yy=yy, mm=mm, dd=dd, h=hs, m=ms, s=ss, __RC__)

(the model crashes at 2016-02-29 at 00:00:00)

[sdeastham]

Which line does it fail on (specifically which line of the ones quoted there)?

[LiamBindle]

This one:

call ESMF_TimeSet(timestamp_, yy=yy, mm=mm, dd=dd, h=hs, m=ms, s=ss, __RC__)

[sdeastham]

Ah, damn. OK - some logic needs to be added there to deal with the situation when we want to extrapolate leap day information from non-leap-year files. I have (had?) logic elsewhere in ExtData which deals with that, but I'm guessing that when reading one of the RRTMG input files (maybe the MODIS surface information or TES profiles) it is using some slightly different logic to do the extrapolation - CheckUpdate is, for example, new (I think) since I wrote my klunky older logic. I'm guessing that an invalid date (e.g. "2002-02-29") is being passed to ESMF_TimeSet, because it's taking today and adding a simple year offset.

[yantosca]

Have you guys thought about using the astronomical Julian day routine? That's what we use in GEOS-Chem Classic and GEOS-Chem Classic History. AJD is an increasing count from a time point way in the past... and the algorithm is set up to handle these leap years and end of century/millenia gracefully.

NOTE: In GCC History, I use the Julian day and convert it to seconds, as that is the only way to avoid roundoff issues.

Just a thought...not sure how easy it is to implement it into MAPL though.

[sdeastham]

Thanks Bob! I suspect that ESMF does use that, internally. The problem here is that we need to grab data for "this day, but N years ago/in the future" - and that's not a valid date. It actually also raises the related issue of what is the correct date to grab (if we want Feb 29th's equivalent in 2002, should we return the data for Feb 28th or March 1st?) but whatever we do it should be consistent with what we do elsewhere for sure!