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

Split up marbl_mod.F90 #86

Closed
mnlevy1981 opened this issue Jul 15, 2016 · 5 comments
Closed

Split up marbl_mod.F90 #86

mnlevy1981 opened this issue Jul 15, 2016 · 5 comments

Comments

@mnlevy1981
Copy link
Collaborator

marbl_mod.F90 could likely be refactored into

  1. marbl_surface_forcing_mod.F90
  2. marbl_interior_forcing_mod.F90
  3. marbl_setup_mod.F90 (for configuration and initialization routines)

This would be an aesthetic fix, making the code significantly more readable / navigable. It would likely not have an effect on the interface, so we can decide if we want to go down this path post MARBL 1.0.0.

@mnlevy1981
Copy link
Collaborator Author

Don't want _forcing in the module name

@mnlevy1981
Copy link
Collaborator Author

I have a branch where I split marbl_mod.F90 into marbl_surface_mod.F90, marbl_interior_mod.F90, and marbl_glo_avg_mod.F90. I still need to come up with better names for set_surface_forcing() and set_interior_forcing() -- I was thinking marbl_surface_fluxes_compute() and marbl_interior_tendencies_compute()? marbl_surface_compute_fluxes() and marbl_interior_compute_tendencies() is another option, though I don't really like splitting the phrases "surface fluxes" and "interior tendencies" like that.

Note that marbl_interior_mod.F90 also has marbl_set_global_scalars_interior(), which I could see naming marbl_interior_set_global_scalars() or I can move it into marbl_glo_avg_mod (marbl_glo_avg_set_interior_scalars()?). I haven't done that because the subroutine basically just calls adjust_bury_coeff(), which I think belongs in marbl_interior_mod.F90.

@mnlevy1981
Copy link
Collaborator Author

Now I'm leaning towards marbl_interior_compute_tendencies(). I think that works best with the other subroutines in interacts with -- on the interface, we'll have marbl_interface%compute_tendencies(), and for the carbon isotope tracers we'll have marbl_ciso_compute_tendencies(). Similarly, we can have marbl_surface_compute_fluxes(), marbl_interface%compute_fluxes(), and marbl_ciso_compute_fluxes().

Note that splitting marbl_mod introduces a discrepancy between how we treat the base tracers (split between marbl_surface_mod and marbl_interior_mod) and how we treat the carbon isotopes. Should marbl_ciso_mod be split into marbl_ciso_init_mod, marbl_ciso_surface_mod, and marbl_ciso_interior_mod?

@mnlevy1981
Copy link
Collaborator Author

After talking with @klindsay28 we decided that the verb should go last in all of these routines. So one more round of renaming, such thatmarbl_interface%surface_flux_compute() calls marbl_surface_flux_mod::marbl_surface_flux_compute(), which then calls marbl_ciso_surface_flux_mod::marbl_ciso_surface_flux_compute() (and similar for interior_tendency).

A couple of notes:

  1. I will also rename marbl_nhx_surface_emis_mod::marbl_comp_nhx_surface_emis() to marbl_nhx_surface_emis_compute()
  2. I'll open a new ticket for cleaning up marbl_co2calc_mod.F90 - I haven't looked closely, but that'll probably turn into marbl_co2_mod.F90 with a lot of marbl_co2_XYZ_compute() subroutines.

@mnlevy1981
Copy link
Collaborator Author

fixed by #308

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

No branches or pull requests

1 participant