[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20020916: problems with gdradr



Yes, that sounds like it is part of the problem with the new path that I added.
I did comment out all of the other NEXRIII with a "!". Is there soime sort of
bug tracking number so that I can tell when/if that problem is fixed?
The one remaining issue is that the NEXRIII path I created first was
$RAD/NIDS/%SITE%/%PROD%/YYYYMMDDHHNN. I put one day's worth of imagery into
this path and gdradr worked, produced the .gem files that I was then able to
plot in gdplot2. But rather than stick the data from 150 days into that path
where each station would have over 100 days worth of data every 6 minutes, I
wanted to create a path that sorted data into days. That is why I modified the
NEXRIII a second time to reflect the YYYYMMDD/%SITE%/%PROD%/YYYYMMDDHHNN path.
It probably did not work because of the problem you suggest. So I commented the
second NEXRIII out and uncommented the first one that I had made that had
previously worked. But now it doesn't work. I have the same data in that
directory that I made the plots from previously, but when I duplicate my
efforts, the messages report the data in that directory is too old. I didn't
know if my changing the .cshrc file might have caused some internal problems or
something. I know its not defaulting to the
$RAD/NIDS/%SITE%/%PROD%/%PROD%_YYYYMMDD_HHNN path because it lists all of the
stations and dates that it is finding. Its as if it is in the correct
directory, but it is not reading the time correctly because it reports that the
last files for the day as 23:58 or 23:59 are too old when in fact I input 2300
as the time, which would make 23:59 too recent.
Its an unfortunate problem because with none of the NEXRIII templates working
properly, I am unable to continue with my dissertation at this time. Any
further suggestions would be greatly appreciated.
Thanks,
Corene Matyas 

On Tue, 17 Sep 2002 14:46:23 +0000, Unidata Support wrote:

> 
> Corene,
> 
> There is a default template coded into gdradr if the NEXRIII template 
> is not found in the datatype.tbl file. That is the same as:
>  $RAD/NIDS/%SITE%/%PROD%/%PROD%_YYYYMMDD_HHNN
> 
> Since gdradr says it is using that pattern, then it seems to
> say that for some reason the NEXRIII template in your datatype.tbl file
> failed. Did you comment out the other NEXRIII entries you were using with a 
> "!" as the first character in the line? 
> 
> The RAD variable is set in Gemenviron, so your changing the value in .cshrc
> would need to be after the Gemenviron file is sourced.
> 
> The problem you may be having with your new directory structure is that 
> the directory path has the YYYYMMDD template in it. The code only
> processes the template in the file name, and not the file path.
> So, your path of /wxdata/archive/YYYYMMDD/%SITE%/%PROD% is
> probably not getting expanded with the date/time as you expected.
> 
> It sounds like I need to modify the code so that the directory path is
> processed for date/time templates as well as the file name.
> 
> Steve Chiswell
> Unidata User Support
> 
> 
> >From: "CORENE MATYAS" <address@hidden>
> >Organization: UCAR/Unidata
> >Keywords: 200209161527.g8GFR3114884
> 
> >I am currently experiencing difficulty successfully running gdradr. I had
> >modified the nexriii entry in the datatype.tbl 2 months ago to reflect the
pat
> > h
> >that my data were stored in. I tested using data from one day and was
> >successful in creating files that I was then able to successfully view in
> >gdplot2. However, I needed to refine my path because I am dealing with data
> >from 150 days so sticking the data into a directory for each station would be
> >too cumbersome. I went to modify the datatype.tbl settings, but my new path
wa
> > s
> >longer than 25 characters. So I decided to set a new environment variable to
> >substitute for the first part of the path and shorten the length. However,
the
> >new environmental variable didn't "take". So I modified .cshrc and reset
> >$RAD equal to the first part of this new path. This did work, but produced a
> >strange pathname. Even though I had added another entry in the datatype.tbl
an
> > d
> >commented out the others, it was still defaulting to the path I had
originally
> >modified. Originally I changed the path to $RAD/NIDS/%SITE%/%PROD%. I then
> >changed $RAD = /wxdata/archive, making my desired path
> >$RAD/YYYYMMDD/%SITE%/%PROD%. However, while running gdradr, it said it was
> >still searching for $RAD/NIDS/%SITE%/%PROD% which is not correct because I
> >commented out that structure in the datatype.tbl. So I decided to switch
> >everything back to the way in which it had worked before, resetting $RAD to
it
> > s
> >original path in .cshrc and deleting the new addition to the datatype.tbl and
> >uncommenting the $RAD/NIDS/%SITE%/%PROD% entry. I tried gdradr with this
> >setting, but now it says the files are too old. I set the radtim for
> >010806/2300 and raddur = 15. It is looking in the correct path because it
list
> > s
> >all of the station files as its running but it lists all of the last ones for
> >that day (23:59, 23:57, etc) for each station and says they are all too old.
> >Yet I had created these very same files prior to messing with any of the
syste
> > m
> >settings and they all came up perfectly.
> >Basically, I'm at a loss for 3 things- why the environmental variable I set
> >didn't work, why does it keep using an old and commented out entry in the
> >datatype.tbl when I added the one I wanted and had been able to use it
before,
> >and finally why when I reset everything to its original state does it say the
> >files are too old when I was able to use them before?
> >
> >Thanks,
> >Corene Matyas
> >
> >
> >
> >From address@hidden Fri Sep  6 09:27:08 2002
> >Received: from webmail8.cac.psu.edu (webmail8.cac.psu.edu [128.118.1.217])
> >     by unidata.ucar.edu (UCAR/Unidata) with ESMTP id g86FR7j27127
> >     for <address@hidden>; Fri, 6 Sep 2002 09:27:07 -0600 (MDT)
> >Organization: UCAR/Unidata
> >Keywords: 200209061527.g86FR7j27127
> >Received: (from webmail@localhost)
> >     by webmail8.cac.psu.edu (8.9.3/8.9.0) id LAA15281;
> >     Fri, 6 Sep 2002 11:27:06 -0400 (EDT)
> >Date: Fri, 6 Sep 2002 11:27:06 -0400 (EDT)
> >Message-Id: <address@hidden>
> >To: Unidata Support <address@hidden>
> >Subject: gdradr problem
> >From: "CORENE  MATYAS" <address@hidden>
> >X-Mailer: Penn State WebMail
> >X-Sender: cjm298
> >X-Originating-IP: 64.178.98.153
> >MIME-Version: 1.0
> >Content-Type: multipart/mixed; boundary="=-/brQcj8UuSid+m2QpwZm"
> >
> >--=-/brQcj8UuSid+m2QpwZm
> >Content-Type: text/plain
> >
> >I am currently experiencing difficulty successfully running gdradr. I had
> >modified the nexriii entry in the datatype.tbl 2 months ago to reflect the
pat
> > h
> >that my data were stored in. I tested using data from one day and was
> >successful in creating files that I was then able to successfully view in
> >gdplot2. However, I needed to refine my path because I am dealing with data
> >from 150 days so sticking the data into a directory for each station would be
> >too cumbersome. I went to modify the datatype.tbl settings, but my new path
wa
> > s
> >longer than 25 characters. So I decided to set a new environment variable to
> >substitute for the first part of the path and shorten the length. However,
the
> >new environmental variable didn't "take". So I modified .cshrc and reset
> >$RAD equal to the first part of this new path. This did work, but produced a
> >strange pathname. Even though I had added another entry in the datatype.tbl
an
> > d
> >commented out the others, it was still defaulting to the path I had
originally
> >modified. Originally I changed the path to $RAD/NIDS/%SITE%/%PROD%. I then
> >changed $RAD = /wxdata/archive, making my desired path
> >$RAD/YYYYMMDD/%SITE%/%PROD%. However, while running gdradr, it said it was
> >still searching for $RAD/NIDS/%SITE%/%PROD% which is not correct because I
> >commented out that structure in the datatype.tbl. So I decided to switch
> >everything back to the way in which it had worked before, resetting $RAD to
it
> > s
> >original path in .cshrc and deleting the new addition to the datatype.tbl and
> >uncommenting the $RAD/NIDS/%SITE%/%PROD% entry. I tried gdradr with this
> >setting, but now it says the files are too old. I set the radtim for
> >010806/2300 and raddur = 15. It is looking in the correct path because it
list
> > s
> >all of the station files as its running but it lists all of the last ones for
> >that day (23:59, 23:57, etc) for each station and says they are all too old.
> >Yet I had created these very same files prior to messing with any of the
syste
> > m
> >settings and they all came up perfectly.
> >Basically, I'm at a loss for 3 things- why the environmental variable I set
> >didn't work, why does it keep using an old and commented out entry in the
> >datatype.tbl when I added the one I wanted and had been able to use it
before,
> >and finally why when I reset everything to its original state does it say the
> >files are too old when I was able to use them before?
> >
> >Thanks,
> >Corene Matyas
> >
> >--=-/brQcj8UuSid+m2QpwZm--
> >
> >
> 
> **************************************************************************** <
> Unidata User Support                                    UCAR Unidata Program <
> (303)497-8643                                                  P.O. Box 3000 <
> address@hidden                                   Boulder, CO 80307 <
> ---------------------------------------------------------------------------- <
> Unidata WWW Service                        http://www.unidata.ucar.edu/      <
> **************************************************************************** <
> 
> 
> 
>