National Weather Service San Diego WRF -National Weather Service San Diego WRF -Leveraging Operational WRF RunsLeveraging Operational WRF Runs

Brandt MaxwellMeteorologistNational Weather Service Forecast Office Web: weather.gov/sandiegoSan Diego, California USA Email: Brandt.maxwell@noaa.gov

Today’s Presentation Today’s Presentation

• History of the WRF at NWS San Diego

• Info about our WRF• How our WRF is Used• Positives/Negatives of

our WRF• “Show and Tell”

– The Best Part!

Short History of Numerical Short History of Numerical Modeling at NWS San DiegoModeling at NWS San Diego

• First ran Workstation-ETA in 2001– Predecessor to the WRF-EMS

• As name suggests, ability to run a model with ETA physics on a Linux PC or workstation

• Developed by COMET (UCAR)

– Original intent: view terrain effects on wind, precipitation and temperature for operational forecasting

– Original grid-spacing: approx. 8 km– Non-hydrostatic– Original computer had only 2 processors– No concurrent post-processing

Upgrade to WRF-EMSUpgrade to WRF-EMS

• First ran WRF-EMS in 2006– Originally used the WRF-NMM for the dynamic core

• WRF-EMS had 2 options (NMM vs. ARW)

– Grid spacing was 4-km (but in diagonal/Arakawa-E grid)

– Had better computer, with 4 cores– Separate post-processing computer let us generate

the Grib files for AWIPS while the WRF was running• No waiting until the end of the run

Further ImprovementsFurther Improvements

• Big improvement in 2009– New 8 core system (2.83 GHz each) with 12 GB

memory (DDR)– Switched from WRF-NMM to WRF-ARW– 3.7-km grid spacing (non-diagonal)– 45 vertical (sigma) levels

• Heavier distribution towards surface (marine layer)

– Around this time, self-implemented e-mail notification of when the disk was full (due to a few WRF crashes due to disk-full errors)

Current WRF for Current WRF for NWS San DiegoNWS San Diego

• We still use the WRF-EMS– We actually have 2 runs every 6 hours

• One run is on our local machine (from 2010)• Alternate run is on the Triton system at the San Diego

Supercomputer Center (since 2012) on space rented by SDG&E

• Both runs use NAM for boundary conditions...but...• Different initial conditions (one uses NAM, one uses RAP)• NAM-init run gives 84-hours of output (takes approx. 3 ½

hours to run)• RAP-init run gives 48-hours of output (takes approx. 2 ½

hours to run)

More on Current WRFMore on Current WRF

• Both runs now use 47 vertical levels– A couple of levels were

added in the mid-levels to attempt to better view elevated convection

– 13 levels below 900 mb (at sea level grid points)

• Grid is 134 x 110 points in the following domain:

Normal Time StepNormal Time Step

• For WRF-ARW, time step (in seconds) should normally be about 6 times the grid spacing (in kilometers)– Allows one to usually satisfy the Courant, Friedrichs

and Lewy (CFL) condition:• The time step must be less than the time it takes the fastest

moving wave in the model to travel one grid space• Violation of this creates noise and/or a crash

– In our case: 3.7-km grid spacing x 6 = 22 seconds– Normal operating mode until 2012

Adaptive Time StepAdaptive Time Step

• A way to speed up the model– If no fast-moving waves are threatening to violate the

CFL condition:• The adaptive time step will increase and “speed up” the WRF• WRF allows as high as a 45-sec. time step for 3.7-km grid

spacing

– We began using this in April 2012• Worked very reliably in late spring and summer with runs

30% faster than before• We started having crashes in autumn though

Adaptive Time Step IssueAdaptive Time Step Issue

• What messed up the WRF?– CFL was violated

• Happened when WRF was running at longer time steps (40-45 seconds) and a wave suddenly appeared

• It has been suggested that due to our small domain, the adaptive time step does not work as well as with a large domain

