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: Erick Lorenz <address@hidden> >Organization: UC Davis >Keywords: 200009220039.e8M0dBb07890 McIDAS-X 7.60 Linux Erick, >The ldm can be stopped and restarted quickly again Good. The problem was me adding FSL2 to the request line. We are looking into this here. re: request for FSL2 data >I don't think there is a demand here for wind profiler data currently. OK. >Also I am in no hurry to get NLDN data at present. The reason I was adding this is that you used to get the data. re: increase of queue from 100 MB to 200 MB >After your last ministrations the LDM stopped saving files again so I >increased the product queue to 400Mb. Since then it has been behaving. I am perplexed about this one. Things should have worked fine with a 200 MB queue. The "fix" may have been in deleting and recreating the queue. >The only problem is that we still are not getting GRID files. I studied >all the documentation on GRIB and XCD and retraced the steps to starting >those processes up. I did all this on Sunday afternoon and two new GRID >files showed up in /var/data/xcd but when I came in today they were gone. >I noticed in the troubleshooting chapter that there should only be one copy >each of ingetext.k and ingebin.k running. When I looked, sure enough there >were two each. >------------------ >[mcidas@ATM20 ~/data]$ ps -aux|grep inge >ldm 902 0.0 0.3 1904 968 ? S 23:53 0:00 ingetext.k DDS >ldm 919 0.1 0.2 1952 732 ? S 23:53 1:24 ingetext.k DDS >ldm 8823 0.0 0.3 1788 956 ? S 12:15 0:00 ingebin.k HRS >ldm 8831 0.6 0.4 1832 1084 ? S 12:15 2:25 ingebin.k HRS >------------------ >I stopped the LDM and confirmed that all inge... processes were gone and >restarted it only to find that there were two each again. The docs suggest >that this may be due to an error in pqact.conf but I can only find the one >entry there which is just like the manual says to do >------------------ ># Entries for XCD decoders (created on 22 Sept 2000) >DDPLUS|IDS ^.* PIPE > xcd_run DDS >HRS ^.* PIPE > xcd_run HRS >------------------ >so I don't know how to edit to prevent this doubling from happening. These >are the only places where xcd_run appears in the file. Your troubleshooting was correct up to the point of enabling the GRID decoding on the McIDAS side: <login as 'mcidas'> cd workdata decinfo.k LIST When I just logged on, GRID decoding was inactive. I turned it back on with decinfo.k SET DMGRID ACTIVE It must have gotten turned off when I was redoing the XCD setup while we were on the phone. >I am also curious about LOCAL.NAM. First there is: >----------------- >" Realtime GRID files (the location should be in the directory >" in which the ldm-mcidas decoders are producing data files) >" >GRID000* /var/data/mcidas >GRID010* /var/data/mcidas >---------------- >Does ldm-mcidas still have any grid files anymore? The Unidata-Wisconsin datastream no longer has any products other than images. The McIDAS distribution is now over a year old, so the comments in LOCAL.NAM are now dated. >And then then there is: >-------------------------- >" Additional GRID files: ETA, MRF, NGM, MAPS (RUC), ECMWF created by McIDAS >XCD >" >GRID5* /var/data/xcd >-------------------------- >which seems right. This is correct. The problem was that DMGRID was inactivate. We send out XCD with GRID decoding turned off because a lot of sites don't have enough disk space to turn on the firehose of GRID decoding. >Thanks >Erick Lorenz, UCDavis Tom