May 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] What needs to be done before a release?
by Jed Brown 31 May '12

31 May '12

On Thu, May 31, 2012 at 12:21 PM, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > Is this a real or potential issue? C interoperability has been implemented > in all compilers I know of for a while. > In 2007, cray, gfortran, g95, intel and NAG already supported this > functionality. http://dx.doi.org/10.1145/1243413.1243414 > The current version is at http://dx.doi.org/10.1145/2073761.2073762 (I > wish it would also give the earliest release each feature was implemented). > ISO C bindings were added in gfortran-4.3. The petsc-maint this morning was using gfortran-4.2. > > For those who don't use fortran and may not have a "recent" compiler, > there is always --with-fortran=0 >

1 0

Re: [petsc-dev] What needs to be done before a release?
by Blaise Bourdin 31 May '12

31 May '12

Hi, Is this a real or potential issue? C interoperability has been implemented in all compilers I know of for a while. In 2007, cray, gfortran, g95, intel and NAG already supported this functionality. http://dx.doi.org/10.1145/1243413.1243414 The current version is at http://dx.doi.org/10.1145/2073761.2073762 (I wish it would also give the earliest release each feature was implemented). For those who don't use fortran and may not have a "recent" compiler, there is always --with-fortran=0 Blaise > Barry is looking at using this flag and reorganizing the f2003 code. > [perhaps the interface functions that need this functionality won't be > compiled selectively - based on this flag] > > Satish > > On Thu, 31 May 2012, Jed Brown wrote: > >> So how do we deal with this function not being implemented unless an F2003 >> compiler is used? Just #ifdef its body and produce a run-time error when an >> old compiler is used? Satish, are you doing this? >> >> On Thu, May 31, 2012 at 11:36 AM, Satish Balay <balay(a)mcs.anl.gov> wrote: >> >>> Added configure check. >>> >>> http://petsc.cs.iit.edu/petsc/releases/BuildSystem-3.3/rev/a6a959d40d3d >>> >>> Satish >>> >>> On Thu, 31 May 2012, Jed Brown wrote: >>> >>>> 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(a)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 -- 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

1 0

Re: [petsc-dev] What needs to be done before a release?
by Satish Balay 31 May '12

31 May '12

