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