I am a vehement defender of reproducible code. It is not enough that it seems to work on Gadi with the Intel compiler. I think that one should try as much different compilers as possible. There should be at least the demand that CABLE gives the same results with the Intel and with the GNU compilers. I personally also use the NAG compiler because it is very picky and good to find errors or inconsistencies.
I understand that the average CABLE user/developper is not able to do that. But the code keepers such as you, Claire, or ACCESS-NRI should be able to do that and inform the developper. You can have a look, for example, at mc16 in offline/build.ksh of the branch CABLE-POP_TRENDY how I do it.
The code keepers should also check with different compiler flags such as for Intel: -fpp -O0 -debug extended -traceback -g -check all,noarg_temp_created -warn all -fp-stack-check -nofixed -assume byterecl -fp-model precise -diag-disable=10382,15009 -fpe0"
and even more -fpe-all=0 -no-ftz -ftrapuv -init=arrays,snan
Aidan
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
23
I just gave the examples for Emacs but you can do that in whatever editor you like.
fprettify is fine with me. But you should use a config file then because some of the defaults are pretty odd for me, e.g. look at the spaces at the beginning of example.f90
Aidan
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
25
You have made an excellent point. If there is a formatting standard it should be explicit and be able to be applied by anyone who wants to contribute code.
So the first step would be to propose a formatting standard and discuss it to make sure it is acceptable for the majority of the community.
clairecarouge
(Claire Carouge, ACCESS-NRI Land Modelling Team Lead)
26
Thanks Matthias and Aidan. I know the formatting is easy to fix. But it can be more challenging to ensure new contributions follow the standard. So automation during CI and explicitly stating the standards are critical.
We are currently in an effort to rewrite the documentation for CABLE, and part of that is to write the coding standards. We don’t have much choice as to the standards we adopt as they have to follow the UM coding standards. Unfortunately, these have never been published which means we have to write our own version of the same standards.
We will also have to go through a big effort to adapt the CABLE code to the UM coding standards past the formatting. We are doing this step by step as part of the project to integrate the CABLE science code in the JULES repository. We do not intend to do this faster as that allows us to think about all aspects of the code (formatting, standards, factorisation) so that they are compatible with CABLE and JULES at the same time.
So the work is underway and we just need more time to get all the pieces ready. In the meantime, I still think we can encourage developers to follow a minimal set of rules when submitting new code even if the legacy code makes it difficult/impossible to follow them to the letter.