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.
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 (http://padilla.cosmic.ucar.edu:8080/repository)... re: > 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 :-) re: > 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). re: > 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 data. 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 entries > 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 building and installing McIDAS. The user runs the script from the $MCDATA directory (which is ~mcidas/workdata for Unidata McIDAS). The result of running 'mcxconfig' 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. 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: ECE-924432 Department: Support McIDAS Priority: Normal Status: Closed