September 2007 - petsc-dev - mailman3.cels.anl.gov

Re: PetscTryMethod and PetscUseMethod
by Barry Smith 15 Sep '07

15 Sep '07

Lisandro, I think it is fine to remove the use of the #. It got it there during the evolution of those macros. Barry On Sat, 15 Sep 2007, Lisandro Dalcin wrote: > PetscTryMethod(obj,A,B,C) and PetscUseMethod(obj,A,B,C) macros are not > consistent regarding parameter 'A', the first expand it to '#A' and de > second do not. > > Should this be fixed? Which version do you want? I'm personally > inclined to the second (that is, no 'stingize', as looks a bit more > explicit in code) > > Regards, > >

1 0

PetscTryMethod and PetscUseMethod
by Lisandro Dalcin 15 Sep '07

15 Sep '07

PetscTryMethod(obj,A,B,C) and PetscUseMethod(obj,A,B,C) macros are not consistent regarding parameter 'A', the first expand it to '#A' and de second do not. Should this be fixed? Which version do you want? I'm personally inclined to the second (that is, no 'stingize', as looks a bit more explicit in code) Regards, -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: [Invitation] Tenative Access Grid PETSc Tutorial @ Mon Oct 29, 2007 ()
by Matthew Knepley 11 Sep '07

11 Sep '07

This sounds fine for me. Matt On 9/11/07, Lorena Barba <l.a.barba(a)bristol.ac.uk> wrote: > hi Matt, > > I'm writing to confirm the Access Grrid PETSc seminar -- we had > tentatively scheduled it for 29 October. Is this still good? > > There is a lot of interest here! > Lorena. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~ > Lorena Barba > Department of Mathematics > University of Bristol > <http://www.maths.bris.ac.uk/people/faculty/aelab/> > <http://www.scat-alfa.eu> > > > > > On 13 Aug 2007, at 18:07, Matthew Knepley wrote: > > <mime-attachment.ics> > <invite.ics> > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: skip c++ mpi in petsc.h
by Lisandro Dalcin 10 Sep '07

10 Sep '07

MPICH2, at least 1.0.5, has a more specific way to ignore the SEEK_* issue. What PETSc is currently doing is just completelly skipping the #include of MPI C++ bindings. In OpenMPI, they try hard to solve this issue and not just generate an error like MPICH2, however, compilation time is (about 4x) increased as they have to include <iostream>. I believe doing #define MPICH_SKIP_MPICXX #define OMPI_SKIP_MPICXX #include <mpi.h> Should always work and then PETSc follows the same path for both MPI's. Of course, if users want to use C++ bindings, then they have to #include <mpi.h> before #include <petsc.h>, but it's up to them to solve the issues with MPICH2. On 9/10/07, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Actually it is the MPI standard and C++ namespaces etc that cause > tis funny problem, MPICH just picked a particular work-around. > I do not know what work around, if any, OpenMPI used. > > Barry > > > On Mon, 10 Sep 2007, Matthew Knepley wrote: > > > Not sure. This only happens because MPICH does funny things with SEEK_SET. > > > > Matt > > > > On 9/10/07, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > > > We currently do the following in petsc.h > > > > > > #define MPICH_SKIP_MPICXX 1 > > > #include "mpi.h" > > > > > > Should do the same for OpenMPI ? > > > > > > > > > -- > > > Lisandro Dalcï¿½n > > > --------------- > > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > > Tel/Fax: +54-(0)342-451.1594 > > > > > > > > > > > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: skip c++ mpi in petsc.h
by Barry Smith 10 Sep '07

10 Sep '07

Actually it is the MPI standard and C++ namespaces etc that cause tis funny problem, MPICH just picked a particular work-around. I do not know what work around, if any, OpenMPI used. Barry On Mon, 10 Sep 2007, Matthew Knepley wrote: > Not sure. This only happens because MPICH does funny things with SEEK_SET. > > Matt > > On 9/10/07, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > > We currently do the following in petsc.h > > > > #define MPICH_SKIP_MPICXX 1 > > #include "mpi.h" > > > > Should do the same for OpenMPI ? > > > > > > -- > > Lisandro Dalcín > > --------------- > > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) > > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) > > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) > > PTLC - Güemes 3450, (3000) Santa Fe, Argentina > > Tel/Fax: +54-(0)342-451.1594 > > > > > > >

1 0

Re: skip c++ mpi in petsc.h
by Matthew Knepley 10 Sep '07

10 Sep '07

