On May 9, 2011, at 10:27 PM, Blaise Bourdin wrote: > > On May 9, 2011, at 9:46 PM, Barry Smith 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? > > Sieve examples are in a sad state indeed. I have a few basic examples that > are not using any data structure from my code, but they will all use exodusII > to build the mesh. I am not completely sure that all the functions necessary > to build a mesh have fortran bindings. It's always been my understanding that > the Mesh creation was to be done in C / C++, and that fortran bindings were > to be written. > >> >> I really don't want to fuck with hard-to-build crap like exodusii and >> netcdf (who in their right mind uses netcdf anyways?) > I am no big fan of netcdf and exo. In a perfect world, we would all be using > some modern file format, but in reality, there aren't so many binary file > formats that are supported my multiple mesh generators and post processors, > and have open C and fortran implementations... What's your favorite > unstructured mesh file format? > >> is there any way I can reproduce the bugs without going through all that >> crap? > > Let me see if I can build a Mesh from an exo file in C, and save it in a > binary file, once MeshLoad is fixed, we can replicate the other bugs from > there.
Ok, let's try that. Barry > Or, I can try to cook a simple mesh reader in C. MeshCreatePCICE looks like > it is working, but I can;t figure out what format is it reading. > > Blaise > > > >> >> >> >> 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 >>> >>> >>> >>> >>> >>> >>> >> > > -- > 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 > > > > > > >
