19991122: A quick overview of how ADDE works (cont.)

>From: "Jennie L. Moody" <address@hidden>
>Organization: University of Virginia
>Keywords: 199911182049.NAA16853 McIDAS ADDE

Jennie,

re: explanation of how ADDE works
>Yes.  This makes total sense.  And I think I see that some of
>my confusion came with failing to catch the (major) distinction between
>the way McIDAS works with the local versus the remote server.  I think
>I now see that if the data is defined on the local server, McIDAS never
>needs to use anything other than the DSSERVE-managed list (RESOLV.SRV,
>right?).

Your session also must know how to get at the data files that compose
the dataset (REDIRECTions and MCPATH).

>I hope this is correct.  And its never explicity stated
>in the McIDAS User's Guide that RESOLV.SRV is what gets written by
>DSSERVE ADD commands, so I might still misunderstand this.  

I guess that SSEC figured that this was at a level of detail that the
average user did not need to be concerned with.

>However, if the dataset is not on the local server, and McIDAS 
>finds this out by reading the McTABLE_READ environment variable, 
>then it locates which remote server something is residing on.

Right.  The sequence is, however, to first check to see if the dataset
is on a remote server (through the files listed in MCTABLE_READ)
failing back to being LOCAL-DATA unless the dataset has been declared
to be LOCAL-DATA in the first place.

>You 
>have outlined the procedure it goes through to get onto that remote 
>server, and when it does, it has to read the RESOLV.SRV file on the 
>remote server to know specifically *where* the data are resident 
>(ie., what AREA and GRID files, and it uses the remote server set of 
>redirections for user mcidas to know what directory, right?).  

Exactly correct.

re: how to declare use of compressed data transfers
>Okay, you explained this to me once before, but I didn't know
>*how* it did this.

OK.

re: how the McIDAS environment is setup by ~mcidas/bin/mcservsh reading .mcenv
>Okay, I get it. 


re: how RESOLV.SRV is found
>Right, and it was the role of the RESOLV.SRV which I was forgetting
>about.

McIDAS _is_ complicated by its flexibility.

>And the RESOLV.SRV should exist independently for each user, 
>correct, since each user can develop there own local datasets.

Correct.

>But anything we want to make available on the remote server
>needs to be added through a dsserve command within user McIDAS
>which will manage the remote users access to what is now
>local data.

Yes.  This shows that you do understand the process now.

re: making sense
>I think so, as long as my comments don't suggest a
>misinterpretation.  

Nope.

>I really appreciate this kind of explicit description of the
>process, at times it can all seem too black-boxish.  

This is the kind of high level overview that we hope people
attending workshops come away with.

>Sorry I waited so long to reply.  I read and started to
>process your answer late Friday (dangerously close to mid-night).
>It actually helped clear up my thinking right away.  But, 
>I didn't get a chance to really think about the message, look
>at McIDAS, etc, until this afternoon.  So, I believe I do 
>have a much more solid understanding.  

No problem.

>Speaking of Tony, I hope you were able to understand the questions
>he sent it, he doesn't always provide a lot of context (understatement),
>but then I probably always provide too much (!)-

I havn't looked yet (lack of time).

>anyway let me give a quick recap:
>
>The operational derived water vapor product image was failing to be
>made after the switchover to McIDAS 7.6.  Tony discovered that the
>GRDCOPY command would not allow him to add the two grids we have
>always added together previously: a correction term
>which is based on the layer average temperature from the Eta
>model, and a correction which is based on the satellite zenith angle.
>The reason appeared to be dependent on the fact that the grids
>were from different times (the zenith angle grid is a function of
>satellite-earth geometry only, so there is no need to recaculate it).
>They also covered different overall domains.  As I have noted,
>the product grid was able to be made with GRDCOPY under 7.4, but
>not under 7.6.  In the meantime, Tony did verify that if he made
>the zenith angle grid on the fly (made it for the current time, 
>and over the same domain as the model grid), then he could revive
>the operational batch and get the product made.  However, we still
>have the question, is this a bug?  Or was it considered a bug in
>7.4 that one could add together grids from different times/regions
>and someone consciously closed that condition??  

I can't answer that without a lot of thought.

>Another question we both (Tony and I) still have involves the fact that
>there is now a visible seam in the  derived product images that we
>didn't have previously.  Again, this is something that has resulted
>from the change from McIDAS7.4 to 7.6, there didn't used to be a visible
>white seam, but now there is.  It seems that to help us with this one
>you might need to look at how we are making these images.  You are welcome,
>if and when you have time to address this one....  

Is the seam at the east-west composite interface?  If so, it could be due
to a change in calibration for one or the other satellite.

re: circular dependency
>Yes, and now I get what you meant.

Super.

re: I hope that the above helped.
>I greatly appreciate your help with all of these things Tom.  

You are welcome.

Tom