[petsc-dev] What needs to be done before a release?

Jed Brown jedbrown at mcs.anl.gov
Thu May 31 09:47:17 CDT 2012 

And we have our first petsc-maint breakage due to this Fortran 2003 thingy.

On Thu, May 31, 2012 at 9:03 AM, Satish Balay <balay at mcs.anl.gov> wrote:

> This code is using "use,intrinsic :: iso_c_binding"
>
> Isn't this a fortran 2003 thingy? Perhaps there should be a configure
> checks for it.
>
> Satish
>
> On Wed, 30 May 2012, Barry Smith wrote:
>
> >
> >    Blaise,
> >
> >     I have pushed PetscOptionsGetEnum() and PetscBagRegisterEnum() for
> f90 to petsc-dev tests are in src/sys/examples/tutorials
> >
> >    Barry
> >
> > On May 29, 2012, at 3:29 AM, Blaise Bourdin wrote:
> >
> > >
> > > On May 29, 2012, at 1:18 AM, Barry Smith wrote:
> > >
> > >>
> > >> Blaise,
> > >>
> > >>    How about the attached? My goal is to have the usage be as similar
> to the other PetscOptions... calls and too not require the Fortran user to
> be C aware that is, they should not have to append null characters or
> declare special C type declaration. In other words, the user writes
> Fortran77 code :-).[see attached file: ex1f.F90]
> > >>
> > >>    I don't think it should bleed, but then I am no longer a Fortran
> programmer.
> > >
> > > Once a fortran programmer, always a fortran programmer... It's not
> like there is a lot to forget.
> > >
> > > Now I understand what you want. I agree with your goal of making the
> call standard and transparent. There is one issue with this approach for a
> function like PetscBagRegisterEnum (as far as I understand the C code),
> where you don't copy the string array in the bag item structure, but keep a
> reference to it (l. 80 in bag.c). After Carray and list1 are deallocated,
> the bag item->list points to some nonsense. I lost my mind trying to find a
> workaround last week.
> > >
> > > Would you be OK with requesting that each of the strings in list have
> some padding at the end, and be modified in the wrapper (adding the
> C_NULL_CHAR)? The alternative would be to modify PetscBagRegisterEnum, in
> order to store the content of list instead of just a reference, which may
> not be something you want to do right now.
> > >
> > > Blaise
> > >
> > >
> > >>
> > >>   Barry
> > >>
> > >>
> > >>
> > >> On May 27, 2012, at 10:16 AM, Blaise Bourdin wrote:
> > >>
> > >>> Barry,
> > >>>
> > >>> If I frame your email, will you sign it for me? ;)
> > >>>
> > >>> I am traveling so I did not have much time to do it, even in my
> sleep, but Tim's solution is essentially right.
> > >>>
> > >>> Have a look at the attached code. I had to write my own interface to
> PetscOptionsGetEnum, but I have to do the equivalent of FIXCHAR by myself
> (basically appending  //C_NULL_CHAR). I checked in the debugger, and the
> list argument that is passed to PetscOptionsGetEList is the same as the one
> passed from C. Is this what you want?
> > >>>
> > >>> Do you want to do the FIXCHAR business in the C or fortran side? I
> suspect that you would prefer not having to append the C_NULL_CHAR in
> fortran, but I can't figure how to do that without allocating a new array
> of strings, and causing a memory leak. What do you think?
> > >>>
> > >>> If this is not what you want, could you meet me half way and write
> the fortran interface you would like to use, in which case I will try to
> write the missing fortran parts.
> > >>>
> > >>> Blaise
> > >>> <PetscF2003.F90>
> > >>>>
> > >>>> Tim,
> > >>>>
> > >>>> Thanks. But what I want is all bundled up a routine that takes in
> the Fortran array of character strings and allocates and copies over them
> to the C ptr business. Likely I could figure it out myself with but Blaise
> is such a Fortran wizard he can do it optimally in his sleep :-)
> > >>>>
> > >>>> Barry
> > >>>>
> > >>>> On May 25, 2012, at 8:14 PM, Tim Gallagher wrote:
> > >>>>
> > >>>>> For what it's worth, I answered a question about how to pass
> string arrays awhile ago on StackOverflow:
> > >>>>>
> > >>>>>
> http://stackoverflow.com/questions/9686532/arrays-of-strings-in-fortran-c-bridges-using-iso-c-binding/9686741#9686741
> > >>>>>
> > >>>>> Tim
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>> From: "Barry Smith" <bsmith at mcs.anl.gov>
> > >>>>> To: "For users of the development version of PETSc" <
> petsc-dev at mcs.anl.gov>
> > >>>>> Sent: Friday, May 25, 2012 8:57:52 PM
> > >>>>> Subject: Re: [petsc-dev] What needs to be done before a release?
> > >>>>>
> > >>>>> Blaise
> > >>>>>
> > >>>>> If you provide a fortran function to convert an array of Fortran
> strings to an array of C strings and tell us how to delete the result then
> we'll provide a PetscOptionsGetEnum() for Fortran.
> > >>>>>
> > >>>>> Barry
> > >>>>>
> > >>>>> On May 2, 2012, at 12:02 PM, Blaise Bourdin wrote:
> > >>>>>
> > >>>>>> Barry,
> > >>>>>>
> > >>>>>>>> Also, fortran wrappers over PetscOptionsEnum and
> PetscBagRegisterEnum would be nice. I understand that it
> > >>>>>>>> is a bit tricky since it involves passing fortran arrays of
> strings.
> > >>>>>>>
> > >>>>>>> Yup. We'd be willing to support these from FORTRAN but someone
> else has to do the dirty work of figuring out how to handle those array of
> strings (maybe F2003?).
> > >>>>>>
> > >>>>>> I am attaching a simple proof of concept example that
> demonstrates how to write a fortran interface and call petsc C functions
> from fortran using F2003 C-interoperability instead of going through the
> fortran bindings.
> > >>>>>>
> > >>>>>> Don't be put off by all the warnings if you use gfortran. They
> would be easy to avoid. Basically, right now, you detect the fortran
> integer and real kinds that match that of the C ones. It would be quite
> simple to get the fortran C-interoperable integer and real types associated
> with the C type of PetscInt, PetscReal etc.
> > >>>>>>
> > >>>>>> Basically, we (I?) could write a fortran interface and a fortran
> function for the tricky functions involving arrays of string, instead of
> creating a custom binding in C. Are you willing to let some fortran
> pollution into the petsc code? Where would these function have to be?
> > >>>>>>
> > >>>>>> Blaise
> > >>>>>>
> > >>>>>> PS: you need FCFLAGS='-ffixed-line-length-none
>  -ffree-line-length-none -ffree-form' or some subset of these to compile
> with gfortran. I'm not sure why these are not the default with a file
> suffix .F90
> > >>>>>>
> > >>>>>> <PetscF2003Binding.F90>
> > >>>>>> --
> > >>>>>> 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
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >> <ex1f.F90>
> > >
> > > --
> > > 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120531/8ba99f80/attachment.html>

More information about the petsc-dev mailing list