-
Notifications
You must be signed in to change notification settings - Fork 91
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
A few solver messages rework #2783
Conversation
- added a few getDataContext() references where it was forgotten - removed some `` (it will be added later on DataContext::toString())
@@ -53,6 +53,11 @@ class SolverBase : public ExecutableGroup | |||
|
|||
static string catalogName() { return "SolverBase"; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rrsettgast should we remove all those base
catalogNames?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes...but we can do that in its own PR. We can also do some of what we talked about yesterday.
/** | ||
* @copydoc SolverBase::getCatalogName() | ||
*/ | ||
string getCatalogName() const override { return catalogName(); } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it be possible to avoid redefining that function for every solver?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. It is a virtual function, so it will give the right name when you ask for the name through a base pointer....unless there is a way to have a derived class override a virtual function without defining the override.
src/coreComponents/physicsSolvers/solidMechanics/SolidMechanicsLagrangianFEM.cpp
Outdated
Show resolved
Hide resolved
…gful-solver-class-name
…duce under the hood
…gful-solver-class-name
@MelReyCG please resolve conflicting files |
src/coreComponents/physicsSolvers/multiphysics/CompositionalMultiphaseReservoirAndWells.cpp
Outdated
Show resolved
Hide resolved
src/coreComponents/physicsSolvers/multiphysics/MultiphasePoromechanics.cpp
Outdated
Show resolved
Hide resolved
src/coreComponents/physicsSolvers/multiphysics/SinglePhasePoromechanics.cpp
Outdated
Show resolved
Hide resolved
src/coreComponents/physicsSolvers/multiphysics/SinglePhaseReservoirAndWells.cpp
Show resolved
Hide resolved
I took the last comments into account, is it good to go ? |
As long as the file conflict is resolved :) |
* aquifer production logging rewrite with unit fix * expose the final class name with getCatalogName() * Used final class where possible on solvers + - added a few getDataContext() references where it was forgotten - removed some `` (it will be added later on DataContext::toString()) * uncrustify * reformulation * removed some direct fmt references * Changed reduce() functions to Allreduce() where it is in fact a AllReduce under the hood * added MpiWrapper::reduce (to avoid unneeded Allreduce()) * replaced a message by a warning (because it is effectively) * replaced flux term by volume * compil fixes * Output names rather than data contexts at some places --------- Co-authored-by: Pavel Tomin <paveltomin@users.noreply.github.com>
This PR aims to rework some messages by:
using meaningful class names in log lines & errors instead of abstract class names (using the final class catalog name, as it is done in other places).
fixing the unit in use in the following log line:
FlowSolverBase compositionalMultiphaseFlow (aquifer.xml, l.28): at time 100s, the <Aquifer> boundary condition 'aquifer1' produces a flux of -0.6181975187076816 kg (or moles if useMass=0).
Our investigations showed that the output value is in
m³
.The proposed new formulation is:
Aquifer aquifer1 (aquifer.xml, l.226): at time 100s, the boundary condition produces a flux of -0.6181975187076816 m3.
remove some direct
fmt::format
reference in favor ofGEOS_FMT
.