1 / 11

Academic Developer’s Perspective

Academic Developer’s Perspective. Talât Odman Georgia Institute of Technology and Amir Hakami Carleton University, Canada. 9 th Annual CMAS Conference October 14 th , 2010. State of Academic Development. There is not much funding out there for model development

lydia-olsen
Download Presentation

Academic Developer’s Perspective

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Academic Developer’s Perspective TalâtOdman Georgia Institute of Technology and Amir Hakami Carleton University, Canada 9thAnnual CMAS Conference October 14th, 2010

  2. State of Academic Development • There is not much funding out there for model development • Model development tasks are not viewed favorably in research proposals • General opinion is that CMAQ ≈EPAMAQ in terms of ownership and development responsibility • Mechanisms for rapid transition from research to operations are lacking • Despite limited resources, model development continues at universities, under different names • We have to maximize the use of those limited resources • Universities need help from the Community • To promote the role of universities in model development • To make model development easier for university researchers

  3. Convoluted Model Development • There are two types of model development • Modular (e.g., ISORROPIA, APT) • Convoluted (e.g., DDM, Adaptive Grid, Adjoint) • In CMAQ, there is an assumption by design that all development will be modular • Convoluted development takes time • In the past, a new version of CMAQ was being released every year • Some convoluted developments became obsolete before completion; others are still subject to the same risk • DDM is a success story but is it an exception? • It was developed to a large extent in another model • It enjoyed exceptional Community (C = C) support • Developers dispersed into the Community; many of them continue the development effort

  4. Stories of Adaptive Grid and Adjoint

  5. How can we make convoluted development easier? • Support of current variables should continue in new versions • Primitive variables should be preferred since they are less likely to be removed (e.g., density instead of a lumped quantity that contains density) • No functionality should be removed without notice • Emission file formats changed in SMOKE • CMAQ version 4.7 removed the RADM cloud • Good to see “backward compatibility” as a priority • New additions should be well documented • Peer reviewed publications • Updates to the science document

  6. CMAQ’s coordinate system is difficult to comprehend • In CMAQ’s horizontal diffusion, the Smagorinsky parameterization assumes Cartesian coordinates. • Becker and Burkhardt (2007, Monthly Weather Review, 135, 1439-1454) revisited Smogarinsky’s mixing-length based parameterization for spherical and terrain following vertical coordinates of a GCM. • The Smagorinsky parameterization must be derived for CMAQ’s generalized coordinates. Meanwhile, by intuition, I proposed

  7. Watch out hemispheric modelers! • There may be a directional bias in horizontal diffusion when the map scales display a wide range over the modeling domain such as in hemispherical applications with polar stereographic coordinates.

  8. What should we do about the generalized coordinate system? • At a minimum , we should add divergence and vorticity to the “model provided variables” list • This way, these coordinate dependent variables can be used directly in parameterizations • Since they wont have to be computed by the developers, a source for mistakes would be eliminated. • For the long run, we should consider providing operators for computing divergence and curl of a vector field. • When a new coordinate system is introduced, these operators would have to be implemented for the new coordinate system. • Parameterizations or other features resorting to divergence and curl of vector fields would be automatically applicable.

  9. Concluding Remarks • Some of the initial modularity concepts are broken, intentionally or unintentionally. • Existing framework is not very supportive of convoluted development • 15+ years after the initial design, it is time to go back to the drawing board. • Leading developers should work together: • Find ways to involve the Community in academic development and vice versa (e.g., joint proposals, visiting scientist programs) . • Start a developers forum that would instigate technical discussion and create a framework for morphing ideas • Have periodic developers workshops

  10. Parallelization • We are moving fast towards an era of computationally intensive applications, e.g. forecasting, variational inversion, forward and adjoint sensitivity analysis, uncertainty analysis, etc. • CMAQ’s parallelization is inefficient and outdated • Particularly when we have 24-thread personal computers • Part of the problem is IOAPI whose parallelization needs revisiting. Georgia Institute of Technology

  11. w VGTYPE = 7 • A new vertical coordinate was introduced in CMAQ to make it compatible with WRF • This coordinate is a function of time • What about apparent fluxes due to movement of vertical layers? • As I recall, the governing equations of CMAQ do not have any terms to accommodate a moving grid. They assume a coordinate system that is constant in time such as VGTYPE = 2

More Related