[petsc-dev] preparing for a PETSc release

[Matthew Knepley]

On Mon, May 9, 2011 at 9:46 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>   Blaise,
>
>     Is there a ANY examples in petsc-dev using mesh/sieve from Fortran? I
> cannot find any and that seems very wrong? How the fuck does Matt expect me
> to fix all the bugs related to F90 interfaces if there is nothing that tests
> them?
>

Guilty.


>     I really don't want to fuck with hard-to-build crap like exodusii and
> netcdf (who in their right mind uses netcdf anyways?) is there any way I can
> reproduce the bugs without going through all that crap?
>

Both of these are supposed to install with configure. If they do not, I will
fix the problems on Sunday when I get back.

   Matt


>
>   Barry
>
> On May 9, 2011, at 3:53 PM, Blaise Bourdin wrote:
>
> >>> There are still a bunch a sieve-related open issues (I realize that I
> email the tickets to petsc-maint and not petsc-dev) introduced when Mesh, DA
> and DM were consolidated, and after the XXXDestroy calling sequence was
> altered:
> >>> - DMMeshView writes a text file, even when instructed to use a binary
> viewer
> >>> - MeshLoad does not read the file written by DMMeshView (perhaps
> because of the issue above)
> >>> - DMMeshRestoreCoordinatesF90 and DMMeshRestoreElementsF90 segfault
> >>
> >>  I'll build the sieve stuff and get cracking on fixing all these things.
> Do you have examples you can point me to so I spend my time fixing the bugs
> rather than trying to reproduce them?
> > I am attaching a fortran example. It requires exodus and netcdf, none of
> which build nicely in configure.py.
> > <TestNewSieve.F90>
> >
> > I compile netcdf using:
> > ./configure --enable-shared --with-pic --disable-fortran
> --disable-netcdf4 --disable-pnetcdf --disable-dap CC=gcc CXX=g++
> --prefix=XXX
> >
> > I use exodusII-4.81 which I compile using the attached makefile
> > <Makefile>
> >
> >>
> >>>
> >>> Also, I have been meaning to send a feature request but have been
> procrastinating. It deals with named options (as in enum) and fortran:
> >>> In C, there are 2 ways to handle options: PetscOptionsXXX wrapped in a
> PetscOptionsBegin/End and PetscOptionsGetXXX.
> >>> The former is nice in that it generates help, but only a subset of the
> later is implemented in fortran.
> >>> 1. Is a fortran equivalent of the PetscOptionsXXX feasible? I
> understand that it would require more than just fortran bindings.
> >>
> >>  Big pain. We won't do it, it would have to be a user contribution.
> > That's fair. I wish I had the skills (and time) to do it.
> >
> >>
> >>> 2. Alternatively, one can implement the options management in C and use
> PetscBag to convert data from a fortran derived type to a C struct and back.
> One limitation is that enums again are not supported, but neither are
> arrays.
> >>> 3. If neither 1. or 2. is feasible, would it be possible to add fortran
> support for PetscOptionsGetEnum. Assuming that we use a integer for the enum
> in fortran, my understanding is that all it would take would be to be able
> to pass an array of fortran strings as the list argument of
> PetscOptionsGetEnum.
> >>
> >>  This is the crux of the matter. We don't have any portable way of
> passing an array of strings from Fortran to C. (Portably passing a single
> string is bad enough). If someone figures out how, using the Fortran 2003
> standard for passing arguments to/from C, to handle arrays of strings
> (assuming the standard supports it) then we could provide
> PetscOptionsGetEnum() for Fortran 2003, but that would be a user
> contribution, we're not going to do the work ourselves.
> >
> > I am attaching an example doing exactly that and illustrates how to
> generate interfaces when variables are passed by address or value. Note how
> interfacing C and fortran using iso_c_binding is much simpler than
> generating the fortran bindings. How flexible is the code that generates
> fortran interfaces? Could it be easily hacked to use the iso_c_binding
> module?
> >
> > <cfunc.c><makefile><TestF2003_C.f90>
> >>> Lastly, since the changes DA->DMDA and in XXXDestroy are already going
> make many people angry, is it time to rename Vec PetscVec and Mat PetscMat?
> >>
> >>   Good question.  If so, then shouldn't we name space everything?
> PetscSNES, etc etc etc Maybe wait until next release so there are not too
> many user changes this release?
> >
> > How feasible would it be to mark all non-namespace names as deprecated
> until the next release but offer preprocessor macros in the meantime? This
> would buy everybody some time.
> >
> > 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
> >
> >
> >
> >
> >
> >
> >
>
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110510/9f34c3d9/attachment.html>