The Gregorian and Proleptic-Gregorian are the same and should be
treated the same, so it looks like we do have a bug. What does
the ncdump header show for the time axis in your file?
And thanks for the example, Russ.
Ansley
Hi,
Yes, there is definitely a bug with the proleptic gregorian time axes leap year algorithm. These axes should be the same.
NOAA/PMEL TMAP
FERRET v7.5 (optimized)
Linux 4.18.0-80.el8.x86_64 64-bit - 12/16/19
26-May-20 11:33
yes? def axis/t/t0="1-jan-1804"/units=days/cal="gregorian"/nam=tax_gr l[l=1:366]-0.5
yes? def axis/t/t0="1-jan-1804"/units=days/cal="proleptic_gregorian"/nam=tax_pgr l[l=1:366]-0.5
yes? sho axis/all
...TAX_PGR TIME 366 r 01-JAN-1804 12:00 01-JAN-1805 12:00
TAX_GR TIME 366 r 01-JAN-1804 12:00 31-DEC-1804 12:00
yes? let var=l[gt=TAX_PGR]
yes? list var[l=58:60]
VARIABLE : L[GT=TAX_PGR]
SUBSET : 3 points (TIME)
CALENDAR : PROLEPTIC_GREGORIAN
27-FEB-1804 12 / 58: 58.00
28-FEB-1804 12 / 59: 59.00
01-MAR-1804 12 / 60: 60.00 <------------Oops!
Cheers,Russ
From: owner-ferret_users@xxxxxxxx <owner-ferret_users@xxxxxxxx> on behalf of Rebecca Lynn Beadling <beadling@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, 26 May 2020 10:39 AM
To: ferret users <ferret_users@xxxxxxxx>
Subject: [ferret_users] Different behavior when reading calendars between Pyferret V7.1 and Pyferret V7.5Hi Ferret community,
I have two different versions on pyferret: V7.1 on my Mac OS X El Capitan and V.7.5 on a Linux Red Hat workstation. The reason I retained the previous version of pyferret on my Mac was to be sure that my old analysis scripts would run flawlessly if there were differences when upgraded to the newer release. Having been working between the two different systems I have noticed two differences that have impacted my figures / analysis. I am going to split this into two separate emails since these topics are not related.
The first issue regards how the two versions handle the proleptic gregorian calendar:
when reading in the same exact file.
Using Pyferret V7.1 on OS X El Capitan:
list siconc_gt_15[d=3,l=1,x=1,y=1]
VARIABLE : CURV_TO_RECT(SICONC_ONLY[D=1], MAP[D=2])
FILENAME : siconc_SImon_MPI-ESM1-2-LR_historical_r1i1p1f1_gn_198601-200512_1x1_regrid_only_gt_15.nc
LONGITUDE: 0.5E
LATITUDE : 0.5N
TIME : 16-JAN-1986 12:00
....
say `siconc_gt_15,return=calendar`
!-> MESSAGE/CONTINUE GREGORIAN
GREGORIAN
Using Pyferret V7.5 on Linux RedHat
yes? list siconc_gt_15[d=1,l=1,x=1,y=1]
VARIABLE : CURV_TO_RECT(SICONC_ONLY[D=1], MAP[D=2])
FILENAME : siconc_SImon_MPI-ESM1-2-LR_historical_r1i1p1f1_gn_198601-200512_1x1_regrid_only_gt_15.nc
LONGITUDE: 0.5E
LATITUDE : 0.5N
TIME : 18-FEB-1986 12:00 PROLEPTIC_GREGORIAN
....
yes? say `siconc_gt_15,return=calendar`
!-> MESSAGE/CONTINUE PROLEPTIC_GREGORIAN
PROLEPTIC_GREGORIAN
Any ideas on why this is happening? The correct calendar label in the .nc file is proleptic gregorian, but my understanding is for the modern time period proleptic gregorian and gregorian are equivalent. It seems like V7.1 equates this to Gregorian and thus it allows me to compute a seasonal climatology just fine, yet I can't do this in V7.4 since it reads it as proleptic.
yes? let MPIESM12LR_clim = MPIESM12LR_SIE[gt=MONTH_GREGORIAN@mod]
yes? plot MPIESM12LR_clim
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-becki'
**ERROR: regridding: only @ASN, @LIN, or @NRST regridding between calendar types: PROLEPTIC_GREGORIAN, GREGORIAN
If you also notice in the TIME dimension output above, V7.1 : TIME : 16-JAN-1986 12:00, while V.7.5 reads 18-FEB-1986 12:00 PROLEPTIC_GREGORIAN.
When I ncdump -t -v -time for the file, the correct time stamp should be: "1986-01-16", so V7.5 appears to be incorrectly shifting it.
Thanks ahead of time for any insight,
Becki
--
Rebecca Beadling | Graduate Student | EPA STAR FellowDepartment of Geosciences | University of Arizona
-- Ansley Manke Science Data Integration Group NOAA Pacific Marine Environmental Laboratory 7600 Sand Point Way NE Seattle WA 98115 I am currently teleworking and am available Tue-Wed-Thu.