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

20021112: McIDAS 2002 install woes at UGa (cont.)

>From: "Thomas L. Mote" <address@hidden>
>Organization: UGa
>Keywords: 200211112240.gABMedX19548 McIDAS-X v2002a make

Tom,

>Everything seems to be working now. Before I received your reply, I did 
>go back and look at the makelog, but didn't see anything obvious. I 
>grep'd through for "error" statements and didn't see anything. So, I 
>just clobbered it and rebuilt this morning. As far as I know, I didn't 
>do anything different, but I now have all 220 .k files. Maybe I 
>miscounted the first time (although it's hard to mess up with "ls -l 
>*.k | wc -l").

Weird!

>You're right, I forgot the VENDOR=-g77 on the make install. That fixed 
>the install issue. 

Sounds good.

>I see that I can even get on the McIDAS web site again ;-)

We are continuing to have problems with our primary web server.  We
will be pressing our development web server machine into service
within the next hour or so, and the web site should work correctly
after the switch.

>Thanks, we seem to be in good shape now. I may try this on cacimbo 
>shortly. Is there anything I should be careful with the 7.805 -> 2002 
>migration regarding the ADDE server?

There are some things that really should be done when upgrading from
v7.8x to v2002x.  A longwinded description of things to look out for
can be found in:

Unidata McIDAS-X 2002
http://www.unidata.ucar.edu/packages/mcidas/2002
  Hot Topics
  http://www.unidata.ucar.edu/packages/mcidas/2002/hottopics.html 
    Release Notes
    http://www.unidata.ucar.edu/packages/mcidas/2002/mcx/release_notes.html 

To me, the highlights of this are:

o v2002 will take more disk space than v7.8x.  This is mainly caused by
  the HDF stuff that is bundled with v2002.

o the country codes were changed in v2002 to match ISO standards.  This
  has ramifications both in McIDAS-X and in McIDAS-XCD.  More on the
  XCD effects below.  For -X, you should just note that you will have
  to modify use of country codes in commands and scripts to use the
  new codes.

o the Unidata graphic user interface to McIDAS, MCGUI, has been updated
  and improved.  You can specify the use of MCGUI when running McIDAS
  by starting using 'mcidas -config' once and selecting that you want
  to start MCGUI automatically.

o several commands available in v7.8x have been removed from v2002.
  The deleted commands and their suggested replacements are listed
  in Release Notes

Changes that will affect XCD:

The Release Notes section on XCD changes has a blow-by-blow listing of
what you should do in the upgrade.  It is pretty simple, however:

Station Database Enhancements and COUNTRY.DAT

If this is the first time that McIDAS-XCD has been installed on your
system you may skip this section because the changes have already been
made to the standard files.

As detailed in Country Codes in Section IV of the McIDAS-X Version 2002
Upgrade Procedure document, we switched the two-letter country codes in
the McIDAS country codes database (COUNTRY.TXT) and station database
(STNDB.CORE) to match those in the widely-accepted International
Organization for Standardization's ISO 3166 list.

As a result, the McIDAS-XCD file COUNTRY.DAT must be recreated so that
it also makes use of the new country codes. In the required actions
below you will rename your existing COUNTRY.DAT file (rather than
remove it) for future reference, then recreate the file with the new
country codes.

Required Action: 

   1.Login to the McIDAS-XCD workstation as user mcidas. 

   2.Change to the ~mcidas/workdata directory. 

          Type: cd ~mcidas/workdata

   3.Rename the current COUNTRY.DAT file to COUNTRY.DAT.OLD. 

          Type: mv COUNTRY.DAT COUNTRY.DAT.OLD

   4.While logged in as user mcidas, start a McIDAS session and
     recreate COUNTRY.DAT using the IDGROUP command.

          Type: IDGROUP LIST

   5.If you have any local modifications in your COUNTRY.DAT.OLD file,
     use the IDGROUP command to add them to your new COUNTRY.DAT file.



While you are making changes on cacimbo, I would ask you to make mods
on the LDM side:

<login as 'ldm'>
cd etc
<edit pqact.conf>

  change:

#
# NEXRCOMP 1 km Regional BREF mosaic
FNEXRAD ^pnga2area Q5 (RM) (.*) (.*) (.*) (.*) (........) (....)
        PIPE    -close
        decoders/bin/pnga2area -v
        /data/nexrad/NEXRCOMP/1km/\4/\4_\6_\7

  to:

#
# NEXRCOMP 1 km Regional BREF mosaic
FNEXRAD ^pnga2area Q5 (RO) (.*) (.*) (.*) (.*) (........) (....)
        PIPE    -close
        decoders/bin/pnga2area -v
        /data/nexrad/NEXRCOMP/1km/\4_flt/\4_\6_\7

-- the modifications are to change 'RM' to 'RO' and the first \4 to \4_flt --

This change will cause cacimbo to start decoding and filing the 1 km
regional NEXRAD composites in the FNEXRAD IDD datastream.  You will
also need to review your scouring of NEXRAD composites (run from a cron
job as the user running the LDM on cacimbo) to make sure that this directory
will be scoured along the rest (this should be the case, but it is wise
to make sure).

Also, I am working on an addendum for v2002 (v2002b) that will contain,
amont other things, a bugfix for a routine used by all XCD data monitors.
The bug is a memory leak that is apparently benign on systems that are
not using gcc 3.2 (like RedHat 8.0 Linux).  On those systems, dmsyn.k
can grow to the point that malloc will go into an infinite loop
and cause excessive CPU use.  I am working on Gilbert Sebenste's machine
to find all of the places causing memory leaks affecting dmsyn.k.

Nothing else big comes to mind in the upgrade from v7.8x to v2002x.

If you run into any snags, please let me know how I can help.

Tom