[McIDAS #AIT-655217]: Ticket ID: FVC-112860

Hi Paul,

re:
> I have been making some good progress but also running into some
> roadblocks.

OK...

re:
> It seems that I have "weather" serving the files correctly and "climate"
> is reading the correct data files. What I am confused about is what batch
> files need to be run to get both computers with the correct lists.

I created BATCH files of ADDE dataset definitions (DSSERVE invocations)
for essentially all of the data that one might receive via the IDD.
I tried to keep each BATCH file focused on a particular type of data
so there was no overlap; NEXRADDE.BAT is an example of these BATCH
files.  I also include a Tcl script called 'mcxconfig' that is designed
to be run by the user setting up ingest/decoding of data in Unidata
McIDAS.  'mcxconfig' asks the user questions like which IDD datastreams
s/he will be ingesting, and then creates combined LDM pqact.conf files,
a file of crontab invocations, and a "master" BATCH file of ADDE dataset
definitions (called LSSERVE.BAT).  The master BATCH file of ADDE dataset
definitions is designed to be edited by the user so that s/he can
set installation-specific things like the location of the files in
question.

My point is that if you are trying to keep weather and climate in
lock step, then the easiest thing to do would be to run 'mcxconfig'
on one of the machines; let it create LSSERVE.BAT; edit LSSERVE.BAT
to set your installation-specific things (e.g., you are writing things
to /home/data/... (or something), while others have their LDM write
data to directories like ~ldm/data/mcidas or /data/ldm/mcidas, etc.).
You should then be able to use your edited version of LSSERVE.BAT
to create/update/maintain all ADDE dataset definitions.  If the
directory structures for data are exactly the same on weather and
climate, you can use the file (after editing it) on both systems
directly.  If the directory structures are different (which might
be the case depending on the NFS mount of the data directory
on one machine and its local definition on the other), you will
have to create a machine-dependent LSSERVE.BAT file on each machine.
Defining the datasets after LSSERVE.BAT is created and modified
(if necessary) will be as simple as:

<as 'mcidas'>
cd $MCDATA
batch.k LSSERVE.BAT

re:
> First of all there is a huge amount of files being create with the
> DSSERVE.BAT file.

Yes, because it is designed to be able to create ADDE datasets
for all of the data available in the IDD.

re:
> How confusing to me! For instance:
> 
> DSSERVE ADD RTNEXRAD/N0Q NEXR TYPE=IMAGE
> DIRFILE=/home/data/level3/\ID/\TYPE/*_* "Base Reflectivity DR Tilt 1
> 
> What is this doing?

DSSERVE creates an ADDE dataset definition.  That definition is the
association of sets of files (specified by the regular expression
supplied to the DIRFILE= keyword) with an ADDE dataset name
(which is of the form 'group/descriptor').  The quote field
is a description of the ADDE dataset that will be returned to
the user running 'DSINFO IMAGE RTNEXRAD'.

re:
> This is run on "weather." Should it also be run on
> "climate?"

It depends on whether or not you want to define the datasets
on climate.  If climate will always get data from datasets
served on weather, then the answer would be no, you don't
have to define the same datasets on climate as on weather.

re:
> Then what is the difference between N0Q and N0R?

The NxQ products (N0Q, N1Q, etc.) are the so-called high resolution
base reflectivity products.  The are referred to as high resolution
not because they have higher spatial resolution, but because they
have higher data resolution.  The N0R product values are quantized
into 16 bins (so there are only 16 different values possible for
any pixel).  The NxQ products have 255 levels.  The Weather Service
considers the NxQ products replacements for the NxR products.
What the found when trying to get rid of all NxR products is that
end-users had a lot of time/effort invested in the creation of
other products from the base reflectivity at tilt 1 or N0R product,
and protested loudly that they did not want to see it dropped
from NOAAPort (at least not immediately).

re:
> Should I treat them identically?

You can.  They are both base relectivities.

re:
> When I tried to use mcidas to generate an image on "climate"
> I was fine with N0R but it could not find any files with N1R.

A number of NEXRAD Level III products were dropped from NOAAPort
a year ago January (January 2010).  The N1R, N2R, N3R products
are some of the ones that were dropped (since N1Q, N2Q, N3Q were
added as replacements).  As I mentioned above, end-users protested
loudly that they did not want the N0R product to be dropped, so
it was retained (for now, at least; it will eventually go away).


Why did I leave ADDE datset defintions for NEXRAD Level III
products that were dropped from NOAAPort?

I struggled with this... I figured that some sites might be using
the RTNEXRAD dataset for non-real-time data so there still may be
N1R, N2R, etc. products that they want to access.  The counter
argument for this is that since the products will not be real-time,
a new dataset should be defined for their access (e.g., NEXRAD/N1R,
NEXRAD/N2R, etc.).

I welcome any input you may have on this issue.

re:
> Let's start here and see where we head.

OK.  Please let me know if any part of the above does not make
sense/needs more clarification.

re:
> Thanks!

No worries.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: AIT-655217
Department: Support McIDAS
Priority: Normal
Status: Closed