>From: Bob Rozumalski Date: Tue, 7 Jan 2003 09:57:27 -0500 (EST) To: soo_strc@comet.ucar.edu Subject: Subject: Re: Why not GFS first? Date: Tue, 07 Jan 2003 09:35:51 -0500 From: "Geoff Dimego" To: Cliff Mass Subject: Re: Why not GFS first? Cliff; I completely understand how you feel, but... If you recall, when we first implemented the Meso Eta 29 km we ran it from 03z and 15z start times allowing us to use current GFS (then AVN) lateral boundaries from 00z and 12z runs. As it turned out, this strategy resulted in a run which was hardly ever used. Maybe it was "ahead of its time" but in fact the users all said the guidance arrived too late to incorporate in their forecast preparations. Therefore, we set about to get the Meso Eta into the "early" slot where the forecasters were used to seeing first the LFM and then the early Eta (80 km then 48 km). NCEP is now approaching the situation where we will run an identical model suite (data assimilations, Meso Eta, GFS and ensembles) every six hours along with the hourly RUC. Periodically, we've had discussions at EMC's annual production suite review about the schedule. This is how we see it: 1) we run the early package (currently Meso Eta 12km) early in order for its guidance to be available soon enough for the Eastern Region (and NCEP service centers) to use in preparing their forecasts. As it is, they don't have as much time as they would like to peruse and absorb the early guidance before having to issue their forecasts. The North American RAOB's are released 20-30 minutes earlier than the rest of the world precisely so they can get into this early run. 2) that brings up the reason why we can't run GFS early - it wouldn't have 'enough' observational data. It takes a couple of hours (nearly 3) for all of the world's data to get processed, transmitted, ingested and prepared for use in our analyses. That's why we can't run the GFS any earlier than 2:45 after ob time. The NGM, whose outermost grid is hemispheric, ran earlier than the GFS and had little data for the analysis on the back half of the hemisphere. This is why there was no degradation in the NGM guidance when we switched off running its RDAS and just implanted the North American early analysis into the 6 hour GFS forecast on the rest of the Norther Hemisphere as its initial condition. 3) we can't run the GFS and the Meso Eta together because they each take up well over half the computer. At the moment, they each take up nearly the whole machine with only the RUC fitting in over the top when either of them is running. I hope this helps explain why we do things the way we do. Geoff Cliff Mass wrote: > > I have been following the discussion and wonder why NCEP doesn't run > GFS first. It would make real sense. Mesoscale models are only as > good as their synoptic solution...in fact, mesoscale models amplify > synoptic errors. Thus, it is crucial to get the synoptics as right > as possible. Currently, Eta's synoptic forecasts over the Pacific > and along the west coast are clearly inferior to the GFS (I have lots > of objective statistics and subjective cases to back this up). Why > not run the GFS first, and as soon as you get in say 3-h, run the > nested mesoscale model in parallel. To run the high resolution model > as an "early" model with inferior synoptics is not the best way to > go. Furthermore, the current approach forcing the eta with 3-h time > resolution of an old GFS run and without the benefit of all the obs > going into the GFS seems problematic. Am I off-base, or could we do > a far better job by reorganizing how we do NWP? > ...cliff > > -- > > Professor Clifford F. Mass > Department of Atmospheric Sciences, Box 351640 > University of Washington > Seattle, Washington 98195 > > email: cliff@atmos.washington.edu > Telephone: (206) 685-0910 (Voice), (206) 543-0308 (Fax) On Mon. 6 Jan. 2003, Geoff DiMego wrote : > Carven; > > I'm afraid there isn't any advice or light we can shed on this > problem of yours. We feel our lateral boundary treatment is as > good as any regional model going. However, we still have to deal > with lateral boundary conditions that come in every 3 hours from a > GFS run initialized 6 hours earlier. It would be wonderful to be > able to re-run with current GFS boundary conditions or with a more > frequent boundary update, but we are swamped and can't respond that > quickly so even if we could do the re-runs it would only be well > after the fact. The GFS folks are talking about providing output > every hour and this would definitely help. The fact that we have > to run with 6 hour old forecasts is unavoidable due to the Eta's > position as the early model run. If this turns out to be a critical > case for you, let us know and we will undertake to do some re-runs > that address the lateral boundary issue. > > On the 3DVAR initialization, there are a couple of aspects that might > be contributing to uncertainty in the Eta's initial conditions when > compared to the GFS. The Eta, as the early run, doesn't get as much > data into its 3DVAR analysis as the GFS which runs 90 minutes later. > Also, the critical data source for you guys and the Pacific area are > satellite data. The Eta 3DVAR can only apply data corrections within > the vertical domain of the Eta. The Eta has a model top of 25 mb, > whereas the GFS has a model top at .266 mb. This is critical for a > proper use of satellite radiances whose influence functions (some call > them weighting functions) are broad and have large contributions from > levels above 25 mb. This year we hope to be able to push our model > top to 2 mb and expect improvements in our 3DVAR assimilation of > satellite data. For the current case, I'm pretty sure you are seeing > lateral boundary condition effects while this model top issue will > explain other cases where the GFS solution differs from the Eta's. > > Carven Scott wrote: > > > > Geoff, > > > > I know there has been substantial dialogue regarding the performance of > > the Eta over the past few months. I recall your shop is looking into the > > "whys" and the "wherefores". > > > > We here at AFC have also noticed "problems" with the Eta over the past > > months. We have attributed most of the error to initialization issues at > > the western boundary of the Eta. The reason being that the Eta > > qualitatively "seems" to perform better with systems that initialize > > well within the Eta boundary. That being said, tonight's (Jan06/0000Z) > > run of the Eta seems especially suspect. > > > > I am working the West Desk this Sunday evening (the punishment desk, > > LOL). I have been comparing the UKMet, the GFS, and the Eta as I am > > concerned about the upstream low currently southeast of Kamchatka. We > > are advertising storm force winds in the marine forecasts (with > > analogous watches in the publics) with the approaching system. > > > > Both the UKMet and the GFS appear fairly similar in the depth and > > location of the cold upper and the surface low. They both also were > > fairly close in the handling of the warm front through 24 hours. It's at > > 24 hours where the system enters the western portion of grid 217, and > > thus appears on our AWIPS Eta. > > > > It's apparent looking at the 24 and 36 hour at the surface that > > something is amiss in the Eta. There is a secondary low forming on the > > triple point in the vicinity of 45N/172W on the UKMet and GFS, while the > > Eta only hints at the development (It's at this point that all 3 models > > diverge). > > > > By 48 hours (looking now at only the GFS and the Eta), there is a > > drastic difference in the depth and intensity of the western low as well > > as the developing low at the triple point. This is a real dilemma for > > AFC. > > > > Was hoping you guys can provide some insight to us poor cousins on the > > edge of the universe up here. > > > > All the Best, > > -c --------------EB46403D5818C8EE9DE483E2 Content-Type: text/x-vcard; charset=us-ascii; name="Geoff.DiMego.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Geoff DiMego Content-Disposition: attachment; filename="Geoff.DiMego.vcf" begin:vcard n:DiMego;Geoff tel;fax:301-763-8545 tel;home:410-451-3437 tel;work:310-763-8000 ext 7221 x-mozilla-html:FALSE org:DOC/NOAA/NWS;NWS/NCEP/EMC version:2.1 email;internet:geoff.dimego@noaa.gov title:Chief, Mesoscale Modeling Branch adr;quoted-printable:;;NOAA/NWS/NCEP/EMC=0D=0AW/NP22 5200 Auth Rd., Rm 205;Suitland;MD;20746-4304;USA fn:Geoff DiMego end:vcard --------------EB46403D5818C8EE9DE483E2-- ------------- End Forwarded Message -------------