Skip to content

Conversation

@GiudGiud
Copy link
Contributor

@GiudGiud GiudGiud commented Nov 12, 2024

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.

@GiudGiud GiudGiud force-pushed the PR_nl_params branch 2 times, most recently from 94329c3 to 38655d9 Compare November 13, 2024 00:19
@roystgnr
Copy link
Member

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 parameters was a good name for a local variable.

@GiudGiud GiudGiud force-pushed the PR_nl_params branch 3 times, most recently from 6b546ae to 4d281ca Compare November 14, 2024 16:02
@GiudGiud
Copy link
Contributor Author

@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?

@moosebuild
Copy link

moosebuild commented Nov 14, 2024

Job Coverage, step Generate coverage on 95fec8c wanted to post the following:

Coverage

f2fd00 #4007 95fec8
Total Total +/- New
Rate 63.56% 63.56% -0.00% 44.26%
Hits 75603 75623 +20 54
Misses 43348 43360 +12 68

Diff coverage report

Full coverage report

Warnings

  • New new line coverage rate 44.26% is less than the suggested 90.0%

This comment will be updated on new commits.

@roystgnr
Copy link
Member

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 solve()? We can't assert that it's equal to our max iterations (unless we set max=1? that wouldn't be crazy) lest we break with -pc_type lu, but we can at least assert that it doesn't exceed our max iterations.

@GiudGiud GiudGiud force-pushed the PR_nl_params branch 3 times, most recently from 3620605 to 5fb6732 Compare November 15, 2024 01:33
@GiudGiud
Copy link
Contributor Author

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.
If we want 100% coverage we'll need a test for every system and every parameter?

@GiudGiud
Copy link
Contributor Author

ok made a little mistake. going to push it again soon

@GiudGiud
Copy link
Contributor Author

@roystgnr

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");
Copy link
Member

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.

Copy link
Contributor Author

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

Comment on lines 346 to 351
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");
Copy link
Member

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.

Copy link
Contributor Author

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


// 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());
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

will do

@roystgnr
Copy link
Member

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 5u instead of 5 there, because cppunit isn't clever enough to cope with tests that mix different types, even as obviously-mixable types as int and unsigned int.

@GiudGiud GiudGiud force-pushed the PR_nl_params branch 2 times, most recently from 6b51ba0 to 69f1be1 Compare November 27, 2024 22:00
@GiudGiud
Copy link
Contributor Author

for the nonlienar system I kept my old test essentially, checking another parameter rather than num linear iterations

@GiudGiud GiudGiud requested a review from roystgnr May 15, 2025 19:49
@GiudGiud
Copy link
Contributor Author

@roystgnr when you have a minute.
The plan after this is to have a NonlinearResidual convergence object in moose on a per system basis

@roystgnr roystgnr merged commit dcc1e1d into libMesh:devel May 21, 2025
20 checks passed
@GiudGiud GiudGiud deleted the PR_nl_params branch May 21, 2025 17:29
@GiudGiud
Copy link
Contributor Author

Awesome thanks for the review!

@roystgnr
Copy link
Member

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.

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.

3 participants