This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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.