The LDAD system in AWIPS can bring in an extremely varied set of hydrometeorological variables. In setting up the default AWIPS configuration, it is impossible to anticipate everything LDAD might bring in and set up display capabilities for it. This was the primary impetus for creating the adaptive plan view plotting subsystem within AWIPS. This capability allows infinitely configurable station model based plan view plots of any LDAD variable. It does not, however, allow the user to contour any of these variables.
The LAPS and MSAS components of AWIPS allow for the ingest and analysis of many standardized LDAD variables, and these can of course be contoured through the Volume Browser. However, LAPS and MSAS were never designed to be locally configurable for the addition of unique LDAD variables. As such, a configurable capability for analyzing and contouring an arbitrary point data variable on the fly was deemed necessary.
The analysis package used to support such a capability should be viewed as more of a visualization tool than an objective analysis. As such, the most important thing is to match the observations as closely as possible given the resolution of the grid used. That is, it would ideally result in contours that look like a person did a hand analysis. Since it runs in real time, it must also be fast.
The simplest well known and documented analysis scheme is the Barnes analysis. One feature of the Barnes is that one must pick a single distance scale representative of the data set. In areas where the distance scale is large compared to the observational density, details get washed out. In areas where the distance scale is small compared to the observational density, there is a tendency to create bullseyes. Add to this a tendency to approach the mean in large voids, and the Barnes is just not suited for matching the observations in a situation where the spatial characteristics of the data set are hard to predict. More complex schemes such as OI would have performance problems.
Here is a high level description of the analysis package that was coded up. First, all observations are resolved to the nearest grid point. A work grid of the same spatial resolution and expanded to twice the size of the analysis grid is used for this task to more accurately handle observations just outside the analysis grid. Where more than one observation resolves to the same point, all of these are averaged. As the values are assigned to the remaining analysis grid points, one always finds the unassigned grid point furthest from any assigned point. Once a value is assigned for that grid point, it becomes a virtual observation for subsequent calculations. When assigning a value for an analysis grid point, the space around the point is divided into octants. The nearest assigned point is found within each octant. If the point is mostly surrounded by data, each point is weighted by the inverse of its distance to the fourth power. If only points off to one side are available, the weighting is according to the inverse of its distance squared.
This scheme is fast and does an excellent job of adapting to the spatial characteristics of the data, even if they vary widely over different parts of the same analysis grid. The spectral response is not pleasing, in that there is a lot of 2-delta noise. However, that is the trade-off for having the analysis rigorously match the observations, which can vary over that space scale as well. Certainly, one would never want to hand the output of this analysis scheme to a numerical model. Nor is there any quality control, so caveat emptor.
There are demonstration versions of this for METARs in 5.2.2 with the menus entries left out. One can temporarily add entries to the end of the METAR->Other Plots submenu in nationalData/dataMenus.txt on the Surface menu to activate these. If one has an override file for dataMenus.txt, one would need to add these to the override file and run the -tables localization task. Here are what these entries need to look like:
productButton: 120120 # T productButton: 120124 # T img productButton: 120121 # Td productButton: 120122 # Wind
To see these menu entries one needs to restart D-2D. This capability uses design files to gather the data and potentially do calculations on the data before it is handed over to the analysis. To understand more about how design files work, one should see adaptivePlanViewPlotting.html. Grid depictables are given keys that point to these design files and to the point data set being used. When a properly formatted depict key entry is made, a PlotDesignData object is constructed and is asked for an analysis of the variable of interest. The Grid depictable then displays that data as if it were any other grid.
We will use these demonstration entries to illustrate how one would go about setting up the contouring of an arbitrary LDAD variable. For any use of this capability, it is up to the user to choose unused keys for the implementation. For now, picking additional keys in the 120200-120999 range should be totally safe.
If one wanted to add menu entries for LDAD displays specific to the local site they would go into /data/fxa/customFiles/LLL-ldadMenus.txt. The product buttons in the demonstration menu are linked to displayable products using these corresponding entries in the file nationalData/productButtonInfo.txt.
120120 | 120120 |Temperature |Metar Temp Analysis | 0 120124 | 120124 |Temp Image |Metar Temp Image | 0 120121 | 120121 |Dewpoint |Metar Dewp Analysis | 0 120122 | 120122 |Wind |Metar Wind Analysis | 0The entries for the local site would go in /data/fxa/customFiles/LLL-localProductButtons.txt. The header documentation at the top of the the default productButtonInfo.txt files explains how these entries work. Depict keys and product buttons are the same by convention, not by necessity; it usually makes it easier to keep track of things. Here are the depict key entries for the demonstation, from nationalData/depictInfo.manual:
120120 |3 |82,120120,1003| |0|1 |METAR Temp Cont (F) |METAR T |1 |0 |1 | |p,150,150,Tf |900 120124 |10|82,120120,1003| |0|0 |METAR Temp Img (F) |METAR T |8 |0 |1 |29 |p,150,150,Tf |900 120121 |3 |82,120120,1003| |0|1 |METAR Dewpt Cont (F)|METAR Td |1 |0 |1 | |p,150,150,Tdf |900 120122 |4 |82,120120,1003| |0|1 |METAR Wind (kts) |METAR Wind |1 |0 |1 | |p,150,150,uW,vW |900The entries for the local site would go in /data/fxa/customFiles/LLL-localDepictKeys.txt. These enties are probably the most difficult to get right and the most specific to the implementation, so even though header documentation exists in nationalData/depictInfo.manual, we will describe the individual entries here in detail. It will still be useful to be familiar with this header documentation. The first field is the depict key associated with the display, and is what goes into the product button table. The second field is the depictable type, 3 for contour, 10 for an image depiction, and 4 for wind barbs. In the third field is a list of data keys to be used (there will be more on data key entries later). 82 is the key for decoded METAR data, 120120 is the key for the associated design file, and 1003 is the key for the METAR station list. The corresponding keys for LDAD would be 87, implementation dependent, and 1011. The next two fields will always be empty and 0 for this type of display, and the next field will be 1 for a graphic and 0 for an image. The next two fields are legend information for the display and for logging. The field immediately after the legend information will be 8 for images and 1 for graphics, and the next two fields will always be 0 and 1. The next field is the color table index and as such needs an entry only for an image. The second to last field is the so called `extra info' field, which is what signals to the grid depictable that it should grab point data and contour it. The `p' is the flag that invokes this feature, the next two numbers are the dimensions of the analysis grid, followed by the item_ids in the design file for what is to be analyzed, one for a contour or image and two for a wind barb display. The last entry is a notification delay, which one might want to make smaller, say 300, for LDAD data. Here is the data key entry for the demonstration, found in the file nationalData/dataInfo.manual.
120120 | | | | | | | |metarAnalDesign |.txt |metar contour demo design fileThe format is straightforward: this just makes data key 120120 point to the appropriate design file, and the choice of this key is arbitrary and implementation dependent. The file where the corresponding entry for a local LDAD display would go is /data/fxa/customFiles/LLL-localDataKeys.txt. The name of the design file of course must be unique, and for a local implementation would reside in /data/fxa/customFiles/. Design files need to have names like *Design.txt. All the default design files are in nationalData/, as is metarAnalDesign.txt. What follows is enough of the contents of metarAnalDesign.txt to understand how the temperature data is presented for analysis. As mentioned before, one can learn more about design files from adaptivePlanViewPlotting.html.
time_step 3600 item_id KF1 constant = 1.8 item_id KF0 constant = -459.67 item_id TC type float dimension scalar netcdf_id temperature min_valid 200 max_valid 340 item_id T10 type float dimension scalar netcdf_id tempFromTenths min_valid 200 max_valid 340 item_id T function or inputs T10 TC item_id Tf function lintrans inputs T KF1 KF0 placement upper_left method formatted format %dThe netcdf_id keyword is always followed by the exact name of some netCDF data variable. For METARs, one can look these up in nationalData/metar.cdl. For LDAD mesonet data, one can look in nationalData/LDADmesonet.cdl for the default set of mesonet variables, but of course the whole point of this is to allow one to see contours of unconventional variables. Thus one would have to look at the override file for LDADmesonet.cdl in that case. What happens for the METARs is that two kinds of decoded temperature in kelvins are available, temperature and tempFromTenths. The `or' function is used to combine these two such that if the more precise tempFromTenths is available it will be used, otherwise the standard METAR temperature will be used. Finally, the item_id `Tf' is defined by doing a units conversion on the `T' item such that the data is in degrees F. Tf is also the string that appears in the depict info that says which item to contour. A units conversion is needed here because there is no way to associate style info with one of these displays as there is for gridded data displays from the Volume Browser. The value 3600 after the time_step keyword means that in a loop there will be one display per hour. The keywords `placement,' `method,' and `format' are significant in two ways. Most importantly, the existance of the `placement' keyword tells the design file that data from this particular item should be made available to the outside world, which is necessary for this capability to work. Second, one could temporarily copy this file to localizationDataSets/LLL/metarStdDesign.txt and then (after a D-2D restart) use the standard METAR plot to see a plot of the data values that will be contoured, which can help with troubleshooting. If one were to do the same thing to troubleshoot an LDAD contour, one could temporarily copy the design file to localizationDataSets/LLL/ldadMeso15Design.txt to test this with the 15 minute LDAD plot.