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

[Cody P. <cod...@gm...>]

Sent from my evil iPad

On Jul 14, 2013, at 10:13 AM, Barry Smith <bs...@mc...> wrote:

>
> On Jul 14, 2013, at 11:00 AM, Cody Permann <cod...@gm...> wrote:
>
>> It's not guaranteed to work on 10.8 and above.
>
>    It prints a message saying it is not guaranteed to work, but I use it and it seems to work. It certainly finds "some" problems and doesn't "seem" to find problems that are not there. So, maybe not perfect but still helpful, much better than not using it.
>
>
I think it breaks down more on the C++ side.  I always get a ton of
false positives.  Another point for C?  :)

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 <ka...@mc...> 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 <cod...@gm...> 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 <po...@ou...> 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
>>>> Lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>