Probable bug in MAPL solar code

[mathomp4]

In MAPL_sun_uc.F90 we have two ways of handling running past the end of the NRL Solar data. By default we "persist" in that if the date of the run is past the end of the NRL file, we just persist the last value:

https://github.com/GEOS-ESM/MAPL/blob/main/base/MAPL_sun_uc.F90#L2651

This is obviously always safe.

But the other option is to instead repeat values from Cycle 24 (the last complete cycle) so that you have a pseudo-cycle 24 and it'll give you more realistic solar data:

https://github.com/GEOS-ESM/MAPL/blob/main/base/MAPL_sun_uc.F90#L2668

In that code, essentially if you are 1000 days past the end of Cycle 25 and that's after the end of the data, you are instead provided with the data from 1000 days into Cycle 24.

But I realize now my code has a bit of a bug. Cycle 24 was 11 years long so if you run GEOS 11 years into the future when the pseudo-Cycle 24 would end, I'm pretty sure this code will...crash? fail? Not sure, but it seems undefined from my reading.

I think what needs to be done is figure out how to do the ESMF Time bits right so this pseudo-cycle will continue ad infinitum. So you can run forever and it just keeps repeating Cycle 24.

I'm adding @darianboggs and @tclune to this so they can help me think on this (and @darianboggs is sort of our ESMF Time expert now!). I'm also adding @dr0cloud as well as our radiation expert.

NOTE: This is a pretty rare thing. My guess is GEOS as it currently is would fail for ExtData reasons before this would be triggered as I don't think we have a full climatology emissions set anymore. But, someone might want to run a climate simulation at some point with a varying solar cycle and...

[darianboggs]

Well, I don't know of a way to specify that an ESMF_TimeInterval is repeating. I could not find anything in the reference manual of the latest nightly snapshot (v8.7.0b05) about repeating intervals. ISO8601 can specify repeating intervals by appending an Rn to an interval string like thisRnPnYnMnDTnHnMnS. (An ESMF_TimeInterval corresponds to an ISO8601 Duration or an ISO8601 Interval.) So, I think that this would be MAPL feature.

[dr0cloud]

Hi @mathomp4 and @darianboggs, I don't think we need to have a specifically ESMF solution to this. Just in the non-persist mode, whenever it runs off the Solar Cycle 24 table, it starts back at the beginning of the table. You can have an actualTime and a tableTime. Initially you say tableTime = begOfLastCompleteSolarCycleTime + (actualTime - endOfLastCompleteSolarCycleTime). Then: while (tableTime > endOfLastCompleteSolarCycleTime) actualTime -= lengthOfLastCompleteSolarCycleTime, the latter length being (endOfLastCompleteSolarCycleTime - begOfLastCompleteSolarCycleTime). This ought to end when we have a valid tableTime inside the lastSolarCycle. Of course this is just pseudo-code. We need to be careful to watch for off-by-one errors and issues of interpolation between points in the table. Matt do you want to have a crack at it, or shall I? P.

[tclune]

Agree with @dr0cloud , but also not seeing the problem of doing this with ESMF time. We don't need a "repeating" interval. Just a duration and modulo arithmetic with the time.

[darianboggs]

There is a mod function for two ESMF_TimeInterval instances, but I haven't used it. ESMF has ESMF_TimeInterval instances that are specific date ranges (ISO8601 Intervals) and general durations (ISO8601 **Durations). I assume the divisor must be a general duration, but I don't know if the dividend can be a specific date range or a general duration. We might be able to use it to calculate tableTime.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 60 days. If there are no updates within 7 days, it will be closed. You can add the ":hourglass: Long Term" label to prevent the stale action from closing this issue.