NOAA-GFDL/MDTF-diagnostics

Time calendar 'noleap' in MJO_prop_amp POD

Opened this issue · 1 comments

Wen-hao-Dong commented

Bug Severity

  • 1 = Minor problem that does not affect total framework functionality (e.g., computation error in a POD, problem with logging output, or an issue on a single system
  • 2 = Major problem that affects overall functionality, but that does not occur for all users (e.g., problems installing the framework with a specific Conda version, a framework option that causes one or more PODs to fail, or missing/incompatible Python modules).
  • 3 = Catastrophic problem that occurs frequently for multiple users and/or on multiple systems (e.g.,framework consistently fails to install on multiple systems, or one or more PODs continuously fails after running successfully)

Describe the bug
MJO_prop_amp POD will fail if the time calendar is NOT set to 'noleap'

Steps To Reproduce
When MJO_prop_amp POD is applied to any data with the time calendar to be 'julian, gregorian, or standard' (e.g., the GFDL AM4 simulations), it will fail due to the processing of the time in the code

Environment
Describe the system environment:

  • OS: [e.g. RHEL 7.2]
  • Conda version: [the conda info command will provide the installation information]
  • branch name and link: [e.g., develop, https://github.com/NOAA-GFDL/MDTF-diagnostics/tree/develop]

Log information and/or terminal output
The error message just complained the index is out of range pointing to L260 in m_diag.ncl (f1 = pr(id_seas+ll,:,:)) . The underlying reason is:
In the m_intp.ncl there are several do end do blocks trying to reset the time for the interpolated data. Take precipitation as an example:

newtime=newpr&time
ntim = dimsizes(newpr&time)
do i=0,ntim-1
newtime(i)=i
end do
newpr&time=newtime

And then when the data is written out, the time calendar is set to 'noleap'
fileattdef(fout, fAtt )
print("set atts on "+wk_dir+"/model/netCDF/model_pr.nc")
filedimdef(fout,"time",-1,True)
newpr2&time@calendar="noleap"
fout->pr = newpr2

Such a reset will cause the POD to fail if the time calendar is not 'noleap'.

The following are some details for the currently tested model simulation:

  1. time calendar: julian
  2. time units: days since 1979-01-01 00:00:00
  3. time range: 19800101-19841231

If we reset the time using the code shown above, the time range will become 19790101-19840102. This will cause the aforementioned error message because 19840101 and 19840102 also fall in the winter period between Nov-Apr. And they are the last two indices in the available time range, therefore, when the ll is greater than 0 or 1, id_seas+ll will exceed the available time range. And the similar thing for prw and hus.

wrongkindofdoctor commented

@Wen-hao-Dong This may not matter, but could you try re-running with an updated version of the main branch? The develop branch is deprecated, and has not been updated in several months.

This issue is being resolved with assistance w/POD developers. I'll make a note here to remind the team to have them submit a PR (or to submit a PR on the dev's behalf) with the fix when ready.