[petsc-dev] preparing for a PETSc release

[Blaise Bourdin]

On May 9, 2011, at 9:01 PM, Barry Smith wrote:

> 
> 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 
>>>> 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.
> 
>    Actually I don't see that it is any simpler than our Fortran interfaces (better, portable, but not simpler).
I see your point, generating the fortran interface is not more complicated than generating the fortran binding. That said, dealing with F90 allocatable and C arrays is trivial with iso_c_bindings, and would avoid some f90-specific custom bindings. Not a big deal once they are written indeed, could be a plus in terms of portability.

> 
>> How flexible is the code that generates fortran interfaces? Could it be easily hacked to use the iso_c_binding module?
> 
>   It would be worth it to handle character strings which we now handle manually. Maybe someday some ambitious person with time on their hands can change it.  I don't see a huge upside in changing it (some upside in not needing to do character strings manually but that is all). With so much fun stuff to do in (and new functionality to add to) PETSc I don't want time wasted on something that doesn't make a big difference.
> 
>   You don't have an example of passing an array of character strings from Fortran to C. Is this because the standard doesn't provide a way? 

Are the C function printconstcharlist, and its fortran binding cfunc_chararray in the example attached what you are looking for? I admit that I don't understand C strings, but I started building this example when I was trying to write custom wrappers around PetscOptionsGetEnum. I just never had time to finish.


Blaise

> 
> 
>     Barry
> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

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