[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010809: "cylinder number" reference



>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


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.