All, 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 PETSC_ARCH setups.
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.. Vijay On Thu, Mar 3, 2011 at 10:28 AM, Boyce Griffith <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
