Clean up of public interface of SolverBase
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 287
- Forks
- 109
- Avg merge
- 4d 41m
- Merged PRs (30d)
- 5
Description
@rrsettgast, @francoishamon, @castelletto1, @TotoGaz , @joshua-white, follwoing the infrastructure meeting, I have created a list of a few things that could be improved in the physics solvers interface. This issue expands what was already mentioned in https://github.com/GEOSX/GEOSX/issues/1653.
I have broken this down into a few different issues and I propose to use this one to keep track of all possible improvements.
-
Revisit the initialization step (https://github.com/GEOSX/GEOSX/issues/2178).
-
Centralize implementation of
solverStepand account for sequentail solvers (https://github.com/GEOSX/GEOSX/issues/2176) -
Functions specific to some physics solverts should be private but are not. This is, obviously, an easy thing to fix.
-
Some virtual functions in
SolverBaseprobably don't need to be virtual. I think we could check if we really need all solvers to be allowed to override certain functions (e.g.,solveLinearSystem,nonlinearImplicitStep,lineSearch).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the SolverBase interface and the linked issues 2178 and 2176, then inspect the public physics-specific functions and virtual methods named here. The issue provides no file paths or agreed final API; done would require a defined and coordinated cleanup across the solver implementations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- hpc
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100