– Time step adjusts (by getting smaller) better with a larger domain when there are waves propagating really fast

SolutionSolution

• Only run WRF with adaptive time step in late spring/summer/early fall

• We run the main (84-hour NAM-init) WRF on our local machine with adaptive time step then

• When we can’t run the WRF with adaptive time step, we run it (NAM-init WRF) on faster Triton and swap the WRF RAP-init to our local machine (since it’s only through 48 hours)

– Computer power is limited, so can’t have a larger domain without sacrificing resolution

– Other note: RAP-init WRF runs without adaptive time step to prevent both WRFs from crashing

Why can’t we just always run 84-hour Why can’t we just always run 84-hour NAM-init WRF on Triton?NAM-init WRF on Triton?

• A couple disadvantages of Triton:• Difficult to set up concurrent post-processing due

to WRF being allocated to different processors each model run on Triton

– When we can run WRF on our own computer, we can view the 24-hour prognosis when the later hours of the WRF are still running

• Internet bandwidth is tight at NWS San Diego, and large post-processed Grib files can take 15-30 minutes to download

Other “specs”Other “specs”

• For both NAM-init and RAP-init runs:– No convective parameterization

• We’ve tried Kain-Fritsch and Grell 3D in the past

– Microphysics: Thompson– PBL: Yonsei– Land-Surface: Noah– Long/Shortwave Radiation: Dudhia

• Part of deciding the “specs” is computational times

Why do we use the WRF-EMS versus the Why do we use the WRF-EMS versus the NCAR version of WRF ARW?NCAR version of WRF ARW?

• Easy (and relatively fast) to install and configure– No compilers required

• Access to COMET’s personal tiles for boundary and initial conditions– Only downloads data (Grib) for your domain– Can also access other Grib data sources, such as NOMADS

(which now have geographic constraints on the data)– COMET has archived data (including offline NAM/GFS data)

• Good network of support– WRF-EMS listserv– NWS offices are #1 on the COMET support priority list– Most other NWS offices use WRF-EMS

How Does NWS San Diego Use the WRFHow Does NWS San Diego Use the WRF

• First of all, WRF is *the* #1 model of choice at NWS San Diego

• General Weather Forecasting– We mostly view WRF in AWIPS– Heavily used for IFPS grids

• Need high-res model here especially for terrain and coastal effects

• 84-hour WRF run means we can use it to populate 3 days worth of grids

• Most often used for winds, temperatures, dew points• Bias-corrected grids are an option which takes into account

WRF biases from past 30 days

Example of Wind Grids using WRF as Example of Wind Grids using WRF as Primary ComponentPrimary Component

WRF: Aviation ForecastingWRF: Aviation Forecasting• Used frequently for aviation forecasting (TAFs)

– We view them in AWIPS and BUFKIT– AWIPS has interpolated vertical levels (due to Grib files) every 3

hours, BUFKIT has *all* vertical model levels every hour

• Specific uses:– Used for depth of marine layer (cloud heights; can impact

visibility)– Used for locations of low clouds (low-level RH fields)– Used for winds at TAF sites– Used for wind shear (especially in BUFKIT soundings which

show every WRF model level at every hour)– Used for pilot briefings (including winds aloft)

Example of Wind Shear in WRF Example of Wind Shear in WRF BUFKIT SoundingBUFKIT Sounding

Fire Weather ForecastingFire Weather Forecasting

• WRF inclusion in IFPS grids helps with– Fire weather forecasts– Spot forecasts

• WRF is a major tool for deciding whether or not to issue a red flag warning

• Excellent for verbal briefings

Marine ForecastingMarine Forecasting

• Useful for winds over coastal waters– Especially when waves from the islands (or from

offshore flow) impact surface winds

• Useful for short-period, locally generated swell– Especially for WNW swells with a wind fetch south of

Point Conception/through the Channel Islands

• WRF low-level shear/instability can assist with waterspout forecasting

