Tom,
Are we going to get an updated gempak distribution once you are confident this
fix works?
Thanks,
Chris
Sent from my iPad
> On Jan 1, 2021, at 7:59 PM, Tom Yoksas <yoksas@xxxxxxxx> wrote:
>
> Hi Larry and David,
>
>> On 1/1/21 5:26 PM, Larry D. Oolman wrote:
>> I found that incorrect file names created from a YYYY template were being
>> done
>> in gemlib/fl/flmnam.f
>
> David Blanchard wrote:
> > I ran a search* and found several files that may need updating:
> >
> > .../gemlib/ti/ticcnt.f
> > .../gemlib//ti/tiyy24.f
> > .../gemlib/fl/flmnam.f
> > .../gemlib/im/imnohd.f
> > .../gplt/transform/mcidas/mcnav.f
> >
> > * did a string search in all *.f files for ".le. 20". Most were false >
> > positives.
>
> Thanks for the information!
>
> Based on David and Larry's input, I modified:
>
> .../gemlib/fl/flmnam.f
> .../gemlib/im/imnohd.f
>
> This was in addition to having already made changes to:
>
> .../gemlib/ti/tiyy24.f
> .../gemlib/ti/ticcnt.f
> .../gemlib/ti/tiyyyy.f
> .../gemlib/ti/ctiyyyy.c
>
> Before making the changes to:
>
> .../gemlib/fl/flmnam.f
> .../gemlib/im/imnohd.f
>
> I had tried rebuilding the entire package from scratch to no avail.
> After making the changes to these two files, I simply rebuilt the
> object files, updated them in $GEMLIB/gemlib.a, and then remade the
> nex2gini and nexrcomp executables and installed them in $GEMEXE.
>
> I now see that properly named composites are being created and inserted
> into the LDM queue for dissemination. Whether or not the files are
> fully viable is TBD.
>
> Larry and David: Many thanks for the help!
>
> Cheers,
>
> Tom
>
>>> On 1/1/21 2:41 PM, Tom Yoksas wrote:
>>>
>>> Hi Russ,
>>>
>>>> On 1/1/21 2:18 PM, Schumacher,Russ wrote:
>>>> I applied changes to the files mentioned by Daryl and John and
>>>> recompiled and that seemed to fix most of the problems. One strange
>>>> issue I'm seeing though is that the FNEXRAD feed has actually had
>>>> a mixture of timestamps today - some files dated 2021 and some dated
>>>> 1921.
>>>
>>> The '1921' dates are somehow related to the GEMPAK year 2021 and greater
>>> bug that has been a topic of discussion in the gembud list recently.
>>>
>>> The Product IDs in the FNEXRAD feed that had the year as '2021' this
>>> morning were a result of me trying things on the product generation
>>> side. The problem with just changing the Product ID date is the date
>>> inside of the product is still incorrectly being set to '1921'. After
>>> this dawned fact dawned on me, and I returned home, I stopped changing
>>> the Product ID, so the dates reverted to having '1921'.
>>>
>>> re:
>>>> In particular, many (but not all) of the files on our LDM between
>>>> 1645-1900 UTC were dated correctly (2021), but then went back to
>>>> being dated 1921 after that time. I don't know why that would happen
>>>> or what the fix might be there (is Unidata the primary source of that
>>>> feed?) Our LDM is just filing them based on the filename, so the
>>>> issue must exist with the actual creation of those files.
>>>
>>> Again, I was the one who was trying some things right after receiving
>>> an inquiry from a TDS user who noted that today's NEXRAD national
>>> composite files were all being labeled as being from 1921.
>>>
>>> All:
>>>
>>> I implemented the change to the two routines noted by Peter Manousos:
>>>
>>> cd $GEMPAK/source/gemlib/ti and edit two files (you may also want to
>>> copies this to a “.orig”) for reference
>>> modify tiyy24.f “.le. 20” to “.le. 25” (the 25 is for 2025 and
>>> you could make this more than 25 if you want but I assume Unidata
>>> will fix this by then)
>>> modify ticcnt.f “.le. 20” to “.le. 25”
>>>
>>> Instead of changing '20' to '25' as Peter suggested, I changed it to
>>> '40' as Pete Pokrandt suggested/mused about. I rebuilt GEMPAK hoping
>>> that the needed change(s) would take affect, but the routines creating
>>> the national composites, nex2gini and nexrcomp, are still creating
>>> output .gem files whose name use '1921' instead of '2021'. I assume
>>> that the date included internally in .gem file also uses '1921' instead
>>> of '2021'. To me, this suggests that there must be another routine that
>>> needs modification, but I have no idea of where to look to find it.
>>>
>>> If anybody has any ideas for where to look or the other file that needs
>>> modification, please let me know!
>>>
>>> Until the GEMPAK year 2021 bug gets fixed globally, the NEXRAD national
>>> composites in the IDD FNEXRAD feed will continue to be mislabeled and
>>> unusable.
>>>
>>> Cheers,
>>>
>>> Tom
>>>
>>>> On 12/31/20, 9:05 PM, "gembud on behalf of
>>>> gembud-request@xxxxxxxxxxxxxxxx" <gembud-bounces@xxxxxxxxxxxxxxxx on
>>>> behalf of gembud-request@xxxxxxxxxxxxxxxx> wrote:
>>>>
>>>> Send gembud mailing list submissions to
>>>> gembud@xxxxxxxxxxxxxxxx
>>>>
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.unidata.ucar.edu%2Flistinfo%2Fgembud&data=04%7C01%7Cruss.schumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I%2BGWkVmWGCn78%2FPydNcyyBOMSJWg40dvRhrW74WSLY8%3D&reserved=0
>>>>
>>>> or, via email, send a message with subject or body 'help' to
>>>> gembud-request@xxxxxxxxxxxxxxxx
>>>>
>>>> You can reach the person managing the list at
>>>> gembud-owner@xxxxxxxxxxxxxxxx
>>>>
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of gembud digest..."
>>>>
>>>>
>>>> Today's Topics:
>>>>
>>>> 1. Re: NMAP2 Data Selection Window Not seeing gridded data with
>>>> fhrs valid past Dec 31 2020 (Tyle, Kevin R)
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Fri, 1 Jan 2021 04:05:09 +0000
>>>> From: "Tyle, Kevin R" <ktyle@xxxxxxxxxx>
>>>> To: "Herzmann, Daryl E [AGRON]" <akrherz@xxxxxxxxxxx>, John Hart
>>>> <highbanker@xxxxxxxxx>
>>>> Cc: "gembud@xxxxxxxxxxxxxxxx" <gembud@xxxxxxxxxxxxxxxx>
>>>> Subject: Re: [gembud] NMAP2 Data Selection Window Not seeing gridded
>>>> data with fhrs valid past Dec 31 2020
>>>> Message-ID:
>>>>
>>>> <CY4PR0401MB3570AF0F2BACB9BF63DBA47ED6D50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>>>>
>>>>
>>>> Content-Type: text/plain; charset="windows-1252"
>>>>
>>>> Hah, 20 years later, we can finally really start partying like it's
>>>> 1999!
>>>>
>>>> _________________________________________________
>>>> Kevin Tyle, M.S.; Manager of Departmental Computing
>>>> NSF XSEDE Campus Champion
>>>> Dept. of Atmospheric & Environmental Sciences
>>>> University at Albany
>>>> Earth Science 228, 1400 Washington Avenue
>>>> Albany, NY 12222
>>>> ktyle@xxxxxxxxxx | 518-442-4578 | @nywxguy | he/him/his
>>>> _________________________________________________
>>>> ________________________________
>>>> From: Herzmann, Daryl E [AGRON] <akrherz@xxxxxxxxxxx>
>>>> Sent: Thursday, December 31, 2020 10:34 PM
>>>> To: John Hart <highbanker@xxxxxxxxx>
>>>> Cc: Tyle, Kevin R <ktyle@xxxxxxxxxx>; gembud@xxxxxxxxxxxxxxxx
>>>> <gembud@xxxxxxxxxxxxxxxx>
>>>> Subject: Re: [gembud] NMAP2 Data Selection Window Not seeing gridded
>>>> data with fhrs valid past Dec 31 2020
>>>>
>>>> Hi John,
>>>>
>>>> Thanks, testing that now! And wow, that's not fixed in the NCEP
>>>> GEMPAK version, which explains why NCEP is having troubles tonight!
>>>>
>>>> SYSTEMS STATUS...
>>>> NCO dataflow and software development support have been working
>>>> the issue with loading surface/upper air and lightning obs, and
>>>> WWA plots in NAWIPS. The problem appears to have been traced to
>>>> an LDM issue. We are attempting a fix to hard code the year until
>>>> we can engage UNIDATA support.
>>>>
>>>> daryl
>>>>
>>>> --
>>>> /**
>>>> * daryl herzmann
>>>> * Systems Analyst III -- Iowa Environmental Mesonet
>>>> *
>>>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmesonet.agron.iastate.edu%2F&data=04%7C01%7Cruss.schumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X39XixShrfRs%2FMrC0VVE4nCOYebmS7kBUme5qWhmRZc%3D&reserved=0
>>>>
>>>> */
>>>>
>>>> ________________________________________
>>>> From: John Hart <highbanker@xxxxxxxxx>
>>>> Sent: Thursday, December 31, 2020 9:30 PM
>>>> To: Herzmann, Daryl E [AGRON]
>>>> Cc: Tyle, Kevin R; gembud@xxxxxxxxxxxxxxxx
>>>> Subject: Re: [gembud] NMAP2 Data Selection Window Not seeing gridded
>>>> data with fhrs valid past Dec 31 2020
>>>>
>>>> I also believe that fl/flmnam.f needs fixed. That is what solved my
>>>> demetr issues.
>>>>
>>>>
>>>> On Thu, Dec 31, 2020 at 9:02 PM Herzmann, Daryl E [AGRON]
>>>> <akrherz@xxxxxxxxxxx<mailto:akrherz@xxxxxxxxxxx>> wrote:
>>>> Hi Kevin and others,
>>>>
>>>> I suspect there are more changes needed. Diffing Unidata's GEMPAK
>>>> against NCEP's GEMPAK for the gemlib/ti/ folder and removing the timezone
>>>> changes.
>>>>
>>>> diff --git a/gempak/source/gemlib/ti/ticcnt.f
>>>> b/gempak/source/gemlib/ti/ticcnt.f
>>>> index b5a62e39..722a5bf0 100644
>>>> --- a/gempak/source/gemlib/ti/ticcnt.f
>>>> +++ b/gempak/source/gemlib/ti/ticcnt.f
>>>> @@ -3,8 +3,8 @@
>>>> C************************************************************************
>>>> C* TI_CCNT
>>>> *
>>>> C*
>>>> *
>>>> C* This subroutine gets the first 2 digits of a 4-digit year based
>>>> on *
>>>> -C* the standard GEMPAK time. Any 2-digit year less than or equal to
>>>> 20 *
>>>> -C* will be assumed to be in the 21st century; years greater than 20
>>>> will*
>>>> +C* the standard GEMPAK time. Any 2-digit year less than or equal to
>>>> 40 *
>>>> +C* will be assumed to be in the 21st century; years greater than 40
>>>> will*
>>>> C* be assumed to be in the 20th century.
>>>> *
>>>> C*
>>>> *
>>>> C* TI_CCNT ( DATTIM, CENT, IRET )
>>>> *
>>>> @@ -22,6 +22,7 @@ C**
>>>> *
>>>> C* Log:
>>>> *
>>>> C* D. Kidwell/NCEP 2/99
>>>> *
>>>> C* D. Kidwell/NCEP 4/99 Allowed 4-digit year; corrected
>>>> prologue*
>>>> +C* B. Hebbard/NCEP 3/18 Moved century break from 2020 to 2040
>>>> *
>>>>
>>>> C************************************************************************
>>>> CHARACTER*(*) dattim, cent
>>>>
>>>> C------------------------------------------------------------------------
>>>> @@ -37,7 +38,7 @@ C
>>>> CALL ST_INTG ( dattim ( 1:2 ), iyear, iret )
>>>> IF ( iret .ne. 0 .or. iyear .lt. 0 ) THEN
>>>> iret = -7
>>>> - ELSE IF ( iyear .le. 20 ) THEN
>>>> + ELSE IF ( iyear .le. 40 ) THEN
>>>> cent = '20'
>>>> ELSE
>>>> cent = '19'
>>>> diff --git a/gempak/source/gemlib/ti/tidtm4.f
>>>> b/gempak/source/gemlib/ti/tidtm4.f
>>>> index 42adc6fb..56732911 100644
>>>> --- a/gempak/source/gemlib/ti/tidtm4.f
>>>> +++ b/gempak/source/gemlib/ti/tidtm4.f
>>>> @@ -4,8 +4,8 @@ C* TI_DTM4
>>>> *
>>>> C*
>>>> *
>>>> C* This subroutine modifies a standard GEMPAK time to include a
>>>> four- *
>>>> C* digit year, instead of a 2-digit year. Any 2-digit year less
>>>> than or*
>>>> -C* equal to 20 will be assumed to be in the 21st century; years
>>>> greater*
>>>> -C* than 20 will be assumed to be in the 20th century.
>>>> *
>>>> +C* equal to 40 will be assumed to be in the 21st century; years
>>>> greater*
>>>> +C* than 40 will be assumed to be in the 20th century.
>>>> *
>>>> C*
>>>> *
>>>> C* TI_DTM4 ( DATTIM, DATTM4, IRET )
>>>> *
>>>> C*
>>>> *
>>>> @@ -22,6 +22,7 @@ C**
>>>> *
>>>> C* Log:
>>>> *
>>>> C* D. Kidwell/NCEP 3/99
>>>> *
>>>> C* D. Kidwell/NCEP 4/99 Added 4-digit year check; fixed
>>>> prologue*
>>>> +C* B. Hebbard/NCEP 3/18 Moved century break from 2020 to
>>>> 2040 *
>>>>
>>>> C************************************************************************
>>>> CHARACTER*(*) dattim, dattm4
>>>> C*
>>>> diff --git a/gempak/source/gemlib/ti/tiyy24.f
>>>> b/gempak/source/gemlib/ti/tiyy24.f
>>>> index 22a1e509..f2883063 100644
>>>> --- a/gempak/source/gemlib/ti/tiyy24.f
>>>> +++ b/gempak/source/gemlib/ti/tiyy24.f
>>>> @@ -3,8 +3,8 @@
>>>> C************************************************************************
>>>> C* TI_YY24
>>>> *
>>>> C*
>>>> *
>>>> C* This subroutine converts a 2-digit year to a 4-digit year.
>>>> *
>>>> -C* Any 2-digit year less than or equal to 20 will be assumed to be
>>>> in *
>>>> -C* the 21st century; years greater than 20 will be assumed to be in
>>>> the *
>>>> +C* Any 2-digit year less than or equal to 40 will be assumed to be
>>>> in *
>>>> +C* the 21st century; years greater than 40 will be assumed to be in
>>>> the *
>>>> C* 20th century. If the year is greater than 999, it is not
>>>> changed. *
>>>> C*
>>>> *
>>>> C* TI_YY24 ( IYY, IYYYY, IRET )
>>>> *
>>>> @@ -21,6 +21,7 @@ C**
>>>> *
>>>> C* Log:
>>>> *
>>>> C* D. Kidwell/NCEP 3/99
>>>> *
>>>> C* D. Kidwell/NCEP 4/99 Do not allow 3-digit years
>>>> *
>>>> +C* B. Hebbard/NCEP 3/18 Moved century break from 2020 to
>>>> 2040 *
>>>>
>>>> C************************************************************************
>>>> iret = 0
>>>> iyyyy = iyy
>>>> @@ -28,7 +29,7 @@ C
>>>> IF ( iyy .gt. 999 ) THEN
>>>> ELSE IF ( iyy .lt. 0 ) THEN
>>>> iret = -7
>>>> - ELSE IF ( iyy .le. 20 ) THEN
>>>> + ELSE IF ( iyy .le. 40 ) THEN
>>>> iyyyy = 2000 + iyy
>>>> ELSE IF ( iyy .le. 99 ) THEN
>>>> iyyyy = 1900 + iyy
>>>> diff --git a/gempak/source/gemlib/ti/tiyymd.f
>>>> b/gempak/source/gemlib/ti/tiyymd.f
>>>> index eb138787..0a4623d0 100644
>>>> --- a/gempak/source/gemlib/ti/tiyymd.f
>>>> +++ b/gempak/source/gemlib/ti/tiyymd.f
>>>> @@ -4,8 +4,8 @@ C* TI_YYMD
>>>> *
>>>> C*
>>>> *
>>>> C* This subroutine converts an integer 2-digit year, month and day
>>>> to *
>>>> C* an integer 4-digit year, month and day. Any 2-digit year less
>>>> than *
>>>> -C* or equal to 20 will be assumed to be in the 21st century; years
>>>> *
>>>> -C* greater than 20 will be assumed to be in the 20th century. If
>>>> the *
>>>> +C* or equal to 40 will be assumed to be in the 21st century; years
>>>> *
>>>> +C* greater than 40 will be assumed to be in the 20th century. If
>>>> the *
>>>> C* year is greater than 99, it is assumed to be a 4-digit year
>>>> already. *
>>>> C*
>>>> *
>>>> C* TI_YYMD ( IYYMD, IYYYMD, IRET )
>>>> *
>>>> @@ -21,6 +21,7 @@ C* -7 = invalid
>>>> year *
>>>> C**
>>>> *
>>>> C* Log:
>>>> *
>>>> C* D. Kidwell/NCEP 3/99
>>>> *
>>>> +C* B. Hebbard/NCEP 3/18 Moved century break from 2020 to
>>>> 2040 *
>>>>
>>>> C************************************************************************
>>>> iret = 0
>>>> C
>>>> diff --git a/gempak/source/gemlib/ti/tiyyyy.f
>>>> b/gempak/source/gemlib/ti/tiyyyy.f
>>>> index 6ebe9dd2..674b986c 100644
>>>> --- a/gempak/source/gemlib/ti/tiyyyy.f
>>>> +++ b/gempak/source/gemlib/ti/tiyyyy.f
>>>> @@ -3,8 +3,8 @@
>>>> C************************************************************************
>>>> C* TI_YYYY
>>>> *
>>>> C*
>>>> *
>>>> C* This subroutine reorders a list of GEMPAK times so that times in
>>>> the *
>>>> -C* 20th century (YY greater than 20) precede those in the 21st
>>>> century *
>>>> -C* (YY less than or equal to 20). The input and output arrays may
>>>> be *
>>>> +C* 20th century (YY greater than 40) precede those in the 21st
>>>> century *
>>>> +C* (YY less than or equal to 40). The input and output arrays may
>>>> be *
>>>> C* the same. The input times must be sorted smallest to largest.
>>>> The *
>>>> C* output times will be sorted earliest to latest.
>>>> *
>>>> C*
>>>> *
>>>> @@ -23,6 +23,7 @@ C* Log:
>>>> *
>>>> C* D. Kidwell/NCEP 2/99
>>>> *
>>>> C* D. Kidwell/NCEP 4/99 Stored to outime; added check for
>>>> YYYY *
>>>> C* T. Piper/SAIC 4/02 Fixed UMR; checked for ntime < 1
>>>> *
>>>> +C* B. Hebbard/NCEP 3/18 Moved century break from 2020 to
>>>> 2040 *
>>>>
>>>> C************************************************************************
>>>> CHARACTER*(*) timin (*), outime (*)
>>>> C*
>>>> @@ -54,7 +55,7 @@ C
>>>> i = 1
>>>> found = .false.
>>>> DO WHILE ( .not. found )
>>>> - IF ( timin ( i ) ( 1:2 ) .gt. '20' ) THEN
>>>> + IF ( timin ( i ) ( 1:2 ) .gt. '40' ) THEN
>>>> found = .true.
>>>> IF ( i .gt. ( ntime / 2 ) ) THEN
>>>> down = .true.
>>>>
>>>> Frantically testing this to see if it gets dcmetr and friends back
>>>> happy.
>>>>
>>>> daryl
>>>>
>>>> --
>>>> /**
>>>> * daryl herzmann
>>>> * Systems Analyst III -- Iowa Environmental Mesonet
>>>> *
>>>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmesonet.agron.iastate.edu%2F&data=04%7C01%7Cruss.schumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X39XixShrfRs%2FMrC0VVE4nCOYebmS7kBUme5qWhmRZc%3D&reserved=0
>>>>
>>>> */
>>>>
>>>> ________________________________________
>>>> From: gembud
>>>> <gembud-bounces@xxxxxxxxxxxxxxxx<mailto:gembud-bounces@xxxxxxxxxxxxxxxx>>
>>>> on behalf of Tyle, Kevin R <ktyle@xxxxxxxxxx<mailto:ktyle@xxxxxxxxxx>>
>>>> Sent: Saturday, December 26, 2020 12:33 PM
>>>> To: gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>
>>>> Subject: Re: [gembud] NMAP2 Data Selection Window Not seeing gridded
>>>> data with fhrs valid past Dec 31 2020
>>>>
>>>> Looks like $GEMPAK/source/gemlib/ti/tiyy24.f is the file that needs
>>>> to be changed.
>>>>
>>>>
>>>> ________________________________
>>>> From: gembud
>>>> <gembud-bounces@xxxxxxxxxxxxxxxx<mailto:gembud-bounces@xxxxxxxxxxxxxxxx>>
>>>> on behalf of Patrick Marsh <pmarshwx@xxxxxxxxx<mailto:pmarshwx@xxxxxxxxx>>
>>>> Sent: Saturday, December 26, 2020 1:07 PM
>>>> To: Manousos, Peter C
>>>> <pmanousos@xxxxxxxxxxxxxxxxxxx<mailto:pmanousos@xxxxxxxxxxxxxxxxxxx>>
>>>> Cc: gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>
>>>> <gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>>
>>>> Subject: Re: [gembud] NMAP2 Data Selection Window Not seeing gridded
>>>> data with fhrs valid past Dec 31 2020
>>>>
>>>> Hi, Pete,
>>>>
>>>> This is the result of a GEMPAK bug within the time library. The
>>>> version of GEMPAK you are using does not recognize the year 2021, rather
>>>> it reverts back to 1921. So, instead of a Y2K bug, it's a Y2K21 bug.
>>>>
>>>> The internal NCEP version of GEMPAK had a patch released earlier in
>>>> December to address this bug, but I suspect no one has incorporated this
>>>> patch into the community version.
>>>>
>>>>
>>>> Patrick
>>>>
>>>> On Sat, Dec 26, 2020 at 12:00 PM Manousos, Peter C via gembud
>>>> <gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx><mailto:gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>>>
>>>> wrote:
>>>>
>>>> Greetings. We are experiencing an unusual problem. NMAP2?s (v
>>>> 7.1.1) data selection window can?t seem to detect grid files for fhrs
>>>> valid past Dec 31 2020.
>>>>
>>>>
>>>>
>>>> This is happening with all our model grid data no matter if it?s the
>>>> gfs, ecmwf, naefs, gefs, etc. and for what its worth, the restore files do
>>>> NOT have a fhr limit specified.
>>>>
>>>>
>>>>
>>>> Quick example is a listing of today?s 00z ECMWF which is typical and
>>>> contains the basic 500, 850 and surface fields out to f240 and which we
>>>> can plot just fine using gdplot3
>>>>
>>>>
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 890368 Dec 26 00:40 ecmwf_2020122600f000
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 888832 Dec 26 00:55 ecmwf_2020122600f024
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 887296 Dec 26 01:00 ecmwf_2020122600f048
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 884736 Dec 26 01:10 ecmwf_2020122600f072
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 882688 Dec 26 01:15 ecmwf_2020122600f096
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 882688 Dec 26 01:20 ecmwf_2020122600f120
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 882176 Dec 26 01:30 ecmwf_2020122600f144
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 883200 Dec 26 01:35 ecmwf_2020122600f168
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 883712 Dec 26 01:45 ecmwf_2020122600f192
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 884224 Dec 26 01:50 ecmwf_2020122600f216
>>>>
>>>> -rw-rw-r-- 1 fewx fewx 884736 Dec 26 01:55 ecmwf_2020122600f240
>>>>
>>>>
>>>>
>>>> However the data selection window in NMAP2 only shows data through
>>>> fhr 120. At the time of this writing fhr 120 corresponds to Dec 31 2020
>>>> 00z.
>>>>
>>>>
>>>>
>>>> By tomorrow we will only be able to see in NMAP2 data out through fhr
>>>> 96 and so on.
>>>>
>>>>
>>>>
>>>> We did try to mess with the Calendar function but this did not help.
>>>> If anyone else is experiencing this and if so any workarounds?
>>>>
>>>>
>>>>
>>>> Pete
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [cid:176a0389f154cff311]
>>>>
>>>> ________________________________
>>>>
>>>> The information contained in this message is intended only for the
>>>> personal and confidential use of the recipient(s) named above. If the
>>>> reader of this message is not the intended recipient or an agent
>>>> responsible for delivering it to the intended recipient, you are hereby
>>>> notified that you have received this document in error and that any
>>>> review, dissemination, distribution, or copying of this message is
>>>> strictly prohibited. If you have received this communication in error,
>>>> please notify us immediately, and delete the original message.
>>>>
>>>> _______________________________________________
>>>> NOTE: All exchanges posted to Unidata maintained email lists are
>>>> recorded in the Unidata inquiry tracking system and made publicly
>>>> available through the web. Users who post to any of the lists we
>>>> maintain are reminded to remove any personal information that they
>>>> do not want to be made public.
>>>>
>>>>
>>>> gembud mailing list
>>>> gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx><mailto:gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>>
>>>>
>>>> For list information or to unsubscribe, visit:
>>>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.unidata.ucar.edu%2Fmailing_lists%2F&data=04%7C01%7Cruss.schumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AT0fozn3jot3TUW6eHVNPVoBgL9M%2FOGhD73S4jl745U%3D&reserved=0
>>>>
>>>>
>>>>
>>>> --
>>>> Dr. Patrick Marsh (@pmarshwx)
>>>> Chief, Science Support Branch
>>>> NOAA/NWS/NCEP Storm Prediction Center
>>>> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pmarshwx.com%2F&data=04%7C01%7Cruss.schumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AXhIpqTYPA5svwmSiY6xpfoOkC4UsxV23qoeL49%2FiXU%3D&reserved=0<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pmarshwx.com%2F&data=04%7C01%7Cruss.schumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AXhIpqTYPA5svwmSiY6xpfoOkC4UsxV23qoeL49%2FiXU%3D&reserved=0>
>>>>
>>>> _______________________________________________
>>>> NOTE: All exchanges posted to Unidata maintained email lists are
>>>> recorded in the Unidata inquiry tracking system and made publicly
>>>> available through the web. Users who post to any of the lists we
>>>> maintain are reminded to remove any personal information that they
>>>> do not want to be made public.
>>>>
>>>>
>>>> gembud mailing list
>>>> gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>
>>>> For list information or to unsubscribe, visit:
>>>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.unidata.ucar.edu%2Fmailing_lists%2F&data=04%7C01%7Cruss.schumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AT0fozn3jot3TUW6eHVNPVoBgL9M%2FOGhD73S4jl745U%3D&reserved=0
>>>>
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL:
>>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.unidata.ucar.edu%2Fmailing_lists%2Farchives%2Fgembud%2Fattachments%2F20210101%2F3d4ebf76%2Fattachment.html&data=04%7C01%7Cruss.schumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gN5MR%2FiWO%2FHjVgCWkJyOD8wt3vd%2B89qk%2F9c1ePRio3Q%3D&reserved=0>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> _______________________________________________
>>>> NOTE: All exchanges posted to Unidata maintained email lists are
>>>> recorded in the Unidata inquiry tracking system and made publicly
>>>> available through the web. Users who post to any of the lists we
>>>> maintain are reminded to remove any personal information that they
>>>> do not want to be made public.
>>>>
>>>>
>>>> gembud mailing list
>>>> gembud@xxxxxxxxxxxxxxxx
>>>> For list information or to unsubscribe, visit:
>>>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.unidata.ucar.edu%2Fmailing_lists%2F&data=04%7C01%7Cruss.schumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AT0fozn3jot3TUW6eHVNPVoBgL9M%2FOGhD73S4jl745U%3D&reserved=0
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of gembud Digest, Vol 125, Issue 17
>>>> ***************************************
>>>>
>>>> _______________________________________________
>>>> NOTE: All exchanges posted to Unidata maintained email lists are
>>>> recorded in the Unidata inquiry tracking system and made publicly
>>>> available through the web. Users who post to any of the lists we
>>>> maintain are reminded to remove any personal information that they
>>>> do not want to be made public.
>>>>
>>>>
>>>> gembud mailing list
>>>> gembud@xxxxxxxxxxxxxxxx
>>>> For list information or to unsubscribe, visit:
>>>> https://www.unidata.ucar.edu/mailing_lists/
>>>>
>>>
>>> --
>>> +----------------------------------------------------------------------+
>>> * Tom Yoksas UCAR Unidata Program *
>>> * (303) 497-8642 (last resort) P.O. Box 3000 *
>>> * yoksas@xxxxxxxx Boulder, CO 80307 *
>>> * Unidata WWW Service http://www.unidata.ucar.edu/ *
>>> +----------------------------------------------------------------------+
>>>
>>> _______________________________________________
>>> NOTE: All exchanges posted to Unidata maintained email lists are
>>> recorded in the Unidata inquiry tracking system and made publicly
>>> available through the web. Users who post to any of the lists we
>>> maintain are reminded to remove any personal information that they
>>> do not want to be made public.
>>>
>>>
>>> gembud mailing list
>>> gembud@xxxxxxxxxxxxxxxx
>>> For list information or to unsubscribe, visit:
>>> https://www.unidata.ucar.edu/mailing_lists/
>
> --
> +----------------------------------------------------------------------+
> * Tom Yoksas UCAR Unidata Program *
> * (303) 497-8642 (last resort) P.O. Box 3000 *
> * yoksas@xxxxxxxx Boulder, CO 80307 *
> * Unidata WWW Service http://www.unidata.ucar.edu/ *
> +----------------------------------------------------------------------+
>
> _______________________________________________
> NOTE: All exchanges posted to Unidata maintained email lists are
> recorded in the Unidata inquiry tracking system and made publicly
> available through the web. Users who post to any of the lists we
> maintain are reminded to remove any personal information that they
> do not want to be made public.
>
>
> gembud mailing list
> gembud@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> https://www.unidata.ucar.edu/mailing_lists/
