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

refactor(sfr): implement submodules for SFR flow methods #1896

Merged
merged 2 commits into from
Jun 25, 2024

Conversation

jdhughes-usgs
Copy link
Contributor

Checklist of items for pull request

  • Formatted new and modified Fortran source files with fprettify
  • Added doxygen comments to new and modified procedures
  • Updated meson files, makefiles, and Visual Studio project files for new source files
  • Removed checklist items not relevant to this pull request

For additional information see instructions for contributing and instructions for developing.

Copy link
Contributor

@langevin-usgs langevin-usgs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the submodules, and after reading about them, they do offer nice compiling benefits as well as better organization. I added a few annoying comments about naming in case we want to fine tune that a bit, but going with what's here now is also fine by me.

Since we are moving into submodules, we should probably add a section to the style guide under development in #1895 at some point.

!> @brief Method for solving for standard reaches
!!
!! Method to solve the continuity equation for a SFR package
!! reach using the standard approach.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this routine description correct? Seems like it should describe how we solve for constant stage reaches?

src/meson.build Outdated
@@ -162,6 +162,8 @@ modflow_sources = files(
'Model' / 'GroundWaterFlow' / 'gwf-uzf.f90',
'Model' / 'GroundWaterFlow' / 'gwf-vsc.f90',
'Model' / 'GroundWaterFlow' / 'gwf-wel.f90',
'Model' / 'GroundWaterFlow' / 'submodules' / 'sm-gwf-sfr-steady.f90',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these are already in a folder named submodules, do they need an "sm" prefix in the file name? Maybe we can drop the "sm"?

@@ -0,0 +1,305 @@
submodule(SfrModule) sm_gwf_sfr_steady
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just throwing this out there for discussion -- if the submodule is part of SfrModule, then does the submodule name need to include "gwf_sfr" in it? (as a separate note, we probably need to rename SfrModule to GwfSfrModule at some point to be consistent with other parts of the code).

In following with our other naming conventions, should the submodule name, then be SteadySubmodule since it by definition determined to part of gwf_sfr?

!!
!<
module subroutine sfr_calc_constant(this, n, d1, hgwf, qgwf, qd)
! -- dummy variables
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor annoying comment -- if we are ditching the "--" in comments, maybe start off fresh with these two new submodule files?

@jdhughes-usgs jdhughes-usgs merged commit 4a8f502 into MODFLOW-USGS:develop Jun 25, 2024
18 checks passed
@jdhughes-usgs jdhughes-usgs deleted the sfr-refactor branch June 25, 2024 21:18
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

Successfully merging this pull request may close these issues.

None yet

2 participants