Common Community Physics Package (CCPP)

Use Cases

This section includes information pertaining to how the CCPP can be used in practice. The following use cases assume that a collection of appropriate CCPP-compliant parameterizations exist and that a host application cap to the CCPP has been implemented, including population of the CCPP data structure with pointers to the host application data that is passed into physics.

Use of a full physics suite through the CCPP within an atmospheric model is accomplished by simply defining a SDF and ensuring that the filename path to it is passed into the ccpp_init() subroutine during the host application initialization stage. A SDF is quite flexible and can be configured to call physics in a number of different ways, whether all physics are called at once, split into multiple calls, or have some calls that are subcycled.

Invoke a full suite of physics in a full model

Consider the simplest case, in which all physics schemes are to be called together with no subcycling. The SDF would contain the following:



<?xml version="1.0" encoding="UTF-8"?>

  <suite name="Suite_A">
  <init>suite_a_initialize</init>
  <ipd part="1">
    <subcycle loop="1">
      <scheme>scheme_1</scheme>
      <scheme>scheme_2</scheme>
      <scheme>scheme_3</scheme>
    ...
      <scheme>scheme_n</scheme>
    </subcycle>
  </ipd>
</suite>


Note the syntax of the XML. The root is the suite with the name of the suite given as an attribute. Children of the suite are the init and ipd elements. The init element contains the name of the subroutine to call to set up the suite prior to time integration. Each ipd element corresponds to a division in the physics calls between which other computation can occur. They each have a part attribute that corresponds to the order in which the parts are called. Subcycles are children of the ipds using loop as an attribute. The value given for loop determines the number of times all of the schemes within the subcycle element are called. Finally, the scheme elements are children of the subcycle elements and are listed in order of their calls within the model.

The example given here names a suite Suite_A, calls suite_a_initialize before time integration, and calls schemes scheme_1 through scheme_n as one group of parameterizations without breaks for extraneous computation and without subcycling. Within the host application cap, the following loop would call all schemes in the suite:


   call ccpp_run ( cdata%suite%ipds(1),cdata, ierr)

Invoke a full suite of physics in a single column model

The procedure to invoke the CCPP is identical whether one uses a single-column model or a three-dimensional model. In fact, the modularity of the CCPP and the ability to use it without changes, is an inherent aspect of the CCPP design. Of course, a host application cap has to exist for any model (single-column or three-dimensional) to be usable with the CCPP.

Invoke a single process or set of process

This example considers the case in which a model requires that some physics be called as a group, followed by some extraneous computation before the rest of the physics is called. In this case, the rest of the physics is a single scheme. The SDF would make use of the ipd elements as follows:



<?xml version="1.0" encoding="UTF-8"?>

<suite name="Suite_B">
  <init>suite_a_initialize</init>
  <ipd part="1">
    <subcycle loop="1">
      <scheme>scheme_1</scheme>
      <scheme>scheme_2</scheme>
      ...
      <scheme>scheme_n-1</scheme>
    
    </subcycle>
  </ipd>
  <ipd part="2">
    <subcycle loop="1">  
      <scheme>scheme_n</scheme>
    </subcycle>
  </ipd>
</suite>


Of course, two calls would be needed within the host application cap:


call ccpp_run ( cdata%suite%ipds(1), cdata, ierr)

[some computation]

call ccpp_run ( cdata%suite%ipds(2), cdata, ierr)

Since the suite is named Suite_B, by default a shared library called libSuite_B.so needs to exist.

Invoke a set of processes using different frequency (subcycling for slow and fast physics)

Third, consider the case where a model requires that some subset of physics be called on a smaller time step than the rest of the physics, e.g. for computational stability. In this case, one would make use of the subcycle element as follows:



<?xml version="1.0" encoding="UTF-8"?>

<suite name="Suite_C">
  <init>suite_a_initialize</init>
  <ipd part="1">
    <subcycle loop="1">
      <scheme>scheme_1</scheme>
      <scheme>scheme_2</scheme>
    </subcycle>
  </ipd>
  <ipd part="2">
    <subcycle loop="2">  
<scheme>scheme_3</scheme>
    ...
      <scheme>scheme_n</scheme>
    </subcycle>
  </ipd>
</suite>


In order to call the schemes, two calls are needed as before:


call ccpp_run ( cdata%suite%ipds(1), cdata, ierr)

[some computation]

call ccpp_run ( cdata%suite%ipds(2), cdata, ierr)

Note that in the CCPP v1 code, the use of subcycling and its timestep is defined by manually coding it in the host application cap according to this example. In the future, the CCPP framework could provide an opportunity for physics developers to specify subcycling information as part of metadata of their physics schemes.


UCAR | Privacy Policy | Terms of Use