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>
