>From: Michael Keables <address@hidden> >Organization: DU >Keywords: 199909152035.OAA16060 LDM ldm-mcidas Mike, I saw your email and decided to answer since Robb was taking some vacation time today. >I'm trying to install the LDM on a Sun Ultra (Solaris 7) aka >cyclone.natnet.du.edu. I've gone through the checklists on the web but am >still unable to get the LDM to run properly. > >When I issue ldmadmin start & a process kicks off but nothing happens. OK, when this happens, you should follow the recommendations at the top of the file ~ldm/etc/ldmd.conf: #### # # This is the main configuration file for the LDM server. All lines that start # with a "#" sign are comments. # # To debug an LDM that hangs on start up, run the following from LDM home: # % bin/rpc.ldmd -vl - -q data/ldm.pq etc/ldmd.conf # # If the LDM still hangs, comment out all lines in this file, try again. In doing so, you could have found out that things would work after you commented out the following line from ldmd.conf: #exec "pqsurf" The reason that this line needed to be commented out was that the queue that pqsurf needs did not exist. The great majority of sites do not use pqsurf anymore, so I left this line commented out. This was not all that was needed, however. I also found that you had two entries for NDLN data. This was a typo from somewhere else since the datasteam is NLDN (D and L transposed). Also, the problem with doing: request NLDN ".*" cirrus.al.noaa.gov is that the NLDN (lightning) data is not one of the ones that gets relayed from upstream sites. All lightning data is sent point-to-point from SUNY Albany. If you havn't already done so, you must request (email) a feed of the NLDN data from: Name David Knight (p) Institution State Univ. of NY-Albany Department Earth and Atmospheric Sciences Street Address #1 1400 Washington Ave. Street Address #2 Earth Sci. Bldg. ES 228 City, State, Zip, Co Albany NY 12222 Phone: 518 442-4204 Fax: 518 442-4494 Email Address address@hidden Dave will enable your machine to receive the data. Once he has done this, you will need to change the request NLDN line from what it is in ~ldm/etc/ldmd.conf to: request NLDN ".*" striker.atmos.albany.edu For convenience, I did this for you but left the line commented out: #request NLDN ".*" striker.atmos.albany.edu When Dave has setup stuff up, all you need to do is uncomment the line and stop and restart the LDM. >After a few minutes I get the following emai: > >Sep 15 19:54:40 UTC cyclone.natnet.du.edu : start_ldm: Server not started >or registered. > >A ps -eaf | grep ldm yields: > >cyclone% ps -ef | grep ldm > ldm 22126 22125 0 14:00:00 ? 0:00 /usr/local/bin/perl >bin/ldmfail -p cirrus.al.noaa.gov -f cirrus.al.noaa.gov > ldm 22125 176 0 14:00:00 ? 0:00 sh -c bin/ldmfail -p >cirrus.al.noaa.gov -f cirrus.al.noaa.gov > ldm 22135 22126 0 14:00:00 ? 0:00 /usr/local/bin/perl >/usr/local/ldm/bin/ldmadmin start > ldm 22265 22259 0 14:07:16 pts/4 0:00 -csh > >Issuing notifyme shows that I have access to cirrus.al.noaa.gov (albeit I >don't have a failover host yet so ldmd.primary and ldmd.failover are the >same as ldmd.conf.) It is great that you used notifyme to see if you have access to your upstream feed site. This was the exact right thing to try! It is also great that you used 'ldmadmin pqactcheck' to check the pqact.conf file entries. See below. >I have deduced the following: > >1. there is a problem with the following statement in pqact.conf (which I >downloaded from the web): > >cyclone% ldmadmin pqactcheck >Sep 15 20:25:57 pqact: feedtype error at line 14: unknown feed name >in feedtype expression: "MCIDAS ^(LWTOA3 .*)" Right. I looked at your pqact.conf file and found that all of the entries had spaces where tabs were called for. The most likely cause for this was someone cutting and pasting example pqact.conf entries into the file; true? I edited pqact.conf and changed all of the spaces to tabs where needed. I then ran 'ldmadmin pqactcheck' to discover other lines that had problems. There were three lines that are very long had line breaks in them. They looked like: #WSI ^NEX/(...)/(BREF1)/..([0-9][0-9])([0-1][0-9])([0-3][0-9])([0-2][0-9])([0 -6][0-9]) This entry was coming out as two lines instead of one. This was also probably due to cutting and pasting. >2. ldm/decoders is empty ... I assumed that I needed to download the >decoders from the web but I get a permissions violation when I try to >download decoders.tar.Z The other things that were missing from ~ldm/decoders were the ldm-mcidas decoders. Binary versions of these can be FTPed from ftp.unidata.ucar.edu from the pub/binary/sunos_5.7-sparc directory. I did this for you: cd ~ldm ftp ftp.unidata.ucar.edu <anonymous> <your email address> cd pub/binary/sunos_5.7-sparc bin get ldm-mcidas.tar.Z quit zcat ldm-mcidas-tar.Z | tar xvf - I then copied the ldm-mcidas decoders to the ~ldm/decoders directory: cp ldm-mcidas-7.6.1/bin/* decoders After that, I went into the decoders directory and setup the McIDAS ROUTE PostProcessing script, batch.k, to match your setup. This script allows such things as composite images to be produced. The editing job consisted of nothing more than changing the definition of MCHOME from /home/mcidas to /export/home/mcidas. What remains to be done is to enable the compositing by running ROUTE from a McIDAS-X session running as the user 'mcidas'. I didn't do this for you since we need to talk about where you have setup data file storage. More on this below. While in the decoders directory, I copied the file xcd_run from the McIDAS distribution: cp ~mcidas/mcidas7.6/src/xcd_run . I then edited xcd_run (another Bourne shell script) and changed MCHOME in the same way that was done for batch.k Finally, since the FSL2 wind profiler decoder needs the McIDAS SCHEMA file in the directory in which the decoder wants to create output MD files, I copied it there. I also copied ROUTE.SYS and SYSKEY.TAB since they will be used/updated by the ldm-mcidas and XCD decoders: cd /var/data/mcidas cp ~mcidas/data/SCHEMA . cp ~mcidas/data/SYSKEY.TAB . cp ~mcidas/workdata/ROUTE.SYS . After that, I was ready to start the LDM: ldmadmin start ldmadmin tail The LDM started up and began receiving data from the upstream feed site. Here is the contents of the /var/data/mcidas directory as I write this: cyclone% cd /var/data/mcidas cyclone% ls AREA0060 AREA0140 AREA0170 AREA0205 ROUTE.SYS AREA0120 AREA0150 AREA0191 AREA0210 SCHEMA AREA0130 AREA0160 AREA0200 MDXX0099 SYSKEY.TAB You can see that a number of images have already been received and decoded and that one MD file has been created. That MD file, 99, was created from the FSL2 6-minute profiler data. >Please advise on how to get out of the mess I'm in. OK, now we need to talk about where the data are currently going: /var/data/mcidas. I did a quick check of disk space on your machine: cyclone% df -k Filesystem kbytes used avail capacity Mounted on /proc 0 0 0 0% /proc /dev/dsk/c0t0d0s0 96455 40768 46042 47% / /dev/dsk/c0t0d0s6 877790 665487 150858 82% /usr fd 0 0 0 0% /dev/fd /dev/dsk/c0t0d0s1 413639 77771 294505 21% /var /dev/dsk/c0t1d0s7 8509324 339070 8085161 5% /export/home /dev/dsk/c0t0d0s5 3007086 917816 2029129 32% /opt /dev/dsk/c0t0d0s7 4031022 140916 3849796 4% /usr/local swap 657744 112 657632 1% /tmp and see that /var is very small (total of 400 MB to begin with). This will not be enough room to store McIDAS or GEMPAK data in. The most likely candidate for data storage is /export/home since it has 8 GB of disk available. I ordinarily don't recommend that data files be kept in /home (or /export/home in your case), but it would be painful to go back and repartition your disk. Is there more disk in the system that hasn't been mounted? If so, and if it is on the order of at least 2-3 GB, then that is where the data should go. In the meantime, in order to exercise the LDM and ldm-mcidas decoders, I left things running. On the McIDAS side of things, I see that you have not yet setup XCD. Once you have done this (I would have done so for you, but there is not enough disk space in /var/data), turning on XCD decoding will be as simple as editing ~ldm/etc/pqact.conf and uncommenting out the lines for XCD processing: # Entries for XCD decoders #DDPLUS|IDS ^.* PIPE # xcd_run DDS #HRS ^.* PIPE # xcd_run HRS (remove the '#' signs at the beginning of the lines while making sure to NOT turn them into spaces). Let's touch base on your setup tomorrow. >Thanks in advance. You are welcome. 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.