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

Tue May 29 22:59:24 CDT 2012

On May 29, 2012, at 8:00 AM, Barry Smith wrote:

>> 
>> 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.
> 
>   Actually. I think PetscBagRegisterEnum() should be modified to copy the list, it is an unsafe function even from C now. Implicitly I assumed that list was declared as a global static variable (hence the current PetscBagRegisterEnum() is ok) but I should not have made that assumption.

   I have changed PetscBagRegisterEnum() to now properly copy the list of enum strings values

   Barry

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