1. Resources applied to WRF 3DVAR NCAR0.75 FTE, split among 1-3 people FSL0.50 FTE, mostly Devenyi CAPS0.80 FTE, 1-2 people NCEP1.30 FTE, Wan-shu Wu (1.0) plus 0.1 each for Derber, Parrish, Purser USAF0.50 FTE, McAtee

2. The Schedule Oct 2001first version – for friendly users; not competitive with operational versions Oct 2002research version – has current state-of-the-art capability 2006advanced version – capable of assimilating all major sources of observations relevant to mesoscale forecasting

3. Decisions made by Working Group on 3DVAR regarding the first version (Oct 2001) The grid and geographic domain for the analysis Analysis grid same as prediction grid, with possible exception that analysis is performed at lower resolution Corollary: analyze on Arakawa-A grid (if alternate dynamical core uses C-grid, initial version will still interpolate background from C to A-grid and the analysis from A back to C-grid Corollary: analyze on sigma-z (later sigma-p). Using different vertical coordinates for model and analysis complicates expression of constraints and would greatly complicate 4DVAR. [Note: spacing/location of gridpoints in vertical imposes no restriction on shape or orientation of 3-D correlations.] Analyze in same geographic domain as model grid with two exceptions: 1) cold start (add lateral margins) 2) assimilating radiances (add layers at top to define non-model background— users can define model top)

4. Decisions about first version of 3DVAR (continued) Treatment of errors Observation error covariance matrix diagonal (use best estimate of error variances) Background errors homogeneous and isotropic, obtained via educated guess or “NMC” method (eventually definition of B should depend upon obs) Application of background error covariances via recursive filtering along the three coordinate directions; anisotropic covariances will appear in research version

5. Decisions about first version of 3DVAR (continued) Control variables Psi – stream function Chi – velocity potential Unbalanced mass variable (height or pressure preferred) Specific humidity

6. Decisions about first version of 3DVAR (continued) Formulation In gridpoint space (as opposed to observation space) Formulations in gridpoint and observation spaces are not always equivalent. Evidence that condition number (rate of convergence) might be much better in observation space Not difficult to change spaces later Analyze increments, not full field. No explicit balance constraints (no J c term); no physical constraints Map factors supplied by Standard Initialization and used in initial version “square-root” preconditioning Adoption of outer/inner iteration structure

7. Decisions about first version of 3DVAR (continued) Parallelization 3DVAR working group strongly supports capability to run code on multiple processors but uncomfortable about guaranteeing that this will be implemented in first version. Domain decomposition – by equal areas (later will probably be based on obs density)

8. Decisions about first version of 3DVAR (continued) Coding Standards Fortran 90 Coding style consistent throughout Naming conventions don’t change across subroutines Adherence to WRF coding standards Memory management consistent throughout

9. Decisions about first version of 3DVAR (continued) Observation types (minimum set) Rawinsondes / dropsondes Surface observations AIREPS / MDCRS Wind profiler

10. Expectations of Obs Preprocessing WG A file or multiple files containing: –Time, location, parameter type, value –Instrument type with associated metadata –Estimated instrument error (representativeness error is purview of 3DVAR WG) –Flags from instrument-specific QC Instrument-specific QC is handled by Obs Preprocessing WG All files in BUFR format Global coverage (issue: huge volumes likely; how long to keep on-line?)

11. Who does what? NCEP works on background error covariances and recursive filter. (Barker will assist.) NCAR works on observation data structures (how obs are handled within the analysis package). FSL works on QC (no variational QC in initial version); QC based upon OI buddy check is a possibility, but would be replaced as soon as practicable. FSL does obs preprocessing inside the analysis (e.g., adjusting for difference between model topo and real topo, filling in raob values, etc.) FSL works with Purser on anisotropic recursive filter and with NCAR on data descriptors. OU/CAPS works on constraint term for mesoscale, forward operators for radar, linking radar assimilation system with CRAFT system. USAF works with FSL with observation operators and obs preprocessing.

12. Near future 9 Feb 01: Each group makes sample of 3DVAR code available thru Web plus a couple of pages of high-level documentation with flow diagram.. Each group looks at the other groups’ codes for two weeks to survey overall code structure, layout, clarity, conformance to WRF standards 23 Feb 01 1230 EST: conference call (AFWA coordinates)

13. Major problems / issues to address in next two years Develop tests to verify that variational assimilation works properly: look at analysis increments resulting from single observation; test correspondence between forward and adjoint observation operators; count iterations to convergence; ensure that analysis fits obs consistent with expected obs errors; test gravity wave noise in model as measure of balance in initial state, etc. Getting WSR-88D data from around the country into the database Improve domain decomposition for better load balancing. Seek better ways of parallelizing minimization algorithms (along with recursive filtering)—tough because many operations involve entire grid. Must frequently synchronize computations in all processors. Work to parallelize filtering associated with anisotropic covariances.

14. 3DVAR WG believes that users should be able to: Specify regional domain in any part of the world Load obs sources appropriate for the domain Determine the data sources to be assimilated Say whether the code should run on single or multiple processors