Barry is looking at using this flag and reorganizing the f2003 code. [perhaps the interface functions that need this functionality won't be compiled selectively - based on this flag] Satish On Thu, 31 May 2012, Jed Brown wrote: > So how do we deal with this function not being implemented unless an F2003 > compiler is used? Just #ifdef its body and produce a run-time error when an > old compiler is used? Satish, are you doing this? > > On Thu, May 31, 2012 at 11:36 AM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > Added configure check. > > > > http://petsc.cs.iit.edu/petsc/releases/BuildSystem-3.3/rev/a6a959d40d3d > > > > Satish > > > > On Thu, 31 May 2012, Jed Brown wrote: > > > > > 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(a)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

1 0

Re: [petsc-dev] What needs to be done before a release?
by Jed Brown 31 May '12

31 May '12

So how do we deal with this function not being implemented unless an F2003 compiler is used? Just #ifdef its body and produce a run-time error when an old compiler is used? Satish, are you doing this? On Thu, May 31, 2012 at 11:36 AM, Satish Balay <balay(a)mcs.anl.gov> wrote: > Added configure check. > > http://petsc.cs.iit.edu/petsc/releases/BuildSystem-3.3/rev/a6a959d40d3d > > Satish > > On Thu, 31 May 2012, Jed Brown wrote: > > > 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(a)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-b… > > > > >>>>> > > > > >>>>> Tim > > > > >>>>> > > > > >>>>> ----- Original Message ----- > > > > >>>>> From: "Barry Smith" <bsmith(a)mcs.anl.gov> > > > > >>>>> To: "For users of the development version of PETSc" < > > > petsc-dev(a)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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

1 0

Re: [petsc-dev] What needs to be done before a release?
by Satish Balay 31 May '12

31 May '12

Added configure check. http://petsc.cs.iit.edu/petsc/releases/BuildSystem-3.3/rev/a6a959d40d3d Satish On Thu, 31 May 2012, Jed Brown wrote: > 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(a)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-b… > > > >>>>> > > > >>>>> Tim > > > >>>>> > > > >>>>> ----- Original Message ----- > > > >>>>> From: "Barry Smith" <bsmith(a)mcs.anl.gov> > > > >>>>> To: "For users of the development version of PETSc" < > > petsc-dev(a)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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

1 0

Re: [petsc-dev] What needs to be done before a release?
by Jed Brown 31 May '12

31 May '12

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(a)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-b… > > >>>>> > > >>>>> Tim > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>> From: "Barry Smith" <bsmith(a)mcs.anl.gov> > > >>>>> To: "For users of the development version of PETSc" < > petsc-dev(a)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 > > > > > > > > > > > > > > > > > > > > > > > > > > >

1 0

Re: [petsc-dev] What needs to be done before a release?
by Satish Balay 31 May '12

31 May '12

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-b… > >>>>> > >>>>> Tim > >>>>> > >>>>> ----- Original Message ----- > >>>>> From: "Barry Smith" <bsmith(a)mcs.anl.gov> > >>>>> To: "For users of the development version of PETSc" <petsc-dev(a)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 > > > > > > > > > > > > > > > >

1 0

Re: [petsc-dev] release preparation
by Dave Nystrom 31 May '12

31 May '12

Thanks. Good to know. Dave Satish Balay writes: > balay@petsc:/sandbox/balay/petsc-dev $ hg tags > tip 23486:c76fb3cac2a4 > release-3.2 20307:cad0859b4453 > release-3.1 15532:f6965e7f147c > release-3.0.0 13216:621178841b37 > release-2.3.3 10547:c59a3fc37afc > release-2.3.2 9364:1aa4d6336f27 > balay@petsc:/sandbox/balay/petsc-dev $ > > When we do the release - we do add a tag for it [in the release repo - > that propegates to petsc-dev]. But the release is not done yet. > > However we haven't been adding tags for patch updates. > > Satish > > On Thu, 31 May 2012, Dave Nystrom wrote: > > > Is there a tag that reflects the petsc-dev state at release time? > > > > Thanks, > > > > Dave > > > > Satish Balay writes: > > > I've now created the release repos - so petsc-dev is now open for all > > > commits. > > > > > > [If you've accumulated petsc-dev related commits - rebasing them with > > > current petsc-dev - before pushing would be good.] > > > > > > > > > Release related commits should now go to the release repo [and not > > > directly to petsc-dev]. Please use the usual release repo > > > workflow. i.e: > > > > > > - clone the release repos > > > - commit/push [to release-repos] > > > - from petsc-dev clone - pull/merge release commits and push to petsc-dev. > > > [or defer this last step to me until the release] > > > > > > ssh://[email protected]//hg/petsc/releases/petsc-3.3 > > > ssh://[email protected]//hg/petsc/releases/BuildSystem-3.3 > > > > > > Satish > > > > > > On Thu, 17 May 2012, Barry Smith wrote: > > > > > > > > > > > petsc-dev folks, > > > > > > > > Recall that we are in a phase of a code freeze that means do not push random new code to petsc-dev, push only bug fixes and clean up to petsc-dev. By all means keep on with code development, just don't push the new stuff to petsc-dev. > > > > > > > > We hope to make the release repository (and then tarball) next Wednesday May 23. So please do be checking the nightly builds and making fixes to petsc-dev. > > > > > > > > Barry > > > > > > > > Note: threaded code and GPU code will not be supported with the release (users should continue to use petsc-dev after the release) so fixes/extensions to those things are not needed and shouldn't be pushed to petsc-dev at the moment. > > > > > > > > > > > > > >

1 0

Re: [petsc-dev] release preparation
by Satish Balay 31 May '12

31 May '12

balay@petsc:/sandbox/balay/petsc-dev $ hg tags tip 23486:c76fb3cac2a4 release-3.2 20307:cad0859b4453 release-3.1 15532:f6965e7f147c release-3.0.0 13216:621178841b37 release-2.3.3 10547:c59a3fc37afc release-2.3.2 9364:1aa4d6336f27 balay@petsc:/sandbox/balay/petsc-dev $ When we do the release - we do add a tag for it [in the release repo - that propegates to petsc-dev]. But the release is not done yet. However we haven't been adding tags for patch updates. Satish On Thu, 31 May 2012, Dave Nystrom wrote: > Is there a tag that reflects the petsc-dev state at release time? > > Thanks, > > Dave > > Satish Balay writes: > > I've now created the release repos - so petsc-dev is now open for all > > commits. > > > > [If you've accumulated petsc-dev related commits - rebasing them with > > current petsc-dev - before pushing would be good.] > > > > > > Release related commits should now go to the release repo [and not > > directly to petsc-dev]. Please use the usual release repo > > workflow. i.e: > > > > - clone the release repos > > - commit/push [to release-repos] > > - from petsc-dev clone - pull/merge release commits and push to petsc-dev. > > [or defer this last step to me until the release] > > > > ssh://[email protected]//hg/petsc/releases/petsc-3.3 > > ssh://[email protected]//hg/petsc/releases/BuildSystem-3.3 > > > > Satish > > > > On Thu, 17 May 2012, Barry Smith wrote: > > > > > > > > petsc-dev folks, > > > > > > Recall that we are in a phase of a code freeze that means do not push random new code to petsc-dev, push only bug fixes and clean up to petsc-dev. By all means keep on with code development, just don't push the new stuff to petsc-dev. > > > > > > We hope to make the release repository (and then tarball) next Wednesday May 23. So please do be checking the nightly builds and making fixes to petsc-dev. > > > > > > Barry > > > > > > Note: threaded code and GPU code will not be supported with the release (users should continue to use petsc-dev after the release) so fixes/extensions to those things are not needed and shouldn't be pushed to petsc-dev at the moment. > > > > > > > > >

1 0

Re: [petsc-dev] release preparation
by Dave Nystrom 31 May '12

31 May '12

Is there a tag that reflects the petsc-dev state at release time? Thanks, Dave Satish Balay writes: > I've now created the release repos - so petsc-dev is now open for all > commits. > > [If you've accumulated petsc-dev related commits - rebasing them with > current petsc-dev - before pushing would be good.] > > > Release related commits should now go to the release repo [and not > directly to petsc-dev]. Please use the usual release repo > workflow. i.e: > > - clone the release repos > - commit/push [to release-repos] > - from petsc-dev clone - pull/merge release commits and push to petsc-dev. > [or defer this last step to me until the release] > > ssh://[email protected]//hg/petsc/releases/petsc-3.3 > ssh://[email protected]//hg/petsc/releases/BuildSystem-3.3 > > Satish > > On Thu, 17 May 2012, Barry Smith wrote: > > > > > petsc-dev folks, > > > > Recall that we are in a phase of a code freeze that means do not push random new code to petsc-dev, push only bug fixes and clean up to petsc-dev. By all means keep on with code development, just don't push the new stuff to petsc-dev. > > > > We hope to make the release repository (and then tarball) next Wednesday May 23. So please do be checking the nightly builds and making fixes to petsc-dev. > > > > Barry > > > > Note: threaded code and GPU code will not be supported with the release (users should continue to use petsc-dev after the release) so fixes/extensions to those things are not needed and shouldn't be pushed to petsc-dev at the moment. > > > > >

1 0