| 9 | | * Run the "open trusting" to test your modifications, see here [wiki:Documentation/UserGuide/Internal/OpenTrusting] |
| 10 | | * the code must be conform to the ORCHIDEE coding guidelines (Documentation/UserGuide/CodingGuidelines) |
| 11 | | * update to latest version: the modifications must be integrated in the latest version of the trunk (use "svn update", or extract a new ORCHIDEE). Be sure that your original code is backup somewhere locally to avoid deleting developments during the update. |
| 12 | | * if svn update induce some conflicts between your local version and the trunk version carefully check them and solve them manually if necessary. Don't forget then, once the conflicts are resolved, to do "svn resolved myfile.f90" |
| 13 | | * the modifications must be tested on at least one platform using MPI parallelism (except if only comments are changed). This means that you should launch a test simulation on more than one processor. |
| 14 | | * check difference in results from your history files. The reason for a change in result must be known before the commit. If possible, avoid change in results except if it was on purpose. |
| 15 | | * communicate and/or be aware of the latest news in the ORCHIDEE core team. For example a colleague announced that she/he will make a commit, better wait or ask if you could commit before. |
| | 9 | * Carefully document your code and parameters. Explain the principles used, cite the papers that were used as a source of inspiration. |
| | 10 | * The code must be conform to the ORCHIDEE coding guidelines (Documentation/UserGuide/CodingGuidelines) |
| | 11 | * Update to latest version: the modifications must be integrated in the latest version of the trunk (use "svn update", or extract a new ORCHIDEE). Be sure that your original code is backup somewhere locally to avoid deleting developments during the update. |
| | 12 | * if svn update results in conflicts between your local version and the trunk version answer "postpone". Revisit all modules for which conflicts occurred. Carefully check the modules and solve the conflicts manually if necessary. Don't forget then, once the conflicts are resolved, to do "svn resolved myfile.f90" |
| | 13 | * Compile your code |
| | 14 | * Run the "open trusting" to test your modifications, see here [wiki:Documentation/UserGuide/Internal/OpenTrusting]. The open trusting will run a battery of tests including: |
| | 15 | * tests on at least one platform using MPI parallelism (except if only comments are changed). This means that the test include simulations with more than one processor. |
| | 16 | * tests for differences in results of the history files. The reason for a change in result must be known before the commit. If possible, avoid change in results except if it was the purpose. |
| | 17 | * Communicate and/or be aware of the latest news in the ORCHIDEE core team. For example a colleague announced that she/he will make a commit, better wait or ask if you could commit before. |
| | 18 | * Run a trusting where you switch off your changes (by using the flags you introduced). In this case the trusting should pass all the test as the model results should be identical to the current head of the trunk. If that is not the case, the remaining problems will need to be solved before proceeding. |
| | 19 | * If you pass the previous test, run the trusting but with your changes switched on. The trusting should still pass several best but because the may have results have changed it won’t be possible to pass all tests. Discuss the results with your supervisor to ensure all test that should be passed are indeed passed. |
| | 20 | * Prepare a text that describes the parameter settings and things which are good to know about this functionality. This text will be added to https://forge.ipsl.fr/orchidee/wiki/Documentation/TrunkFunctionality4 |
| | 21 | |
