Stage 1) in December, upgrade the current Eta-48km/38level early Eta run at 00z and 12z to 32km/45levels. This run's domain covers ALL of N. America including Alaska & Hawaii. This run would continue to go out to at least 48 hours and may be extended to 60 hours from the 00z run.
Stage 2) in March, move the current Meso Eta-29km/50level runs at 03z & 15z to 06z and 18z, run them at 32km/45levels on the LARGE domain out to TBD hours (18, 30, 42, or 54 hours depending on resources). This then constitutes a 4-per-day run of the Meso (32km/45level) for all of the N. American domain running in the early slot (i.e. dump time of an hour and 20 minutes after 00z, 06z, 12z & 18z) prior to NGM and AVN at 00z & 12z and prior to AVN at 06z & 18z.
OUTPUT STRATEGY: We can NOT make changes to the AWIPS data stream in the short term, so ...
We will continue to generate the same output from the early Meso Eta as we currently put out from the early Eta, e.g. AWIPS grid #211 (80km). [We will also be generating 80-90km NGM-look-alike files to keep various legacy systems (AFOS, FOS and FAX) and orphaned codes alive.] YES, they're horribly degraded in resolution, BUT they all will reflect improvements in the forecast quality due to the increase in resolution of the actual computational model from 48km/38levels to 32km/45levels, you just won't be able to see the higher resolution signals without doing something extra like pulling down stuff (see next paragraph) from the OSO server for display on the SOO/SACs or with PCGRIDDs.
IN ADDITION, we will be generating a full complement of output fields on the higher resolution grid #212 (40km), the normal small complement of fields on #215 (20km) and a full complement on the computational resolution grid #221 (32km - this is a NEW grid which covers all of North America and the computational grid of the early Meso Eta on a Lambert conic-conformal grid projection at 32 km resolution with ~97000 grid points). We intend to generate incremental tiles for grid #221, so users would only need to pull down those tiles which cover their area (and a master grid #222 which will be 188km version [every 6th point] of #221 used to process the increments and which can be used to see the BIG PICTURE or whole domain of the early Meso Eta with little bandwidth demands).
Summary:
Higher resolution runs of the Meso Eta will have to wait for the acquisition of our next computer (hopefully to arrive mid FY98 and be operational by early FY99). We intend to push our 4/day runs as close to 10 km as we can. How close we get will depend on the amount of machine our measly $30-40 million will buy us. In the meantime, we will continue to make the nested runs for practice. FY99 is also the timeframe I've heard that will allow changes / expansion of the AWIPS gridded product distribution, so the OSO server connection will have to do until then, I guess.
WHAT IS THE DIFFERENCE BETWEEN THE EARLY AND MESO ETA RUNS?
Currently, the same source code is used in both the Early and Meso Eta Model systems. The last major implementation was on 18 Feb 97.
The Early Eta is named after the operational slot that it runs in, it is the first of the operational models to run and is therefore known as the "Early" run. It replaced the LFM in this slot in June 1993, and the LFM was also known as the "Early" run. The Early Eta has 48km horizontal resolution and 38 vertical layers and runs over a domain which encompasses nearly all of North and Central America including surrounding oceans. Initial conditions are provided by the Eta Data Assimilation System (EDAS) which runs on a 3h forecast/OI analysis/update cycle for 12h prior to the start time of a model run. The Early Eta runs twice a day at 0000 and 1200 UTC. Boundary conditions are provide by the previous cycle's AVN run of the Global Spectral Model.
The Meso Eta is the operational mesoscale version of the Eta Model. It contains a 29km horizontal resolution and 50 vertical layers, running over a domain that includes the U.S. and most of Canada and Mexico plus surrounding ocean regions. Initial conditions are provided by a "mini-EDAS" which is a 3h forecast/OI analysis/update cycle that begins 3h prior the the start time of a model run. The Meso Eta runs twice a day at 0300 and 1500 UTC, the later start time allows for more data to be used in the analysis and for boundary conditions from the current cycle's AVN run.
Future plans are to run the Meso Eta in the "early" time slot at 32km/45layers beginning in late summer 1997. This will replace the 48km Early Eta run. The domain will approximately be the same as the 48km Early Eta, which will cover nearly all of North America including Alaska and Hawaii. Shortly after this, we plan to move the 03 and 15Z Meso Eta runs to 06 and 18Z and make the model identical to the "Early Meso" run at 32km/45levels. This would be the four times-a-day Meso Eta system running in the early slot at 00 and 12Z and off time at 06 and 18Z with EDAS done for all of North America in between.
18 FEBRUARY 97 EARLY AND MESO IMPLEMENTATIONS
Here are a few things to look for since our change BUNDLE went into the early and Meso runs 18 February:
form drag - this was put in to reduce the problem that all NCEP models have with lows coming out of the Rockies too far north and too intense. This problem is not severe in the Eta (as opposed to NGM and AVN) The changes you should expect are pretty minimal in the 48 km early and 29 km Meso runs, but will help when we are forced to run a back-up version at 80 km (hasn't happened YET!).
better moisture and cloud advection - this is an incremental change which I don't think you will be able to see, but everything is handled just a little bit better.
eccentric orbit + corrected ozone + aerosol - these corrections and changes reduce a problem we recently found in our radiation package which was producing excess net shortwave radiation at the ground, which was producing higher daytime temp's and more vigorous pbl mixing which generated too deep a mixed layer dragging the surface dew-points too low (inverted V on a skew-T).
reduced albedo over snow - this will allow low level temperatures to get a little warmer over snow during daytime
improved computation of cloud fraction + radiation feels cloud in each model layer rather than rather than through 3 layers - these are incremental improvements and are better physical representations with the model's atmosphere feeling the effects of the model's clouds in each of the Eta model layers, the result is slightly cooler max temps during day and slightly warmer min temps at night under cloudy conditions.
improved input fields of vegetation greenness fraction and initial soil moisture - more accurate and higher detail
improved soil moisture and enhanced bare soil evaporation - these changes increase the evaporation or latent heat flux and compensate somewhat for the low-level dryness induced by the too deep mixed layer
corrections to physical processes related to melting snow - 2 m dew points used to be warmer than 2 m temp over melting snow, this situation is now corrected.
increased the background level of turbulent mixing - slightly more mixing under very low wind speeds, can produce slightly warmer temperatures under radiational cooling situations where the Eta is too cold.
Geoff DiMego
CHANGES TO THE OPERATIONAL "EARLY" AND MESO ETA MODELS
At 1200 UTC 18 February 1997 a series of changes was implemented in the operational Early (48km/38lev) Eta model, and at 1500 UTC 18 February 1997, the same changes were implemented in the operational Meso (29km/50lev) Eta. A brief description of these changes follows:
1) MODEL CHANGES - Addition of a form-drag scheme - Implementation of a more efficient and accurate positive definite advection scheme for moisture and cloud. - Eccentric (rather than circular) orbit around the Sun - Corrected atmospheric ozone distribution - Effect of aerosols on net shortwave radiation added - Reduced albedo over snow - Model radiation impacted by cloud in each individual model layer, rather than through 3 deep layers - Improved computation of cloud fraction - Improved input fields of vegetation greenness fraction and initial soil moisture - Enhanced bare soil evaporation - Corrections to physical processes related to melting snow - Increased the background level of turbulent mixing 2) POST-PROCESSOR CODE AND OUTPUT CHANGES - Implementation of a more efficient version of the Eta model post-processing code. - The following grids will be directly output by the Early Eta model post-processor (complimenting the existing grids) at 6-h forecast intervals: - AWIPS grid 211 (80 km Lambert Conformal over CONUS) - AWIPS grid 214 (48 km polar stereographic over Alaska) - The following grids will be directly output by the Early Eta model post-processor at 3-h forecast intervals: - AWIPS grid 212 (40 km Lambert Conformal over CONUS) - Eta model computational grid on pressure levels - Eta model computational grid on model levelsThese additional fields will be accessible via anonymous ftp on the nic server (nic.fb4.noaa.gov or 140.90.50.22). The content and timeliness of the current Eta model products on the OSO server remains unchanged. The additional grids described above will be available on the OSO server in the near future.
A previously advertised change of GRIB file identifiers for Eta boundary layer fields (GRIB PDS octets 9-12) is NOT part of this implementation due to delays in users software conversion. These changes will occur at a later date.
THE ETA HAS BEEN MORE ERRATIC LATELY, WHY?
More details of the QUESTION:
Isolating this change to a single causality is far more difficult since there are several factors which may separately or together have brought on the change. Those which come to mind include:
1.) The recently implemented changes to the ETA model...have we implemented routines of increased sensitivity to the real atmosphere which induced potentially nonlinear modes which were designed to increase the model sensitivity and response...with the unintended consequence of higher order chaotic response in phase space.
2.) A series of storms which have had a southerly origin and been phased to miss the Mexican raobs...resulting in a temporal data void with crucial timing.
3.) A change in some data assimilation or acquisition routine which has increased the inherent variation in the overall database.
4.) The unusual nature of the late winter flow with consistent ridging and strong subtropical jet flow over our area, thus the systems have been originating in a data void area...where the models can not be expected to handle them well.
Any comments or other possibilities?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ANSWER:
Apology #1: Both the atmosphere and numerical models are extremely complex and highly non-linear in their behavior. For this reason, I tend to resist the urge to find a single cause for anything.
Apology #2: Personally, I have a hard time connecting solutions to our numerical model problems to the concepts of non-linear instability, modes & phase space and, especially, the dreaded CHAOS thing. I mean, conceptually, they are great and help us all understand complex atmospheric behavior, but when it comes down to helping me decide how to change our numerical model, specifically the Eta Model, I find they aren't much help. Maybe I'm just thick headed. I know I'm bald, for what that's worth.
We have not implemented routines deliberately to increase our sensitivity PER SE. We have implemented new routines or changes to existing ones that simulate real atmospheric behavior in a more accurate manner. This has been a continual process and our change package of 2/18/97 was, for the most part, in this category: incremental improvements. In my opinion, none of those changes individually nor the bundle as a whole is the cause of the behavior you have noticed.
On the other hand, our current system IS more sensitive than it used to be. This comes from our improved ability to simulate the full spectrum of atmospheric behavior through a better model with better physics and numerics. Thus, the model has an increased ability to respond to initial conditions, and, like a marriage, this is for better or worse, for richer or poorer. Here, of course, I'm talking about data sensitivity. Your points 2), 3) and 4) ALL relate to data and YES we are more sensitive to initial conditions and data voids. BUT I wouldn't go back to being less sensitive. Again, there is a whole lot of better and richer that has come along with this heightened sensitivity in the form of improved analysis and data assimilation.
Higher sensitivity has also come through the positive impact of higher grid resolution. The early Eta has been at 48 km / 38 levels since October 1995 and we will upgrade this again this year to 32 km / 45 levels. With the higher resolution, there has been an increased ability to resolve all features in the model and to better predict their evolution with time. Perhaps most visible, however, is the higher level of detail of the model's terrain field and initial conditions. We are hammered by y'all to continue to get as much detail (as in mesoscale structure) into those fields as possible. A particular challenge is getting observations which lie below the model terrain to be included and have a beneficial effect on both the initial conditions and subsequent forecast. We've had more success with this in the 10 km / 60 level Nested Eta than at coarser resolutions.
There is a risk here. Consider the word - resolution. It is related to the ability to resolve. Norm Phillips, the creator of the NGM, always used the rule of thumb that any feature that was not covered by AT LEAST 10 grid-lengths was NOT adequately resolved in a numerical model. Undoubtedly, some features in every initial analysis fall below this level of resolution. Most have NO impact on the subsequent forecast. In addition, we use higher-resolution to justify using observations which at coarser resolutions were considered UN-representative. There is still the risk that noise or observation errors are now indistinguishable from the true signal or level of detail we want to include in our analyses. Quality control of observations is, therefore, a very high priority for us and it is increasingly difficult. Replacing the Optimum Interpolation analysis (boo hoo, that was my code) with the new 3D-variational (3DVAR) scheme this fall will help the analysis and initial conditions.
I can't stress enough nor agree more with your points 2) and 4) relating to storms coming out of the southern stream or through traditionally data sparse areas. Data assimilation techniques can not correct for model forecast errors if there is no data. Our new 3DVAR will allow us to use much more of the satellite data from GOES, which should help especially in those data poor areas.
You may have seen my response (I sent it to SOO_SAC) to Eastern Region recently where we looked at a sequence of model runs which initially called for a snow storm in NYC and then went south, leaving the city high and dry. In that case, ALL our models (Eta, NGM and AVN) did the switch in storm track and scenario AT THE SAME TIME. The UKMET and ECMWF models did likewise. This inconsisitent behavior was traced to initial condition uncertainties in the large scale over the Pacific. Thus, it was not related to anything we had done with or to the Eta model in particular. From a forecasters point of view, I realize it was inconsistent nonetheless.
With NCEP's migration off of the HDS Front-end machines, there have been some inconsistencies in the volume of our observational database in the last 2 months or so. Canadian and Mexican RAOBs have arrived late (after early Eta run) on occasion and ACARS data which is used exstensively in the Eta data assimilation system (EDAS), has been frequently sporadic in its arrival times at NCEP. There was a QC problem with RAOB winds. Now that the HDS is gone, the dust is settling and most of these data problems have been corrected.
Another problem arising from the upheaval of moving many codes to the Cray and creating a lot of new UNIX scripts was discovered (and fixed) just this weekend. There have been 11 cases since our change bundle went in 2/18/97 where the EDAS did not complete in time to provide the early Eta with a first guess. In these instances, we use a global guess and a non-EDAS script. It turns out that a problem existed in that script that allowed the possibility of old AVN lateral boundary conditions to be used (we can't tell exactly how old). Therefore, there were as many as 11 cases with a double whammy: inferior first-guess from the global PLUS old boundaries. I strongly believe we would find a high correlation between these runs and some if not all of your observations of inconsistent model performance. Let me repeat that this problem was corrected 4/19.
We are also committed to reducing the frequency with which we have to use the global as a first guess. This related somewhat to the current Standard Operating Procedure of making sure (at all costs) that the NGM runs so y'all get MOS. I will be suggesting that maybe we could take a little more time to finish the EDAS and early Eta so that that model (which is much more accurate than the NGM) NOT be hobbled by inferior initial conditions. Let me know how y'all fell about that.
WILL THE CHANGES TO THE MODEL AFFECT INTERPRETATION OF THE MODEL GUIDANCE?
Yes, we are making everyone's job harder by changing the physics, we don't mean to do that, but its a fact, no doubt about it. But, I would argue that the "rules of thumb" that have been used to forecast parameters that the models haven't done a good job of forecasting in the past were developed to overcome deficiencies and lack of sophistication in the model physics. I don't think we can avoid changing the way we use models once the models start changing and (hopefully!) doing a better job of forecasting physical processes. It's our job to try to understand the impact of these changes and try to show how to use this new guidance in a different, but hopefully better way, to produce better forecasts. I'm sure that we're not doing a very good job at this, but its a new world for us too, the frequency of changes to operational model has just recently started to increase (in a huge way), so we need to change the way we do business in getting this sort of information out to the users of the models. Any ideas on how to improve how we get information out to the field will be much appreciated!!! I hope I'm not sounding too preachy, but we are moving into a new era, and you and I are sort of like explorers venturing into a new frontier, its going to be rough but I think we'll all be better off, the extra effort it takes now will pay off eventually.
HOW DOES THE STAGGERED GRID WORK?
Staggered grid H V H V H V H V H V H V H V H V H V H V - dlat H V H V H - -dlon- IM=3, JM=5 H=mass point V=vel pointfor this example, GDS octets 18-20 would be 3 (no. of mass points along southernmost row) and GDS octets 21-23 would be 5 (no. of rows in each column). For the 29km grid, there are 181 mass points in the southernmost row and 180 velocity points in that same row for a total of 361 total points. (the next row then has 180 mass and 181 velocity) In the north-south direction for the 29km grid, there are 271 total points in each column (136 mass, 135 velocity in the first column, for example). The east-west resolution of the grid is 0.19444 deg (dlon=7/36) and the north-south resolution is 0.185185 deg (dlat=5/27).
I'm not sure where this idea started that the current 29km Meso Eta is NOT Operational. It most certainly IS. The idea that it is experimental, I think, causes people to take it less seriously. The Eta Model is in two Operational slots and we have distinguished the two runs as early Eta (48km 00&12z) and Meso Eta (29kk 03&15z). In my mind, the Meso Eta has been Operational since August 1995 when we recieved CAFTI approval for it at the end of the field evaluation led by Russ Schneider (now at NCEP's SPC). The lack of a TPB describing that evaluation has not helped. It is still in preparation.
In addition, just because it is not on AFOS doesn't make it non-operational either. Unfortunately, the dissemination plans for the Meso Eta had always been via AWIPS not AFOS. Presently, the OSO server connection is our (operational) bridge to the day when everyone gets the Meso Eta at full resolution via AWIPS. By then we will have a single Eta system running at Meso resolution for the whole North American domain in the early slot but 4 times a day (00, 06,12 & 18z). This will undoubtedly cause even more confusion, so stay tuned!
CAN THE ETA-10 DOMAIN BE ENLARGED? OR RUN ELSEWHERE?
THE ETA-10 DOMAIN WAS REDUCED ON 27 JUNE 97.
The shrinkage of the Nest-in-the-West was our fault here at EMC. I've attached a response I recently composed to Peggy Bruehl on this topic. I am sincerely sorry that you will no longer be covered by the Eta-10 nest.
1) Our initial committment to run the Nest-in-the-West was for 6 months so that Western Region could perform a subjective evaluation of these experimental forecasts. The evaluation was completed in May and our 6 month period ended in June. Making this run in near real time has taken a considerable amount of computer time and resources and can not be sustained if we are to make progress towards our 4/day early Meso Eta runs with a large domain 32km/45level version.
2) There were requests to continue the runs. a) there is a southern CA Ozone study taking place until August for which data are being taken for restrospective comparison (also MM5 runs) and very positive feedback has come from the coastal offices indicating the Eta-10 would be of considerable use, b) Arizona will be taking extra soundings for their convective season and will give lots of attention to Eta-10 and its summertime performance, c) Salt Lake City folks have found lots to complain about so we'd like them to continue to keep the heat on us and d) Tom Potter told Ron McPherson it would be very greatly appreciated if we could continue Eta-10 even if on a limited (area) basis.
3) Therefore, rather than turning it off completely, the nest-in-the-west has shrunk to about half its original size. The reduced domain covers California, Nevada, Utah and Arizona. This is a permanent change until the run is removed in late July or August.
4) I'm afraid we won't be able to accommodate SR, CR or even northern WR with real time Eta-10 runs.
5) There is a lot involved in getting our 4/day early Meso Eta runs with a large domain 32km/45level version tested, verified and implemented. We are also very heavily involved in procurement and benchmark activities for the new Class VIII computer (which will allow us to run 4/day early Meso Eta runs with a large domain at 10km/60level version of the model!) If it weren't for all this activity, I would offer to make episodic Eta-10 runs for CR & SR (ER too), but I'm stretched too thin already.
6) I intend to run the Eta-10 in support of Lake Effect snow and other experiments this winter. The domain is TBD but will cover parts of CR & ER.
Geoff DiMego
DOES THE CLOUD SCHEME INTERACT WITH THE CONVECTIVE SCHEME?
The convective scheme works as advertised, it produces convective precip and "pretend clouds" that go into the radiation scheme only, there is no cloud water that is produced by the convective scheme. The problem is that we don't know how to correctly tie in the convective cloud to the cloud water, which would then tie into the "grid-scale" precipitation scheme. I'm not explaining it very well, but the convective scheme sort of takes the formation of clouds into account in its final result, so the only output we should be using from the Betts scheme is the temp and moisture changes along with precip at the ground. A separate parameterization is used to come up with some cloudiness in the radiation scheme that is based upon the convective rainfall. The cloud water scheme is not involved directly in the process of producing convective rain at the moment, we should use a different convective scheme if we want it to produce convective cloud water, the Betts isn't intended for that. This is something that's in the longer-range plans.
One thing to keep in mind, the cloud water scheme is actually two schemes, one that produces cloud water/ice from water vapor and "large-scale" condensation, then the other produces precip from the cloud water. The second one can be called the "grid-scale" precip scheme, or just the precip scheme if the cloud water is produced from "large scale" and "sub-grid scale" condensations. Right now, it only gets cloud water from the "grid-scale" condensation.
HOW IS THE MOISTURE INITIALIZED?
The moisture ini, along with the initialization scheme in total, is discussed in Rogers et al Dec 1995 W&F paper. The moisture ini is just a univariate OI analysis of specific humidity obs. Everything else gets "initialized" through the spin-up runs during the EDAS. So, its nothing fancy and has lots of room for improvement. Actually, the analysis scheme is basically the same as the NGM's, except its done on the eta coordinate, so DiMego's 1988 MWR paper on the regional OI is a good place to look.
HOW IS THE SOIL MOISTURE INITIALIZED?
1) global data assimilation system (GDAS) uses a land-surface package with 2 soil layers for which they carry soil Temperature and soil moisture. The package carries these as history variables, so they evolve with the free forecast. We don't use any observed values for soil so when it comes time to update the GDAS forecast every 6 hours, the previous forecast values are passed on as the new "analysis" or initial conditions. The only control on this process is that exerted by the use of atmospheric data. The global folks have found that there isn't any severe drift in this field (I think they have a very weak nudging term towards climatological values). The same is essentially true, I think, for skin temperature as well, which goes into and comes out of the surface energy balance calculations. Precipitation (and evaporation) produced in the model has a great effect on the topmost soil layer's soil moisture. The field is very much dependent on the recent precipitation patterns in the model.
2) a nearly identical land-surface scheme is used in the Eta Model and, thus in the Eta data assimilation system (EDAS). Every 12 hours, the EDAS system is "cold started" at T-12 from the GDAS values interpolated to the Eta grid and levels including the 2 soil layers. Values can evolve during the forecast but are not updated by any data at the 3-hourly EDAS update times. Like the GDAS, the topmost soil layer is very dependent on the model precip. Fortunately, the Eta precip is generally much better than the global's.
3) sometime this year we are going to start cycling the EDAS on itself. This will eliminate the "cold-start" and connection to the GDAS soil. At this time we will be able to add 2 layers to our soil (since we won't have to match the GDAS). Since Eta's precip is better than the global's, this should be a good thing. No severe drifts were observed in the soil fields when this cycled EDAS was tested for a 3 month unbroken cycle.
4) also planned for this year is the addition of an adjustment scheme to the cycled EDAS which will use analysed hourly precipitation (from Baldwin) to 'force' the Eta Model forecast precip to match that which is observed. This will enforce an observed aspect on what otherwise is an uncontrolled soil evolution.
I think there are basically two reasons for the difference in the forecast relative humidities between the Eta Model and other models (e.g. NGM and AVN):
i) The new cloud scheme currently in the Eta model uses a low critical value of grid-averaged relative humidity for the large-scale condensation (75% over land and 80% over ocean). This means that large-scale condensation can occur as long as RH reaches 75% (or 80% over ocean). However, the large- scale condensation, when it occurs, is calculated based on the convergence of moisture and the local changes of temperature, relative humidity and pressure rather than the RH values. This is a important feature of the cloud scheme which has been proofed to improve the cloud, precipitation and moisture forecasts significantly. The critical values of grid-averaged RH used in the NGM and AVN models for large-scale condensation, however, are higher than that in the Eta model (95% in the NGM and 100% in the AVN).
ii) The second reason is the inclusion of cloud ice particles in the cloud scheme. The RH used in the large-scale condensation is calculated with respect to ice in regions where cloud ice exists. However, the model output of RH is calculated over water on all model grids. This makes a big difference between the RH in model outputs and the RH used by the model in its condensation calculations in regions where cloud ice exists, especially at the upper atmosphere and during winter time. If we look at the RH used in model's condensation, the values seems more realistic than those in the model outputs.
Quin Yun Zhao
The scheme tries to imitate nature, with cloud water starting to form at RH's greater than 75%, but the condensation rate is a function of the amount of "extra RH" (above 75%), it doesn't take out all of the "extra RH" above a given threshold like the other models or like the Eta used to do. So, in a similar way to what you do to diagnose cloudiness from RH, the model does the same thing, it produces a little bit of cloud at RH around 75%, and the cloud amounts increase as you get closer to 100%. The cloud then can produce rain if enough cloud water forms, just like in reality.
Anyway, I would say that we intend to improve our forecast of RH compared to the real RH, and that's a separate issue from forecasting cloud amount. The model has a cloud fraction field that is output, and I would suggest starting to use that, (and validate it and give us feedback!!) rather than using the RH to diagnose what you think the model cloud fraction would be. I think we've shown that the RH forecast has improved with the new cloud physics scheme, so I think that these lower values are actually closer to what is observed. I'm sure they're not perfect, but closer to reality than the old Eta or the other models.
WHY ARE THE INITIAL FIELDS SO BAD?
A while back several of you pointed out some problems with the initial fields for the Eta. At the time, there were some who associated the problems with the change to the early Eta model code in January, making it identical to the Meso. This association was simply coincidental. We (Eric Rogers mostly) have now identified the problem as being in the analysis.
The problem occurs in the interpolation of the first-guess to the observation location in preparation for forming the observed increment (OB - FG) which is the quantity analyzed, i.e. the quantity added back to the first-guess as a correction: ANL = FG + analyzed increment. In the vicinity of certain Eta steps, a vertical inconsistency was being introduced between height increments computed below (in the shadow of) and above (in the free atmosphere) neighboring elevated terrain steps. In the latter case, all four bi-linear interpolation weights are non-zero, whereas, in the former case, some of the weights are zero because they are below the model terrain. Since the Optimum Interpolation (OI) analysis uses height increments in vertical pairs (their difference being proportional to the temperature increment), when the pair being used is an increment of the latter type together with one of the former type, the inconsistency between them appears as a temperature error. If both height increments are of a single type, there is no inconsistency and the temperature analysis is well behaved. This is the case in VAST majority of analysis layers. The problem is present in a very narrow layer in the vertical (at ONLY the 850 mb level near the Black Hills and Rapid City, SD). In addition, the degree of error is strongly dependent on synoptic regime, being most apparent when there is a strong gradient present at the observation. This explains why the signal doesn't appear all the time in EVERY analysis. Fortunately, because of its local and extremely shallow nature, the forecast model normally damps out the erroneous feature fairly rapidly.
A solution to this problem has been coded and is scheduled to be implemented in the Eta analyses in the very near future. A NEW analysis system is being prepared to replace the OI. It is based on a three-demensional variational approach (3D-VAR) like that used in the NCEP's global system and will not suffer from this problem because 1: it uses temperature directly and 2: all the observed data are used at once. Therefore, it won't need to use heights at all and it won't need to do any local selection of limited sets of data (or pairs).
Thanks to everyone who pointed out the various problems, and PLEASE, let us know whenever you see problems.
Geoff DiMego
Early and Meso Eta initialization:
1) the Early has the EDAS (Eta Data Assimilation System-since October 1995) providing the first-guess for its analysis at 00z and 12z. The EDAS is a 12-hour per-forecast data assimilation period during which an Eta forecast is updated with analyzed (by an OI on Eta surfaces) corrections every 3-hours. A global first-guess is used at the beginning of the pre-forecast, the OI is squeaky clean (i.e. done on Eta coordinate surfaces and at full model resolution -- no unnecessary interpolations). The 3-hour updates make use of all data from RAOB/pibal balloon observations, surface observations, Profiler, ACARS (aircraft) and polar-orbiting satellite (thicknesses). The last 3-hour forecast from the EDAS is the 1st guess for 00z or 12z analysis. A first-guess that has been generated by the Eta forecast model (via the EDAS) is preferable to one based on a static analysis of a global spectral model-based first-guess because of the matching physics, the better resolution and a less "spin-up".
2) the meso (since August 1995) has only a 3-hour preforecast data assimilation period (we call this a mini-EDAS), but uses an analysis at 29 km resolution along with the 29 km forecast to spin things up for 3 hours and has the benefit of a later cut-off time for on-time 00z or 12z data as well as the benefit of the 3z or 15z data.
3) As to which is "BETTER"...a difficult question to answer, because statistics like 'fits-to-data' (at 00z and 12z the early and meso are comparable, but meso has a little more data) can be misleading and are not really good indicators of "quality" for analyses at these resolutions and with our current observational base. There are aspects of the early's analyses that I prefer over the meso and vice versa. When we get more mesoscale observational data into the system (like radial velocities from the WSR-88D network), then the 29 km meso will be capable of responding to it, whereas the 48 km will have less capability. Right now, there isn't really any true mesoscale data getting into either analysis. The bottom-line is forecast skill, and the meso Eta (despite having a much shorter period of data assimilation) is our best model (it has the best resolution, the latest data and the best lateral boundary conditions).
Our plans call for extending the length of the Meso Eta's mini-EDAS period to 6-hours and replacing the global first guess with one based on the 48 km early Eta (this is possible now since the physics are identical between early and meso and the EDAS is now implemented in the early). We also intend to replace the use of Optimum Interpolation (OI) with a variational analysis.
4) none of the Eta analyses use any initialization procedures (like the vertical normal modes used in NGM). This is generally a good thing, since initialization can damp features which are deemed to be 'ugly', but which are real and important. There are some indications, however, of gravity wave 'noise' in the first few hours of the forecast from the meso but this dies down rapidly. Nevertheless, this has prompted us to look again at the use of a Lynch filter to suppress these oscillations, but our hope is that the 3D-VAR will produce much less of these oscillations and make the use of the filter unnecessary.
5) satellite data is used from the TOVS (polar orbiter) in thickness form by the OI in both Eta's. When 3D-VAR replaces OI we will go to direct use of radiances from TOVS as well as GOES. The military satellites (DMSP) provide SSMI precipitable water and it is used in both of the Eta analyses (global uses it too). This data has good horizontal resolution, but has NO information about vertical distribution of moisture) and can be used only to do an adjustment of the guess' vertical distribution. We are about to implement (subject to successful pre-implementation test) the use in our OI of precipitable water (4-layers) from GOES 8 & 9. Each of the 4 layers is treated like the SSMI and results in an adjustment to the guess profile in the particular layer. GOES sounding data are provided over land and ocean, BUT NOT where it is cloudy. We also continue to use 'moisture bogus' generated subjectively by NESDIS from cloud signatures. This data are low resolution (~200 km / 6 mandatory levels of RH estimates), oceanic only and restricted to areas where distinct signatures are present. Thus, all current and near-term satellite moisture sources suffer from some shortcoming(s). We are still hoping our direct use of the radiance channels will allow us to take better advantage of the data once the 3D-VAR is implemented.
6) GOES satellite data will soon be used to help initialize the cloud fields in the Eta, which currently are not updated at the analysis times. This is expected to have a positive impact on the moisture field , precipitation and surface temperature.
Geoff DiMego 301-763-8056 Mesoscale Modeling Branch Environmental Modeling Center/NCEP
IS THERE A 20KM AND A 40KM MESO ETA RUN?
THERE IS NO 20km Eta RUN NOR IS THERE A 40km Eta RUN!
There is some major confusion here about model runs and output grids which I hope is not rampant among all the regions. The following facts, I hope, will begin to clear up some of it. I know the way these data are identified on the OSO SERVER is confusing, so we have to be very careful.
I'm definitely biased, but I don't agree that the value of the Meso Eta forecasts diminishes so rapidly with forecast range as to be useless beyond 18 hours. For example, we do not see a rapid drop off in even our QPF scores. Similarly, Western Region has been quite pleased with the Meso-Eta and have not experienced significant drops in value out to 33 hours. Every performance measure we have indicates that the Meso Eta is our best model, and dropping its output would seem to be shortsighted. The #212 (the 40km OUTPUT grid) fields are adequate in representing the 29km Meso Eta forecast fields on isobaric levels, but the surface and precip fields are desirable on #215, the 20 km OUTPUT grid, where the full computational resolution can be reproduced.
THE FACTS ARE AS FOLLOWS:
1) NCEP runs at 00z and 12z a 48 km / 38 level early Eta from which AWIPS grid #211 80 km output fields are generated for OSO and FOS.
2) NCEP runs at 03z and 15z a 29 km / 50 level Meso Eta from which BOTH of the following are generated as dictated by AWIPS Appendix K: a)full complement of fields on the AWIPS 40 km grid #212 PLUS b)a small set of fields on the AWIPS 20 km grid #215 - not a different model run, just additional output on a higher-resolution grid.
3) on the OSO server, the early Eta output data described by 1) come under directories beginning with us008_gf089_97mmddhh_YxQAx and us008_gf089_97mmddhh_ZxQBx where the 089 indicates the early Eta (48km) is the generating model and the Q indicates output on grid #211.
4) on the OSO server, the Meso Eta output data described by 2a) come under directories beginning with us008_gf085_97mmddhh_YxRAx and us008_gf085_97mmddhh_ZxRBx where the 085 indicates the Meso Eta (29km) is the generating model and the R indicates output on grid #212.
5) on the OSO server, the Meso Eta output data described by 2b) come under directories beginning with us008_gf085_97mmddhh_YxUAx and us008_gf085_97mmddhh_ZxUBx where the 085 indicates the same Meso Eta (29km) is the generating model and the U indicates output on grid #215, just a higher resolution output grid for fields like pressure, precipitation, 2 m temperature, 2 m RH, 10 m wind and boundary layer fields.
WHY IS THERE A JUMP IN THE 2M DEWPOINT AT 00Z?
A forecaster has noted that in the springtime in the southern Plains, looking at the hourly forecasts from the Meso Eta, the 2m dewpoint "spikes" up at 00Z.
The 2m T and q is derived by assuming a constant flux in the layer from the ground up to the middle of the 1st model level. The 1st model level also shows a jump, but it's not as obvious (+1 deg Td instead of +2 deg) and it doesn't come right back down the next hour.
The surface exchange is driven by the incoming radiation, which is still turned on at 00z. Probably because of the time of year, with the soil relatively moist, more of the energy is going to evaporation than sensible heating. It turns out that at 00z, the sensible heating has turned off and has actually switched to cooling, so the surface temps are starting to cool and the vertical mixing from the surface has shut off. But, there is still fairly strong evaporation, so the moisture is increasing just above the ground. Then, about an hour later, the sun has gone down and there is no more energy driving the evaporation, so it shuts off too, which probably explains why the dew point comes back right after 00z.
Here is some information about the so-called supplemental fields from the early Eta and Meso Eta. They have been requested by the ICWF folks and can be used as an alternative starting point (the previous ICWF forecast or a gridded NGM MOS are the other 2 options) for ICWF. The gridded fields can be ingested directly into the ICWF from their Lambert conic-conformal grid. I prefer to call them sensible weather guidance fields from the Eta Model.
These were first generated from the 10km Nested Eta runs performed for last summer's Olympic games and used as an alternative starting point in the ICWF processing for venue specific forecasts. For the Olympics, the fields were on a 10 km grid #218 (Lambert conic conformal). For temperature, the dependence of surface temperatures on elevation came out very nicely. These fields have been generated from the early Eta (on 40 km grid #212) and from the Meso Eta (on 20 km grid #215) for about a year now. These fields have been available on NCEP's NIC server and more recently on the OSO server. DRG RC#2111 put them into the main AWIPS distribution stream.
Here are the fields, which are available every 3 hours throughout the forecast period, and a few comments on how they are generated:
In evaluations of the Olympic Eta-10km temperature, specific humidity and wind speed forecasts against surface reports, the Eta-10 was found to be superior to the Eta-29 Meso Eta forecasts. These comparisons were WITHOUT compensation for the difference between the Eta terrain and that of the stations. The error level would be expected to be higher than that of MOS at the MOS stations, but on the otherhand, MOS would be unable to modulate temperatures from valleys to mountain tops. Undoubtedly, this is the largest cause of perceived systematic error in Eta forecasts versus MOS forecasts (which we don't access). It is our intent to perform this required compensation in the Eta Model post-processor in the very near future, resulting in model forecast fields of the sensible weather elements listed above that will be directly comparable to the observations at surface reporting stations.
INFO ON 29 JULY 1997 IMPLEMENTATION
CHANGES TO THE OPERATIONAL "EARLY" AND MESO ETA MODELS At 1200 UTC 29 July 1997 a series of changes to the post-processed output from the operational Early (48km/38levs) and Meso (29km/50lev) Eta were implemented at NCEP. A brief description of each change follows: 1) FOUS60-FOUS78 OUTPUT - The T3 and T5 values in the Eta FOUS60-78 messages were corrected to to reflect temperatures at approximately the same pressure level above the model terrain as those from the NGM FOUS. For example, T5 for the NGM FOUS is the temperature at sigma=.7848, which is about 215 mb above the model surface. In the previous version of the eta model, T5 was the temperature at 120-150 mb above the model terrain. The T3 temperature in the NGM FOUS is at sigma=.8967, about 100 mb above the model surface. In the Eta FOUS T3 was the temperature at 60-90 mb above the model surface. 2) GRIDDED OUTPUT - The codes which compute tropopause height have been modified to conform to the WMO definition of the tropopause height. - An error in the computation of cloud water on pressure surfaces in the Early Eta was corrected. 3) HOURLY STATION PROFILE OUTPUT - The station list used for hourly station output from the Eta model has been modified to reflect recent changes in rawinsonde station location and to correct some errors. A summary of these changes follows: - 74389 (Gray, ME) added, 72606 (Portland, ME) dropped - 72634 (Gaylord, ME) added - 72426 (Wilmington, OH) added, 72421 (Cincinnati, OH) dropped - 72582 (Elko, NV) added, 72583 (Winnemucca, NV) dropped - 74455 (Davenport, IA) added - 72364 (Santa Teresa, NM) added, 72270 (El Paso, TX) dropped - 72376 (Flagstaff, AZ) added, 72374 (Winslow, AZ) dropped - 72672 (Riverton, WY) added, 72576 (Lander, WY) dropped The following stations were not being placed at the correct location: - 71600 (Sable Island, NS) - 71201 (Key West, FL) - 70308 (St. Paul Island, AK) - 91165 (Lihue, Kauai, HI) (48 km Eta only)Back to Table of Contents
HOW DO I GET THE BUFR OUTPUT FILES?
We have hourly output files available via anonymous ftp on a near real-time basis. These files are in BUFR format and contain forecasts of sounding and surface variables. To get them, ftp to nic.fb4.noaa.gov (140.90.50.22), log on as anonymous, and cd to /pub/mso/meso.cur/BUFR . Inside this directory should be a list of about 500 files, each one containing the entire meso eta forecast for a given station location. The files are named bufrhr.STATID.YYMMDDHH where STATID is the 5 digit station id and YYMMDDHH is the date and hour of the beginning of the forecast. A station list can be found in /pub/mso/meso.cur/stat_list which links the station ids to their locations (some ids are non-standard). I do not know very much about decoding BUFR files, I will have to refer you to /pub/nws/nmc/codes/bufr and /pub/nws/nmc/docs/bufrguide for sample codes and documentation on decoding BUFR files. If you have access to a SOO-SAC workstation that runs GEMPAK, we could provide software to convert these files to GEMPAK.
Two types of CAPE/CIN are currently computed by the Eta model post-processor (both Early Eta and Meso Eta). The actual computation is the same in both cases but what differs is parcel that is lifted. The first computation is listed in a GEMPAK (N-AWIPS) "gdinfo" listing as:
PARM VCORD LEVL1 LEVL2 CAPE NONE 0 CINS NONE 0In these fields the model sounding is searched in a 70mb layer above the ground to find the parcel with the highest THETA-E. In GRIB this is labeled as surface CAPE/CINS (level type=1).
The second computation is listed in a GEMPAK (N-AWIPS) "gdinfo" listing as:
PARM VCORD LEVL1 LEVL2 CAPE PDLY 180 0 CINS PDLY 180 0In these fields the 30mb thick "Boundary Layer" with the highest THETA-E is used to define the parcel. In GRIB this is labeled as pressure depth layer CAPE/CINS (level type=116).
Recall that after integration of a 33 hour forecast, the Eta model post-processor creates 6 "boundary layers" each 30mb thick that are terrain following (sort of like sigma surfaces) and stacked on one another. In GEMPAK they are labeled as PDLY layers (Pressure Depth LaYer). The first 30mb thick layer (PDLY 30:0) is from p[sfc] to p[sfc]-30mb. These gridded fields are averages for a 30mb layer that can contain as many as 5 Eta levels. The second 30mb layer (PDLY 60:30), third (PDLY 90:60) ... etc. are all averages for terrain following layers stacked upon one another. If the surface pressure were everywhere 1000mb the layers would be 1000-970mb, 970-940mb, 940-910mb, 910-880mb, 880-850mb, and 850-820mb. In reality the layers are terrain following with the bottom layer (30:0) starting at the surface pressure. It is one of these layers (the one with the highest layer-average THETA-E) that serves as the parcel for this "best" CAPE/CIN calculation.
In both cases the vertical integration of the positive or negative buoyancy for the selected parcel is continued through the highest buoyant layer. This assures that the computation will not miss a second layer of (perhaps major) instability that is "capped" by a second (perhaps minor) stable layer. It assures us that the CAPE calculation will consider all unstable layers. It also means that in areas of zero CAPE the CIN will be zero as well. To avoid misinterpretation, areas of zero CAPE should probably be clearly indicated since they are likely regions of strong stability but CIN is undefined.
Some of these descriptions conflict with Russ Treadon's post-processor TPB but do reflect the current methodology employed in the Early Eta and Meso Eta models.
According to Ralph, PCGRIDDS will make up a label name that is the average of the 2 levels given if more than one level is packed into the GRIB header, so the "best" CAPE will have a level indicator that is around 910, while the "surface" CAPE will have a level indicator of b015. That's my guess at least.
0-3km storm-relative helicity grids will soon (the next few weeks) be available from the Meso Eta model post-processor (At present helicity will not be available for the Early Eta). The computation mirrors the technique described in Davies-Jones et al. (1990). The mean-layer wind in the cloud bearing layer is estimated with the 850-300mb layer-average wind. For wind speed less than 15 m/s the storm motion vector is estimated as 75% of the magnitude and 30 degrees to the right of the 850-300mb mean-layer wind. For wind speeds greater than 15 m/s the storm motion vector is estimated as 80% of the magnitude and 20 degrees to the right of the 850-300mb mean-layer wind. The storm-relative helicity is then integrated for the 0-3km AGL layer of the model atmosphere using wind data for each Eta model layer. The results are output into three grid files available in the AWIP3D GRIB file (grid #212). They are ....
VALUE PARAMETER UNITS 190 Storm-relative Helicity m**2/s**2 191 U-component Storm Motion m/s 192 V-component Storm Motion m/sThese parameters have to be added to the nmcgrib2 gempak GRIB1 conversion table used in "nagrib" if you transform the data from GRIB to N-AWIPS (GEMPAK) format locally. At the National Centers the data will appear in a "gdinfo" listing of the Meso Eta model output as:
PARM VCORD LEVL1 LEVL2 HLCY HGHT 3000 0 USTM PRES 300 850 VSTM PRES 300 850Reference:
Davies-Jones, R., D.W. Burgess and M. Foster, 1990: Test of helicity as a tornado forecast parameter. Preprints, 16th Conference on Severe Local Storms (Kananaskis Park, Alberta), Amer. Meteor. Soc., 588-592.
What about the high values of helicity?
The units of helicity are m^2/s^2. The computation is based upon a preprint by Davies-Jones et al (1990), who tested helicity calculations against observed storm intensity. The storm motion that is used is a mass-weighted mean of the 850-300mb winds, reduced in speed by 25% (20% if mean wind speed is > 15m/s) and rotated to the right by 30 deg (20 deg if mean speed is > 15m/s). The helicity is computed using this storm motion. Their paper talks about values in the 150-900 range corresponding with tornadic thunderstorms. Helicity is basically a measure of the low-level shear, so in high shear situations, such as behind strong cold fronts or ahead of warm fronts, the values will be very large maybe as high as 1500. High negative values are also possible in reverse shear situations.
There are two types of LI's which can have different labels from Eta Model forecasts, the "best (4 layer) LI" and the "surface LI". Each of these should have a different name/label in PCGRIDDS, GEMPAK, and when it is originally packed into GRIB. I am guessing that the confusion is in the "surface LI" of which there can be two different ways of coming up with a "surface" parcel to lift to 500mb. One way is to use the actual lowest model layer variables, and this is packed as the "1000-500mb LI" where the layer label is given as 1000:500 in GEMPAK, and probably 750 in PCGRIDDS (average of 1000 and 500). The other way is to use the lowest "eta boundary layer" which Russ discussed above. This is a mass-weighted mean of the model variables in the lowest 30mb above the ground, which is then lifted. The layer label on this version is a "pressure depth" layer from 30 to 0, or probably b015 in PCGRIDDS. The "best LI" is computed by taking the each of 6 "eta boundary layers", finding the LI, and taking the lowest of the 6. So it represents the lowest LI in the lowest 180 mb above the ground, while each parcel is a 30mb average of the actual model variables. (it's layer label is a PD layer from 180 to 0, or b090 in PCGRIDDS?)
There has been some recent confusion concerning the lifted index products available on AFOS graphics. The LI fields available for the NGM and Eta models are calculated differently and should, therefore, be compared with the difference in mind.
The LI for the NGM model on AFOS graphics is a "best" lifted index. The least stable of the lowest 4 model sigma layers is lifted to produce the value. This type of calculation is useful in cases in which elevated layers above the surface are less stable than the surface.
The AFOS graphics LI for the Eta model, on the other hand, is a calculation based on the lowest Eta layer, a carry-over from the LFM which gave a surface-based LI. This field, therefore, will not reflect elevated instability. Cases in which a layer just above the surface is very unstable while the surface air remains stable will show a stable LI.
Three different LIs are currently computed by the post-processor of the Eta model. They differ in the depth of the layer that is being lifted. The computations are listed in a GEMPAK (N-AWIPS) "gdinfo" listing as:
PARM LEVL1 LEVL2 VCORD LIFT 30 0 PDLY LFT4 180 0 PDLY LIFT 500 1000 PRESThe first LI calculation lifts the lowest, post-processed, 30 mb thick, and terrain-following "boundary layer". The second lifts each of the lowest six 30 mb deep "boundary layers" and takes the "best" LI. The third value is the LI based on lifting the lowest Eta layer.
The post-processor of the NGM computes 2 LIs:
PARM LEVL1 LEVL2 VCORD LFT4 8400 9800 SGMA LIFT 500 0 PRESHere, the first computation lifts the lowest 4 NGM sigma levels and takes the "best" value, while the second one lifts only the lowest sigma layer.
A good example of the difference between the two fields on AFOS graphics was found in the 36 and 48-hour forecasts made at 12Z 1/25/96. The NGM LI fields in the East showed instability much farther to the north than the Eta LI field. The "best" LI from the Eta (not available on AFOS graphics) shows a similar instability pattern as the NGM. Those who wish to view the Eta model "best" LI or the NGM surface-based LI fields will need to use an alternate method (such as PCGRIDDS) of viewing model output.
Specifically, users of PCGRIDDS using the front end file can obtain the "best" LI from the post-processed grids. It is listed as:
PARAM LEVEL LIFT 0000To compute an LI analogous to the boundary layer value, the following function in '93 PCGRIDDS must be used:
LNDX LVL1 LVL2
For the Eta model, the proper values for the last two terms are B015 and 500, while they are S982 and 500 when using the NGM.
Users of PCGRIDDS using the OSO file will find two different lifted index products:
PARAM LEVEL LIFT 0000 LIFX 0000The LIFT is the "best" lifted index, while the LIFX is based on the lowest sigma layer for the NGM and the lowest Eta level for the Eta. The same function used to compute a low-level LI already discussed for the front end file also works for the OSO files.
Finally, whereas the AFOS graphics depict differently calculated LI fields, the values included in FOUS messages from the NGM and Eta model runs both reflect the "best" lifted index from the respective models.
10 meter wind is computed using the Eta Model's first atmospheric layer wind (which is defined at the mid-point of the first layer) and the momentum flux between the ground (skin) and that mid-point. The assumption that the flux is constant across this interval allows us to solve for a wind anywhere in the interval and we solve for a wind at anemometer level or 10 meters (above MODEL terrain).
WHY IS THE SURFACE PRESSURE GIVEN IN THE BUFR OUTPUT DIFFERENT FROM WHAT IS OBSERVED?
1) It is the pressure at the Eta Model's surface (e.g. skin T level, whereas the other SFC stuff is at 2m and sfc winds are at 10m ABOVE Eta Model GROUND LEVEL. That elevation is undoubtedly higher than the elevation of the ASOS station (by about 85-95 m I'd guess based on the 13mb difference). You must take this into account when comparing model surface stuff against observations.
This difference is also reflected in and needs to be accounted for when using the FOUS stuff that's generated from the Eta and NGM, except that the situation is worse there because of all the extra interpolations that are done to generate FOUS (YUK). The BUFR soundings are definitely the way to go because there is NO interpolation involved, the Eta profile from the nearest Eta step is output directly.
We have had a few spectacular successes of making a slight change in specified location for the BUFR site and getting a more representative Eta step profile. This happens normally when there is a strong gradient nearby (e.g. Salt Lake City and Buffalo) so that a small change in distance puts you onto a lower step.
2) For BUFR or FOUS, the interpretation is the same, i.e. PSFC is the model's surface pressure at the model's terrain level (SELV?). Each model Meso Eta, early Eta, NGM, RUC etc., each have their own terrain and they can be vastly different. There is a FOUS TPB that has a Table of the NGM elevations, but the Table for the early Eta is out of date since we went to the 48km grid and will be even more out of date when we (this year) go to 32km (45 levels) in all 4 Eta runs.
1) NGM and Eta get initial snow from daily Air Force analysis (512x512 1/8 Bedient ~47km). The NGM uses a yes/no (binary) snow field which is held fixed throughout the forecast. The Eta uses the actual snow depth and allows this field to evolve (melt or accumulate) during the forecast.
2) The Global Data Assimilation System (GDAS or sometimes called FNL) updates its snow depth field once a week from a NESDIS product on a 2 deg x 2 deg grid. The snow field evolves within the GDAS between the weekly updates. The AVN and MRF use the GDAS snow depth as initial condition and allow it to evolve during the forecast period.
3) NESDIS is testing a high-resolution (~24km) daily capability which should be ready for next winter and which we will go to as soon as they go operational: see http://hpsab8en.wwb.noaa.gov/SSD/DATA/snow
4) Viewing the initial snow field from the NGM is problematic, BUT not all of the blame is ours. The NGM code says that the snow depth output field is set to 0 for no snow and set to 100 (no units specified) for snow. Somewhere in the bowels of that godawful code, the value that is output which was 100 becomes 100,000! It's as if it felt the need to convert meters to millimeters, but there should be no need since both GRIB and the old NMC Office Note 84 have units of meters for the snow depth. Anyway, we continue to search the NGM code for the place where that multiplication is performed and intend to remove it.
To make matters worse, fields of snow depth are generated by an NCO code via bi-quadratic interpolation from the NGM native grid #104 (NGM super C grid) to AWIPS grids #202, #207 and #211. The use of bi-quadratic interpolation of binary values of 0 and 100,000 results in some pretty large NEGATIVE values (like -19256) and smears the precise location of the no snow/snow line. Folks have pretty much given up trying to figure out what is in there after seeing unpacked values ranging from -19256 to over 100,000!
5) Currently, the Eta puts out snow water equivalent (using 10 inches of snow for 1 inch of water equivalent). We are looking into what it would put out if we ask for snow depth.
Link to the OSO and NIC Info Page
FILENAME Source Content ---------------- ------ ------------ yymmddhh us008_gf083_96041612_Yxmnx NCEP 083 ETA FCST model # - 80 km resolution 085 Meso-ETA FCST model # 30 km resolution 089 ETA forecast model # - 48 km resolution Y domestic GRIB designator Z domestic GRIB designator m=N 207/Regional Alaska data m=Q 211/Regional CONUS m=R 212/Regional CONUS m=U 215/Regional CONUS Y domestic GRIB designator n=A 00 forecast hour (for 'Y' Grib only) n=B 06 n=C 12 n=D 18 n=E 24 n=F 30 n=G 36 n=H 42 n=I 48 forecast hour Z domestic GRIB designator n=B 03 forecast hour (for 'Z' Grib only) n=E 09 n=H 15 n=K 21 n=L 27 n=O 33 forecast hourContact: Dan Starosta 301 713 0877
In addition to this, the GRIB documentation discusses the WMO Header which is used to make up the filenames on the server. This incomplete discussion is in Appendix A of ON 388 and could help to determine what the other model files are.
HOW ARE MODEL VERTICAL VELOCITIES COMPUTED?
All of NCEP's models use their 'vertical momentum' equation for ultimately getting vertical velocity. There is no kinematic approach used so there is no need to apply an O'Brien correction. The third equation of motion involves the material derivative of the vertical coordinate, i.e. d(sigma or eta)/dt - what is written quite often as sigma-dot or eta-dot. Through the hydrostatic assumption, this material derivative equation is reduced to the model's continuity equation involving integrated mass-flux divergence and the surface pressure tendency. The values of sigma-dot or eta-dot get converted to a conventional vertical velocity in the models' post-processor.
WHAT HAPPENED TO THE MODELS ON THE WINTER STORM CASE?
We have looked at this case in some detail (as available resources permit).
1) All models agreed at the 48 hour range that the short waves in the northern and southern streams would phase in and a sizable storm would result for NYC and elsewhere. As I understand it, the extended range progs (MRF and ECMWF) had been doing repeated flip-flops in the days leading up to this point, but at this time the AVN, NGM and Eta all had pretty much the same scenario predicted, with the Eta characteristically more detailed and with more intense snow over NYC.
2) At the 36 hour range, the predicted scenario by ALL the models changed and the northern short wave didn't phase in. The southern wave produced a very modest storm with different track resulting in no precip at all over NYC. This new scenario was predicted at shorter ranges by ALL models and verified.
3) We have looked at some of the ensemble output with a new tool that is capable of tracing back areas of uncertainty to their origins. It is clear that the erroneous forecasts made by ALL models at the 48 hour range was due to initial condition errors in the northern stream that did not get corrected until the next cycle 12 hours later.
4) ALL models shared this shortcoming in initial conditions. The problem area was in a data void, so there was no opportunity for alternative analysis schemes to respond differently because there was no data to repond to.
5) ALL prediction models responded in the same way to the erroneous initial conditions, which is not uncommon nor is it unexpected. While we appreciate the faith you put in the Eta Model predictions relative to the other models, it can't correct for errors of this type where a fundamental error exists in the large scale initial conditions.
6) We have seen other cases of this type where the Eta is disappointingly similar to the other models and WRONG. We saw a glaring case of a fictitious low development in Montana the first week we ran the Eta in the operational early slot back in June 1993. After quite extensive examination AND testing, we concluded it was a case of large scale initial condition errors over the eastern North Pacific and Gulf of Alaska. I am quite certain this recent case is of the same type.
7) All of the cases I am aware of (like this recent one) share the behavior that once the erroneous feature(s) are corrected (by moving over a data rich area), the forecast shifts ONCE from the bad scenario to the correct one. Thus, there is on occasion a FLIP to the correct solution, but very seldom (in my experience) any subsequent FLOP to another solution or back to the original one.
8) I wish I could give you a handle on when these will occur. I really can't. Initial condition uncertainty in areas with little or no data are almost impossible to identify. The folks who are doing ensemble work here (Steve Tracton and Zoltan Toth) are confident, however, that with time the experienced forecaster will be able to use the information in the ensembles to determine forecast uncertainty and based on that, to know in which cases to hold off until the next cycle before issuing storm watches and in which cases the watches can be issued in advance with confidence.
I know this isn't entirely satisfactory, but we're working very hard to improve all aspects of the Eta Model and its initial conditions such that it can be relied upon to give good guidance day-in and day-out.
HOW CAN WE IMPROVE OBSERVATIONS AND ANALYSES OF MOISTURE TO IMPROVE QPF?
1) We have lots of room for improvement of the models and their accuracy in simulation atmospheric behavior. These things will keep us (I hope) employed indefinitely. We have lots of room for improvement of model resolution. This will come with more powerful computers. There is lots of room for improvement of initial conditions (which is where I sense you are coming from) BOTH in technique and in observational basis. Improvements (better forecasts) will be limited if we can't get better obs, but the other things will each generate increments of improvement in forecast accuracy. Depending on where in the forecast you look, however, that increment will be different. If we can't get better obs, then analysis and assimilation and model improvements will be limited by the initial error (though that error may grow more slowly). You may not think very much of our Eta Model QPF's but we have come a LONG way since June of 1993. We've come this far because of progress in ALL of the above areas. So, while I agree that low-level moisture is critical, I think progress is possible even without it. With Four Dimensional Data Assimilation, EVERYTHING contributes to improved QPF, not just the low level moisture. I'm not advocating any action on this and was adamant about NOT reducing RAOBs (not that anyone listens to me).
2) I'm hopeful on several fronts. I don't think the network of RAOBs will be decimated TOO BADLY. We need more than just those 12-hour obs anyway, but they are a great anchor for low level moisture. A water-vapor sensor is now being tested on a couple of UPS aircraft. Potentially, if deployed on our domestic carriers, we could be getting a whole bunch of ACARS moisture data from aircraft on every ascent / descent. GPS ground receivers can infer column precipitable water, and SSM/I and GOES provide this type of information now. The trade off is relatively high temporal frequency versus NO vertical resolution and not particularly high horizontal resolution. New Variational techniques give us the ability to get maximum benefit from these types of data. Direct use of brightness temperatures (radiances) with 3D-VAR eliminates the errors in retrieval methods that, for moisture, rapidly swamp the signal. There is a Radio-Acoustic Sounder that provides low level thermodynamic info and can be added to the Profilers, but I don't expect a lot of these for quite some time and they are NOISY. Currently we make little use of cloud and precipitation observations in the EDAS, BUT that is ABOUT to change. While this information may not be specific to low-level content, it is still quite useful in correcting the structure of the complete moisture/condensate field in general. Finally, (I may have left something out), detailed information from the WSR-88D (in my opinion, the ONLY mesoscale observing system we have) will be used in our 3D and 4D-VAR assimilations and that information will be even better/more useful if they go with a polaraized strategy in the future. We already use radial velocity in our 10km 3D-VAR analysis for the Nest-in-the-west (also used it for Olympics run). Reflectivity and VIL will come next.
IS THE NGM GOING TO BE TERMINATED?
The NGM is planned to be moved to the Cray J916 computers when we acquire the new computer next year. The new computer will replace our Cray C-90 and there are no plans (or resources) to convert the NGM to the new machine. It can be run (albeit slower) on a J916 with no conversion and will likely be run there until late 1999 or until the last of NCEP's J916's is decommissioned, whichever happens first.
NGM termination is NOT up to EMC, and it is definitely NOT be connected to our move to the 4/day Meso. Most likely its demise will come when we buy our next computer (or the one after that) and a choice is made NOT to convert it to that new machine (assuming any amount of effort outside of basic re-compilation) which may possibly be one of quite different architecture. That selection of a Class VIII computer for NCEP will happen 1/98 with installation 7-8/98, acceptance 10-11/98 and our operational utilization of it ~1/99.
