This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Wayne Bresky <address@hidden> >Organization: Cornell >Keywords: 200108091752.f79Hqc127856 McIDAS cylinder Wayne, >I was confused by the following statement in configuring the mcidas account >section of the installation. What is meant by the following: > >"Modify the file name cylinder number so match your McIDAS data files." > >Is this a refernce to the file range for each ADDE dataset? I am not exactly sure where this reference is, but I can offer the following: The concept of a "cylinder number" in McIDAS refers to the number portion of data files named with McIDAS naming conventions: AREA1234 <- 1234 MDXX0001 <- 0001 GRID9999 <- 9999 The standard McIDAS way of naming files is to use a fixed base name (AREA, MDXX, GRID) combined with a 4 digit number that can range from 0001 to 9999. The reference above is most likely related to setting up your local copy of the ADDE server mapping table BATCH file, LSSERVE.BAT. In my instructions, LSSERVE.BAT is first created as a copy of DSSERVE.BAT (all of this is done in the ~mcidas/data directory) and then edited _if necessary_ to match the local setup. The idea is that the end user (you) has complete control of how many of each type of product is kept on disk at his/her (your) institution. The default setup sent with Unidata McIDAS is to save 10 of each kind of image in the Unidata-Wisconsin (LDM MCIDAS feed type) datasetream. If one stays with this setup, then the entries in DSSERVE.BAT (and hence the LSSERVE.BAT copy that you make) are ready to use. If, on the other hand, one decides to keep more or less of any particular product, then the set of data files that will comprise an ADDE dataset (like RTIMAGES/GE-IR for example) will be different and the user (you) will need to make adjustments when setting up that dataset. >I assume I >would only have to make changes to these ranges if I were renaming the >files (say I wanted to move AREA0100 to AREA0500 or something >like that). This is another example. If you somehow took the set of files being ingested in one cylinder range, say AREA0060 - AREA0069, and copied them to another cylinder range, say AREA1100 - AREA1172, and wanted to be able to serve the set that was copied using the same name that would be used for the original set, then you would need to change the setup in LSSERVE.BAT before you make those definitions active by running 'BATCH LSSERVE.BAT' from a McIDAS session as the user 'mcidas'. The other thing you might do in LSSERVE.BAT is comment out all entries for datasets that you don't/won't have locally. This way, your server won't be setup to say you will serve a dataset when you won't have the data to serve. What I have in mind here is commenting out the entries in LSSERVE.BAT for the datasets WNEXRAD and WNOWRAD. These datasets would be useful IF one were still contracting with WSI for NIDS and NOWrad (tm) products. Since the IDD now carries the NEXRAD Level III radar images, one no longer needs to pay for the NIDS products (they are the same as the NEXRAD Level III images from NOAAPORT that are conveyed by the IDD). One could, on the other hand, still be getting the NOWrad national composite radar imagery since there is no equivalent product being conveyed in the IDD. In this case, one would keep the definition for WNOWRAD (perhaps renaming the dataset to RTNOWRAD). >The ADDE dataset names appear to match the data files. Yes, as sent out everything is self consistent. If you stay with the default setup, you don't have to do anything other than possibly commenting out the LSSERVE definitions for datasets you don't/won't have. I know that a lot of this stuff seems very strange and hard to grasp. It is a legacy of the really terrible naming convention adopted for default file names in McIDAS. We are working on moving away from this in order to make life easier for McIDAS users. Please let me know if the section you were referring to was different than the one I went into aboe. Tom