[petsc-users] [Libmesh-users] Really Really Really Weird SNES behaviour

Barry Smith bsmith at mcs.anl.gov
Sun Jul 14 12:29:51 CDT 2013


>> 
>> 
> I think it breaks down more on the C++ side.  I always get a ton of
> false positives.  Another point for C?  :)

   +1

> 
> Cody
> 
> 
>> Barry
>> 
>>> If you have an older OS, it's fine.
>>> 
>>> Sent from my iPhone
>>> 
>>> On Jul 14, 2013, at 9:59 AM, Dmitry Karpeyev <karpeev at mcs.anl.gov> wrote:
>>> 
>>>> Are there known problems with valgrind for macos?
>>>> I have it installed from macports and it seems to work fine.
>>>> Dmitry.
>>>> 
>>>> 
>>>> On Sun, Jul 14, 2013 at 7:26 AM, Cody Permann <codypermann at gmail.com> wrote:
>>>> Sounds like a memory corruption problem. I know several users that are
>>>> experts at writing code like that.
>>>> 
>>>> Unfortunately, it can be difficult to track down on OS X due to a lack
>>>> of working memory analysis tools.
>>>> 1. Since this problem popped up after you changed your initial
>>>> condition, you may just want to start by carefully looking at your
>>>> code and thinking about cases where your variables might not be
>>>> initialized, or where calculations could potentially produce underflow
>>>> or overflow conditions.
>>>> 2. If you have access to a Linux box, then you will have bounds
>>>> checked STL containers at your disposal in debug mode.  You'll also be
>>>> able to run your code through valgrind.  Both of those operations are
>>>> relatively easy to perform.  Let us know if you have any questions.
>>>> 
>>>> Cody
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On Jul 13, 2013, at 11:17 PM, subramanya sadasiva <potaman at outlook.com> wrote:
>>>> 
>>>>> Hi, I am observing some really really really weird SNES behavior in my SNESVI code called through Libmesh. This behaviour appeared after I changed some initial conditions and only happens in an optimized build. I am running this code on a Macbook pro running os x 10.8..
>>>>> When the debug code is run, the residuals computed for the initial conditions provided give norms which are of the expected magnitude.. so the SNES_Monitor output is,
>>>>> solving the cahn hilliard time step  0 SNES Function norm 8.223262421671e-01  1 SNES Function norm 3.793806858333e-03Nonlinear solve did not converge due to DIVERGED_MAX_IT iterations 1
>>>>> The output from SNES_Monitor with the optimized code on the other hand is,
>>>>> solving the cahn hilliard time step  0 SNES Function norm 5.153882032022e+19  1 SNES Function norm 1.446612980133e+19Nonlinear solve did not converge due to DIVERGED_MAX_IT iterations 1
>>>>> 
>>>>> Absolutely nothing else has changed in the code except that one code is built with a debugging and one with an optimized version of the code.
>>>>> Any ideas?Subramanya
>>>>> ------------------------------------------------------------------------------
>>>>> See everything from the browser to the database with AppDynamics
>>>>> Get end-to-end visibility with application monitoring from AppDynamics
>>>>> Isolate bottlenecks and diagnose root cause in seconds.
>>>>> Start your free trial of AppDynamics Pro today!
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Libmesh-users mailing list
>>>>> Libmesh-users at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>> 



More information about the petsc-users mailing list