WRF OnlineWRF Online• We have our WRF model

online:– Some of our partners/users do

look at the WRF (including fire weather)

– Online WRF uses GrADS scripts created by Dan Leins, NWS Phoenix (with modifications by Stefanie Sullivan, NWS San Diego)

– NAM-init is used during summer, RAP-init is used during winter

http://weather.gov/sandiego/wrf

ResearchResearch

• WRF is used for case studies– All NWS San Diego WRF runs are archived back to

2010

– For older dates (or if other boundary/initial conditions are desired), other sources of data can be used as input to the WRF

• If high-res nested domain is desired, output Grib files from the WRF can be used as input to the high-res run– Mixed results here, probably because domain can be

too small

What the WRF does wellWhat the WRF does well

• Winds: Does well in most cases– Gap winds perform well in places like San Gorgonio

Pass, Cajon Pass– Mountain wave winds do moderately well

• But...WRF has a tendency to go too high here– In “weak Santa Anas”, WRF sometimes erroneously

predicts strong winds at 850 mb near Cajon Pass to reach the valley floor

– Rotors (such as near Palm Springs) appear with some accuracy

– Sea breeze winds are well modeled

What the WRF does well, cont.What the WRF does well, cont.

• Relative humidity:– Boundary layer RH is an accurate indicator of

marine layer stratus (especially at night)– Good for showing marine layer depth (time-

height cross sections)– Moderately good for fire weather

• Temperature:– Performs well with bias correction for IFPS

Weaknesses of the WRFWeaknesses of the WRF

• Precipitation, especially convective– Stratiform precip is OK, though usually with values too

high– Convective precip is difficult to predict in So-Cal

• One problem is that a lot of our thunderstorms are very small core in summer

– Convective parameterization has not helped enough to justify the extra model time needed

• However, WRF is at least moderately good with predicting indicators for convection (instability, convergence, etc.)

– Visibility values (aviation) are not good

““Self-Inflicted” Negative Impact on our WRFSelf-Inflicted” Negative Impact on our WRF

• Our domain is too small– Despite buffer of more than 5 grid points beyond our

County Warning & Forecast Area (CWFA), a COMET study showed that the ideal domain should be much larger—perhaps double your forecast area!

– Seems to impact precipitation (especially convective) the most

– Likely impacts our adaptive time step

• However...larger domain needs larger more expensive computer

““Show and Tell” – Operational WRF Show and Tell” – Operational WRF Run from 20 March 2011Run from 20 March 2011

• Low-pressure system with strong height/MSLP gradients moved through California– Strong mountain wave in San

Bernardino County: Stationary jump and lee waves

• Measured wind gust of 115 MPH at Lucerne Valley (Mojave Desert)

• Damage: Lots of roof damage (one house had total roof destructions). Power lines and trees down.

WRF Surface WindsWRF Surface Winds

• All images are from 0600 UTC run (20 Mar 2011)

• 2100 UTC prognosis

• Time is near/just after the “peak”

• Strongest winds are just north of the San Gabriel/San Bernardino Mtns.

WRF 700-mb Omega and WindWRF 700-mb Omega and Wind

WRF Cross-Section WRF Cross-Section

• Inland Empire – San Bernardino Mtns – Mojave Desert (including Lucerne Valley)

WRF Cross-SectionWRF Cross-Section

• 2100 UTC• Potential temperature,

omega and wind• Clear stationary jump

with weaker lee waves

• 15 deg C temperature jump in the wave at 700-mb!

• 80-knot wind just above 850-mb

SummarySummary

• WRF is a big part of the forecast operations for NWS San Diego (#1 model)– IFPS would be difficult without it given our terrain/coastline

• WRF does well with wind, temperature and dew point in So-Cal, not as well with precipitation (especially convective)

• Great model for case studies– 20 March 2011

• Our WRF is online: http://weather.gov/sandiego/wrf

Questions?Questions?