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


Reply via email to