Hi Marty,
re: big snow in eastern-central Colorado high country
> Wow! You are a lot higher than we are here. Sounds like it was a good
> snow storm for April.
It was great! I got 30" at my house and loved every inch of it... except
the 3 days of shoveling!
re: wrong password for 'ldm'
> Sorry for the password error. The password has been changed to what I
> emailed earlier.
> If you have any problems you can call me at 435-797-4635.
Excellent. I SSHed as 'ldm' to your machine immediately after seeing
your email this morning. Access works nicely now, thanks!
re: zero-length SCHEMA file in /usr/local/ldm/data/mcidas
> Thanks for finding this. I would not have found that one.
I'm sorry that I forgot to mention this as a possibility in our
original email exchanges.
OK, so things look like they are working now (although we need to monitor
the situation for awhile to be completely sure).
Here are the few fairly minor things that I did:
- as 'ldm' I reviewed the configurations in the files:
~ldm/decoders/xcd_run
~ldm/decoders/batch.k
I found the same problem in both files: the MCHOME directory
was left as /home/mcidas even though the MCHOME directory on
your machine is /usr/local/mcidas.
The other thing I found was some syntax errors in determining
the MCHOME directory in ~ldm/decoders/batch.k. These were my
errors - they worked well under Linux, but not other Unixes:
~mcidas -> OK in a Bourne shell script under Linux, but not Solaris
~ldm -> ditto
- after fixing the problems above, I took a look at the files being
written to the $MCDATA directory in the 'mcidas' account. I saw
that the MD file MDXX0070 was being written there instead of in
/usr/local/ldm/data/mcidas.
I corrected this by editing the $MCDATA/LWPATH.NAM file and adding
file REDIRECTions for the MD files MDXX007*, MDXX008* and MDXX009*.
- the next thing that I did was to SUSpend some of the entries in
the McIDAS routing table, ROUTE.SYS:
<as 'mcidas'>
cd $MCDATA
route.k SUS MA NF NG RM RS UA UC UR US
route.k SUS R1 R2 R3 R4 R5 R6 R7 R8 R9
route.k SUS RA RB RC RD RE RF RG RH RI RJ RK RO
These changes were really not needed, but they tidy up the routing
table so that a listing will show if you are getting products that
are expected.
The things that I do not see working yet are:
- RL 6 km Nat. Base Refl. Comp 1160-1169 none none none 3
RN 10 km RCM Composite 1170-1179 none none none 3
These will not be updated because you are processing these products
outside of the McIDAS routing table. Please review the ~ldm/etc/pqact.conf
pattern-action file for details.
U2 FSL2 hourly wind profiler default none none none 3
U6 FSL2 6-minute Wind profil default none none none 3
I noticed that you were not requesting the FSL2 data from your upstream
machines. I added a ~ldm/etc/ldmd.conf REQUEST line for these data and
then stopped and restarted your LDM. These data should now be decoded.
- certain CIMSS products have not been available in the Unidata Wisconsin
datastream (IDD feedtype UNIWISC aka MCIDAS) for some time, so the lack
of reporting in the routing table are expected:
CA Cloud Top Pressure 1100-1109 none none CTP.BAT 3
CB Precipitable Water 1110-1119 none none PW.BAT 3
CC Sea Sfc. Temperature 1120-1129 none none SST.BAT 3
CD Lifted Index 1130-1139 none none LI.BAT 3
CE CAPE 1140-1149 none none CAPE.BAT 3
CG NH Wildfire ABBA 1190-1199 none none WFABBA.BAT 3
CH SH Wildfire ABBA 1200-1209 none none WFABBA.BAT 3
I did not SUSpend these products since I am still trying to find alternate
sources for them.
- remote access to the various datasets being created via ADDE.
This requires that 'root' run the ADDE setup script:
<as 'root'>
cd /usr/local/mcidas
sh ./mcinet2008.sh install mcadde
Before this can be run, however, the user 'mcadde' must be created. It
needs to be created so that:
- it is _not_ a login account
- its HOME directory is the same as for the user 'mcidas'
- it is in the same group as 'mcidas' and 'ldm'
Also, access to the machine through port 112 must be enabled. This is
also a job for 'root'.
- I am unable to use the LDM utility 'notifyme' to monitor the reception
of data products on cldbz1.usurf.usu.edu even from itself:
notifyme -vl- -f FSL2 -o 1000 -h cldbz1.usurf.usu.edu
Apr 20 19:11:46 notifyme[11271] NOTE: Starting Up: cldbz1.usurf.usu.edu:
20090420185506.146 TS_ENDT {{FSL2, ".*"}}
Apr 20 19:11:46 notifyme[11271] NOTE: LDM-5 desired product-class:
20090420185506.146 TS_ENDT {{FSL2, ".*"}}
Apr 20 19:11:46 notifyme[11271] INFO: Resolving cldbz1.usurf.usu.edu to
129.123.195.32 took 0.000495 seconds
Apr 20 19:11:46 notifyme[11271] ERROR: NOTIFYME(cldbz1.usurf.usu.edu): 7:
Access denied by remote server
Since I added the ALLOW line in ~ldm/etc/ldmd.conf and restarted the LDM,
it is likely that the failure is due to a firewall block of traffic
to port 388.
All-in-all, things are looking pretty good at the moment. Spot checking
would be made easier by you enabling remote access via ADDE (outlined above).
Is this a possibility?
Cheers,
Tom
--
****************************************************************************
Unidata User Support UCAR Unidata Program
(303) 497-8642 P.O. Box 3000
address@hidden Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage http://www.unidata.ucar.edu
****************************************************************************
Ticket Details
===================
Ticket ID: JUT-731693
Department: Support McIDAS
Priority: Normal
Status: Closed
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.