Child pages
  • Recent CLM4.5 Refactoring
Skip to end of metadata
Go to start of metadata

>>Terms of Use
>>Go BACK to previous page.

We have recently completed a number of significant code refactorings in the CLM 4_5 code base. You will only notice differences in the code if your starting point is prior to clm4_5_10 and you are merging to a recent tag. We strongly urge you to look over the source code in a CLM trunk tag that is at least as recent as clm4_5_36. Please feel free to contact us at with any questions and we will be happy to assist you.

Parameters in CLM 4_5

  • We are in the process of moving parameters and physical constants out of assignments in code to values stored in netcdf files. This makes our code easier to maintain and modify, but most importantly, allows users to do sensitivity analysis tests in an easier way. There are three points to our approach that are worth explaining by example:
    1. If a parameter is only used within one module, then that parameter is private to that module and read by a routine that is a part of that module.
      Private Parameters - example from CNAllocationMod.F90
    2. If a parameter is shared by more than one module, then it is placed in a module whose only purpose is to read that shared module.
      Shared Parameters - example from CNSharedParamsMod.F90 and CNDecompCascadeCNMod.F90
    3. The routines for both shared and private variables are called from readParamsMod.F90
      Reading parameters - readParamsMod.F90

Associate refactor

  • Please do not use pointers as arguments to a subroutine if that pointer is not placed in a associate block. Using an Associate Block removes one declaration for each pointer, makes the code easier to modify, makes the code more robust and sets us up for future interface refactorings. Refer also to the section above .
    Associate Refactor

Refactor clmtype

  • We have flattened the structure of clmtype so that most variables only require one dereference. You will immediately notice if you have used the old style as your code will not compile. An example is shown below.
    Refactor clmtype

Preprocessor macro removal

  • We are in the process of removing all preprocessor macros (CPP tokens) from the CLM code. Doing so will allow us to use one binary in all of our test suite and greatly speed up the development and testing process. There are two steps in the process:
    1. Remove most ifdef declarations from the code and replace with logical variables in main/controlMod.F90.
      Macro removal - Step 1
    2. The final portion of this work (which will be in an upcoming CLM tag), removes all of the remaining ifdefs and replaces this functionality via namelist variables.
      Macro removal - Step 2

The bounds type

  • The introduction of the bounds type cleans up CLM interfaces since we don't have to pass begc, endc, etc... explicitly. Currently, only the bounds type is passed and then members are de-referenced in a routine when you need to use them. If you don't want to use this
    you can place the following in an associate statement.
    Doing so may save you some refactoring work in the body of the subroutine or function you are working with.
    CLM without the bounds type
    CLM with the bounds type

Terms of Use

  • No labels