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

20010323: Unidata application installation at Valparaiso (cont.)

>From: Simon Kissler <address@hidden>
>Organization: Valparaiso
>Keywords: 200103231414.f2NEEhL25449 McIDAS-X ADDE

Simon,

>thanks again for your quick response. Here's what I have done:
>
>I have added the ucarsupp accounts to the compiler group so they can
>access the compiler.

Excellent, this allows me to test the ADDE setup on aeolus.

>The reason for the permissions are that we only have
>2 floating compiler licenses and are trying to restrict people as much as
>possible from using the compilers.

I am pretty sure that the license does not cover the shared libraries.
You may want to set the permissions on the SC5.0/lib directory so that
executables linked against them can be used by all users.

>Originally the compilers were NFS
>mounted from another machine, however, I found that they were performing
>poorly that way and have since copied them over. The permissions are in
>part a relic to it, but this seemed like an easier solution. :)

OK, I understand.

>I have also combined the /var/data/mcidas and /var/data/xcd directories as
>you suggested and made the updates as you suggested.

Very good.

>Furthermore I have opened the Firewall on port 500 and 503 as requested.

Super!  I can now point at your machine and list/display the data in the
various datasets that it hosts.  A quick check of plotting a meteorogram
shows that POINT source access is working.

While doing the quick check, I noticed that you have ten days of each kind
of POINT source data files.  I also noticed that neither 'ldm' or 'mcidas'
has a cron file (/var/spool/cron/crontabs).  Taking both of these
observations together means that you are not yet scouring the McIDAS
POINT source files created by XCD.  This needs to be done since the
way the XCD decoders work is to append to existing POINT source files.
The files use a circular naming scheme so that files MDXX0001 - MDXX0010
are where decoded surface data is stored; MDXX0011 - MDXX0020 are
where mandatory level upper air data is stored; etc.  The naming convention
further specifies which file relates to which day.  The last digit of the
MDXX file name is the same as the last digit of the Julian day of the
data.  For instance, today is Julian date 2001082.  The last digit of this
date is '2'.  The MDXX file for todays surface data is MDXX0002; the MDXX
file for todays mandatory level upper air data is MDXX0012; etc.
After 10 days, new data will be written to the end of the file that was
used for data ten days ago.  This is bad for two reasons.  First, the
plotting routines will see the data that is 10 days old first instead
of seeing the current data.  Second, the MDXX files have a finite size.
Once the file is as big as it is setup to be, newly decoded data will
be "thrown on the floor".

So, you need to setup data scouring for the POINT source files.  You do
this using a McIDAS routine in the distribution: mcscour.sh.  As the
user 'mcidas', copy mcscour.sh from the ~mcidas/workdata directory
to some other directory like ~mcidas/bin or ~mcidas/mcidas/data.
After doing this, you must edit the copy to set directory entries that
match your setup (mcscour.sh contains information on how to setup
the various environment variables).  Near the end of the script, there
are a number of lines that actually do the data scouring.   In the
copy of mcscour.sh that is sent out, these look like:

MCPATH=$MCPATH PATH=$PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH mcenv << EOF

qrtmdg.k GRID 5001 6000 1
doqtl.k  1  70 2
doqtl.k 71  80 2
doqtl.k 81  90 2
doqtl.k 91 100 2
delwxt.k 1 10
igu.k DEL 132
lwu.k DEL VIRT9001
lwu.k DEL VIRT9002
lwu.k DEL ROUTEPP.LOG
exit

EOF

The routine that is doing the POINT source data file scouring is doqtl.k.
The doqtl.k lines above are setting up saving of various types of POINT
source data files for a maximum of 2 days:

doqtl.k  1  70 2
         ^  ^  ^__ # of days to keep
         |  |_____ ending MD file number
         |________ beginning MD file number

An entry just for surface data could look like any of the following:

doqtl.k  1  10 2          <- keep 2 days
doqtl.k  1  10 3          <- keep 3 days
doqtl.k  1  10 6          <- keep 6 days

