[McIDAS #BUU-210466]: 20200611: Reading in RESOLV.SRV and himawari update

Hi Carol,

re:
> Cathy reached out to Greg and I about the real-time himawari data. She
> said that she had talked to you first, and you didn't know of any
> sources for himawari.

I know that the SSEC Data Center has Himawari data and that Unidata sites
can download up to 5 GB/day for free, but Cathy figured that her needs
would exceed that free limit.

re:
> Thus, I'm guessing you haven't heard about the "new" public cloud server
> that NOAA NESDIS has set up for himawari data.
> https://noaa-himawari8.s3.amazonaws.com/index.html

No, I did not know about this resource.  Thanks for passing it along!

re:> 
> Tom,
> 
> Greg and I just heard about this from Debra at CIRA on Monday. It looks
> like the server was started up at the beginning of 2020, and you can get
> real-time data. The delay is about 15 minutes after the satellite pass
> start time. Anyways, I figured I would let you know since it seemed like
> you hadn't heard about it.

Excellent, I appreciate it!

re:
> My second question is about reading my RESOLV.SRV file. When I run my
> setup_mcenv.sh file as user 'ldm', I want to be able to read
> /home/mcidas/workdata/RESOLV.SRV. Do I need to add this to the
> MCTABLE_READ variable?

No, the McTABLE_READ environment variable is for client routing tables
which are read in the directories specified in the semi-colon list of
directories specified in McTABLE_READ.   McIDAS expects that there will
be only one server mapping table, RESOLV.SRV.

re:
> Also, I don't even have a $MCDATA/MCTABLE.TXT
> file, so I should just delete that part?

Typically, the non-mcidas user (e.g., 'ldm' in your case) will,
in addition to definiing McTABLE_READ will also define the
McTABLE_WRITE environment variable.  McTABLE_WRITE defines the
client routing table which will be updated by DATALOC invocations.
The idea is that the non-mcidas user can define client routing
table actions that are used in preference to the ones defined
by the user 'mcidas' as system wide defaults.

re:
> Original:
> MCTABLE_READ="$MCDATA/MCTABLE.TXT;$MCHOME/data/ADDESITE.TXT"
> 
> New:
> MCTABLE_READ="$MCHOME/data/ADDESITE.TXT;$MCHOME/workdata/RESOLV.SRV"

This is incorrect since it is a mixture of two different kinds of
tables.  The 'Original' entry is correct.

re:
> In my haste to get this running in the fall, I just copied the
> $MCHOME/workdata/RESOLV.SRV file to $MCDATA/RESOLV.SRV. I now realize
> that any changes I make to $MCHOME/workdata/RESOLV.SRV then aren't
> recognized when I run the setup_mcenv.sh.
> 
> Hopefully that makes sense. I'm guessing this would fix my problem, right?

I think I understand.

You have two options, one of which is greatly preferred to the second.

1) you can define your MCPATH environment variable so that it contains
   the $MCHOME/workdata directory

   If 'ldm' does not have a RESOLV.SRV file in its MCDATA directory,
   and if you include the $MCHOME/workdata directory in your MCPATH,
   then the $MCHOME/workdata/RESOLV.SRV file will be used.

   NB:

   If 'ldm' does have a RESOLV.SRV file in its MCDATA directory AND
   its MCDATA directory is specified before $MCHOME/workdata in its
   MCPATH, then the 'ldm' copy of RESOLV.SRV will be used as it will
   be the first one found.

   If, on the other hand, the $MCHOME/workdata directory is specified
   before 'ldm's MCDATA directory in the MCPATH, then all of the files
   in the $MCHOME/workdata directory will be used in preference to
   files of the same name in 'ldm's MCDATA directory.

   How this works is easy to understand if you remember that:

   MCDATA contains a colon separated list of directories that will be
   searched from left to right by McIDAS when it is looking for a file.

2) there is another file finding mechanism in McIDAS, file REDIRECTions

   A file REDIRECTion is implemented by the REDIRECT command.  It associates
   a file mask (regular expression) with a disk location (directory).  File
   REDIRECTions take precedence over the search order specified in MCPATH,
   so they are a "foolproof" way of telling McIDAS that it should always look
   in a specific directory for a file/files that match a regular expression.

   File REDIRECTions are saved in the file LWPATH.NAM, and this file should
   be located in the user's MCDATA directory.

   NB:  There is a gotcha when specifying REDIRECTions.  If the user's MCPATH
   contains, for instance, the 'mcidas' users working directory, 
$MCHOmE/workdata,
   and if the user 'mcidas' has specified file REDIRECTions, then the file
   $MCHOME/workdata/LWPATH.NAM will exist, and if the $MCHOME/workdata directory
   is before the user's MCDATA directory in the user's MCPATH, then 'mcidas's
   LWPATH file will be used instead of one that may (or may not) exist in the
   user's MCDATA directory

So, which do I recommend?

Setting up a file REDIRECTion is foolproof as long as the user's MCPATH setting
has its own MCDATA directory first in the list of directories to search.

If the user does not have its own server mapping table, RESOLV.SRV, and
if the user's MCPATH contains the 'mcidas' working directory, then the
'mcidas' users server mapping file will be used.  This will be OK, but
if 'mcidas's server mapping table is not writable by the non-mcidas
user, the non-mcidas user will not be able to add new server mapping
entries (entries created/maintained using DSSERVE).  This also means
that all server mapping entries would need to be added/deleted/modified
by the user 'mcidas'.

I think that the best thing to do is to make sure that the user's MCDATA
directory is always the first directory in its MCPATH, and to setup
file REDIRECTions for things that must be found in single directories.

I hope that the above makes sense, but, if it doesn't, please let me
know and I can provide examples that should clarify the situation.

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: BUU-210466
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.