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

[McIDAS #JUT-731693]: Cannot generate composite RTIMAGES/GEW-IRTOPO and POINTS

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:


  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

  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 R1 R2 R3 R4 R5 R6 R7 R8 R9

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


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.