Difference between revisions of "Adding dH/dt module"
| Line 1: | Line 1: | ||
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. | 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 === |
(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. | ||
| Line 59: | Line 59: | ||
end module fo_upwind_advect</source> | end module fo_upwind_advect</source> | ||
| + | |||
| + | '''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. | ||
Revision as of 10:55, 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
(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.
