[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
20041213: 20041213: 20041210: GEMPAK won't view "mrf"
- Subject: 20041213: 20041213: 20041210: GEMPAK won't view "mrf"
- Date: Mon, 13 Dec 2004 14:46:47 -0700
>From: Nancy Selover <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200412131856.iBDIujlI020306
>Steve,
> Okay. In order to avoid missing satellite imagery for my
>archive, can I add an archive cron script to run every 1/2 hour to copy
>and gzip the latest satellite images from each folder to the archive
>folder in gojira? Then, as the images are scoured out to leave only the
>latest 10 images, I won't miss anything in the archive. I still have
>the script command to locate the latest image based on time.
Nancy,
sure, you can do that.
Another approach would be to run a script half hourly that
would list the contents of the image directory and
then for each image time there, see if it existed in your archive,
and if not copy it over and gzip it. Usually somparing, you
would just have to compare the root name (eg the :r part since your
archive files would have a .gz appended to them).
I suggest that was since if you only do the latest each half hour, then
you could have gaps if the cron didn't run over a period of time for
some reason- like gojira was down, while mothra was still up collecting
data.
Steve
>
>Nancy
>
>-----Original Message-----
>From: Unidata Support [mailto:address@hidden]
>Sent: Monday, December 13, 2004 11:36 AM
>To: Nancy Selover
>Cc: Unidata Support
>Subject: 20041213: 20041210: GEMPAK won't view "mrf"
>
>
>Nancy,
>
>I'll remove the FILE lines for Antarctic and the short (3.9) and far
>12.0/13.3 IR channels.
>
>Your LDM action was previously filing satellite data into
>/var/data/mcidas/AREAxxxx files, and the names in the gempak/images/sat
>were all symbolic links.
>
>The circular AREA file naming would look like AREA0120 through AREA0129
>so at most you had 10 images, regardless of how many links from
>IR_YYYYMMDD_HHNN since those links were going back to file names that
>mcidas was reusing.
>
>Steve Chiswell
>Unidata User Support
>
>
>
>
>>From: Nancy Selover <address@hidden>
>>Organization: UCAR/Unidata
>>Keywords: 200412131805.iBDI5JlI014310
>
>>Steve,
>> Thank you. It is working well now. The loops as well as the
>vertical
>>profiles. I see that the 4km satellite imagery includes 12.0 and 3.9
>>in addition to IR and VIS, and GOES-12 includes 13.3 and 3.9 in
>>addition to IR , VIS and WV.
>>
>>We aren't particularly interested in these extra satellite products.
>>Is it possible to NOT keep them around in order to save disk space?
>>And is there a way to NOT save the ANTARCTIC satellite imagery. I just
>
>>keep dumping it, but haven't been able to prevent it from being filed.
>>
>>Also, does the problem with the looping affect our archived imagery. I
>
>>believe what we are saving is the "IR_YYYYMMDDHHMM" file, NOT the link.
>>I tried a big loop of the archived stuff, and it still had the problem
>>in looping correctly. Does this mean I managed to save the same image
>>several times with different names?
>>
>>Thank you very much for your help.
>>
>>Nancy
>>
>>-----Original Message-----
>>From: Unidata Support [mailto:address@hidden]
>>Sent: Friday, December 10, 2004 3:36 PM
>>To: Nancy Selover
>>Cc: Unidata Support
>>Subject: 20041210: GEMPAK won't view "mrf"
>>
>>
>>Nancy,
>>
>>The default for MRF was set to a higher resolution grid than you are
>>receiving. I have configured the Garp_defaults to use the
>>mrf201 grid for this option now.
>>
>>Also, my test of the corss section now works.
>>
>>Also, the reason you were having trouble with satellite images is that
>>you were using the circular file names in mcidas AREA files (eg 10
>>unique names for each product), and the old nsat_links script to
>>generate symbolic links to that files. With 1/2 hourly data, you would
>>only have a loop of 5 hours possible, and since links were to files
>>AREAxxx0 through AREAxxx9, when the circular file names were reused,
>>the GUIs would show diffrerent data than what the time of the link
>showed.
>>
>>To correct the satellite image problem, I have made pqact file the data
>
>>directly to the GEMPAK tree using standard date/time file names.
>>However, you likely won't have enough disk space for a day's worth of
>>satellite images.
>>For the weekend, I'll cut this down to 10 hours and look to see how
>>disk space can be utilized next week.
>>
>>Steve Chiswell
>>Unidata User SUpport
>>
>>
>>>From: Nancy Selover <address@hidden>
>>>Organization: UCAR/Unidata
>>>Keywords: 200412102044.iBAKiDlI015311
>>
>>>This is a multi-part message in MIME format.
>>>
>>>--Boundary_(ID_cGT0IS3b7sbJePx+z/GMTw)
>>>Content-type: text/plain; charset="us-ascii"
>>>Content-transfer-encoding: quoted-printable
>>>
>>>For some reason, GEMPAK on gojira will not display the "mrf" model.
>>>There are 5 "mrf" files in the directory (2 are _mrf201, and the
>>>others
>>
>>>are _mrf037.gem, -mrf039.gem, and _mrf040.gem - and they all have
>data.
>>>The Gempak datatypes.tbl looks okay, pointing to 4 types of mrf files.
>>>But no files come up in the Garp window under mrf.
>>> Where do I look next? =20
>>>Nancy
>>>
>>>Nancy J. Selover=20
>>>Asst. State Climatologist=20
>>>Office of Climatology tel: 480-965-0580=20 Arizona State University
>>>fax: 480-965-1473=20 Tempe, AZ 85287-1508 e-mail: address@hidden=20
>>>
>>>
>>>
>>>--Boundary_(ID_cGT0IS3b7sbJePx+z/GMTw)
>>>Content-type: text/html; charset="us-ascii"
>>>Content-transfer-encoding: quoted-printable
>>>
>>><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META
>>>HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>>>charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange
>>>Server version = 6.0.6603.0"> <TITLE>GEMPAK won't view
>>>"mrf"</TITLE> </HEAD> <BODY>
>>><!-- Converted from text/rtf format -->
>>>
>>><P><FONT SIZE=3D2 FACE=3D"Arial">For some reason, GEMPAK on gojira
>>>will
>>
>>>= not display the "mrf" model. There are 5
>>>"mrf" = files in the directory (2 are _mrf201, and the
>>>others
>>
>>>are _mrf037.gem, = -mrf039.gem, and _mrf040.gem - and they all have
>>>data. The Gempak = datatypes.tbl looks okay, pointing to 4 types
>
>>>of mrf files. But no = files come up in the Garp window under
>>>mrf.</FONT></P>
>>>
>>><P> <FONT SIZE=3D2 =
>>>FACE=3D"Arial">Where do I look next? </FONT>
>>>
>>><BR><FONT SIZE=3D2 FACE=3D"Arial">Nancy</FONT> </P>
>>>
>>><P><B><I><FONT SIZE=3D2 FACE=3D"Arial">Nancy J. =
>>>Selover</FONT></I></B><I></I><FONT FACE=3D"Times New Roman"><BR>
>>></FONT><I></I><I><FONT SIZE=3D2 FACE=3D"Arial">Asst. State =
>>>Climatologist</FONT></I><FONT FACE=3D"Times New Roman"><BR>
>>></FONT><FONT SIZE=3D2 FACE=3D"Arial">Office of Climatology tel: =
>>>480-965-0580</FONT><FONT FACE=3D"Times New Roman"><BR> </FONT><FONT
>>>SIZE=3D2 FACE=3D"Arial">Arizona State University fax: =
>>>480-965-1473</FONT><FONT FACE=3D"Times New Roman"><BR> </FONT><FONT
>>>SIZE=3D2 FACE=3D"Arial">Tempe, AZ 85287-1508 e-mail: =
>>>address@hidden</FONT><FONT FACE=3D"Times New Roman"> </FONT> </P>
>>><BR>
>>>
>>></BODY>
>>></HTML>=
>>>
>>>--Boundary_(ID_cGT0IS3b7sbJePx+z/GMTw)--
>>>
>>--
>>***********************************************************************
>>*
>>Unidata User Support UCAR Unidata
>>(303)497-8643 P.O. Box
>>address@hidden Boulder, CO
>>-----------------------------------------------------------------------
>>-
>>Unidata WWW Service
>>-----------------------------------------------------------------------
>>-
>>NOTE: All email exchanges with Unidata User Support are recorded in the
>
>>Unidata inquiry tracking system and then made publicly available
>>through the web. If you do not want to have your interactions made
>>available in this way, you must let us know in each email you send to
>us.
>>
>>
>--
>************************************************************************
>Unidata User Support UCAR Unidata
>(303)497-8643 P.O. Box
>address@hidden Boulder, CO
>------------------------------------------------------------------------
>Unidata WWW Service
>------------------------------------------------------------------------
>NOTE: All email exchanges with Unidata User Support are recorded in the
>Unidata inquiry tracking system and then made publicly available through
>the web. If you do not want to have your interactions made available in
>this way, you must let us know in each email you send to us.
>
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web. If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.