Not sure. This only happens because MPICH does funny things with SEEK_SET. Matt On 9/10/07, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > We currently do the following in petsc.h > > #define MPICH_SKIP_MPICXX 1 > #include "mpi.h" > > Should do the same for OpenMPI ? > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

skip c++ mpi in petsc.h
by Lisandro Dalcin 10 Sep '07

10 Sep '07

We currently do the following in petsc.h #define MPICH_SKIP_MPICXX 1 #include "mpi.h" Should do the same for OpenMPI ? -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

testexamples failing
by Lisandro Dalcin 05 Sep '07

05 Sep '07

Matt, I was able to build petsc-dev after you corrections, but now 'make testexamples' is failing in 'src/ksp/ksp/examples/tutorials', ex22, ex25 and ex32. Could you please verify this? I do not want to push my changes to SNES until all petsc-dev tests are passing. Thanks, -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

cannot build petsc-dev with C
by Lisandro Dalcin 05 Sep '07

05 Sep '07

Matt, petsc-dev seems to be broken for building with C. Could this be your recent addition of 'meshmgsnes.c' ?? -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: changes to SNES
by Barry Smith 04 Sep '07

04 Sep '07

On Tue, 4 Sep 2007, Lisandro Dalcin wrote: > On 9/4/07, Matthew Knepley <knepley(a)gmail.com> wrote: > > If we want to change from he existing scheme, why not replicate it with > > calls to VecPlaceArray()? > > Because this can interact bad with user code? Nested calls currently > generate an error. Isn't all this a case of premature optimization?. > > I'm inclined to think that two vec copies are not expensive compared > with computing actual functions/jacobians, solving linear systems > (perhaps next doing line search/ trust region), and even computing > VecNorm's in many places. Does this reasoning make sense? Lisandro One concern is that naive people "benchmark" by running trivial problems, then copies can have impact. If the code passes all tests, testexamples_C, testexamples_xxxx,.... then I am fine with you pushing the simplier code. Barry > > > > > > Matt > > > > > BTW, I'm also getting rid of the SNESConverged_{LS|TR}. The inner > > > trust region tolerance convergence test is done inside the inner trust > > > region loop in SNESSolve_TR. The only two convergence tests provided > > > by PETSc will be SNES{Default|Skip}Converged(), the > > > 'snes-ops-converged' pointer will never be NULL now (if users pass > > > NULL to SNESSetConvergenceTest, SNESSkipConverged is set). > > > > > > Is all this fine? > > > > > > > > > > > > > > Barry > > > > > > > > > > > > > > 1- "vec_sol", and "vec_sol_always" > > > > > > > > > > 2 - "vec_func", and "vec_func_always" > > > > > > > > > > Is this extrictly needed? Do you remember some corner case needing this? > > > > > > > > > > > > > > > > > > > > On 8/31/07, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > > > > > Lisandro, > > > > > > > > > > > > The changes sound fine for petsc-dev, improving the > > > > > > reference counting. But this is too large a change for a patch. > > > > > > Patches are supposed to be minimulistic changes that fix particular > > > > > > problems that are impacting end users. > > > > > > > > > > > > Barry > > > > > > > > > > > > On Fri, 31 Aug 2007, Lisandro Dalcin wrote: > > > > > > > > > > > > > There are some things broken in SNES, and others that could be > > > > > > > improved. In particular, I am going to make sure SNES take ownership > > > > > > > and correctly manage reference counting of all the user provided > > > > > > > vectors, that is: > > > > > > > > > > > > > > - function vector (passed in SNESSetFunction) > > > > > > > - solution vector (passed in SNESSolve/SNESSetSolution) > > > > > > > - afine vector (passed in SNESSolve/SNESSetRhs) > > > > > > > > > > > > > > All this is similar to what I did in the past for KSP > > > > > > > > > > > > > > I almost sure all those changes are completelly backward compatible. > > > > > > > For example, the user was in charge of calling VecDestroy() with the > > > > > > > provided function vector, but after calling SNESSolve. Now, users are > > > > > > > able to call it after SNESSetFunction is called, so they do not need > > > > > > > to mantain a reference to the function vector. The same applies to > > > > > > > solution and afine vectors. > > > > > > > > > > > > > > So I want to ask you: can I push this in release-2.3.3? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Lisandro Dalcín > > > --------------- > > > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) > > > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) > > > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) > > > PTLC - Güemes 3450, (3000) Santa Fe, Argentina > > > Tel/Fax: +54-(0)342-451.1594 > > > > > > > > > > > > -- > > What most experimenters take for granted before they begin their > > experiments is infinitely more interesting than any results to which > > their experiments lead. > > -- Norbert Wiener > > > > > > >

1 0