Guidelines and help to commit on the trunk (or a branch)

Author: J. Ghattas
Last revision: 2024/05/18, S. Luyssaert

Here are some general guidelines for committing into the trunk ORCHIDEE. These recommendations can also be applied to branches and other versions under SVN control.

Before commit:

• Carefully document your code and parameters. Explain the principles used, cite the papers that were used as a source of inspiration.
• The code must be conform to the ORCHIDEE coding guidelines (Documentation/UserGuide/CodingGuidelines)
• 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.
• 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"
• Compile your code
• Run the "open trusting" to test your modifications, see here Documentation/UserGuide/Internal/OpenTrusting. The open trusting will run a battery of tests including:
  • 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.
  • 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.
  • 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.
• 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.
• 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.
• 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

Some cases must be discussed in advance:

• if the behavior of the model change. For example: change in parameter name in getin function, change in default value for some parameters, etc..
• if the interface towards the atmosphere is changed
• structural modifications

During commit:

• a commit should only resolve one problem at a time, related to one ticket.
• write a useful log message in English
• Within this log message, use #X to refer to the ticket number X (the # will make a link directly to the ticket when visualizing the log message on the web). Use [Y] to refer to another commit number Y.

After commit:

• tell the project group if the results changed even for tiny changes. A new reference simulation must then be run in the ​trusting.
• if related to a ticket, add a link to the commit in the ticket using [Y], where Y is the revision number on the commit. Close the ticket if all questions are treated.
• if the trusting fails after commit, the commit should be reverted if a correction could not be done directly.