20000410: XCD storage of ETA H>48 grids (cont.)

>Eirh-Yu Hsie <address@hidden>
>Organization: University of Virginia
>Keywords: 200004072010.OAA01470 McIDAS-XCD IDD ETA ADDE XCD DMGRID DSSERVE 
>RTMODELS.CFG GRIBDEC.PRO

Hsie,

I apologize for not replying to your messages of the 10th and 11th.  As
you have seen, I was consumed putting together an addendum for
McIDAS-X,-XCD.

I am pretty sure that the modules that were fixed/modified in the
addendum are the ones that will allow you to correctly store the ETA
grids in model run-specific GRID files.  In addition, the addendum
fixes a problem in dmgrid.k: it had an internal buffer that was too
small to handle the 10 km national radar product created from
Radar Coded Messages (RCMs).  McIDAS-XCD does not yet decode the RCM
radar summary into GRID files, but it will in an upcoming addendum
(or the next full McIDAS release, Version 7.7).

Previously, you asked:

>Your instructions are very clear.  I still have one more question.  It seems to
>me that the 18Z data will overwrite the 12Z data:
>
>   5041        0  2000101  4000  ALL  18Z ETA 0  HR<=VT<=24 HR
>   5051        0  2000101  4000  ALL  18Z ETA 24 HR< VT<=48 HR
>
>They are using GRIDs 5041, 5051 for storage.  I think the 06Z data will 
>overwrite 00Z data.

You were almost correct here.  The 18 Z ETA model grids would be put in
the same file as the 12 Z model grids, but they would not overwrite the
12 Z grids.  The same is true for the 6 Z grids: they would be put into
the same file as the 0 Z grids, but would not overwrite anything.

Everything would have been fine with the existing setup IF you had been
willing to live with GRID files containing more than one model run.  We
decided internally that this was not, however, the best way to save the
data since that structure would have further increased the time it
would take ADDE applications to get data out of the GRID files.
Instead, storing model data for a particular run grouped by forecast
time interval seemed like the best thing to do.  The only problem with
this was that the ETA grids had to be moved into a new set of GRID file
numbers.  This, in turn, requires that people adjust their ADDE data
set definitions so that the new GRID files can be accessed.

>From address@hidden  Tue Apr 11 14:26:10 2000
>Subject: Re: 20000411: XCD storage of ETA H>48 grids 

On the 11th you noted:

>After modify my McIDAS setup following your instructions.  I only get April
>10, 18Z ETA data.

Again, the new setup should prevent this sort of thing from happening.

The UPC and one test site have been running with the new setup for several
days with no problems, so I am pretty confident that your setup will
work correctly.  Please let me know if you have any problems with the
addendum.

On another topic, in the past, you had McIDAS-X installed on a machine
named stratus.  In addition, at one point the remote ADDE server was
setup on stratus and was basically open to the world.  I see now that
you have installed TCP wrappers around the McIDAS ADDE services (mcserv
and mccompress).  This is what we have done here at Unidata, but we
keep our server open to the world.  I am wondering if your intention is
to deny remote ADDE access to all external sites, or if you are
planning on adding access on a case-by-case basis?  I ask for two
reasons:

o I find it useful to have ADDE access to sites so that when they
  report problems I can take a quick look at the data they are
  receiving/decoding/making available

o at some point in the not too far future, I was going to ask sites
  that have installed the McIDAS remote ADDE server if they would
  be willing to cooperate with each other by letting the other sites
  have ADDE access to their McIDAS-XCD and ldm-mcidas decoded datasets

Any thinking on ADDE access to your machine(s) that you would care to
make would be greatly appreciated.

Tom