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 bui
On 3/3/11 10:44 AM, Roy Stogner wrote:
>
> On Thu, 3 Mar 2011, John Peterson wrote:
>
>> I confess that even with dbg builds of libmesh, I use the optimized
>> PETSc libraries... therefore the PETSC_ARCH and PETSC_DIR that gets
>> set at configure time is truly constant in my builds. One reason f
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
>>
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 dif
On Thu, 3 Mar 2011, John Peterson wrote:
> I confess that even with dbg builds of libmesh, I use the optimized
> PETSc libraries... therefore the PETSC_ARCH and PETSC_DIR that gets
> set at configure time is truly constant in my builds. One reason for
> this is that even optimized PETSc builds ha
On Mon, Feb 28, 2011 at 3:47 PM, Vijay S. Mahadevan wrote:
> Hi all,
>
> While using libMesh configured with Petsc using both debug and
> optimized versions (by means of different PETSC_ARCH variables), will
> it not be easier to take the PETSC_DIR and PETSC_ARCH information from
> the environment
Hi all,
While using libMesh configured with Petsc using both debug and
optimized versions (by means of different PETSC_ARCH variables), will
it not be easier to take the PETSC_DIR and PETSC_ARCH information from
the environment configuration of the shell directly instead of
hard-coding this in Mak