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

subramanya sadasiva potaman at outlook.com
Sun Jul 14 11:00:28 CDT 2013


I haven't been able to install valgrind on 10.8 . Subramanya 

From: karpeev at mcs.anl.gov
Date: Sun, 14 Jul 2013 10:58:25 -0500
Subject: Re: [petsc-users] [Libmesh-users] Really Really Really Weird SNES behaviour
To: codypermann at gmail.com
CC: potaman at outlook.com; libmesh-users at lists.sourceforge.net; petsc-users at mcs.anl.gov

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



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20130714/88ec9ce1/attachment.html>


More information about the petsc-users mailing list