[petsc-dev] preparing for a PETSc release

[Barry Smith]

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
> 
> 
> 
> 
> 
> 
>