[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000824: Strange ROUTE entries after sounder data

>From: Thomas Mote <address@hidden>
>Organization: University of Georgia
>Keywords: 200008241414.e7OEEjN11917 ldm-mcidas ROUTE.SYS BATCH McIDAS


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


>The last two things I need to do are: (1) configure for the CIMSS
>products, and (2) configure for the NOAAPort GINI products in

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

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:

 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

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

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


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.