At maximum, you should keep 9 days (you can keep 10 days if the scouring
is run immediately before 0Z.

After editing mcscour.sh, you should setup a cron entry that is something
like:

00 21 * * * /home/mcidas/mcidas/data/mcscour.sh

(adjust for the directory into which you copied mcscour.sh).

You can adjust the time you run this; 21 hours is what we use here.

>And as a last deed I created a user with username ucarsup3 which should
>have the same password than you set ucarsup2 to and which is functionally
>equivalent to the mcidas user.

Yes, but it can not do things as 'mcidas'.  If it could, I would have
setup the POINT source data scouring for you.  Since you now have 10
days for each kind of POINT data online, you need to setup scouring
immediately, or decoded data will be lost.

Tom

>From address@hidden Fri Mar 23 15:50:57 2001
>Subject: Re: 20010323: Unidata application installation at Valparaiso (cont.)

Tom,

response below:


On Fri, 23 Mar 2001, Unidata Support wrote:

[...]

> >I have also combined the /var/data/mcidas and /var/data/xcd directories as
> >you suggested and made the updates as you suggested.
> 
> Very good.

I'm seeing some issues are these due to the scouring or due to the
change. Please advise (see message where we crossed paths).

[...]

> While doing the quick check, I noticed that you have ten days of each kind
> of POINT source data files.  I also noticed that neither 'ldm' or 'mcidas'
> has a cron file (/var/spool/cron/crontabs).  Taking both of these
> observations together means that you are not yet scouring the McIDAS
> POINT source files created by XCD.  This needs to be done since the
> way the XCD decoders work is to append to existing POINT source files.
> The files use a circular naming scheme so that files MDXX0001 - MDXX0010
> are where decoded surface data is stored; MDXX0011 - MDXX0020 are
> where mandatory level upper air data is stored; etc.  The naming convention
> further specifies which file relates to which day.  The last digit of the
> MDXX file name is the same as the last digit of the Julian day of the
> data.  For instance, today is Julian date 2001082.  The last digit of this
> date is '2'.  The MDXX file for todays surface data is MDXX0002; the MDXX
> file for todays mandatory level upper air data is MDXX0012; etc.
> After 10 days, new data will be written to the end of the file that was
> used for data ten days ago.  This is bad for two reasons.  First, the
> plotting routines will see the data that is 10 days old first instead
> of seeing the current data.  Second, the MDXX files have a finite size.
> Once the file is as big as it is setup to be, newly decoded data will
> be "thrown on the floor".
> 
> So, you need to setup data scouring for the POINT source files.  You do
> this using a McIDAS routine in the distribution: mcscour.sh.  As the
> user 'mcidas', copy mcscour.sh from the ~mcidas/workdata directory
> to some other directory like ~mcidas/bin or ~mcidas/mcidas/data.
> After doing this, you must edit the copy to set directory entries that
> match your setup (mcscour.sh contains information on how to setup
> the various environment variables).  Near the end of the script, there
> are a number of lines that actually do the data scouring.   In the
> copy of mcscour.sh that is sent out, these look like:
> 
> MCPATH=$MCPATH PATH=$PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH mcenv << EOF
> 
> qrtmdg.k GRID 5001 6000 1
> doqtl.k  1  70 2
> doqtl.k 71  80 2
> doqtl.k 81  90 2
> doqtl.k 91 100 2
> delwxt.k 1 10
> igu.k DEL 132
> lwu.k DEL VIRT9001
> lwu.k DEL VIRT9002
> lwu.k DEL ROUTEPP.LOG
> exit
> 
> EOF
> 
> The routine that is doing the POINT source data file scouring is doqtl.k.
> The doqtl.k lines above are setting up saving of various types of POINT
> source data files for a maximum of 2 days:
> 
> doqtl.k  1  70 2
>          ^  ^  ^__ # of days to keep
>          |  |_____ ending MD file number
>          |________ beginning MD file number
> 
> An entry just for surface data could look like any of the following:
> 
> doqtl.k  1  10 2          <- keep 2 days
> doqtl.k  1  10 3          <- keep 3 days
> doqtl.k  1  10 6          <- keep 6 days
> 
> At maximum, you should keep 9 days (you can keep 10 days if the scouring
> is run immediately before 0Z.
> 
> After editing mcscour.sh, you should setup a cron entry that is something
> like:
> 
> 00 21 * * * /home/mcidas/mcidas/data/mcscour.sh
> 
> (adjust for the directory into which you copied mcscour.sh).

This is done. I have set it to 9 days for now. Since our meteorology
department has mentionned wanting to keep around at least some amount of
history.


> 
> You can adjust the time you run this; 21 hours is what we use here.

I stuck with 21 for right now .. it doesn't matter so much to me
personally :).

> 
> >And as a last deed I created a user with username ucarsup3 which should
> >have the same password than you set ucarsup2 to and which is functionally
> >equivalent to the mcidas user.
> 
> Yes, but it can not do things as 'mcidas'.  If it could, I would have
> setup the POINT source data scouring for you.  Since you now have 10
> days for each kind of POINT data online, you need to setup scouring
> immediately, or decoded data will be lost.

Ah. ... I have changed mcidas's password to that of ucarsup2

-Simon


> 
> Tom
> **************************************************************************** <
> Unidata User Support                                    UCAR Unidata Program <
> (303)497-8644                                                  P.O. Box 3000 <
> address@hidden                                   Boulder, CO 80307 <
> ---------------------------------------------------------------------------- <
> Unidata WWW Service                        http://www.unidata.ucar.edu/      <
> **************************************************************************** <
> 

-------------------------------------------------------------------------------
Simon Kissler                                   address@hidden
UNIX Systems Administrator                      Phone: (219) 464 6773
Electronic Information Services                 Fax  : (219) 464 5381
Valparaiso University
Kretzmann Hall B22
Valparaiso, IN 46383
-------------------------------------------------------------------------------

                Without trust, you don't have anything.

-------------------------------------------------------------------------------