-
Notifications
You must be signed in to change notification settings - Fork 285
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
Potential issue with PETSc 3.9 debug builds #1889
Comments
To reproduce the problem, you must configure PETSc with |
I will try to smooth MOOSE and libMesh with PETSc-3.9.4 |
I saw some similar issues before in MOOSE, and will try again |
Dammit. All my CIVET tests are using PETSc opt. It's a simple change to the module statement on my CIVET server to use PETSc dbg. I can turn that on when folks are ready. |
@pbauman is it possible for you to make an optional/attachable PETSc-debug recipe? That way we could attach it to a "test" PR and at least get some feedback without breaking all GRINS builds. I'm not sure exactly what your recipes look like, but you should be able to make an optional recipe by adding |
We have this on CIVET but not for PETSc 3.9 yet (we currently do MOOSE testing with PETSc 3.8.x). |
I was able to reproduce the failure using PETSc 3.9.4 configured with:
and SLEPc 3.9.2. The following was used to configure libmesh:
As far as I could tell nothing surprising occurred when running
Hopefully this is helpful. |
Thanks for this info @andfranklin, looks like the error is in the optimization solvers (TAO) stuff this time around and that does make sense... we have not gone in and fixed those like we have for the NonlinearSolver and DiffSolver classes. |
For reference, see also the related fixes in PetscDiffSolver (25154f3) and PetscNonlinearSolver (45241af). In this case the solution is probably to call
in the |
This should fix the error: Object is in wrong state Vec is locked read only, argument # 1 we currently get when running the libmesh examples using a PETSc built with --with-debugging=1. Refs libMesh#1889. See also: libMesh#1294, libMesh#630.
Fixed by #1898. |
I have a preliminary report from @andfranklin (no stack trace yet, unfortunately) that we are once again incorrectly accessing a locked PETSc vector in PETSc 3.9 from one of the libmesh examples, basically the same thing that was reported in #1294. The problem does not seem to be present in PETSc 3.8. I'll try to add more information to this ticket as it becomes available.
cc: @fdkong
The text was updated successfully, but these errors were encountered: