Policy on introduction of changes into the NCEP GSI analysis system

 

The GSI analysis system was developed with the intent that it would be used both in research and operations.  The multiple uses of this system make the management of the code particularly difficult and require a strict code management policy.  It is desirable to incorporate various options developed by the research groups into the system so they can be fairly evaluated, however it is necessary that the operational code operate robustly and efficiently and to remain fairly simple and easy to modify.  To balance these goals the following policy and process for incorporating changes into the NCEP GSI analysis system will be followed.  Of course, all users are welcome to make any changes to the their own versions.  However, we wish to foster a process to develop a single analysis system with many contributors rather than the development of many different competing versions of the same system.

 

To return to the main GSI code page, click here.

Page last modified: 9/9/2005 12:30 PM

 

Policy

 

EMC will decide which code updates (modifications, additions, deletions) are incorporated into the EMC core GSI analysis system.  EMC must maintain control over the GSI analysis system to ensure a robust, efficient and accurate system for NWS operations.  Criteria for accepting an update include:

 

  1. Computational efficiency
  2. Quality of coding
  3. Quality of science
  4. Complexity
  5. Whether or not the update fits in with the long-term goals for the analysis system
  6. Whether or not there is another better way of doing the same thing (possibly under development by another group at the same time)
  7. Impact on quality of analyses and forecasts

 

Additional criteria may be included at EMC’s discretion.

 

Since it would be unfortunate for a group to expend substantial effort and since some of the criterion cannot be quantified, developers are encouraged to contact EMC with plans and progress on their development as early and often as possible to ensure their project remains on a path towards inclusion in the system. 

 

 

Process

 

The process described below is intended to minimize the required resources while keeping the process simple and straightforward.  Significant changes in the details of the process (including location of the base code, method of submitting changes, etc.) are expected as the system and capabilities at NCEP evolve.

 

1.  A call for updates will be issued by EMC prior to release of a new version of the code (currently every two to three months).

 

2. Updates will be submitted to EMC following instructions in the notification.  Updates submitted prior to the deadline will be evaluated based on the above criteria.  Developers will be notified of the status of their submitted updates.  Possible outcomes are:

  1. Update is accepted.
  2. Update is rejected.  Reasons will be supplied
  3. Update is returned to developer – improvement to update required.  Reasons for returning the update could include insufficient documentation, inadequate coding, errors in the update, and other suggestions for improving the update.
  4. Update is returned to developer - delayed until next version.  With substantial changes to large parts of the code there may be large overlap between various developers updates.  In this case, one or more developers may be asked to delay the inclusion of their update and merge their update with a newer version of the system.

 

Note that all submitted updates must be based on the current version of the analysis system.  Updates based on older versions will not be accepted.

 

3. Updates will be merged with other updates by EMC, the system will be tested and a new version of the GSI system released.  A notice of the release will be e-mailed to all registered users.

 

4. Developers should test the new version of the system to ensure updates properly incorporated.

 

5. If necessary intermediate versions will be released as major errors are discovered and repaired.