access_SourceAndDataManagementIssues - ACCESS-NRI/accessdev-Trac-archive GitHub Wiki
#!html
<h1 style="text-align: center; color: blue"> ACCESS Source Code and Input Data Management: Issues </h1>
Source Data Management for NWP the top page for NWP Source Code and Input Data Management
Each repository should have a clearly defined branch structure for each APS version (e.g. APS2, APS3,...)
The same branch structure should ideally apply across all repositories
When a user creates a suite they should
- Create a branch (Should this be done as part of setting up suite set up scripts?)
- Keep track of changes to the trunk using svn diff
- Keep up-to-date as much as possible using svn update
- Exchange developments with svn merge
- Submit updates to the trunk for review as frequently as possible * This is made safer & easier if changes can be controlled by namelists * Applying large update sets make checking much, much more complex, expensive and frustrating
At some point the decision is made to begin pre-operational testing of APSx
- A branch structure in all repositories should be created for the pre-operational suite
- When ready for operational implementation an operational branch should be made off the pre-operational suite
A conceptual image of this is attached as SVN_trunks.pdf, highlighting the general development of ACCESS, then at some stage a Pre-Operational branch is taken place, but at the same time the ongoing development of ACCESS continues. After sufficient testing the Operational branch is created.
- Note: This is only for illustrative purposes. The actual structure of the svn repostories can differ, as long as it is clear where to get copies of latest research, pre-operational and operational systems.
A key part of using the power of svn is to be able to exchange updates. >>> That means frequently updating your branch <<<
- Do not worry about your work being unfinished before committing to your branch
- The branch allows you to revert back any number of revisions if you make a major mistake
- There should be no expectations on code quality or robustness of software from your branch during development
- Frequent updating allows other people to take just some of your revisions etc.
1. Where do I put new files?
This needs to be very clear, one option is:
Each directory in the data repository should contain a README file briefly outlining what belongs in it
The same information should be cut and pasted onto a Wiki Page (associated with the svn repository)
2. Extraction of the same reference suite across different repositories There may be a clever svn way of doing this, but a script to check out APSx would be simple & effective (but possibly limited functionality
The svn repositories are being managed to make this very straightforward
3. How do we keep track of reference suites for each configuration (i.e. APSx-G, R, C etc.) under Rose svn repository?
4. Do different versions of data files be kept as different filenames or as different revisions? For files that depend on the forecast basedate (e.g. Sonde StationLists) then Xiao's current method makes sense
The big advnatge is that it allows for the version number to be the same as the Met Office
For other files - maybe revision numbers are OK. Unsure
5. What about large, binary data files? Ancillary and CovStats files are not suitable for svn, BUT
The scripts & suites used to generate them ARE.
* Scripts to create these files should be under svn, and form part of the APSx suite
* The files should be kept under ~access/nwp, preferably in a directory that corresponds to the svn location of the creation script
6. How often should I update my branch? Often! Preferably every time you complete a small step along the way, but at least once a day.
If you are working on it all day, then I would hope that you reach complete at least a small stage
If you are working on it off and on, then committing at least once a day makes it easier to remind yourself of where you are up to.
**7. ACCESS_UTILS and cylc-suite ${script_dir} ** There are two sets of scripts that form an important part of an NPW suite: * scripts in the cyls-suite/bin directory. - These generally can only be run under cylc as the reference various cylc functions etc. - They are maintained in the rose repository * scripts etc. under ACCESS_UTILS svn repository - These include a lot of my (Peter Steinle) plotting and verification python scripts etc. - They can be run outside of cylc * PJS: My guess is that it is OK to keep as seperate repositories, but we should think about this a bit