Programming of CESM-CAM5

[rajkmsaini]

Hello CESM users/Team,

I'm a beginner in CESM-CAM, I want your recommendations so I can learn in detail of the programing of CAM.

--- programming guide of CAM.

Thank you in advance.

Best regards,
Dr. Raj
IIT Bombay/ IIT Delhi (INDIA)

 

[nusbaume]

Hi Raj

Apologies for the late reply! There isn't really a programming guide per se, but we do have a general set of rules for the fortran code which is used by the software engineers. Those rules are:

-----------------------

MUST

• No naked use statements
• No continued single-line if statements (i.e., all if statements should have a "then" if the statement is on more than one line)
• Every namelist variable in each active namelist group is present in the namelist file. An active namelist group is one which may be read during the current run.
• All namelist variables except for logical quantities are initialized to invalid values (integer: -HUGE(1), real: Nan, character: 'UNSET').
• Do not combine statements on a single line (i.e., avoid use of the semi-colon to combine statements).
• Use intent for dummy arguments except for pointers.
• Functions may not have side effects.
• No trailing spaces
• All variables of type real must have a specified kind, including literals. For example, use 1.5_r8, not 1.5 or 1.5D0.

SHOULD

• Avoid use of preprocessor directives (e.g., #if, #ifdef). Always try for runtime variable logic instead.
• Keep formula statements relatively short. Use temporary variables to break long formulas into easier-to-read sections.
• Use subroutines to avoid repeated (cut and paste) code logic.
• Avoid side effects in subroutines. Pass variables to routines instead of 'using' them from elsewhere.
• Use comments to explain what you are doing (logic). When working with code, always check the comments to make sure they are still correct and useful.
• Do not use comments to "save code for later in case it might be useful".
• List dummy arguments one per line, however, related items may be grouped.
• Dummy argument order should match the order in the argument list.
• Use symbolic numerical comparison operators (e.g., ==, /=, <, >=) not old character versions (e.g., ".eq.").
• Avoid the use of pointers as dummy arguments (exceptions must be discussed in design or code review)

Indentation and Style

• Scoping: Indentation should follow scope. That is, whenever entering a new scope (e.g., module, subroutine, if, do), indent that scope relative to the scoping statement (recommended 3 spaces but each module should at least be self consistent).
• Continue lines: Indent continue lines 5 spaces or align with similar lines in statement.
• Use spaces to ease reading statements (e.g., before and after operators, after commas except in a dimensions list)
• Include a space after "if", "else", "end", "do", and "while".
• Include a space before and after " :: "
• No space after only, i.e., "only:", not "only :".
• When aligning code for readability, commas go immediately after a symbol (no space).

-----------------------

Also, please note that CESM1-CAM5 is no longer under active development, but if you end up working with CESM2-CAM6 and find a bug, or would like to add your code additions to the main code base, then simply follow the instructions found here:

https://github.com/NCAR/CAM/wiki/CAM-Development-Workflow-in-GitHub

Specifically, make sure that you create an issue first that can be validated by someone at NCAR before making a pull request. Otherwise your pull request may be rejected.

Anyways, I hope that helps, and if you have any specific questions about programming in CAM then feel free to make another post on this forum (which will hopefully be responded to more quickly).

Thanks, and have a great day!

Jesse