-
Notifications
You must be signed in to change notification settings - Fork 299
Add a parameter object on the system, use it in derived classes #4007
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
Conversation
94329c3 to
38655d9
Compare
|
I like this, and I wouldn't scale it down, though I'm crossing my fingers hoping we aren't breaking any user subclasses that also thought |
6b546ae to
4d281ca
Compare
|
@roystgnr do you have thoughts on testing this? Do you want to rely on our use in MOOSE for testing? This will be used for new Convergence objects for each nonlinear system in a multi-system context. Or should there be an example? Or some other form of testing? |
|
Job Coverage, step Generate coverage on 95fec8c wanted to post the following: Coverage
Warnings
This comment will be updated on new commits. |
||||||||||||||||||||||||||
|
I hate relying on MOOSE tests for coverage, and IIRC we deliberately exclude MOOSE tests from our coverage stats for that reason. It's hard to come up with a good unit test here, but ... maybe set up a problem that should require a lot of linear iterations, but then set a system parameter that holds us to a tiny max number of iterations, and check the number of iterations reported after a |
3620605 to
5fb6732
Compare
|
I added a test that should show that parameters are read from the system rather than the equation system when both are present. It's not the best either because if we changed the name of the parameter of the system, the test would pass even through the change does nothing. |
|
ok made a little mistake. going to push it again soon |
730214d to
f3746dc
Compare
src/systems/implicit_system.C
Outdated
| return std::make_pair(this->get_equation_systems().parameters.get<unsigned int>("linear solver maximum iterations"), | ||
| this->get_equation_systems().parameters.get<Real>("linear solver tolerance")); | ||
| else | ||
| libmesh_error_msg("ERROR: Insufficient linear solver parameters"); |
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.
This isn't what we want to do, is it? If we override one parameter for a particular system, we should still just default to the EquationSystems parameter value for the other.
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.
ah that works.
I was thinking of forcing the user to be consistent between where each parameter comes from
it s probably more flexible this other way
src/systems/frequency_system.C
Outdated
| const Real tol = parameters.have_parameter<Real>("linear solver tolerance") ? | ||
| double(parameters.get<Real>("linear solver tolerance")) : | ||
| es.parameters.get<Real>("linear solver tolerance"); | ||
| const unsigned int maxits = | ||
| const unsigned int maxits = parameters.have_parameter<unsigned int>("linear solver maximum iterations") ? | ||
| parameters.get<unsigned int>("linear solver maximum iterations") : | ||
| es.parameters.get<unsigned int>("linear solver maximum iterations"); |
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.
As long as we have to change all these anyway, wouldn't auto [maxits, tol] = this->get_linear_solve_parameters(); work? We can't do that in EigenSystem because it doesn't inherit from ImplicitSystem, but it seems like it ought to work here, and in LinearImplicitSystem, and (albeit for just these two parameters) in NonlinearImplicitSystem.
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.
Changed it to that everywhere. It's a little trappy because get_linear_solve_parameter is already implemented in nonlinear implicit system, retrieving the values from attributes instead
tests/systems/systems_test.C
Outdated
|
|
||
| // We set the solution to be 1 everywhere, so the final l1 norm of the | ||
| // solution is the product of the number of variables and number of nodes. | ||
| Real ref_l1_norm = static_cast<Real>(mesh.n_nodes() * li_system.n_vars()); |
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.
Instead of using enough iterations to converge and then testing convergence, we should be using too few iterations to converge (so we stop at the max iteration count) and testing to make sure we're at the specified max iteration count.
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.
will do
7680964 to
329cfd4
Compare
|
We might be out of luck for the nonlinear test; that has no way to tell you the final step's linear iteration count, only the nonlinear iteration count. The linear test ought to be sufficient, except that you'll have to use |
6b51ba0 to
69f1be1
Compare
|
for the nonlienar system I kept my old test essentially, checking another parameter rather than num linear iterations |
69f1be1 to
02c160b
Compare
02c160b to
862bcb5
Compare
- centralize change in get_linear_solve_parameters - enable the test - use the number of iterations for the test
Simplify linear system parameter test
from the solver instead of parameters
|
@roystgnr when you have a minute. |
|
Awesome thanks for the review! |
|
Thanks for the extra ping; not sure how I missed the review request last week, but I'm glad I got this in time to squeeze it into the submodule update PR tonight. |
refs #4006
If this is too much, I could scale this down to just the nonlinear_implicit_system. That's all I need.
We could consider a getParam routine that does this 3-liner operation instead.