[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20010217: McIDAS-X Calculation of MIXDVG (cont.)
- Subject: 20010217: McIDAS-X Calculation of MIXDVG (cont.)
- Date: Sat, 17 Feb 2001 13:22:17 -0700
>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 *
******************************************************************************