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

[IDD #SET-184160]: GOES-W AREA Files

Hi Jim,

re:
> Here are the lines from the LDM pqact.conf file:
> 
> # McIDAS Actions for PNG
> UNIWISC pnga2area Q. (..) (.*) (.*) (.*) (.*) (........) (....)
> PIPE    -close
> pnga2area -vl logs/ldm-mcidas.log -d /sdata/mcidas-c -r \1,\2

This action will match the Product IDs of the older products, but not
the new ones.  The reason for the non-match of the new products is
the first parenthetical expression: '(..)'.  This will match
fields where the product code is 2 characters in length, and the
new products have product codes that range from 4-7 characters in
length.

re:
> #
> # GOES-West Visible
> UNIWISC ^pnga2area Q. (U9) (.*) (.*) (.*) (.*) (........) (....)
> PIPE    -close
> pnga2area -d /sdata/mcidas-c -r \1,\2 -vx

This action will match products whose product code is 'U9'.  The
product that used be used to generate this this product was a VIS image from
GOES-15.  With the turning off of the GOES-15 satellite, these products
are no longer generated by the process that created them, so they are
no longer available in the UNIWISC feed.

re:
> #
> # GOES-East/West VIS fill disk composite
> UNIWISC ^pnga2arua Q. (FDC02) (.*) (.*)_IMG (.*)um (.*) (........) (......)
> FILE    -close
> /sdata/GOES-EW/\6_\7.png

This action would match the Full Disk Channel 2 (0.64 um) GOES-East (GOES-16)
and GOES-West (GOES-17) images IF/WHEN the incorrect spelling of 'pnga2area'
is corrected - right now the action has 'pnga2arua' instead of 'pnga2area'.

re:
> The first block is what we have always used to put data in AREA#### format.

Yes.

re:
> This used to return both GOES-E and GOES-W files.

Yes again.

re:
> Since I was no longer getting any GOES-W AREA files,

GOES-15, which used to be GOES-West, was put into a standby mode by
the Weather Service.  It is scheduled to be returned to active duty
in late August of this year for use in monitoring of eastern Pacific
hurricanes.  We have no plans to again distribute UNIWISC images
that are/were based on GOES-15 imagery.  We will change this position
if needed because of problems with the current GOES-West, GOES-17.

re:
> I added the second block to see if I could at least get the GOES-W
> visible AREA files (AREA012* for us).

The product with product code 'U9' was generated from GOES-15 imagery,
and that is no longer available since the Weather service put GOES-15 into
standby mode on March 2.

re:
> As I said, we are getting GOES-16 McIDAS AREA files from the first block,

Yes, those products are still being created, but they are scheduled to
be removed from the feed when we are confident that all sites have transitioned
to use of the new imagery.

re:
> but nothing from GOES-W.

For the old GOES-West/15 images, this is correct.

re:
> We have received data from the third block for the GOES-16/17 full
> disk composite for both GOES-16 and GOES-17.
> 
> We still use the AREA formats for MCIDAS-based web applications,
> 
> i.e. https://vortex.plymouth.edu/myo/sat/mcidas-area.html

Very good.

re:
> They are also used in some of our WXP applications.

Like I said in my previous email, I have no idea if WXP will work
with the true GOES-16/17 images since their projection is new/different
from the GOES-13/15 images.

re:
> which still works well with current GOES-16 AREA data.

That is likely because I create the old GOES-16 images by using
McIDAS-X to remap (IMREMAP) the GOES-16 images into the old
GOES-13 projection.  We would like to be able to discontinue
generation of those products, but we will not do so until our
users have made the transition to the new images.

re:
> Here are the request lines from our ldmd.conf file:
> 
> request         UNIWISC ".*"    flood.atmos.uiuc.edu
> request         UNIWISC ".*"    idd.ssec.wisc.edu

OK, the REQUESTs are for everything in the feed, good.

I recommend that you change your REQUEST to idd.ssec.wisc.edu to
either idd.unidata.ucar.edu or iddb.unidata.ucar.edu.  The reason
for making the change is that the machine idd.sec.wisc.edu does
not have enough RAM to allow creation of an LDM queue that is
large enough so that the residency time of products in the queue
is more than a few minutes.

re:
> Our log file does show the GOES-E AREA files processing normally,

The old ones...

re:
> but I never see anything logged or errors for GOES-W processing. It's
> like no GOES-W data are being received.

Again, there is a typo in the action that would match both GOES-East (GOES-16)
and GOES-West (GOES-17) full disk channel 2 images.  As soon as the typo
is corrected, you should start seeing images FILEd to disk.  Whether or
not these will work in WXP is something I can not say.

To correct the typo and get image FILEing working, do the following:

<as 'ldm'>
-- edit your LDM pattern-action file and correct the typo that I
   noted above

-- check to make sure that there are no gross errors in the pattern
   action file:

ldmadmin pqactcheck

-- use 'ldmadmin' to send a HUP signal to all 'pqact' invocations that
   are running; the HUP signal tells them to reread their pattern-action
   files

ldmadmin pqactHUP

Last comment:

- the only Plymouth machine that I see reporting real-time stats is
  named srvlp-dpt-met02.plymouth.edu

  This machine is apparently _not_ REQUESTing the UNIWISC feed:

  
https://rtstats.unidata.ucar.edu/cgi-bin/rtstats/siteindex?srvlp-dpt-met02.plymouth.edu

  It would be useful for us if you turned on reporting of real-time stats
  on the machine that is REQUESTing the UNIWISC feed.  This is done by making
  sure that the LDM configuration file entry that looks like:

EXEC    "rtstats -h rtstats.unidata.ucar.edu"

  is not commented out.  If it is commented out, then uncomment the line and
  stop/restart your LDM.  If it is already commented out, it should mean
  that it is already reporting under some name which I am not seeing
  (the value of 'hostname' in the LDM registry file, ~ldm/etc/registry.xml),
  or a firewall at Plymouth is preventing its reports from getting to us.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: SET-184160
Department: Support IDD
Priority: Normal
Status: Closed
===================
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.