Difference between revisions of "Adding dH/dt module"

From Interactive System for Ice sheet Simulation
Jump to: navigation, search
Line 2: Line 2:
  
 
===Step 1 ===
 
===Step 1 ===
 +
 +
*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.
 
(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.
  

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.

(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.

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

(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 ...

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.