>> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: TestNewSieve.F90 Type: application/octet-stream Size: 1724 bytes Desc: not available URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110509/ad6eb57f/attachment.obj> -------------- next part --------------
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 7615 bytes Desc: not available URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110509/ad6eb57f/attachment-0001.obj> -------------- next part -------------- > >> >> 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: cfunc.c Type: application/octet-stream Size: 1095 bytes Desc: not available URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110509/ad6eb57f/attachment-0002.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: makefile Type: application/octet-stream Size: 307 bytes Desc: not available URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110509/ad6eb57f/attachment-0003.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: TestF2003_C.f90 Type: application/octet-stream Size: 2585 bytes Desc: not available URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110509/ad6eb57f/attachment-0004.obj> -------------- next part -------------- >> 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
