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
