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

20040226: new ldm at stc (cont.)



>From: "Anderson, Alan C. " <address@hidden>
>Organization: St. Cloud State
>Keywords: 200402182057.i1IKvTrV011544 McIDAS-X setup

Alan,

Sorry I have not been able to respond to this inquiry before now, but
I have been in Costa Rica since Feb. 22 and have not been able to
respond to email as consistently as I would like.

>In my message from yesterday, I commented that while our new ldm seems
>to be running ok,  I am not getting any content in my log file,
>ldmd.log
>
>The file was created (upon start ?) but is empty.  I checked my lines
>in /etc/syslog.conf,  and these seem ok.

I sent back a message earlier that outlined some troubleshooting
you can do:

- check the /etc/syslog.conf entries to make sure that they are correct
- stop and restart syslogd
- use the 'logger' command to see if you can successfully write to
  the log file:

logger -p local0.debug 'test of syslog writing to LDM log file'

If 'logger' doesn't work, it means that either your /etc/syslog.conf
file entries are bad, syslogd is not running or is wedged, or
~ldm/logs/ldmd.log is not writable by you.

>Also,  have another problem.   I have downloaded and installed the
>mcidas-ldm decoders as directed on your web page.

OK, just so we are on the same page, the ldm-mcidas decoders are
for the Unidata-Wisconsin (IDD feedtype UNIWISC) imagery, NLDN
lightning data, and FSL wind profiler data.  The have nothing to do
with surface or upper air decoding in McIDAS.  These are handled
by the McIDAS-XCD decoders.

>I can create images
>and  a skewT but cannot get a simple plot of surface data.

We should first make sure of what machine you are pointing to to
do the plots.  Please let me know the output of:

DATALOC LIST RTPTSRC

If you are pointing at some other ADDE server, you are seeing a
problem on their server, not yours.  If you are pointing elsewhere,
you should do the following to point back at your own machine:

DATALOC ADD RTPTSRC LOCAL-DATA

  -- or --

DATALOC ADD RTPTSRC cyclone.stcloudstate.edu

The latter invocation of DATALOC assumes that the remote ADDE sever
has been correctly setup on cyclone.

>Seems like
>I must have Area and upper air files where they are supposed to be,
>but am not getting suface data (or else mcidas is looking in the wrong
>place ?).

If you are trying to access the RTPTSRC data from cyclone or LOCAL-DATA,
then the failure to plot surface data points to a problem decoding
the surface data.

>Checked my redirect list and also  the string  XCDDATA,
>everything points to /var/data/mcidas which is where I keep  the
>files.
>
>Any hints ?

Again, if you are pointing at your own machine, then you should
try the following from a McIDAS session running as 'mcidas':

1) DMAP MDXX

   Do you have MDXX files 1-10 or any subset listed?  If no, then
   no surface data is being decoded.  If yes, are they current?
   If no, then the decoding is not running.  Do you have 10
   surface MDXX files listed?  If yes, then you are not scouring
   the data files before they get to be 10 days old, and they are
   most likely full.  In this case, the easiest thing to do
   is stop the LDM, delete the MD files, and then restart the LDM.

2) it could be the case that the rapid access files were never
   correctly created before turning on the LDM.  If the items in
   1) don't fit/are not the problem, do the following:

   stop the LDM
   <as 'mcidas'> do:
   cd workdata
   batch.k XCD.BAT
   batch.k XCDDEC.BAT
   decinfo.k LIST

   Was surface decoding (DMSFC) turned on (the decinfo.k listing should
   tell you this).  If not, turn it on:

   decinfo.k SET DMSFC ACTIVE

   restart the LDM

>Thanks

Is cyclone accessible to me via ssh?  I just logged on, so it is.

I checked what I wrote above and all looks OK.  I can list out
individual records out of the current MD file using PTLIST, but
I am unable to list using SFCLIST.  Now, I am stumped!

Right at the moment, I am thinking it may have something to do with the
time.  The reason I say this is that it is 7 am Boulder time, so the
time in UTC is 14:03.  McIDAS on cyclone thinks it is 8:03 UTC:

cyclone% tl.k
H           :=  8:03:57
XCDDATA     := /var/data/mcidas
Y           := 2004061
  --END OF LIST

Yup, you have a system clock problem.  To see this in another way,
plesae take a look at the latencies for the IDS|DDPLUS data:

http://my.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?IDS|DDPLUS+cyclone.stcloudstate.edu

Notice that your clock is off by 21600 seconds.  This must be the problem
with accessing data in McIDAS since the data looks like it is in the future.

When you correct your clock, two things should happen:  the LDM latency
plots should return to normal values, and the McIDAS decoding and
access to data should get corrected.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.


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.