<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Bob,<div><br></div><div>I have a fix for this precise problem thanks to Michael Duda at NCAR. WRF was producing "eternal lake effect storms" over lakes on the Tibetan Plateau that were being assigned SST values representative of the Indian Ocean...yikes! But Michael's fix has eliminated the really bad LSTs and all works fine now.</div><div><br></div><div>Unfortunately it is not a trivial thing...it involves transforming your landuse data set to have a new "inland lakes" index (using code that Michael Duda at NCAR has written) (or just obtaining the transformed data from Michael or myself), making minor changes to GEOGRID.TBL and namelist.wps, and running a new program after metgrid called "tavgsfc.exe", whose output is then used by real.exe to define lake temperatures as the diurnally averaged surface air temperature during the time period of the metgrid analysis.</div><div><br></div><div>If you are using multiple resolutions of landuse, you would have to transform all of them with Michael's code. I've only used it on the 30s landuse data set, and so now I use my transformed 30s landuse data with lakes for all WRF grids of ~1km or coarser.</div><div><br></div><div>I can give you more details if you're interested. I think I have an old email somewhere that gives a step-by-step to someone else who asked about it.</div><div><br></div><div>It would be really great if the NCAR WRF team could incorporate this fix into the standard WPS and WRF systems in a manner that makes it much more transparent to the user. But I don't know if that is in their queue or not.</div><div><br></div><div>Mark</div><div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="font-family: Helvetica, Arial, sans-serif; font-size: 12px; color: rgb(0, 0, 0); ">--<span class="Apple-converted-space"> </span><br><span style="font-weight: bold; ">Mark Stoelinga, PhD</span><br><i>Senior Scientist</i><br><a href="http://www.3tier.com/" style="border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; "><img src="http://www.3tier.com/emailgraphics/3t_logo_sig.gif" alt="3TIER Inc." style="border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; "></a><br>3TIER Inc.<br>2001 6th Avenue, Suite 2100<br>Seattle, WA 98121</div><div style="font-family: Helvetica, Arial, sans-serif; font-size: 12px; color: rgb(0, 0, 0); ">USA<br>+1 206.708.8588 <span style="color: rgb(125, 125, 125); ">direct</span><br>+1 206.325.1573<span class="Apple-converted-space"> </span><span style="color: rgb(125, 125, 125); ">main</span><br>+1 206.708.8589 <span style="color: rgb(125, 125, 125); ">fax</span><br><br><a href="http://www.3tier.com/" style="color: rgb(243, 116, 33); text-decoration: underline; ">www.3tier.com</a><br><br><span style="font-size: 10px; color: rgb(125, 125, 125); display: block; width: 400px; ">This email message and all attachments transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and/or legally privileged information.<span class="Apple-converted-space"> </span></span></div></div></div></span></span>
</div>
<br><div><div>On Mar 15, 2010, at 1:42 PM, Dumais, Bob (Civ, ARL/CISD) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br>FYI-<br><br> Refer to my recent emails to Dave Gill over at NCAR. It looks<br>to me like the problem of these occasional temperature "bullseye"<br>patterns arises due to the hi res land use interpolation producing<br>single point "islands" in the nest domain that are classified as water.<br>These isolated small inland water bodies are not well initialized in<br>terms of SST (or I guess SKINTEMP/TSK) values from the external model<br>(in the case of my Afghan 1 km nest example, the GFS). Is there a way<br>any of you know to improve the initial condition, without doing too much<br>effort? Maybe there is a parameter in GEOGRID.TBL or METGRID.TBL that<br>can allow for manual setting of SST/SKINTEMP/TSK for any nest inland<br>water bodies? Thanks-<br><br><br>Bob<br><br>-----Original Message-----<br>From: Dumais, Bob (Civ, ARL/CISD) <br>Sent: Monday, March 15, 2010 2:07 PM<br>To: <a href="mailto:'gill@ucar.edu">'gill@ucar.edu</a>'<br>Cc: 'Jim Dudhia'<br>Subject: RE: single grid point surface peculiarities in SNOW & TSLB out<br>of real.exe (UNCLASSIFIED)<br><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br>Dave,<br><br> Sorry to have bothered you so much on this topic! My<br>conclusion after further looking at both the Afghanistan and the<br>Washington state/Columbia River Basin hi res cases is this: <br><br> (i) it is possible to get very small areas, even singular<br>grid point areas, of water classification within a much larger<br>surrounding area of land (I suppose vice versa over an open water area<br>may also be possible). <br><br> (ii) the default value for water temp (SST??) in such an<br>instance, such as from GFS 1-degree, may not at all be very<br>representative. For example, the Afghanistan "water" grid point where I<br>have been finding the bullseye 2 magl temperature value pattern is much<br>warmer than it should be for this time of year (~ 296-297 deg K<br>initialization). Over the CONUS, the higher res NAM 218 does a decent<br>job initializing SST/ Skin Temp for the larger inland lake bodies such<br>as Great Salt Lake.<br><br> (iii) I find that TSLB and SST fields at t=0 are the same,<br>but that TSLB becomes different thereafter. Does TSLB even matter for a<br>water point through a WRF simulation? Is it just garbage after t=0 h?<br>The T 2 magl does seem to stay fairly consistent with the initial SST<br>value throughout the recent Afghan simulation .<br><br> (iv) How best to modify in a cold start such initial water<br>temp values for points such as these, when it is obvious that the<br>initial value provided is out in left field? <br><br><br><br>Bob -----Original Message-----<br>From: Dumais, Bob (Civ, ARL/CISD)<br>Sent: Monday, March 15, 2010 1:23 PM<br>To: <a href="mailto:'gill@ucar.edu">'gill@ucar.edu</a>'<br>Cc: 'Jim Dudhia'<br>Subject: RE: single grid point surface peculiarities in SNOW & TSLB out<br>of real.exe (UNCLASSIFIED)<br><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br>Hi again Dave,<br><br> I looked at this particular case in Afghanistan a little<br>more closely this morning, and it seems to actually be related to the<br>landuse / landmasking coming out of geogrid.tbl. These are high<br>resolution nests (nest 1 is 9 km; nest 2 is 3 km; nest 3 is 1 km) and I<br>used 30 arc sec terrain/land use option in geogrid for the<br>interpolations of all my nests. I'm finding that for the point I<br>identified on the 1 km nest (figures were attached in Friday's email),<br>the landmask and xland parameters also produce a bullseye due to a<br>"water" classification. This is basically a single "water" point on the<br>1 km nest out all alone amidst the surrounding land. When I plotted<br>"xland" using GRADS for the initial "0" output, it bullseyed to a value<br>of 1.79. I don't know if this is an artifact of GrADS, but shouln't it<br>have gone to 2? Also, plotting landmask produces a bulleseye value of<br>just under 0.3 (as opposed to 0 as I would expect). Finally, plotting<br>lu_index shows another bullseye pattern with 14 in the center (ie;<br>water). All this stuff leads to the behaviors in the SNOW & TSLB field<br>that I noted Friday. Any thoughts on this? Is it ok to leave as a 1 km<br>bullseye, even if it looks less than "pretty"? Thx-<br><br> Bob <br><br>-----Original Message-----<br>From: Dumais, Bob (Civ, ARL/CISD)<br>Sent: Friday, March 12, 2010 5:34 PM<br>To: <a href="mailto:'gill@ucar.edu">'gill@ucar.edu</a>'<br>Cc: 'Jim Dudhia'<br>Subject: single grid point surface peculiarities in SNOW & TSLB out of<br>real.exe (UNCLASSIFIED)<br><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br>Hi Dave,<br><br> I sent this email below off to Jimy a bit back, and he<br>suggested forwarding to you since it seems a real.exe issue (perhaps<br>with snowcover adjustment if skintemp exceeds 0 deg C??). Enjoy the<br>weekend.<br><br><br>Bob<br><br><br>-----Original Message-----<br>From: Dumais, Bob (Civ, ARL/CISD)<br>Sent: Friday, March 12, 2010 5:07 PM<br>To: 'Jim Dudhia'; wrfhelp<br>Cc: 'Mark Stoelinga'; 'Sen Chiao'; 'Don Morton'; 'David Ovens'; 'Andre<br>Pattantyus'; 'Min Zhu'; Haines, Patrick (Civ, ARL/CISD); Knapp, Dave<br>(Civ, ARL/CISD); Wang, Yansen (Civ, ARL/CISD); Williamson, Chatt (Civ,<br>ARL/CISD); Passner, Jeff (Civ, ARL/CISD); 'Dr. Craig A. Mattocks';<br>'Thomas Raab'; 'Hoeth, Brian R. (JSC-WS8)[NOAA]'<br>Subject: RE: [Wrf-users] Upper boundary cfl error (UNCLASSIFIED)<br><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br>All,<br><br> I have captured some examples of the anomalous 2 magl T<br>points (alluded to somewhere in our email trail below), which I have<br>come across in a few places where I have established high resolution<br>grids (such as the Columbia River Basin in WA & Afghanistan). I<br>definately used GFS as ICs for my Afghanistan examples attached here,<br>but can't recall off the top of my head if it was NAM 218 or GFS for the<br>Washington state plots. <br><br> The plots above show the evolution of three different fields<br>over time (SNOW, T2, & TSLB), the first set for a case over Washington<br>state and another for Afghanistan near Kabul. Both are "zoomed in" areas<br>of my 1 km domain to isolate the anomaly better. I also show comparative<br>temps at sigma level 1 in a few plots, to show that the anomaly is<br>basically isolated to the diagnostic 2magl T level and the surface. I do<br>realize now that I left out my t=0h TSLB plot for the Washington case<br>above.<br><br> What I've seen in these forecasts plotted is the following<br>behavior:<br><br> (i) T2 starts out too warm at an isolated grid<br>point, and tend to remain that way<br><br> (ii) TSLB starts out too warm at the same<br>isolated point (even though that plot is not attached, it does so in the<br>Washington case too), but then as the model evolves appears to become a<br>local cool spot. The Washington case started at 12z- the Afghanistan<br>case at 00 Z. <br><br> (iii) SNOW starts out with a local min value<br>at the same grid point.<br><br> (iv) at the first sigma level and above, this<br>seems to have little if any impact on T field.<br><br> The WRF version used for the Washington run above was<br>3.0.1.1, and 3.1.1 was used for Afghanistan. To me, this problem seems<br>rooted to the initial value of SNOW (and perhaps TSLB) that are<br>generated by metgrid.exe in WPS 3.1. I looked at the METGRD.TBL and I am<br>using the default interpolation method of four pt + average_4pt. I will<br>try a different interpolation method next week to see if it has an<br>impact. Have any of you seen this before?<br><br><br>Bob <br><br><br><br><br><br><br><br>-----Original Message-----<br>From: Dumais, Bob (Civ, ARL/CISD)<br>Sent: Tuesday, March 09, 2010 10:56 AM<br>To: 'Jim Dudhia'<br>Cc: Mark Stoelinga; Sen Chiao; Don Morton; David Ovens; Andre<br>Pattantyus; Min Zhu; Haines, Patrick (Civ, ARL/CISD); Knapp, Dave (Civ,<br>ARL/CISD); Wang, Yansen (Civ, ARL/CISD); Williamson, Chatt (Civ,<br>ARL/CISD); Passner, Jeff (Civ, ARL/CISD); Dr. Craig A. Mattocks; Thomas<br>Raab; Hoeth, Brian R. (JSC-WS8)[NOAA]<br>Subject: RE: [Wrf-users] Upper boundary cfl error (UNCLASSIFIED)<br><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br>Jimy,<br><br> I was thinking the same thing, and would be glad to!! Very<br>exciting I believe. I don't believe I'd be able to provide anything like<br>the rigid mathematical treatment you provided in your REPLY for the<br>various stability criteria, but I could attempt to provide a little<br>better information for users on how to apply epsmm and time step for<br>such a complex terrain region as British Columbia if applying a fine<br>horizontal resolution nesting scheme. For this, I would probably stick<br>initially to the 1 km grid spacing which gave me problems for the past<br>few months! Thanks for all your help, as always. You are always a good<br>sport about supplying ideas and suggestions, even though I realize you<br>are probably swamped by your own research problems and concerns. Have a<br>great day!<br><br><br>Bob<br><br><br>-----Original Message-----<br>From: Jim Dudhia [mailto:dudhia@ucar.edu]<br>Sent: Tuesday, March 09, 2010 10:46 AM<br>To: Dumais, Bob (Civ, ARL/CISD)<br>Cc: Jim Dudhia; Mark Stoelinga; Sen Chiao; Don Morton; David Ovens;<br>Andre Pattantyus; Min Zhu; Haines, Patrick (Civ, ARL/CISD); Knapp, Dave<br>(Civ, ARL/CISD); Wang, Yansen (Civ, ARL/CISD); Williamson, Chatt (Civ,<br>ARL/CISD); Passner, Jeff (Civ, ARL/CISD); Dr. Craig A. Mattocks; Thomas<br>Raab; Hoeth, Brian R. (JSC-WS8)[NOAA]<br>Subject: Re: [Wrf-users] Upper boundary cfl error (UNCLASSIFIED)<br><br>Bob,<br> Very good to hear. I certainly encourage seeing if you can get<br>longer time steps by increasing epssm further. You should look at<br>whether other things in the solution are affected, but I think probably<br>not, since it is only sound waves we are damping heavily.<br> It might be nice to have a grid of various epssm and time-steps to<br>see what works and what doesn't, and give a clue how to compromise<br>between them. Could make for a nice workshop talk.<br>Jimy<br><br>On Mar 9, 2010, at 10:39 AM, Dumais, Bob (Civ, ARL/CISD) wrote:<br><br><blockquote type="cite">Classification: UNCLASSIFIED<br></blockquote><blockquote type="cite">Caveats: NONE<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">All,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Great news to report of my latest Whistler run!! Dr. Dudhia's <br></blockquote><blockquote type="cite">suspicion seems confirmed, and his suggested solution also seems to be<br></blockquote><br><blockquote type="cite">spot on!! Last night, with the 90 level version of the model on my 1 <br></blockquote><blockquote type="cite">km domain, I was able to proceed with no issues at all!! This with <br></blockquote><blockquote type="cite">nonlinear grid stagger per WRF DomainWizard, and a lowest half-level <br></blockquote><blockquote type="cite">of about 24 magl. Recall that my outer mesh is 9 km (I triple nest-<br></blockquote><blockquote type="cite">9/3/1 km).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> (i) set my course grid advective time step to 6 s from<br></blockquote><br><blockquote type="cite">my previous value of 9 s (then apply 3:1 ratio onto other nests, so <br></blockquote><blockquote type="cite">the<br></blockquote><blockquote type="cite">1 km nest has an advective time step of about 0.667 s) .<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> (ii) reset the value of the vertical sound wave <br></blockquote><blockquote type="cite">damping coefficient (epssm) from 0.1 to 0.3<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Now refer to my new plots above for the 1 km domain: two of them at<br></blockquote><br><blockquote type="cite">the 5h fcst mark valid 12-23-2010 17Z, and another showing the w <br></blockquote><blockquote type="cite">vertical profile at the same point and time (50.0565 N; -123.362 W, 30<br></blockquote><br><blockquote type="cite">s at 12-23-2010 12:00:30 Z)that had the significant low-level vertical<br></blockquote><br><blockquote type="cite">instability in w yesterday. The differences are amazing! The <br></blockquote><blockquote type="cite">combination of larger epsmm and smaller timestep completely alleviated<br></blockquote><br><blockquote type="cite">the problem.<br></blockquote><blockquote type="cite">The 5 h forecast fields (I have just plotted wind vectors here) look <br></blockquote><blockquote type="cite">very complex but reasonable. Jimy's earlier worked showed that for <br></blockquote><blockquote type="cite">greater and greater model slopes, the solution had to be either <br></blockquote><blockquote type="cite">progressively smaller advective time steps or higher epssm (between 0 <br></blockquote><blockquote type="cite">and 1). I kind of compromised here and did a little of both, and the <br></blockquote><blockquote type="cite">results are very promising. I trust from Jimy's paper that this <br></blockquote><blockquote type="cite">damping coeefficient has been shown to have limited to no impacts on <br></blockquote><blockquote type="cite">the important flow/meteorological modes other than acoustical.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> My next step is to do the same model run again, except with a <br></blockquote><blockquote type="cite">larger time step (9 s for 9 km grid). If this fails, I'll keep that <br></blockquote><blockquote type="cite">time step and go to a higher epssm. Finally, if one or the other <br></blockquote><blockquote type="cite">works, I'll try a final experiment with a time step of 27 s for 9 km <br></blockquote><blockquote type="cite">(a 3;1 ratio for grid space/time step). Many thanks need to go out to <br></blockquote><blockquote type="cite">Dr. Dudhia for his suggestion over the past week- someone should buy <br></blockquote><blockquote type="cite">him a beer this weekend!! We have plenty we can experiment with <br></blockquote><blockquote type="cite">seemingly. Cheers-<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Bob<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-----Original Message-----<br></blockquote><blockquote type="cite">From: Dumais, Bob (Civ, ARL/CISD)<br></blockquote><blockquote type="cite">Sent: Monday, March 08, 2010 10:44 AM<br></blockquote><blockquote type="cite">To: 'Jim Dudhia'; 'Mark Stoelinga'; 'Sen Chiao'; 'Don Morton'; 'David <br></blockquote><blockquote type="cite">Ovens'; 'Andre Pattantyus'; 'Min Zhu'; Haines, Patrick (Civ, ARL/ <br></blockquote><blockquote type="cite">CISD); Knapp, Dave (Civ, ARL/CISD); Wang, Yansen (Civ, ARL/CISD); <br></blockquote><blockquote type="cite">Williamson, Chatt (Civ, ARL/CISD); Passner, Jeff (Civ, ARL/CISD); 'Dr.<br></blockquote><blockquote type="cite">Craig A.<br></blockquote><blockquote type="cite">Mattocks'<br></blockquote><blockquote type="cite">Subject: RE: Re: [Wrf-users] Upper boundary cfl error (UNCLASSIFIED)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Classification: UNCLASSIFIED<br></blockquote><blockquote type="cite">Caveats: NONE<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Greetings!<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> For all of you who enjoyed last week's message trail regarding <br></blockquote><blockquote type="cite">the single point "blow-up" on my Whistler, BC 1 km domain- I have more<br></blockquote><blockquote type="cite">:)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> As noted in my earlier email from this morning, I did move my <br></blockquote><blockquote type="cite">nest<br></blockquote><blockquote type="cite">3 (1 km) domain center slightly to the east by 0.25 deg longitude in <br></blockquote><blockquote type="cite">order to avoid that troublesome point in my initial domain (~<br></blockquote><blockquote type="cite">50.1286 N;<br></blockquote><blockquote type="cite">-123.6265 W). The plots I emailed Thursday were from that domain and <br></blockquote><blockquote type="cite">showing that particular grid point location.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> I let the new domain with the shift run over the weekend, and <br></blockquote><blockquote type="cite">when I looked at the results this morning I discovered it blew up <br></blockquote><blockquote type="cite">again but at a new location!! At first glance it appeared to be <br></blockquote><blockquote type="cite">possibly at the same I,J location on the new grid as in the initial <br></blockquote><blockquote type="cite">domain. I have confirmed to myself this is not the case, so we can put<br></blockquote><br><blockquote type="cite">that concern to bed. This is back to purely a slope discussion again I<br></blockquote><br><blockquote type="cite">think.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> The plots I have now show the blow up for the new domain, at/near<br></blockquote><br><blockquote type="cite">the grid point location (50.0565 N and -123.362 W). The first set of <br></blockquote><blockquote type="cite">slides show the w, horizontal vector sfc wind, and terrain fields for<br></blockquote><br><blockquote type="cite">this area/point. Notice the same exact behaviors as noted for the <br></blockquote><blockquote type="cite">other location in my original configuration!! Since this new grid <br></blockquote><blockquote type="cite">point location also happened to be contained in my original nest <br></blockquote><blockquote type="cite">configuration, the last few plots attached here will show some of <br></blockquote><blockquote type="cite">these same plots for the new location in the old configuration. Notice<br></blockquote><br><blockquote type="cite">the vertical profile of W in the last plot and how similar it appears!<br></blockquote><blockquote type="cite">Just<br></blockquote><blockquote type="cite">not enough apparently to cause a CFL violation at this point in the <br></blockquote><blockquote type="cite">original configuration. Interesting.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> The only other comment I have to make about hi res complex model<br></blockquote><br><blockquote type="cite">topography and strange behaviors is this. In certain places (such as <br></blockquote><blockquote type="cite">my Columbia River Basin runs in Washington at 1 km), I do not see such<br></blockquote><br><blockquote type="cite">blow ups but another phenomena. In or near the narrow river basin <br></blockquote><blockquote type="cite">locations (which may be just a few grid points across), I'll <br></blockquote><blockquote type="cite">occasionally find single points where there appear to be "bullseyes"<br></blockquote><blockquote type="cite">in the surface T/TD fields along with stronger wind values. These <br></blockquote><blockquote type="cite">bullseyes appear almost immediately at the start of the simulations, <br></blockquote><blockquote type="cite">and can cause differences of up to several deg C between that point <br></blockquote><blockquote type="cite">and its surroundings. I do not know if there is some kind of relation <br></blockquote><blockquote type="cite">to the things we are seeing with the slope, or if it some kind of <br></blockquote><blockquote type="cite">Bernoulli flow kind of thing. I'll try to capture and example for you <br></blockquote><blockquote type="cite">all later.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Bob<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">PS: You can open all these gif attachments with MS Picture Manager or <br></blockquote><blockquote type="cite">similar. Note that in my original configuration I sent Thur, the blow <br></blockquote><blockquote type="cite">up really took off at about 1m 45s (even though my plots may have <br></blockquote><blockquote type="cite">erroneously said 90s ). In my new configuration at the new "blow up"<br></blockquote><blockquote type="cite">location, the blow ups and CFLs appear to be even earlier at 30s. <br></blockquote><blockquote type="cite">Plots<br></blockquote><blockquote type="cite">1-6 attached show fields for this new point location. Plots 7 and 8 <br></blockquote><blockquote type="cite">show fields for this same location within the old configuration at 1m <br></blockquote><blockquote type="cite">45s of that run. Notice it has some of that strange low-level w <br></blockquote><blockquote type="cite">behavior but not enough to cause a blow up or CFL violations!!<br></blockquote><blockquote type="cite">Disregard the wording on my plot title in Figs 7-8 - it should read <br></blockquote><blockquote type="cite">the opposite of what it does!<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-----Original Message-----<br></blockquote><blockquote type="cite">From: Dumais, Bob (Civ, ARL/CISD)<br></blockquote><blockquote type="cite">Sent: Thursday, March 04, 2010 5:22 PM<br></blockquote><blockquote type="cite">To: 'Jim Dudhia'; 'Mark Stoelinga'; 'Sen Chiao'; 'Don Morton'; David <br></blockquote><blockquote type="cite">Ovens; 'Andre Pattantyus'; 'Min Zhu'; Haines, Patrick (Civ, ARL/CISD);<br></blockquote><br><blockquote type="cite">Knapp, Dave (Civ, ARL/CISD); Wang, Yansen (Civ, ARL/CISD); Williamson,<br></blockquote><br><blockquote type="cite">Chatt (Civ, ARL/CISD); Passner, Jeff (Civ, ARL/CISD)<br></blockquote><blockquote type="cite">Subject: Re: [Wrf-users] Upper boundary cfl error (UNCLASSIFIED)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Classification: UNCLASSIFIED<br></blockquote><blockquote type="cite">Caveats: NONE<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">All-<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> For anyone interested, here are a few GRADS plots along <br></blockquote><blockquote type="cite">with my configuration namelists (using my triple nest configuration) <br></blockquote><blockquote type="cite">for that problematic domain near Whistler, BC (where the blow-ups <br></blockquote><blockquote type="cite">happen after a few minutes). I've tried several cases in Feb, such as <br></blockquote><blockquote type="cite">Feb 23 12Z - Feb 24 12Z (using 06UTC Feb 23 GFS datasets), and this <br></blockquote><blockquote type="cite">happens all the time in this configuration. I also have a double nest <br></blockquote><blockquote type="cite">configuration (basically, nests 2 and 3 shown here without outer nest,<br></blockquote><br><blockquote type="cite">using<br></blockquote><blockquote type="cite">NAM-218)<br></blockquote><blockquote type="cite">where this happens also. My GEOGRID.TBL shows I am using just a <br></blockquote><blockquote type="cite">single pass smoothing in all my previous attempts. Perhaps this is a <br></blockquote><blockquote type="cite">good domain for others to focus upon for investigating this problem?<br></blockquote><blockquote type="cite">Thanks,<br></blockquote><blockquote type="cite">and all have a good evening!<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Bob<br></blockquote><blockquote type="cite">Classification: UNCLASSIFIED<br></blockquote><blockquote type="cite">Caveats: NONE<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Classification: UNCLASSIFIED<br></blockquote><blockquote type="cite">Caveats: NONE<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Classification: UNCLASSIFIED<br></blockquote><blockquote type="cite">Caveats: NONE<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><03fixw.gif><02fixw.gif><01fixw.gif><br></blockquote><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br><br><br>Classification: UNCLASSIFIED<br>Caveats: NONE<br></div></blockquote></div><br></div></body></html>