August 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] calling petscinitialize from fortran code
by Jed Brown 18 Aug '12

18 Aug '12

On Sat, Aug 18, 2012 at 3:54 AM, Stefano Zampini <stefano.zampini(a)gmail.com>wrote: > It seems it is related with using -h options in my FEM code. Is -h a > shortcut for -help for PETSc? Yes

1 0

Re: [petsc-dev] calling petscinitialize from fortran code
by Stefano Zampini 18 Aug '12

18 Aug '12

Sorry for late reply. It seems it is related with using -h options in my FEM code. Is -h a shortcut for -help for PETSc? Indeed, ./src/ksp/ksp/examples/tutorials/ex2f -h prints all the options. Stefano 2012/8/11 Satish Balay <balay(a)mcs.anl.gov> > I don't see this. Perhaps you can run in a debugger to see > what is hapenning on your end? > > Satish > ---- > asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials>./ex2f > Norm of error 0.1192E-05 iterations 4 > asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials>./ex2f > -options_table > Norm of error 0.1192E-05 iterations 4 > #PETSc Option Table entries: > -display :0.0 > -fp_trap > -malloc_dump > -options_table > #End of PETSc Option Table entries > asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials> > > > On Sat, 11 Aug 2012, Stefano Zampini wrote: > > > Hi, > > > > I'm experiencing some boring behaviour with my working copy of petsc-dev. > > During the call to PetscInitialize(PETSC_NULL_CHARACTER,ierr), it seems > it > > calls PetscOptionsView. > > This does not happen with C code, and did not happen some time ago. So, I > > think it's related with some recent Fortran bindings. > > > > I tried a pull right now, cleaning libraries and recompiling (recreating > > the fortran stubs) but the problem remains. > > > > Can you fix it? > > > > Thanks, > > > > -- Stefano

1 0

Re: [petsc-dev] YAML patch take 3
by Sean Farley 17 Aug '12

17 Aug '12

> The minimum requirement must be that they are binary and source-level > compatible. That means that no public symbols can be renamed, no public > structures can be changed, and no interfaces can be changed. So it basically > only allows private changes within the same API and non-conflicting new > APIs. This patch worries me too much for adding to petsc 3.3 for the exact reasons Jed wrote. I strongly think it should only be in pets-dev. On second thought, after reading this patch carefully, there is a subtle but big change in functionality: the _YAML was private on purpose. The user should not have to call a whole new function just for yaml. The vision I had for Weston's code was to pass a yaml string (in hopes of command line parsing) or a yaml file to already existing functions and not have to hardcode calling yaml (or json or some-future-thing). If this patch could be reworked to have passing a yaml file to PetscOptionsInsertFile (so that yaml could be in ~/.petscrc) then I would be +1 for that patch. As is, I'd rather keep the current code and try to fix it so that _YAML was still private and that current functions (PetscOptionsInsertFile, etc.) could parse yaml.

1 0

Re: [petsc-dev] YAML patch take 3
by Jed Brown 17 Aug '12

17 Aug '12

On Fri, Aug 17, 2012 at 2:36 PM, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > Should there be a rule for inclusion in the release tree vs. development? > For instance that patches cannot change or delete a public interface and > must pass all tests? The minimum requirement must be that they are binary and source-level compatible. That means that no public symbols can be renamed, no public structures can be changed, and no interfaces can be changed. So it basically only allows private changes within the same API and non-conflicting new APIs. Now implicit in the "pN" naming that these patches are strictly bug fixes. That isn't strictly true, and if we are going to put new (but always "safe") functionality into the release branch, I would prefer to do it as a subminor release. This is the conventional meaning of subminor release, so it's perfectly acceptable in my opinion.

1 0

Re: [petsc-dev] YAML patch take 3
by Blaise Bourdin 17 Aug '12

17 Aug '12

On Aug 17, 2012, at 2:12 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > I'll test this. I'm impressed by how much code you have removed and I'm happy to put it in petsc-dev, but we're building up a lot of changes to petsc-3.3. That's because it doesn't aim at being a full fledge yaml parser, and is based on a very minimalist recursive parser I found at http://stackoverflow.com/a/621451 rather than on the full featured example in the libyaml distribution. I'll try to get a student to work on implementing aliases and sequences this semester. I added 2 tests (ex79.c and ex79f90.f90) and runex79 in the makefile in src/sys/examples/tutorials The global option -options_file_yaml can also be used to > Should we call the next patch release 3.3.1 instead of 3.3p? It's a significant enough change that people should be able to test for it with the PETSC_VERSION_ macros. That's fine with me. That said, I doubt that the patch will break anybody's code. Should there be a rule for inclusion in the release tree vs. development? For instance that patches cannot change or delete a public interface and must pass all tests? > > This line can certainly be removed. > > +#define PETSC_MAX_YAML_LEN 128000 Yike... it was supposed to be removed indeed. Blaise > > On Fri, Aug 17, 2012 at 1:52 PM, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > Hi, > > Here is a revised version of my YAML patch that eliminates the limit on the yaml file length. Is there any rational objection to pushing it to petsc-3.3 and petsc-dev? > > Blaise > > > > -- > Department of Mathematics and Center for Computation & Technology > Louisiana State University, Baton Rouge, LA 70803, USA > Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin > > > > > > > > > -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin

