Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MARBL reset module #85

Open
matt-long opened this issue Jul 14, 2016 · 5 comments
Open

MARBL reset module #85

matt-long opened this issue Jul 14, 2016 · 5 comments
Milestone

Comments

@matt-long
Copy link

In order to represent "preformed" tracers, we need a tracer reset capability, which will likely entail a new MARBL interface.

@matt-long matt-long added this to the Post-MARBL1.0.0 milestone Jul 14, 2016
@mnlevy1981
Copy link
Collaborator

There are efficiency concerns with copying the full tracer arrays in and out of MARBL un-necessarily.

@mnlevy1981
Copy link
Collaborator

Idea would be that preformed tracers have no source / sink term, and every timestep the surface value is reset to match the non-preformed version of the same tracer.

@mnlevy1981
Copy link
Collaborator

@matt-long and @kristenkrumhardt -- I think this will be a fairly trivial feature to implement. It will require a marbl_preformed_init_mod.F90 module to set the tracer metadata, but since we set surface_fluxes = 0 and interior_tendencies = 0 at the beginning of surface_flux_compute() and interior_tendency_compute(), respectively, I don't think we would need marbl_preformed_surface_flux_mod.F90 or marbl_preformed_interior_tendency_mod.F90.

Also, it doesn't seem like we would need any preformed-specific diagnostics because we would just rely on the GCM's tracer diags. So we need a place in the code to reset the preformed surface values, but that's it. (There will also be some infrastructure work, but I think that's mostly introducing a preformed_on setting with a default of .false. and updating marbl_tracer_index_type)

Anyway, I think a day or two would be plenty of time to get it up and running, with maybe another half-day to run sanity checks and look at output. What's the timeline for this experiment? I definitely want to wait until we bring in #330 (later this week if all goes well) but I can spend a few days working on this before finishing #156.

@mnlevy1981
Copy link
Collaborator

Oh, I forgot to ask the big question: which tracers will have preformed counterparts? All the tracers are listed in the indexing type:

  type, public :: marbl_tracer_index_type
    ! Book-keeping (tracer count and index ranges)
    integer (int_kind) :: total_cnt = 0
    type (marbl_tracer_count_type) :: ecosys_base
    type (marbl_tracer_count_type) :: ciso

    ! General tracers
    integer (int_kind) :: po4_ind         = 0 ! dissolved inorganic phosphate
    integer (int_kind) :: no3_ind         = 0 ! dissolved inorganic nitrate
    integer (int_kind) :: sio3_ind        = 0 ! dissolved inorganic silicate
    integer (int_kind) :: nh4_ind         = 0 ! dissolved ammonia
    integer (int_kind) :: fe_ind          = 0 ! dissolved inorganic iron
    integer (int_kind) :: lig_ind         = 0 ! Fe-binding Ligand
    integer (int_kind) :: o2_ind          = 0 ! dissolved oxygen
    integer (int_kind) :: dic_ind         = 0 ! dissolved inorganic carbon
    integer (int_kind) :: dic_alt_co2_ind = 0 ! dissolved inorganic carbon with alternative CO2
    integer (int_kind) :: alk_ind         = 0 ! alkalinity
    integer (int_kind) :: alk_alt_co2_ind = 0 ! alkalinity with alternative CO2
    integer (int_kind) :: doc_ind         = 0 ! dissolved organic carbon
    integer (int_kind) :: don_ind         = 0 ! dissolved organic nitrogen
    integer (int_kind) :: dop_ind         = 0 ! dissolved organic phosphorus
    integer (int_kind) :: dopr_ind        = 0 ! refractory DOP
    integer (int_kind) :: donr_ind        = 0 ! refractory DON
    integer (int_kind) :: docr_ind        = 0 ! refractory DOC

    ! CISO tracers
    integer (int_kind) :: di13c_ind       = 0 ! dissolved inorganic carbon 13
    integer (int_kind) :: do13ctot_ind    = 0 ! dissolved organic carbon 13 (semi-labile+refractory)
    integer (int_kind) :: di14c_ind       = 0 ! dissolved inorganic carbon 14
    integer (int_kind) :: do14ctot_ind    = 0 ! dissolved organic carbon 14 (semi-labile+refractory)

    ! Living tracers
    type(marbl_living_tracer_index_type), allocatable :: auto_inds(:)
    type(marbl_living_tracer_index_type), allocatable :: zoo_inds(:)
    ! For CISO, don't want individual C13 and C14 tracers for each zooplankton
    ! Instead we collect them into one tracer for each isotope, regardless of
    ! zooplankton_cnt
    integer (int_kind) :: zootot13C_ind   = 0 ! total zooplankton carbon 13
    integer (int_kind) :: zootot14C_ind   = 0 ! total zooplankton carbon 14

  contains
    procedure, public :: add_tracer_index
    procedure, public :: construct => tracer_index_constructor
    procedure, public :: destruct => tracer_index_destructor
  end type marbl_tracer_index_type

Would the general tracers all have preformed copies as well? And would we do the same for the isotopic tracers if a user runs with both ciso_on = .true. and preformed_on = .true?

@mnlevy1981
Copy link
Collaborator

@klindsay28 pointed out that POP already has a reset function for passive tracers that we want to take advantage of, so instead of shoehorning the reset into interior_tendency_compute(), we really need a new marbl_instance%reset() stage. (That will require updating the documentation and the stand-alone driver.)

Other design details that came up:

  • a new derived setting named reset_required (that at the moment will be equal to preformed_on, but if we add new_tracer_module_on that also makes use of the reset stage then reset_required would reflect that)
  • marbl_instance%reset() will return immediately if reset_required is .false.
  • POP should use get_settings('reset_required') to determine if it should even call marbl_instance%reset() (and avoid the overhead of copying tracer data if it's not needed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants