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

MatInvertBlockDiagonal
by Jed Brown 02 Jun '12

02 Jun '12

This routine currently returns PetscScalar**, but I don't think it was ever intended to be writable. I'm changing it to const PetscScalar** unless someone speaks up. Also, the auto Fortran interface was incorrect, thus clearly unused.

1 0

Re: [petsc-dev] switch petsc-dev to use --with-shared-libraries by default?
by Matthew Knepley 01 Jun '12

01 Jun '12

On Fri, Jun 1, 2012 at 2:18 PM, Aron Ahmadia <aron.ahmadia(a)kaust.edu.sa>wrote: > I recall you were fighting with this recently. Did you figure out what was > > wrong? > > The semantics for compiling/linking on BG/P with XL compilers is not > that hard. All objects need to be compiled with the -qpic flag. > Shared libraries are built with the -qmkshrobj -qnostaticlink flags. > Final executables must be linked without the -qmkshrobj flag but with > the -qnostaticlink flag. xlc also insists that all libraries linked > Here is the problem for BuildSystem right now. We just need to fix it to put -qnostaticlink flag in LDFLAGS. That should put it in the shared object link along with -qmkshrobj fro sharedLibraryFlags, and in the executable. Matt > are .so, so trying to link in static library archives will confuse it > as well. > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] switch petsc-dev to use --with-shared-libraries by default?
by Barry Smith 01 Jun '12

01 Jun '12

On Jun 1, 2012, at 1:18 PM, Satish Balay wrote: > I think the problems come from different types of externalpackage > usages. [for ex: mpi not built shared]. Also we don't explicitly build > all externalpackages shared - and this can cause grief in some > cases. [they just get pulled into libpetsc.so] > > We had this default for a while and then gaveup. But now that we > default to --with-single-library=1 - some of those issues don't bite > us.. Maybe after the release is well tested we can try changing the default in the nightly builds. Note that making --with-shared-libraries=1 the default doesn't need to mean that shared library works on every two-bit obscure machines. On machines where shared libraries don't work the user would just us --with-shared-libraries=0 Barry > > Satish > > On Fri, 1 Jun 2012, Barry Smith wrote: > >> >> Is it time to change in petsc-dev the default of --with-shared-libraries to true by default? It is a nicer user experience to use shared libraries (much faster link of executable for example). >> >> Does it work pretty much everywhere? >> >> Barry >> >> >> >

1 0

Re: [petsc-dev] What needs to be done before a release?
by Barry Smith 01 Jun '12

01 Jun '12

On Jun 1, 2012, at 1:34 PM, Blaise Bourdin wrote: > > On Jun 1, 2012, at 12:47 PM, Barry Smith wrote: > >> >> On Jun 1, 2012, at 12:37 PM, Blaise Bourdin wrote: >>> >>> What compiler is this? I don't have access to any solaris box, and have pretty bad memories of sun's fortran compilers. My understanding of the C interoperability is that these are perfectly legal look at the example at http://fortranwiki.org/fortran/show/c_loc >>> >>> I pushed a change to bagenum.F Could you have a look and see if you get the same error in PetscBagRegisterEnum? >>> >>> Also, this binding needs an explicit interface (technically, the old one too, but Barry's trick for getting farray length was a workaround the lack of explicit interface). >> >> Huh, what? We don't want to require an explicit interface! Where is this change? What is the url of the change you made? Did you put it in petsc-dev or petsc-3.3? Why do you need to change it to require an explicit interface. >> >> Be like Jed and when you say you made some change include the url business so people can jump immediately to the change you are talking about instead of wasting 1/2 and hour trying to find something they cannot find. > > Apologies, will do next time. That would also have helped me realize that I had pushed to my own clone, not petsc-3.3 or petsc-dev repository... I am attaching the patch I was planing on submitting. > > Out of curiosity, what is the rationale for not wanting an explicit interface? As far as I understand, the fortran standard mandates an explicit interface in this situation (array of strings). I'm confused. F77 supported passing an array of strings but doesn't even have the concept of an explicit interface so how can flater require an explicit interface for the exact same call? Is it because you want to use size(FArray) instead of looking for the '' string? > I would understand in the situation of pure f77 compatibility for instance, but we threw this away with the iso_c_binding module anyway... I want the user experience to be as close to f77 (what they are used to) as possible and not introduced unnecessary flater crap. Barry > > Perhaps introducing f2003 in petsc was a bad idea, considering the large variety of compilers you need to support. If you feel that it introduces more issues than solving problems, feel free to strip the PetscOptionsEnum and PetscBagRegisterEnum bindings. They could easily be packaged separately for the few people who will ever need them. > > <PetscBagRegisterEnum.patch> > > Blaise > > >> >> Barry >> >> >> >>> I can't figure out where to put it. so for the moment, it is in ex5f90 >>> >>> >>> Blaise >>> >>> >>>> >>>> thanks, >>>> Satish >>>> >>>> >>>> On Thu, 31 May 2012, Satish Balay wrote: >>>> >>>>> 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 >>> >>> >>> >>> >>> >>> >>> >> > > -- > 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 01 Jun '12

01 Jun '12

On Fri, Jun 1, 2012 at 3:38 PM, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > Having the interfaces requires those extra interface files in the includes > that we already hate so much, and we can't protect the headers (to make > including the right ones simple like in C) because you have to include them > for every subroutine. > > > Not really. You don't need to include the modules in each subroutine or > function if they are included (used) in the Program or Module in which the > function is defined > I was referring to #include *.h90 files. > Apart for [1], I fully agree. I actually think that there should only be > two way to use fortran: the old f77 way without any type checking, > interface, and where all petscobjects are integer, or the right way which > you described. > What about people with legacy code that want to use VecGetArrayF90? Should they have to rewrite with type(Mat) everywhere just for that change? What about mixing two Fortran codes, one of which does things the new way and one does the old way? > Unfortunately, that forces people to spell out things like type(Mat) [2] > and XGetContext() either requires an explicit interface written by the user > [3] or use of the ISO C bindings in the interface [4]. > > Not really. As long as your context is not too large (so that allocating a > copy and copying the data won't kill you), you can always write a generic > interface for XGetContext that returns an array of your favorite data type, > then use transfer. And when your context is large, you should pass by > address anyway). Conceptually, it is not really different from casting into > a *void. McCormick has a nice writeup on this > http://www.macresearch.org/advanced_fortran_90_callbacks_with_the_transfer_… > > How does using iso_c_binding helps with a fortran library called from > fortran? > I had a 50 message conversation about this with Ondrej Certik this winter. He eventually agreed with me and summarized the various choices here. http://fortran90.org/src/best-practices.html#type-casting-in-callbacks Choice 5 (V) is the preferred way to do this. With transfer (choice 6), you have to write 30 lines of boilerplate to define typeX2data and data2typeX for each typeX that you want to be able to pass through a callback (but at least you don't have to write an interface to every function you pass the context through). Transfer is also a very different (and worse) semantic because you get a copy of the actual data structure, thus any modifications that you make from the callback (e.g. logging some statistics) will not be visible in the external context. Compare the gists (cited at the bottom of that page) https://gist.github.com/1665626 (best way I know, uses ISO C bindings) https://gist.github.com/1665630 (note the need for my_data_type.f90) I'm relieved that ISO C bindings exist, at least it's possible to write modular software now, but you know the standards committee was impaired or sadistic when the foreign function interface is better than the native function interface. > I can think of no explanation for this absurdity other than that the > Fortran language standards committee is the most successful global trolling > agency in modern history [5]. > > Not even an emoticon? I thought this was funny. > [1] Better, but it would be best for them to stop using Fortran. > > Why not. But what is the alternative knowing that I am not willing to give > up array sections, operator overloading and vector operations? Are you > going to suggest that I switch to C++? > You are aware that every use of non-leading dimension stride 1 array sections involves a dynamic memory allocation, a copy in, and a copy out? > [2] No #includes means no macros [6] and no equivalent of typedef. > > The only macro I would miss are CHKERRQ and SETERRQ. I would actually make > an exception for these two. For numerical and string types, the fortran way > of doing typedef is kind. > The kind parameter still pollutes the namespace (don't get me started on how bad they botched namespaces ;-)) and has to appear throughout the code and can't be used for types like Vec, Mat, etc. Fortran could claim to have a useful typedef when I can do the equivalent of typedef struct _p_KSP *KSP; typedef PetscErrorCode (*TSIFunction)(TS,PetscReal,Vec,Vec,Vec,void*); > [3] Disaster because (a) it is maintained by the user with no way to check > that it is correct and (b) the user may need multiple incompatible > definitions in the same project. > [4] Indeed, the best way to write a Fortran library called from Fortran is > to use the ISO C bindings. > [5] The people who dream up ways to link MKL and the Portland Group > deserve honorable mention. > [6] Type macros are terrible anyway because of the aforementioned > punchcard nostalgia leading to different projects adopting different > line/format styles and compilers having no portable way to select. > > I don't know of any compiler which does not default to free form for > .f90/.F90 files, do you? Free format has been around for over 20 years. > That some people insist on coding on 72 cols (or is it 78?) in the days of > large screens is beyond me indeed. > As a library, we should be able to make the library part work the same regardless of which choice the *user* makes. This is especially important when coupling two codes written by users with different conventions. You will notice in PETSc Fortran files that we place the line continuation character (&) in column 73 so that it is ignored by a fixed form compiler (because it's not between columns 7 to 72) as well as a continuation character in column 6 so that fixed form compilers know it's a continuation. We also avoid using line continuations at all in rows that have macros because the macro may expand to different length strings. > So I guess that you guys don't want an explicit interface for > PetscBagRegisterEnum, right? I'll fix the harmless bugs in the current > binding, then. > It should be there just like VecGetArrayF90 needs one, I just felt like ranting. ;-D

1 0

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

01 Jun '12

On Fri, 1 Jun 2012, Blaise Bourdin wrote: > > > > Hm - we do have explicit interfaces - for ex: VecGetArrayF90() does not work without it.. > > Touchï¿œ... > > So where should the interfaces for PetscOptionsGetEnum and PetscBagRegisterEnum go? Presumably into finclude/ftn-cusom/petscsys.h90 [similar to petscvec.h90] There are also petscvecdef.h90 petscvechide.h90 there - I'm not sure if you would need similar stuff to for enum. Also you'll need finclude/petscsys.h90 [similar to finclude/petscvec.h90] - and petsc.h90 including petscsys.h90] Just a comment. Interface for VecGetArrayF90 its mandatory. But looks like its optional for PetscOptionsGetEnum()/PetscBagRegisterEnum(). But then - internals of these routines wont' work without a f2003 compiler anyway. Satish

1 0

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

01 Jun '12

> > Hm - we do have explicit interfaces - for ex: VecGetArrayF90() does not work without it.. Touché... So where should the interfaces for PetscOptionsGetEnum and PetscBagRegisterEnum go? Blaise -- 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 01 Jun '12

01 Jun '12

On Fri, 1 Jun 2012, Blaise Bourdin wrote: > > On Jun 1, 2012, at 2:23 PM, Jed Brown wrote: > > > On Fri, Jun 1, 2012 at 1:34 PM, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > > Apologies, will do next time. That would also have helped me realize that I had pushed to my own clone, not petsc-3.3 or petsc-dev repository... I am attaching the patch I was planing on submitting. > > > > Out of curiosity, what is the rationale for not wanting an explicit interface? As far as I understand, the fortran standard mandates an explicit interface in this situation (array of strings). I would understand in the situation of pure f77 compatibility for instance, but we threw this away with the iso_c_binding module anyway... > > > > Fortran modules are horribly nonportable from a build system perspective since every compiler manages them differently. > > I agree. Some compilers even change the flag names from one release to the next. > > > > Having the interfaces requires those extra interface files in the includes that we already hate so much, and we can't protect the headers (to make including the right ones simple like in C) because you have to include them for every subroutine. > > Not really. You don't need to include the modules in each subroutine or function if they are included (used) in the Program or Module in which the function is defined > > > > > I think it would be better [1] for the "modern" Fortran users for PETSc to do everything with modules, using explicit interfaces for all functions, and datatypes for PETSc objects. > > Apart for [1], I fully agree. I actually think that there should only be two way to use fortran: the old f77 way without any type checking, interface, and where all petscobjects are integer, or the right way which you described. > > > > Unfortunately, that forces people to spell out things like type(Mat) [2] and XGetContext() either requires an explicit interface written by the user [3] or use of the ISO C bindings in the interface [4]. > Not really. As long as your context is not too large (so that allocating a copy and copying the data won't kill you), you can always write a generic interface for XGetContext that returns an array of your favorite data type, then use transfer. And when your context is large, you should pass by address anyway). Conceptually, it is not really different from casting into a *void. McCormick has a nice writeup on this http://www.macresearch.org/advanced_fortran_90_callbacks_with_the_transfer_… > > How does using iso_c_binding helps with a fortran library called from fortran? > > > I can think of no explanation for this absurdity other than that the Fortran language standards committee is the most successful global trolling agency in modern history [5]. > > > > > Perhaps introducing f2003 in petsc was a bad idea, considering the large variety of compilers you need to support. If you feel that it introduces more issues than solving problems, feel free to strip the PetscOptionsEnum and PetscBagRegisterEnum bindings. They could easily be packaged separately for the few people who will ever need them. > > > > [1] Better, but it would be best for them to stop using Fortran. > Why not. But what is the alternative knowing that I am not willing to give up array sections, operator overloading and vector operations? Are you going to suggest that I switch to C++? > > > [2] No #includes means no macros [6] and no equivalent of typedef. > The only macro I would miss are CHKERRQ and SETERRQ. I would actually make an exception for these two. For numerical and string types, the fortran way of doing typedef is kind. > > > > [3] Disaster because (a) it is maintained by the user with no way to check that it is correct and (b) the user may need multiple incompatible definitions in the same project. > > [4] Indeed, the best way to write a Fortran library called from Fortran is to use the ISO C bindings. > > [5] The people who dream up ways to link MKL and the Portland Group deserve honorable mention. > > [6] Type macros are terrible anyway because of the aforementioned punchcard nostalgia leading to different projects adopting different line/format styles and compilers having no portable way to select. > I don't know of any compiler which does not default to free form for .f90/.F90 files, do you? Free format has been around for over 20 years. That some people insist on coding on 72 cols (or is it 78?) in the days of large screens is beyond me indeed. > > So I guess that you guys don't want an explicit interface for PetscBagRegisterEnum, right? I'll fix the harmless bugs in the current binding, then. > Hm - we do have explicit interfaces - for ex: VecGetArrayF90() does not work without it.. Satish > Blaise > >

1 0

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

01 Jun '12

On Jun 1, 2012, at 2:23 PM, Jed Brown wrote: > On Fri, Jun 1, 2012 at 1:34 PM, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > Apologies, will do next time. That would also have helped me realize that I had pushed to my own clone, not petsc-3.3 or petsc-dev repository... I am attaching the patch I was planing on submitting. > > Out of curiosity, what is the rationale for not wanting an explicit interface? As far as I understand, the fortran standard mandates an explicit interface in this situation (array of strings). I would understand in the situation of pure f77 compatibility for instance, but we threw this away with the iso_c_binding module anyway... > > Fortran modules are horribly nonportable from a build system perspective since every compiler manages them differently. I agree. Some compilers even change the flag names from one release to the next. > Having the interfaces requires those extra interface files in the includes that we already hate so much, and we can't protect the headers (to make including the right ones simple like in C) because you have to include them for every subroutine. Not really. You don't need to include the modules in each subroutine or function if they are included (used) in the Program or Module in which the function is defined > I think it would be better [1] for the "modern" Fortran users for PETSc to do everything with modules, using explicit interfaces for all functions, and datatypes for PETSc objects. Apart for [1], I fully agree. I actually think that there should only be two way to use fortran: the old f77 way without any type checking, interface, and where all petscobjects are integer, or the right way which you described. > Unfortunately, that forces people to spell out things like type(Mat) [2] and XGetContext() either requires an explicit interface written by the user [3] or use of the ISO C bindings in the interface [4]. Not really. As long as your context is not too large (so that allocating a copy and copying the data won't kill you), you can always write a generic interface for XGetContext that returns an array of your favorite data type, then use transfer. And when your context is large, you should pass by address anyway). Conceptually, it is not really different from casting into a *void. McCormick has a nice writeup on this http://www.macresearch.org/advanced_fortran_90_callbacks_with_the_transfer_… How does using iso_c_binding helps with a fortran library called from fortran? > I can think of no explanation for this absurdity other than that the Fortran language standards committee is the most successful global trolling agency in modern history [5]. > > Perhaps introducing f2003 in petsc was a bad idea, considering the large variety of compilers you need to support. If you feel that it introduces more issues than solving problems, feel free to strip the PetscOptionsEnum and PetscBagRegisterEnum bindings. They could easily be packaged separately for the few people who will ever need them. > > [1] Better, but it would be best for them to stop using Fortran. Why not. But what is the alternative knowing that I am not willing to give up array sections, operator overloading and vector operations? Are you going to suggest that I switch to C++? > [2] No #includes means no macros [6] and no equivalent of typedef. The only macro I would miss are CHKERRQ and SETERRQ. I would actually make an exception for these two. For numerical and string types, the fortran way of doing typedef is kind. > [3] Disaster because (a) it is maintained by the user with no way to check that it is correct and (b) the user may need multiple incompatible definitions in the same project. > [4] Indeed, the best way to write a Fortran library called from Fortran is to use the ISO C bindings. > [5] The people who dream up ways to link MKL and the Portland Group deserve honorable mention. > [6] Type macros are terrible anyway because of the aforementioned punchcard nostalgia leading to different projects adopting different line/format styles and compilers having no portable way to select. I don't know of any compiler which does not default to free form for .f90/.F90 files, do you? Free format has been around for over 20 years. That some people insist on coding on 72 cols (or is it 78?) in the days of large screens is beyond me indeed. So I guess that you guys don't want an explicit interface for PetscBagRegisterEnum, right? I'll fix the harmless bugs in the current binding, then. Blaise -- 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 01 Jun '12

01 Jun '12

On Fri, Jun 1, 2012 at 1:34 PM, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > Apologies, will do next time. That would also have helped me realize that > I had pushed to my own clone, not petsc-3.3 or petsc-dev repository... I am > attaching the patch I was planing on submitting. > > Out of curiosity, what is the rationale for not wanting an explicit > interface? As far as I understand, the fortran standard mandates an > explicit interface in this situation (array of strings). I would understand > in the situation of pure f77 compatibility for instance, but we threw this > away with the iso_c_binding module anyway... > Fortran modules are horribly nonportable from a build system perspective since every compiler manages them differently. Having the interfaces requires those extra interface files in the includes that we already hate so much, and we can't protect the headers (to make including the right ones simple like in C) because you have to include them for every subroutine. I think it would be better [1] for the "modern" Fortran users for PETSc to do everything with modules, using explicit interfaces for all functions, and datatypes for PETSc objects. Unfortunately, that forces people to spell out things like type(Mat) [2] and XGetContext() either requires an explicit interface written by the user [3] or use of the ISO C bindings in the interface [4]. I can think of no explanation for this absurdity other than that the Fortran language standards committee is the most successful global trolling agency in modern history [5]. > Perhaps introducing f2003 in petsc was a bad idea, considering the large > variety of compilers you need to support. If you feel that it introduces > more issues than solving problems, feel free to strip the PetscOptionsEnum > and PetscBagRegisterEnum bindings. They could easily be packaged separately > for the few people who will ever need them. > [1] Better, but it would be best for them to stop using Fortran. [2] No #includes means no macros [6] and no equivalent of typedef. [3] Disaster because (a) it is maintained by the user with no way to check that it is correct and (b) the user may need multiple incompatible definitions in the same project. [4] Indeed, the best way to write a Fortran library called from Fortran is to use the ISO C bindings. [5] The people who dream up ways to link MKL and the Portland Group deserve honorable mention. [6] Type macros are terrible anyway because of the aforementioned punchcard nostalgia leading to different projects adopting different line/format styles and compilers having no portable way to select.

1 0