Hi Adriano,

Thanks for giving it a go. I took a quick crack at it myself (for about 5
mins) and it's not as trivial as PetscNonlinearSolver, it seems. (I didn't
encounter the error you did, but rather the solver made no progress on the
residual and therefore the line search died.)  I'm very sorry, but I'm just
exceptionally busy all of this week and won't be able to look at this until
next week. I've gone ahead and added libmesh-devel into the discussion in
case someone else has time to look at it before then.

Just FYI, I did try using PETSc 3.5.4 and PetscDiffSolver works fine with
no changes from libMesh master. So, if you can live with PETSC 3.5.4 for
the time being, that will get you going immediately. Sorry I can't be more
helpful this week.

Best,

Paul

On Tue, Mar 22, 2016 at 2:52 PM, Adriano Côrtes <adrimacor...@gmail.com>
wrote:

> Hi Paul,
>
> How are you? Hope this email finds you well.
> I tried to mimic the solution you pointed to me in Github, but it still
> not working properly. I am getting the error bellow:
>
> Solving time step 0, time = 0
> Assembling the residual
>   PetscDiffSolver step 0, |residual|_2 = 8.91374
> Assembling the Jacobian
> Assembling the residual
> Assertion `this->closed()' failed.
>
> Stack frames: 17
> 0: 0   libmesh_dbg.0.dylib                 0x000000010bc57959
> libMesh::print_trace(std::__1::basic_ostream<char,
> std::__1::char_traits<char> >&) + 2265
> 1: 1   libmesh_dbg.0.dylib                 0x000000010bc50370
> libMesh::MacroFunctions::report_error(char const*, int, char const*, char
> const*) + 592
> 2: 2   libmesh_dbg.0.dylib                 0x000000010c54f4cd
> libMesh::PetscVector<double>::zero() + 1613
> 3: 3   libmesh_dbg.0.dylib                 0x000000010c7dfdd5
> libMesh::FEMSystem::assembly(bool, bool, bool) + 1797
> 4: 4   libmesh_dbg.0.dylib                 0x000000010c73a97f
> __libmesh_petsc_diff_solver_residual + 1135
> 5: 5   libpetsc.3.6.dylib                  0x000000011063aa1d
> SNESComputeFunction + 3437
> 6: 6   libpetsc.3.6.dylib                  0x000000011071b150
> SNESLineSearchApply_BT + 6016
> 7: 7   libpetsc.3.6.dylib                  0x00000001107309a3
> SNESLineSearchApply + 2739
> 8: 8   libpetsc.3.6.dylib                  0x00000001106dc9df
> SNESSolve_NEWTONLS + 8543
> 9: 9   libpetsc.3.6.dylib                  0x000000011064bbed SNESSolve +
> 4861
> 10: 10  libmesh_dbg.0.dylib                 0x000000010c73bbc0
> libMesh::PetscDiffSolver::solve() + 592
> 11: 11  libmesh_dbg.0.dylib                 0x000000010c779106
> libMesh::UnsteadySolver::solve() + 86
> 12: 12  libmesh_dbg.0.dylib                 0x000000010c796693
> libMesh::DifferentiableSystem::solve() + 419
> 13: 13  libmesh_dbg.0.dylib                 0x000000010c7e21cf
> libMesh::FEMSystem::solve() + 31
> 14: 14  ex1                                 0x000000010ba1c1ee main + 8830
> 15: 15  libdyld.dylib                       0x00007fff8fe785c9 start + 1
> 16: 16  ???                                 0x0000000000000001 0x0 + 1
> [0] ./include/libmesh/petsc_vector.h, line 995, compiled Mar 15 2016 at
> 14:09:08
>
>
>  
> ------------------------------------------------------------------------------------------------------------------
> | Time:           Tue Mar 22 15:34:50 2016
>                                         |
> | OS:             Darwin
>                                         |
> | HostName:       Adrianos-MacBook-Pro.local
>                                         |
> | OS Release:     14.5.0
>                                         |
> | OS Version:     Darwin Kernel Version 14.5.0: Tue Sep  1 21:23:09 PDT
> 2015; root:xnu-2782.50.1~1/RELEASE_X86_64  |
> | Machine:        x86_64
>                                         |
> | Username:       cortesam
>                                         |
> | Configuration:  ../configure
>  '--prefix=/Users/cortesam/libmesh/petsc-3.6-g/install'
>         |
> |  '--with-vtk-include=/usr/local/opt/vtk/include/vtk-6.3'
>                                         |
> |  '--with-vtk-lib=/usr/local/opt/vtk/lib'
>                                         |
> |  '--with-hdf5=/usr/local/opt/hdf5'
>                                         |
> |  '--enable-perflog'
>                                          |
> |  'PETSC_DIR=/Users/cortesam/petsc-3.6'
>                                         |
> |  'PETSC_ARCH=arch-darwin-c-debug'
>                                          |
> |  'SLEPC_DIR=/Users/cortesam/slepc-3.6'
>                                         |
>
>  
> ------------------------------------------------------------------------------------------------------------------
>
>
> The error is in a instruction rhs->zero() that asserts for this->close().
> I am attaching to this email the code I am testing  (FEMSystem example 1)
> and the code petsc_diff_solver.C with the changes I made to try to fix the
> problem with the lock. I was not able to understand were the error is
> coming.
>
> Thank you.
> best regards,
> Adriano.
>
>
>
> 2016-03-16 17:30 GMT-03:00 Adriano Côrtes <adrimacor...@gmail.com>:
>
>> Thanks :):):) I will try it and let you know.
>> Another question that could help me a lot. I'm trying to get a picture of
>> how libmesh classes work together. For sure XCode and debug mode help a
>> ton... but just in case do you have a good diagram (not the ones generated
>> by doxygen) of how the classes are organized and with the most important
>> methods of each class? If not, do you recommend a good program that does it?
>>
>> Thank in advance for any help.
>> Best regards,
>> Adriano.
>>
>>
>> 2016-03-16 14:57 GMT-03:00 Paul T. Bauman <ptbau...@gmail.com>:
>>
>>>
>>> On Wed, Mar 16, 2016 at 1:48 PM, Adriano Côrtes <adrimacor...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Thanks again. Sorry but can you be I little bit more specific? What do
>>>> you mean by "The fix for this got put into the "primary" PETSc
>>>> classes" ?
>>>>
>>>
>>> This "locking" of PETSc vectors started happening in PETSc debug mode in
>>> version 3.6+. The "primary" PETSc classes I was referring to were things
>>> like PetscNonlinearSolver. The fix is in this commit:
>>>
>>>
>>> https://github.com/libMesh/libmesh/commit/45241afeaceb8c10562affb4fd1a189ecee98f58#diff-b3985fa832b099b796eaea1581eb1995
>>>
>>>
>>>> Is there a quick fix I could try here?
>>>>
>>>
>>> If you want to try applying the fix yourself to the petsc_diff_solver.C,
>>> go for it. It's basically mimicking some of the behavior in the commit
>>> above.
>>>
>>> Actually, could you send me your modified example? It would be very
>>> helpful for me to use it to construct the fix.
>>>
>>>
>>>> I know about GRINS, but I'd like to stick initially with plain Libmesh.
>>>>
>>>
>>> Sorry, that was aimed mostly at Roy; didn't mean to advertise or
>>> otherwise be pushy about GRINS. Of course, if you get interested in GRINS,
>>> I'm happy to chat about it.
>>>
>>>
>>>>
>>>> Best,
>>>> Adriano.
>>>>
>>>> p.s.: By the way, I started working in a project with Professor Alvaro
>>>> Coutinho (i think you know him)
>>>>
>>>
>>> Indeed!
>>>
>>>
>>>> that will use libmesh, so I guess I will exchange a lot of emails :):):)
>>>>
>>>
>>> Great!
>>>
>>>
>>>>
>>>> 2016-03-16 14:37 GMT-03:00 Paul T. Bauman <ptbau...@gmail.com>:
>>>>
>>>>> Hi Adriano,
>>>>>
>>>>> Thanks for reporting this. The fix for this got put into the "primary"
>>>>> PETSc classes, but not this one (again, this isn't exercised very much).
>>>>> I'll put in a fix.
>>>>>
>>>>> (As an aside: Hopefully in the next few days, I'll have an interface
>>>>> to this in GRINS so we can exercise this in some tests.)
>>>>>
>>>>> On Wed, Mar 16, 2016 at 1:33 PM, Adriano Côrtes <
>>>>> adrimacor...@gmail.com> wrote:
>>>>>
>>>>>> Dear Paul,
>>>>>>
>>>>>> Thank you for your reply. I tried what you told. It worked somehow,
>>>>>> that is, the diff_solver is changed to PetscDiffSolver, but Petsc gave 
>>>>>> the
>>>>>> error bellow:
>>>>>>
>>>>>> *Solving time step 0, time = 0*
>>>>>> *Assembling the residual*
>>>>>>
>>>>>> *[0]PETSC ERROR: --------------------- Error Message
>>>>>> --------------------------------------------------------------*
>>>>>> *[0]PETSC ERROR: Object is in wrong state*
>>>>>> *[0]PETSC ERROR:  Vec is locked read only, argument # 1*
>>>>>> *[0]PETSC ERROR: See
>>>>>> http://www.mcs.anl.gov/petsc/documentation/faq.html
>>>>>> <http://www.mcs.anl.gov/petsc/documentation/faq.html> for trouble 
>>>>>> shooting.*
>>>>>> *[0]PETSC ERROR: Petsc Release Version 3.6.3, unknown *
>>>>>> *[0]PETSC ERROR: ./example-opt on a arch-darwin-c-debug named
>>>>>> Adrianos-MacBook-Pro.local by cortesam Tue Mar 15 15:08:49 2016*
>>>>>> *[0]PETSC ERROR: Configure options --download-blacs --download-hypre
>>>>>> --download-metis --download-ml --download-mumps --download-superlu
>>>>>> --download-superlu_dist --download-ptscotch --download-pastix
>>>>>> --download-p4est --download-pardiso --download-parmetis
>>>>>> --download-scalapack --download-fblaslapack=1 --download-hdf5 
>>>>>> --with-opencl
>>>>>> --with-blacs=1 --with-debugging=yes --with-precision=double
>>>>>> --with-scalar-type=real --with-pcbddc=1 --with-shared-libraries=1
>>>>>> PETSC_ARCH=arch-darwin-c-debug*
>>>>>> *[0]PETSC ERROR: #1 VecGetArray() line 1646 in
>>>>>> /Users/cortesam/petsc-3.6/src/vec/vec/interface/rvector.c*
>>>>>> *[0]PETSC ERROR: #2 VecSetValues_MPI() line 908 in
>>>>>> /Users/cortesam/petsc-3.6/src/vec/vec/impls/mpi/pdvec.c*
>>>>>> *[0]PETSC ERROR: #3 VecSetValues() line 890 in
>>>>>> /Users/cortesam/petsc-3.6/src/vec/vec/interface/rvector.c*
>>>>>>
>>>>>>
>>>>>> I could find how the error appears, but do not know how to solve it.
>>>>>> Attached is a screenshot of my Xcode with the stack of functions call. 
>>>>>> The
>>>>>> problem as you can see above is that Vec is locked, that is, the lock
>>>>>> variable inside Vec is equal to 1, and by the screenshot you can see that
>>>>>> it happens inside the function *DofMap::enforce_constraints_exactly*
>>>>>>   What I realize debugging is that this function is called twice at
>>>>>> *PetscDiffSolver::solve().* The first time is here:
>>>>>>
>>>>>> 372: #ifdef LIBMESH_ENABLE_CONSTRAINTS
>>>>>> 373:  _system.get_dof_map().enforce_constraints_exactly(_system);
>>>>>> 374: #endif
>>>>>>
>>>>>> I checked and at this moment the Vec is not locked, that is, lock
>>>>>> variable is 0, so everything goes well. The second time it is called is
>>>>>>
>>>>>> 400: ierr = SNESSolve (_snes, PETSC_NULL, x.vec());
>>>>>>
>>>>>> But this time vec is locked, and I could not find where this variable
>>>>>> was set to 1.
>>>>>>
>>>>>> Any help?
>>>>>>
>>>>>> Thank you very much.
>>>>>> Best,
>>>>>> Adriano.
>>>>>>
>>>>>>
>>>>>> 2016-03-11 17:59 GMT-03:00 Paul T. Bauman <ptbau...@gmail.com>:
>>>>>>
>>>>>>> Hi Adriano,
>>>>>>>
>>>>>>> On Fri, Mar 11, 2016 at 1:49 PM, Adriano Côrtes <
>>>>>>> adrimacor...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Dear Roy,
>>>>>>>>
>>>>>>>> I discovered that the example 1 of FEMSystem (NS equation) uses
>>>>>>>> NewtonSolver, that is, _diff_solver in libMesh::TimeSolver points to
>>>>>>>> NewtonSolver. Where should I change the code to use
>>>>>>>> PetscDiffSolver? Is
>>>>>>>> there an example where I can take a look?
>>>>>>>>
>>>>>>>
>>>>>>> Unfortunately there's not an example (that I know of). But, what you
>>>>>>> can do is when the TimeSolver is first created (line 144 in the 
>>>>>>> unmodifeed
>>>>>>> fem_system_ex1.C), you can the the diff_solver() (
>>>>>>> http://libmesh.github.io/doxygen/classlibMesh_1_1TimeSolver.html#abaf790fa7f3fc464e6e607a9b914a753)
>>>>>>> and reset it to PetscDiffSolver: system.time_sover.diff_solver().reset( 
>>>>>>> new
>>>>>>> PetscDiffSolver(system) )
>>>>>>>
>>>>>>> Let us know if you have any trouble. I don't think anyone has hit
>>>>>>> PetscDiffSolver very hard, so please do let us know if anything peculiar
>>>>>>> pops up.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Adriano Côrtes
>>>>>> =================================================
>>>>>> Research assistant
>>>>>> High-performance Computing Center (NACAD)
>>>>>> Federal University of Rio de Janeiro (UFRJ)
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Adriano Côrtes
>>>> =================================================
>>>> Research assistant
>>>> High-performance Computing Center (NACAD)
>>>> Federal University of Rio de Janeiro (UFRJ)
>>>>
>>>
>>>
>>
>>
>> --
>> Adriano Côrtes
>> =================================================
>> Research assistant
>> High-performance Computing Center (NACAD)
>> Federal University of Rio de Janeiro (UFRJ)
>>
>
>
>
> --
> Adriano Côrtes
> =================================================
> Research assistant
> High-performance Computing Center (NACAD)
> Federal University of Rio de Janeiro (UFRJ)
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to