Adding dH/dt 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
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.
- Add these new modules to the build by altering the file Makefile.am ...
libglide_a_SOURCES = glide.F90 glide_setup.F90 glide_types.F90 glide_temp.F90 \ glide_bwater.F90 glide_deriv.F90 xls.F90 ice3d_lib.F90 \ glide_velo_higher.F90 glide_thck.F90 glide_velo.F90 \ glide_mask.F90 glide_stop.F90 glide_io.F90 \ glide_nc_custom.F90 isostasy.F90 isostasy_el.F90\ isostasy_setup.F90 isostasy_types.F90 glide_lithot.F90\ glide_lithot3d.F90 glide_lithot1d.F90 glide_profile.F90\ glide_diagnostics.F90 glissade.F90 glissade_remap.F90\ glissade_velo.F90 glissade_constants.F90 glide_vertint.F90\ glide_thckmask.F90 glide_nonlin.F90 glide_grids.F90\ glam.F90 glam_strs2.F90 glam_thck_ppm.F90\ remap_advection.F90 remap_glamutils.F90 glide_ground.F90
becomes ...
libglide_a_SOURCES = glide.F90 glide_setup.F90 glide_types.F90 glide_temp.F90 \ glide_bwater.F90 glide_deriv.F90 xls.F90 ice3d_lib.F90 \ glide_velo_higher.F90 glide_thck.F90 glide_velo.F90 \ glide_mask.F90 glide_stop.F90 glide_io.F90 \ glide_nc_custom.F90 isostasy.F90 isostasy_el.F90\ isostasy_setup.F90 isostasy_types.F90 glide_lithot.F90\ glide_lithot3d.F90 glide_lithot1d.F90 glide_profile.F90\ glide_diagnostics.F90 glissade.F90 glissade_remap.F90\ glissade_velo.F90 glissade_constants.F90 glide_vertint.F90\ glide_thckmask.F90 glide_nonlin.F90 glide_grids.F90\ glam.F90 glam_strs2.F90 glam_thck_ppm.F90\ remap_advection.F90 remap_glamutils.F90 glide_ground.F90 \ ! CHANGED LAST TWO LINES fo_upwind_advect_mod.F90, fo_upwind_advect.F90