[McIDAS #HDN-934891]: ERAU ADDE configuration and Conference call to discuss equipment purchase

Hi Chris,

re:
> No problem with the slight delay in getting back to me.  I teach M/W/F and
> my hours were pretty full.

OK, I'm glad that I wasn't holding things up.

re:
> I don't know how Outlook is going to do with my reply inline, but here goes 
> nothing!  Look for "#CGH#" for my comments.

re:
> [#CGH#] Robert and I will draft an email of what options we have and send that
> out to you.  Should we use the same tracking info, or should we send that as 
> a new item?

Keep it with the same ticket id (tracking info you are referring to).

re: naming convention for images matches what we use routinely
> [#CGH#] Yup, that's probably not a coincidence!  We try to conform
> when we can!

I believe that Chiz came up with the naming scheme.

re:
> [#CGH#] Robert is out sick.  We'll have a service account for you
> to connect.  Could you send me an SSH key that we can drop in place to let 
> you in?

I'll do this is a separate email not in our tracking system.  This will be 
sometime
later today.

re:
> [#CGH#] I have the ADDE service running (he said with some excitement!) and it
> is open to the Internet.  (Robert, I tweaked the rule in the load balancer to
> make it work.)

What is the name of your machine?

re: example DSSERVE invocation
> [#CGH#] This worked just fine, thanks!

Excellent.

re:
>> ERAUPROD - group name, 8 characters maximum and some characters are not 
>> allowed
>> VISPP    - descriptor name, 12 characters maximum and some characters are not
>> allowed
> 
> [#CGH#] Is there a list of restricted characters somewhere, or do I get to
> find them through trial and error?  (-:

The HELP for the DSSERVE command (HELP DSSERVE) presents a list, but that
list did not include the '+' sign.

re: how to store files more efficiently for serving

> [#CGH#] This suggests that we need to have a separate data tree for the ADDE
> service from our NMAP/GEMPAK data.

Maybe yes, maybe no.

re:
> Do you use symbolic links and a cron script to populate this list of "N" 
> files?

I wrote a script that implements the 'current' set of files for our GOES-16 
processing.
I based it on the 'ldmfile.sh' script that I include in the Unidata McIDAS 
distribution,
so the basics should already be in your McIDAS installation.  I could tidy the 
latest
script up and send it to you if you are interested.

re: test the newly created dataset
> [#CGH#] Works just fine!

re: example McIDAS BATCH file
> [#CGH#] It appears that Outlook (and the Exchange Server) felt a need to 
> protect me
> from your malicious script.  Could you please rename the script with a "txt" 
> extension
> and send it again?  Thanks!

It is attached to this reply.  I recommend renaming it to use the .BAT suffix
after you extract it from this email.

re:
> [#CGH#]
> I took a stab at modifying the file RESOLV.SRV (after making a backup), and I 
> was
> able to add the various AREA and GINI files (from the NOAAPort).

Excellent.  I modify RESOLV.SRV directly all the time as it is quicker for me.
Please be careful, however, that you include all of the ','s needed as one typo
will make definitions past the mistake unusuable.

re:
> The response is a bit sluggish, but there are more than 1300 files in the 
> typical
> directory.  Any suggestion for a max count to serve?

I typically keep about 96 of the most recent images in my 'current' sets.  The
actual number that one should keep depends on the frequency that the images
are updated, and how one interprets 'current'.

re:
> I would also like to serve surface and upper air data.  Will this require a 
> local
> data processing, or can I serve Gempak files?

McIDAS ADDE works with McIDAS formatted files.  If you want to serve GEMPAK
point files, you can not use ADDE, but you could use the TDS.

re:
> I just found a source of Python 3.6 RPMs that I can use in our RHEL 6 
> environment.
> I'll work on the tile problem of the GOES-16 data next.

Ryan has already made a Python script approach available in the Unidata
section of GitHub under the name ldm-alchemy.  I'd check that out before
reinventing the wheel.

re:
> You said that this version of McIDAS can't serve those, correct?

Correct, but the release I am working on right now can.

re:
> Thanks for your help!

No worries.

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: HDN-934891
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.

REM
REM All images are assumed to be in AREA format!
REM

DSSERVE ADD ERAUPROD/CLD   AREA 
DIRFILE=/opt/wxdata/gempak/images/sat/ERAU/CONUS/CLD/CLD*   "ERAU CLD images
DSSERVE ADD ERAUPROD/GCH   AREA 
DIRFILE=/opt/wxdata/gempak/images/sat/ERAU/CONUS/GCH/GCH*   "ERAU GCH images
DSSERVE ADD ERAUPROD/IR    AREA 
DIRFILE=/opt/wxdata/gempak/images/sat/ERAU/CONUS/IR/IR*     "ERAU IR images
DSSERVE ADD ERAUPROD/TSRA  AREA 
DIRFILE=/opt/wxdata/gempak/images/sat/ERAU/CONUS/TSRA/TSRA* "ERAU TSRA images
DSSERVE ADD ERAUPROD/V1    AREA 
DIRFILE=/opt/wxdata/gempak/images/sat/ERAU/CONUS/V1/V1*     "ERAU V1 images
DSSERVE ADD ERAUPROD/VISPP AREA 
DIRFILE=/opt/wxdata/gempak/images/sat/ERAU/CONUS/VIS++/VIS* "ERAU VIS++ images
DSSERVE ADD ERAUPROD/WV    AREA 
DWVFILE=/opt/wxdata/gempak/images/sat/ERAU/CONUS/WV/WV*     "ERAU WV images