20051122: ldm feed (cont.)

>From: "Happel, Shelly" <address@hidden>
>Organization: USF
>Keywords: 200511221843.jAMIhP7s009090 IDD FNEXRAD notifyme ADDE

Hi Shelly,

>Thanks for helping me with this.

No worries.

>Could part of my problem be that the
>pqact.conf does not contain any of the decoding for mcidas/FNEXRAD? I
>have a file called pqact.conf_nexrad - which has the decoder commands
>for FNEXRAD.

One can setup their LDM to run multiple invocations of pqact, so
there not being any FNEXRAD actions in ~ldm/etc/pqact.conf does not
necessarily say that you are not trying to process the data.  What
you should do is take a look at your ldmd.conf file to see what
processes you are 'exec'ing:

<as 'ldm'>
cd ~ldm
grep ^exec etc/ldmd.conf

This will show you how many pqact invocations should be running; which
feed(s) they will be processing; etc.  Given your comment about there
being a pqact.conf_nexrad, I suspect that you have two pqact invocations
running.  If you do, the second one should have been told to process
products in the NEXRAD and FNEXRAD datastreams. The ldmd.conf entry
for processing of specific stream(s) might look like:

exec    "pqact  -f FNEXRAD|NNEXRAD etc/pqact.conf_nexrad"

If you have a line like this, and if you have two pqact invocations
running, you should be processing the FNEXRAD products as per entries
in your pqact.conf_nexrad configuration file.

>I did everything you said in your email. I checked the pqact.conf and
>it's fine (but doesn't have the above info).

OK.  'ldmadmin pqactcheck' only checks the ~ldm/etc/pqact.conf file
for syntax errors.  Now that we know that you have at least two
configuration files, you need to add an option to your 'ldmadmin'
invocation:

<as 'ldm'>
cd ~ldm
ldmadmin pqactcheck -p etc/pqact.conf_nexrad

>I ran ldd which pngg2gini
>(& ldd 'which pngg2gini') and nothing at all happened. 

Hmm...  This would say that the directory containing pngg2gini is not in
the PATH of the user 'ldm', OR it could mean that pngg2gini is not
executable, OR it could mean that pngg2gini is not found at all.

What do the FNEXRAD actions in pqact.conf_nexrad look like?

>The file that pqact.conf_nexrad places the files in the gempak directory
>- which is not helpful since we're trying to use these files to generate
>the following: 
>
>http://metlab.cas.usf.edu/cgi-bin/gen_mcidas_sat_reg_ir.cgi?type=GINIEAS
>T%2FGE4KIR
>
>http://metlab.cas.usf.edu/cgi-bin/gen_mcidas_sat_reg_ir.cgi?type=GINICOM
>P%2FGSN8KIR
>
>http://metlab.cas.usf.edu/cgi-bin/gen_mcidas_sat_reg_ir.cgi?type=NAGINIC
>OMP%2FGSN8KIR

McIDAS doesn't care where the files are located AS LONG AS it is configured
to know where to look for the files.  Defining an ADDE dataset in McIDAS 
uses the DSSERVE command, and one of the keywords, DIRFILE=, is used
to tell McIDAS where to look for the files in the set.

So, if you have McIDAS configured to be able to find the files in
the GEMPAK directory tree, everything will be OK.  To check this,
do the following:

<login as 'mcidas'>
cd workdata
dsserve.k LIST GINIEAST

Check to see _if_ the dataset is defined, and if it is, if it is
defined correctly.

>These used to work, but now they don't and trying to figure out where
>the error is has taken me pathetically long to get to the place where I
>say "ah, where are metlab's pngg2gini files???

They used to work?  When, and what happened inbetween?  I have a
feeling that the situation you are experiencing may be related to
your McIDAS installation "pointing" (having a client routing table
entry) that pointed to adde.ucar.edu.  Check this with:

<as 'mcidas'>
cd ~mcidas/workdata
dataloc.k LIST

If you see that your system is configured to look for GINIEAST
images on adde.ucar.edu, then your problem is being caused by
our changing the hardware that is adde.ucar.edu and our moving
it to a new IP address.  Again, if you see a pointing for
GINIWEST to adde.ucar.edu, please do the following:

<still as 'mcidas'>
grep ADDE.UCAR.EDU ~mcidas/data/ADDESITE.TXT
grep ADDE.UCAR.EDU ~mcidas/workdata/MCTABLE.TXT

If you see a line that looks like:

HOST_ADDE.UCAR.EDU=128.117.15.119

it means that your McIDAS account is configured to look for the
old adde.ucar.edu IP address.  Since this machine is no longer
active, your plots are no longer working.  In this case, the
fix is simple:

<still as 'mcidas'>
cd ~/workdata
dataloc.k HOST

This will cause McIDAS to update the IP address of the cached
entry for adde.ucar.edu.

>The log files do not have any pngg2gini in it anywhere..... agh..

OK.  I am betting that you were using a remote ADDE server
for your displays and they are no longer working because an IP
address cached by McIDAS is no longer correct.  The 'DATALOC HOST'
invocation (dataloc.k HOST) will correct any/all incorrect
cached IPs to correct ones.

NB: fixing the pointing to a remote ADDE server does not fix 
processing of FNEXRAD data on your machine.

>Thanks again Tom, you're simply the BEST - hands down.

Thanks for the pops :-)

Cheers,

Tom
--
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.