Difference between revisions of "Adding dH/dt module"

From Interactive System for Ice sheet Simulation
Jump to: navigation, search
Line 3: Line 3:
 
===Step 1 ===
 
===Step 1 ===
  
*In step 1, we will create modules containing "empty" subroutines and add these modules to the build.
+
In step 1, we will create modules containing "empty" subroutines and add these modules to the build.
  
(i) Create a module '''for_upwind_advect_mod.F90''' that contains the necessary subroutines. For now, these will just be "stubs", which we will fill in later.
+
* Create a module '''for_upwind_advect_mod.F90''' that contains the necessary subroutines. For now, these will just be "stubs", which we will fill in later.
  
 
<source lang=fortran>module fo_upwind_advect_mod
 
<source lang=fortran>module fo_upwind_advect_mod
Line 41: Line 41:
 
end module fo_upwind_advect_mod</source>
 
end module fo_upwind_advect_mod</source>
  
(ii) create another module '''for_upwind_advect.F90''' that will contain the "driver" subroutine - that which is called from the main code, which in this case is '''glide.F90''' ...
+
* Create another module '''for_upwind_advect.F90''' that will contain the "driver" subroutine - that which is called from the main code, which in this case is '''glide.F90''' ...
  
 
<source lang=fortran>module fo_upwind_advect
 
<source lang=fortran>module fo_upwind_advect

Revision as of 10:57, 22 July 2009

This page contains step-by-step instructions for adding a new module to Glimmer-CISM. In this case, the module is a first-order, upwinding advection scheme for mass transport (dH/dt) using velocities calculated from a higher-order dynamics model. The procedure, however, is generic and could apply to adding almost any module.

Step 1

In step 1, we will create modules containing "empty" subroutines and add these modules to the build.

  • Create a module for_upwind_advect_mod.F90 that contains the necessary subroutines. For now, these will just be "stubs", which we will fill in later.
module fo_upwind_advect_mod
 
! subroutines for mass advection scheme based on 1st order upwinding
 
    contains
 
!----------------------------------------------------------------------
 
    subroutine fo_upwind_advect_init( )
 
    ! initialization for 1st-order upwinding mass advection
 
    end subroutine fo_upwind_advect_init
 
!----------------------------------------------------------------------
 
    subroutine fo_upwind_advect_final( )
 
    ! finalization for 1st-order upwinding mass advection
 
    end subroutine fo_upwind_advect_final
 
!----------------------------------------------------------------------
 
    subroutine fo_upwind_advect_main( )
 
    ! 1st-order upwinding mass advection
 
    end subroutine fo_upwind_advect_main
 
!----------------------------------------------------------------------
 
end module fo_upwind_advect_mod
  • Create another module for_upwind_advect.F90 that will contain the "driver" subroutine - that which is called from the main code, which in this case is glide.F90 ...
module fo_upwind_advect
 
    ! this is the driver routine for the 1st order, upwind mass transport scheme
 
    use fo_upwind_advect_mod, only : fo_upwind_advect_main
 
    implicit none
    private
    public :: fo_upwind_advect_driver
 
    contains
 
    subroutine fo_upwind_advect_driver( )
 
        call fo_upwind_advect_main( )
 
    end subroutine fo_upwind_advect_driver
 
end module fo_upwind_advect

NOTE: This may seem like extra work ... why don't we just call the subroutine fo_upwind_advect_main directly from the main code? In this case, perhaps this is true. In general, however, having a "driver" routine is good practice. For example, there might be additional pre/post processing of variables that needs to take place before and after the call to the subroutine fo_upwind_advect_main. Making space for that here rather than in the main program, where only the driver is called, makes more sense and keeps the main code cleaner and easier to understand.