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