I have had to debug petsc, slepc code in the past and it helps me to
have this available along-side the optimized versions. But I do
understand that when you are working using the libMesh wrappers,
debugging petsc seems unnecessary. I see that the general consensus is
to have two separate builds for libMesh configured with the different
While changing just the environment variable, I had to comment out the
PETSC_DIR, PETSC_ARCH lines in make.common and then recompile my code
that sits on top of libMesh. This linked with the correct libraries
without any errors. Also, I have to mention that all of the libraries
are statically linked. The final executable actually runs without any
issues and I checked the configure options with -log_summary to make
sure it was using the optimized petsc build. Note: I did not recompile
libMesh after changing the PETSC_ARCH option. I also compared the
timings of the runs with-debugging and the optimized Petsc and they of
course show improvement on the order of 4.
I am not sure whether my code compiled and linked because of the
libraries are static or that the only change between the different
PETSC_ARCH builds is the --with-debugging parameter. I do not have an
installation available currently to test this on a shared library
setting for Petsc, Slepc, LibMesh. If someone has the time and can
check this also, I'd be very interested in it.
I also like Boyce's suggestion about using different PETSC_ARCH for
say METHOD=opt,dbg builds. This could provide on-the-fly changes that
is consistent with the configure options. It also makes the configure
options a little complicated because now Make.common is tied to the
METHOD variable. Not sure what is the way forward here..
On Thu, Mar 3, 2011 at 10:28 AM, Boyce Griffith <griffith@...> wrote:
> On 3/3/11 11:15 AM, Roy Stogner wrote:
>> On Thu, 3 Mar 2011, Boyce Griffith wrote:
>>> Because I think it is in general hard to detect robustly whether you
>>> can "safely" switch between PETSC_ARCH'es without doing a full
>>> recompilation, a nice compromise might be to be able to associate
>>> different PETSC_DIR/PETSC_ARCH values with different libMesh build
>>> modes. At least, this a feature that I would use.
>> In general this is starting to sound like the "buildroot" support I've
>> been quite impressed by in a few of my group's application codes:
>> "mkdir opt && cd opt && ../configure --with-opt-stuff && make && cd .."
>> "mkdir debug && cd debug && ../configure --with-debug-stuff && make"
> You also can easily do these sorts of" VPATH" builds with
> Autoconf/Automake-based build systems. But, as I'm sure you already
> know, everyone hates Autoconf/Automake. ;-)
> This might be a dopey suggestion, but, sticking with the current build
> system, what if PETSC_DIR/PETSC_ARCH were not hardcoded, but if instead
> the values of PETSC_DIR/PETSC_ARCH were cached in some configuration
> file the first time that make is invoked with a particular build METHOD.
> In subsequent invocations with that same METHOD, if the cached values
> to not match the current settings for these environment variables, then
> either a warning or an error message is emitted.
> -- Boyce
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> Libmesh-users mailing list