Community Development of LAPS

1. Community Development of LAPS Ligia Bernardet NOAA ESRL GSD 2nd LAPS Users Workshop 23 October 2012 Boulder, CO

2. A word about the speaker • I work in FAB but not with LAPS • I am bringing the perspective of an outsider to this community • I work in projects of the Developmental Testbed Center (DTC) • Our mission is to facilitate transfer of NWP research to operations • One strategy to facilitate R2O is to make operational codes available and supported to the community (downloads, documentation, help desk etc) • We also facilitate users in transitioning their development back to the centralized code

3. Overview of this talk • How LAPS development is done • In NOAA GSD • In the community • Issues related to community software development • Is everything working great or is there room for improvement? • Pose some issues for discussion in breakout session

4. LAPS Development • LAPS development started with the group now called NOAA/ESRL/GSD/FAB (then NOAA FSL) in the early 1990s • LAPS has been adopted operationally by the US NWS and others • Main development occurs in FAB • Development also takes place in the community

5. Communication in the LAPS community • Scientific publications • LAPS Workshops • Other conferences and workshops • LAPS Forum • Announcements of new releases • Bug reports (~2 per year) • Development/General discussion (~30 per year) • Is there enough exchange among users? Are users aware of what others are doing? And benefitting from each other to the fullest extent possible?

6. LAPS code and releases • LAPS code is housed in a CVS code repository at NOAA • Links to CRTM library maintained by NOAA JCSDA • Repository access only given to FAB • Repository not used for code development • Development is done on disk • Repository has mature development, ready for parallel testing • LAPS releases: ~5 times per year, tarfile in website • Seems that transfer from FAB to community works well

7. LAPS testing at FAB • New development put in repository frequently (weekly build) • Parallel runs start using new code • Parallel runs cover a variety of computational platforms and domain configuration • After “sufficient” testing, developments are transitioned to production runs • No formal protocols for testing and acceptance of code • Is this an issue? Only if questionable code is being accepted, or code is taking too long to be accepted or ??? • Who should determine is code is acceptable? Should there be more participation from users and WFOs?

8. LAPS Community developments • FAB development easily gets to repository and community • Unclear path for community development to make its way back to central repository and to other • Some user development does not get back to FAB • Other user development makes it back in outdated versions so it is challenging to integrate with current code • Why is that and can it be improved?

9. Motivations for community code • Users need to perceive an advantage in a community development. Most users do not contribute code out of altruism • Advantages for users • Access to development from other users • My code available in the official release means I do not have to maintain it myself • When next release is available, I can easily upgrade and benefit from bug fixes and updated science

10. Issues that prevent code integration • Programmatic • Development is proprietary • Developer wants to publish first • Developer wants to be the only one to take advantage of it (can only be overcome if user sees advantage in community) • Technical • Code does not meet standards • Coding practices (declaring all variables, indentation etc) • Development is not general enough, not applicable to other users • Can be isolated and only triggered with a namelist • Code in outdated version is difficult to integrate

11. Addressing technical issues • There is a cost to this! And the perceived benefit needs to be higher than the cost. • Planning • Education, training • Implementation of new system • Code reviews • Testing

12. Coding practices and testing • Community agrees on coding and testing practices • Developers follow practices • It can be that simple!

13. A solution for synchronization of distributed development • Make code repository available to all developers -> SVN or Git • [Provide anonymous checkout?] • Reserve trunk for vetted code • Use branches for development, keep up to date • Once development is ready, propose it for adoption in the trunk • Committee reviews the code • Test (various computational platforms, various applications) • Approve code or send it back to developer to address concerns

14. Details on possible code management Contributions from FAB Trunk Developers branch

15. This solution makes people nervous • Community intimidated by code version control (CVS, SVN) • Requires training but, even I can do it, it cannot be that bad  • Main developers feel lack of control about opening repo • Not an issue, as repositories can be setup to prevent inadvertent write to trunk and, if it happens, can be reverted • A two-repository solution can be considered, in which the main repository is mirrored for the community • Discouraged: prone to error and increased labor costs

16. Can we do something simpler?? • Suppose we do not open the code repository… • If we make the weekly build available to the community… • Can community developers commit to putting their code in the latest version email it back? No sending old code!! • With code in the latest version, easier for FAB to integrate. • Does this meet our needs?? • Scalability: this may work if we have a handful of developers but not if we have tens…

17. Discussion Topics

18. Discussion Topics • Communications among users and developers • Enough? Efficient? • What is the best way for users to contribute code back • Avoid version divergence • Avoid Steve having to integrate code from old versions • Make new developments available to all users timely • Cost/benefit analysis of solutions (open repository) • Testing protocols and standards • Coding standards • Other issues?