1 0

Re: [petsc-dev] Ghost values in sieve
by Matthew Knepley 17 Aug '12

17 Aug '12

On Fri, Aug 17, 2012 at 1:21 PM, Chris Eldred <chris.eldred(a)gmail.com>wrote: > I was wondering how ghost values were handled when creating a > distributed (global) vector from a specific PetscSection over a > DMComplex object- ie what defines the stencils used to figure out > which values need to be ghosted? What about local vs. global indexes? This answer will have to be long because the question is mixing levels in the interface. A PetscSection is only an offset structure, so it has no designated fields for overlap information. What I do for DM is to create 2 sections: one describing the layout of the local vector, and one describing the global vector and ghosts. The global section can be created automatically given the local section and a PetscSF (successor to VecScatter). The PetscSF describes the parallel overlap, and also has scatters and reductions. This is created by the DMComplex instead of a scatter since it can handle arbitrary types, and has a better query interface. DMComplex creates a (non-overlapping) partition of some stratum of points, usually cells for FEM. Then the closure(p) U star(p) for each point is added to that partition, and the dofs on any shared point are ghosted. This is all now done using the vanilla DM interface, so DMGlobalToLocal() and LocalToGlobal() and cousins work as normal. Does that make sense? Matt > > -Chris > > -- > Chris Eldred > DOE Computational Science Graduate Fellow > Graduate Student, Atmospheric Science, Colorado State University > B.S. Applied Computational Physics, Carnegie Mellon University, 2009 > chris.eldred(a)gmail.com > -- 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: [petsc-dev] YAML patch take 3
by Jed Brown 17 Aug '12

17 Aug '12

I'll test this. I'm impressed by how much code you have removed and I'm happy to put it in petsc-dev, but we're building up a lot of changes to petsc-3.3. Should we call the next patch release 3.3.1 instead of 3.3p? It's a significant enough change that people should be able to test for it with the PETSC_VERSION_ macros. This line can certainly be removed. +#define PETSC_MAX_YAML_LEN 128000 On Fri, Aug 17, 2012 at 1:52 PM, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > Hi, > > Here is a revised version of my YAML patch that eliminates the limit on > the yaml file length. Is there any rational objection to pushing it to > petsc-3.3 and petsc-dev? > > Blaise > > > > -- > Department of Mathematics and Center for Computation & Technology > Louisiana State University, Baton Rouge, LA 70803, USA > Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 > http://www.math.lsu.edu/~bourdin > > > > > > > > >

1 0

YAML patch take 3
by Blaise Bourdin 17 Aug '12

17 Aug '12

Hi, Here is a revised version of my YAML patch that eliminates the limit on the yaml file length. Is there any rational objection to pushing it to petsc-3.3 and petsc-dev? Blaise -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin

1 0

Ghost values in sieve
by Chris Eldred 17 Aug '12

17 Aug '12

I was wondering how ghost values were handled when creating a distributed (global) vector from a specific PetscSection over a DMComplex object- ie what defines the stencils used to figure out which values need to be ghosted? What about local vs. global indexes? -Chris -- Chris Eldred DOE Computational Science Graduate Fellow Graduate Student, Atmospheric Science, Colorado State University B.S. Applied Computational Physics, Carnegie Mellon University, 2009 chris.eldred(a)gmail.com

1 0

Re: [petsc-dev] TS fortran binding patch
by Jed Brown 17 Aug '12

17 Aug '12

http://petsc.cs.iit.edu/petsc/releases/petsc-3.3/rev/22c370214d74 On Fri, Aug 17, 2012 at 10:25 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Do you have any tests for this? > > There were some duplicate names > > +#define tssetifunction_ tssetifunction > +#define tssetifunction_ tsgetifunction > +#define tssetijacobian_ tssetijacobian > +#define tssetijacobian_ tsgetijacobian > > and missing error checking > > +void PETSC_STDCALL tsgetijacobian_(TS *ts,Mat *J,Mat *M,int *func,void > **ctx,PetscErrorCode *ierr) > +{ > + *ierr = TSGetIJacobian(*ts,J,M,0,ctx); > +} > > which I am fixing up. > > On Fri, Aug 17, 2012 at 9:00 AM, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > >> Hi, >> >> The attached trivial patch adds fortran bindings for a few TS functions >> (TSGetIFunction, TSGetRHSFunction, TSGetIJAcobian, TSSetOptiosnPrefix, >> TSAppendOptionsPrefix). Can somebody push it to petsc-3.3 if it makes sense? >> >> Blaise >> >> >> -- >> Department of Mathematics and Center for Computation & Technology >> Louisiana State University, Baton Rouge, LA 70803, USA >> Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 >> http://www.math.lsu.edu/~bourdin >> >> >> >> >> >> >> >> >> >

1 0