Some derived types and subroutines do not need marbl_ prefix

[mnlevy1981]

I think the convention for when to name something marbl_... should be limited to

1. All Fortran file names should have the marbl_ prefix

2. All public subroutines in marbl_XYZ_mod.F90 should have the marbl_XYZ_ prefix, which obviously includes the marbl_ prefix by definition

3. The datatypes of all public variables in marbl_interface_class should be marbl_..._type

   • For example a GCM might want a subroutine to process diagnostic output, and should be able to pass a marbl_diagnostics_type object

So the datatypes in marbl_interface_private_type.F90 are not meant to be accessible to the GCM (e.g. marbl_instance%PAR is private) and therefore do not need the marbl_ prefix.

Note that similar logic points towards dropping the marbl_ prefix from the following subroutines in marbl_mod.F90:

  private :: marbl_set_surface_particulate_terms
  private :: marbl_update_particulate_terms_from_prior_level
  private :: marbl_update_sinking_particle_from_prior_level
  private :: marbl_setup_local_tracers
  private :: marbl_consistency_check_autotrophs
  private :: marbl_compute_particulate_terms
  private :: marbl_compute_autotroph_elemental_ratios
  private :: marbl_compute_PAR
  private :: marbl_compute_carbonate_chemistry
  private :: marbl_compute_function_scaling
  private :: marbl_compute_Pprime
  private :: marbl_compute_Zprime