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: "Paul L. Sirvatka" <address@hidden> >Organization: College of DuPage >Keywords: 200102162013.f1GKD9L01250 McIDAS-X SFCCON GRDDISP Paul, >Thanks so much Tom! You really are the best! Why, thanks for the compilment! >Just a few follow-up questions and comments. OK. re: not being able to directly create/plot MIXDVG; use GRDDISP with MATH >Yech! Do you want me to try this alone or are you willing and able to help >with this? I gave this a shot a couple of minutes ago and have come up with something that I need you to try out and evaluate. >There is something that is desperately needed in the weather >community. IT is called the short fuse composite. It used to be done by >the Dodge City NWS but with AWIPS they are unable to do some of the >products. I am trying to imitate this with McIDAS. There will be some >difficulty but I think it is ultimately do-able. > >see http://www.dodgecity.net/nws/shortex.html >and http://www.dodgecity.net/nws/fuse.html for examples. OK, I took a look. I am pretty sure that McIDAS provides all of the calculation support for this to be done. The key is figuring out the steps. >We have tried to do this for some time and now with my return to McIDAS I >hope to do it this spring. OK. Here is what I came up with to calculate MIXDVG from surface data: IGU DEL 1234 SFCCON MIX SURFACEMAP LATEST OUT=SAVE MYDATA/GRIDS.1234 SFCCON STREAML SURFACEMAP LATEST OUT=SAVE MYDATA/GRIDS.1234 GRDDISP MYDATA/GRIDS.1234 2 MAP=SURFACEMAP G1='PARAM MIX' G2='PARAM U' G3='PARAM V' NEWPAR=MDVG GKGS SFC MATH='(G2*(DDX(G1))+G3*(DDY(G1)))' I am not 100% sure about this (I am totally rusty on actually calculating meteorological parameters), so I will rely on you to correct the notion of how to calcuate divergence of a quantity. 1) first, you will need a local ADDE dataset into which you can store objective analyses. The setup I send out with the McIDAS distribution has a BATCH file that can be used to define a dataset called MYDATA. The various descriptors in this dataset are GRIDS, IMAGES, PTSRCS, and TOPO. If you don't have this dataset setup in the account in which the BATCH files are running, then you need to set it up before proceeding: BATCH MYDATA.BAT 2) The MYDATA dataset setup allows local ADDE invocations (ones run from your account, not ones to a remote server) to access the full range of McIDAS GRID, IMAGE, PTSRC (MDXX), and TOPOgraphy data files. In the setup there is a one-to-one match between the dataset position and the actual file that represents that position. For example: MYDATA/IMAGES.1 -> AREA0001 ... MYDATA/IMAGES.9999 -> AREA9999 MYDATA/GRIDS.1 -> GRID0001 ... MYDATA/GRIDS.9999 -> GRID9999 MYDATA/PTSRCS.1 -> MDXX0001 ... MYDATA/PTSRCS.9999 -> MDXX9999 This setup allows one to think both in terms of ADDE access and in terms of direct, non-ADDE access to the data files. This concept will become more familiar as you work more with ADDE. 3) The first thing I did was to delete the GRID file GRID1234: IGU DEL 1234 There was nothing special in my choosing GRID1234 to work with. All you have to make sure of is that you choose a GRID file that is not one that is being written to by XCD decoders or is one that you do not want to use as a scratch GRID file. I could just as easily have chosen GRID0132 or anything else. 4) The next thing I did was to do an objective analysis of surface data to produce a grid of MIX. I want to save that objective analysis into an ADDE dataset group/descriptor.position (i.e., a specific GRID file): SFCCON MIX SURFACEMAP LATEST OUT=SAVE MYDATA/GRIDS.1234 The OUT= keyword says to do the objective analysis and save the output into the ADDE dataset group/descriptor.position MYDATA/GRIDS.1234. This dataset/descriptor.position was chosen to match the scratch GRID file that I chose in step 3). 5) I then created the necessary U and V grids that will be needed to calculate the mixing ratio divergence, again saving the objective analysis into MYDATA/GRIDS.1234 (which, again, is GRID1234): SFCCON STREAML SURFACEMAP LATEST OUT=SAVE MYDATA/GRIDS.1234 6) Finally, I use GRDDISP to create a field of mixing ratio divergence that is calculated from the MIX, U, and V grids previously made. The resultant field is displayed in frame 2 over the same map used in the objective analysis steps using a contour interval of 5x10**-6 while drawing negative values (convergence) with dashed lines: GRDDISP MYDATA/GRIDS.1234 2 MAP=SURFACEMAP G1='PARAM MIX' G2='PARAM U' G3='PARAM V' NEWPAR=MDVG GKGS SFC MATH='(G2*(DDX(G1))+G3*(DDY(G1)))' Again, I rely on you to correct my notion of how to calcualte the divergence of a parameter. re: storing parameter definitions in context files >That works. I assume I can create other .SITE files for 12 hour height >differences, etc... on upper maps? Actually, you create one SFCCON.SITE file and put all of your definitions in it. If you want to override a particular definition, you would create a SFCCON.USER file and put the definition that you want to use in it. The idea here is that there is a hierarchy of definitions defined in context files. The definitions of highest precidence will be found in xxx.USER followed by xxx.SITE, and finally xxx.CORE. With this setup, the McIDAS distribution can be sent out with a set of definitions (xxx.CORE); the site administrator can add to or override those definitions by creating an xxx.SITE file with entries that will be used by all users (xxx.SITE should be put into ~mcidas/data); and finally, each individual user can add to or override definitions from the core or site files by creating an xxx.USER file (should be put in ~user/mcidas/data). >BTW on the above command I put in CINT=.5 and althought the contouring >works, the labelling does not. It just say 0 0 1 1 2 2 for 0 0.5 1 1.5 2 >2.5 etc... That is because of the FORMAT=I3 specification that I sent along: P3DIF FORMAT=I3 \ MATH='P1-P2' \ ISFC='P1=PSL {TIME (NOW);DAY (NOW)}' 'P2=PSL {TIME (NOW-3);DAY (NOW-3)'\ SVCA='na'\ SYN= 'P1=PSL {TIME (NOW);DAY (NOW)}' 'P2=PSL {TIME (NOW-3);DAY (NOW-3)'\ ISHP='P1=PSL {TIME (NOW);DAY (NOW)}' 'P2=PSL {TIME (NOW-3);DAY (NOW-3)}' You can change this format to anything that makes sense. For instance, if you want to see 10ths of a mb change, you could set FORMAT to be FORMAT=F5.1. This gives one decimal point, two places for whole mb values and one space for a negative sign. >Everything else is working fine! Thanks. Your welcome. >From address@hidden Sat Feb 17 09:53:23 2001 >Subject: Re: 20010216: The first of many? > >One other thing... > >> OS "te.k DATE \"`datelist.k #Y FORM='(MM)/(DD)/(YY)'` >> TE SFCTIME "#DATE #HZ > >On this...what I would like is not the hour to be xx:xx:xx but just the >hour like 16Z. That is why I used syskey. OK. There are a number of ways of doing these kinds of things. For instance, you could write a little McBASI script that would do the formatting for you: REM ? Name: DATEFMT.MCB REM ? REM ? Purpose: Format the current DAY and time as MM/DD/YY HHZ REM ? REM ? Invocation: REM ? RUN stringname FILE=DATEFMT.MCB REM ? REM ? or REM ? REM ? DATEFMT stringname REM ? REM ? where 'stringname' is the name of a string in which you want REM ? to save the formatted data. REM ? REM ? Exmaple: REM ? REM ? DATEFMT DATE REM ? REM History: 20010217 - Example code REM Get 'stringname'. If not specified, default to "DATE" input s$ if s$ = "" let s$ = "DATE" REM Format the DAY d$ = mid$(day$,3,2) + "/" + mid$(day$,5,2) + "/" + mid$(day$,1,2) REM Add the formatted TIME d$ = d$ + " " + mid$(time$,1,2) + "Z" REM Save complete formatted date in the string table as 's$' ptable d$,s$ REM Done stop >As long as I am getting data won;t that be OK to use my own syskey? Yes, but what happens when your data ingestion is not running for some reason and you want to take advantage of other ADDE servers out there? >Gosh I guess it is more than one thing...but I want to look at my own MD >files anyway.... I agree. I just want you to be in a position to be able to take advantage of all of those other sites running ADDE servers that may be getting data that you will want/need to access at some point in the future. >I need to set things up so that MD files are viewed >locally. SFCPLOT the way things are now is looking elsewhere at yoour >remote site. Am I right here? This depends on how things were setup at COD. This is the real beauty of ADDE. Changing where you get data from is extremely simple. To answer your question about where you are accessing PTSRC (MD) data, you only need to do a: DATALOC and look to see what the output for RTPTSRC is. If it is pointing at something other than LOCAL-DATA or the name/IP address of your own machine, then you are going out on the net to look for the data. If it is LOCAL-DATA, then it means that your account is running the ADDE commands in your own McIDAS session. In order for this to work, your session would have had to been configured to: o know how to find needed MD files (REDIRECTion and MCPATH settings) o know the mapping between MD files and ADDE POINT source datasets (DSSERVE settings) The cool thing is that you can have your account setup to be able to do this, AND have your local system be setup to be able to do this (i.e., run the remote ADDE server on your ingest machine), AND be able to go out on the net if desired. I guess that this has always been one of the hard things about using McIDAS: there are just so many ways of doing what you want that it gets confusing at times. By the way, a little while ago I was asked if I would help upgrade COD to McIDAS-X 7.7. I commented that the upgrade was very easy and should be tried locall first so as to get the hang of doing upgrades. I never heard any more about this, so I don't know: o if you have been upgraded from 7.6x to 7.7x o if you are, in fact, running a remote ADDE server there at COD Can you shed any light on the status there? If need be, I can help you get the remote server up and running and provide some examples of accessing local and remote data through ADDE. It is not that you don't already know how to do this, but some examples showing some of the possibilities might be illuminating. I think you can chat with Gilbert S. about this to get his view of things. Tom >From address@hidden Sun Feb 18 13:06:58 2001 >From: "Paul L. Sirvatka" <address@hidden> >To: Chuck Doswell <address@hidden> >Subject: Moisture Divergence Chuck... I hope things are well for you. Spring is coming really quickly. I hope SDS is not too severe (although for me it is!) Anyway, I have a question that Tom Yoksas from Unidata and I were trying to figure out. It is moisture (flux) divergence. We are trying to figure out how to calculate it. From you tech memo you state that it is the divergence of the product of velocity and a moisture parameter, let's say w. So..it should be del dot (w*velocity), no? or expanded.... w*(du/dx + dv/dy) + u*dw/dx + v*dw/dy from grid point calculations. To get usuable readings, I should multiply this answer by 3600 to get the values to (g/kg)/hour. A few questions...can I use w in g/kg in the above expansion or must I use kg/kg? Is that equation correct or am I doing something wrong? Do I need to multiply by another 10 to get usable values? On the SPC site they have moisture convergence of g/kg/hr**7 I have no idea what that is! See http://www.spc.noaa.gov/sfctest/mcon.htm Also...LAMPS has http://www.nws.noaa.gov/tdl/lamp/analysis_pages/MRDV.shtml which is different. From your tech memo it has an example of (g/kg)/hour * 10. Thanks for any help you can be! Paul -- ****************************************************************************** * Paul L. Sirvatka | Office: (630) 942-2118; Lab: (630) 942-2590 * * Professor of Meteorology | COD Weather Lab: (630)-858-0032 * * College of DuPage | Address: 425 22nd St. Glen Ellyn, IL 60137 * ******************************************************************************