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

[McIDAS #ECE-924432]: Creating and populating a local ADDE server

Hi Kevin,

Sorry for the _slow_ response... I have been working on a RAMADDA installation
for a PASI workshop that UCAR/Cosmic is putting on in Cartagena, Colombia at
the end of May/beginning of June 

> Hi Tom, comments below ... sorry that M$**T Outlook won't let me do a "reply"
> that looks to properly indent things to make it clear where I am replying to 
> you ...

No worries.

re: I got together with Marty to discuss McIDAS ADDE last Friday
> Yes, I knew you were going to do this, but alas I had to get to the airport 
> ...

There never seems to be enough time to do the meetings AND discuss
other things in-depth (sigh).

re: decoding of METARs, etc.

> So that is not done in "real time" via a decoder (a la dcmetr) spawned
> by LDM's pqact?

Exactly.  The setup is a bit different than the single action per
decoder setup of GEMPAK, but it is similar.

re: similarities between GEMPAK and McIDAS POINT files

> Yes, you related that story to me ... very interesting ... not surprising
> I guess!

Not surprising at all given that McIDAS and GEMPAK are the "grand ole men"
of meteorological display/visualization packages :-)

> I know very little about relational databases, but I'm under the impression
> they are more "efficient" than the flat files such as GEMPAK/MD.

Yes, but if GEMPAK accesses .gem files like McIDAS accesses MD files, there
is a bit of SQL involved ... SSEC wrote their own database code to provide
the services needed (you have to remember that McIDAS began before Unix,
so they had to invent things that were needed).

> I guess the EDEX component of AWIPS2  is going down the database road, since
> it uses Postgres.

Postgress is only used to store metadata.  The actual data are stored in HDF5
files.  This is very similar to how McIDAS uses MySQL to serve GRIB2 model

re: setting up the user 'mcadde'
> OK, I did not do that right, then ... I set up "mcadde" with its own home
> directory ...

SSEC has their users do that.  I find that it too cumbersome to maintain
two user accounts (three actually for SSEC, they also have a user
known as 'oper').  A long time ago, I combined the activities of 'mcadde'
with 'mcidas' to simplify the setup/management of McIDAS and ADDE.  I
think my approach works very nicely.

re: what script does one run to setup pqact.conf files, ldmd.conf and crontab 

> Which script is this?  It's not the mcunpack or mcinet2009.sh script, right?

The script is named 'mcxconfig'.  The user 'mcidas' runs the script after 
and installing McIDAS.  The user runs the script from the $MCDATA directory
(which is ~mcidas/workdata for Unidata McIDAS).  The result of running 
is a couple of pqact.conf files, a file of ldmd.conf entries and third file
of crontab entries that the user needs to incorporate into the LDM setup.

re: offer to login to set things up
> Thanks ... maybe soon!  Right now I am just playing with this on my local
> machine.  If I can't figure out how to use the XCD features and the decoding
> aspect, I will ask you to pay me a virtual visit ...

OK.  If you find yourself struggling to understand anything, please ask.


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: ECE-924432
Department: Support McIDAS
Priority: Normal
Status: Closed

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.