NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>From: Thomas Mote <address@hidden> >Organization: University of Georgia >Keywords: 200008241414.e7OEEjN11917 ldm-mcidas ROUTE.SYS BATCH McIDAS Tom, >After spending all of that time getting cacimbo (my SPARC 20) running >correctly, we decided we'd better eventually move over to this dual >Pentium LINUX system I mentioned (sirocco.ggy.uga.edu). I'm feeding from >cacimbo to sirroco while I get it ready. I saw your messages to Anne on this move. >I've actually made quite a bit of progress. After a few glictes, the LDM >seems to be working fine. GEMPAK and McIDAS installed/built correctly. I >got the ADDE server working (I think, haven't checked it yet), and the XCD >decoders working. Sirocco seems to be handling the load much >better. It also has a 100Mbit card and is on the same hub as my >instructional lab, which will be important when I start using it in class. Sounds good. >I was setting up postprocessing for the GOES composites when I ran into >problems. I made sure the xcd_run was set up and released the appropriate >ROUTE entries. For reference, xcd_run controls the XCD data decoding. For ROUTE PostProces BATCH file processing, you need to do the same configuration to the Bourne shell script file, batch.k. A copy of 'batch.k' is distributed with ldm-mcidas; it should be copied to some intransient directory in the 'ldm' account (like ~ldm/decoders). Edit it just like you did for xcd_run, and make sure that the directory it is in is in the PATH for 'ldm' and it is set to be executable. >After a while, I would get very strange ROUTE entries: > > 2144--213 62144 0621 4 Hmm... The routing entries are written by the decoder, pnga2area in this case. >The entries appear 10-20 times in the ROUTE LIST. Sounds very bad. >I started with a fresh ROUTE.SYS file, released the entires for >postprocessing, the did an "ldmadmin watch -f MCIDAS" and tailed the >BATCHPP.LOG file. The strange ROUTE entries occured with... > >Aug 24 13:46:21 pqutil: 78707 20000824134610.164 MCIDAS 000 pnga2area >Q0 CB 1110 GOES-10_SND UNKBAND 14km 20000824 1200 >Aug 24 13:48:19 pqutil: 76537 20000824134810.615 MCIDAS 000 pnga2area >Q0 CD 1130 GOES-10_SND UNKBAND 14km 20000824 1200 > >in the feed and... > >BATCH CB 0 100237 120000 1 " >BATCH CD 0 100237 120000 1 " > >Are these the CIMSS products? Yes, these are CIMSS products. The indicator in the 'ldmadmin watch' output is the 'Q0' time quartile indicator. >I haven't tried to configure for those yet. OK. >The last two things I need to do are: (1) configure for the CIMSS >products, and (2) configure for the NOAAPort GINI products in >/data/goeseast. OK, this should not be too difficult. >I have saved your e-mails from when you did this on >cacimbo and was going to try to reproduce on sirocco. Also, it doesn't >appear that the composites are actually being created. So, something is wrong. >If you want a peek, the mcidas login is ... temporarily. (I know >it's short on space for now. I will eventually move the disk on cacimbo >over to this system.) I tried getting on the machine and running McIDAS things, but I was unable to: cd workdata dmap.k ROUTE.SYS dmap.k: Cannot create negative UC This says that you are out of memory!? This is strange given that you appear to have a bunch of swap available: $top 12:59pm up 3 days, 3:17, 4 users, load average: 0.61, 0.24, 0.55 82 processes: 75 sleeping, 3 running, 4 zombie, 0 stopped CPU states: 11.3% user, 6.0% system, 1.5% nice, 1.8% idle Mem: 257684K av, 254516K used, 3168K free, 55228K shrd, 58460K buff Swap: 530104K av, 2368K used, 527736K free 119584K cached The thing I did notice, however, was that you were totally out of disk space: $ df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda6 7155068 6792364 0 100% / /dev/hda2 23333 5001 17128 23% /boot /dev/fd0 1412 647 693 48% /mnt/floppy This could be the reason for the dmap.k failure. As soon as you can get some space for maneuvering, I will login again and continue to take a look. >Thanks. > >P.S. Still bugging UCNS about port 503. Having a hard time just getting a >reponse from anyone. I can't negotiate with anyone because I can't find >the person responsible for blocking the port! Keep after it. Eventually, someone will be found that understands the network setup and also be able to make the needed change. Tom