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

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 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 would understand in the situation of pure f77 compatibility for instance, but we threw this away with the iso_c_binding module anyway... 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. 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] switch petsc-dev to use --with-shared-libraries by default?
by Jed Brown 01 Jun '12

01 Jun '12

On Fri, Jun 1, 2012 at 1: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. Is this the part that PETSc is doing incorrectly now? > xlc also insists that all libraries linked > are .so, so trying to link in static library archives will confuse it > as well. This should be avoided everywhere.

1 0

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

01 Jun '12

Yep, I was trying to have PETSc build a flapackblas and that was falling over. I have a pre-built blas/lapack that I should have tried switching over to. A On Fri, Jun 1, 2012 at 9:18 PM, Satish Balay <balay(a)mcs.anl.gov> 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.. > > 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 Satish Balay 01 Jun '12

01 Jun '12

On Fri, 1 Jun 2012, Satish Balay wrote: > > Or I can make the configure test much stricter so that this compiler is rejected [for PETSC_USE_F2003] ok - pushed this fix. Satish

1 0

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

01 Jun '12

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 are .so, so trying to link in static library archives will confuse it as well.

1 0

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

01 Jun '12

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.. 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 Satish Balay 01 Jun '12

01 Jun '12

On Fri, 1 Jun 2012, Blaise Bourdin wrote: > > On Jun 1, 2012, at 11:44 AM, Satish Balay wrote: > > > Ok - nightly builds on opensolaris has the following error. > > > > character(kind=c_char),pointer :: nullc => null() > > Character(kind=C_char,len=99),Dimension(:),Pointer::list1 > > > >>>>>>>>>>>>>>>>>>>>>>> > > /export/home/petsc/soft/mpich2-1.2.1p1/bin/mpif90 -D__INSDIR__="" -O -moddir=include -M/export/home/petsc/petsc33/include -M/export/home/petsc/petsc33/arch-opensolaris-pkgs-opt/include -M/export/home/petsc/soft/mpich2-1.2.1p1/include -I/export/home/petsc/petsc33/include -I/export/home/petsc/petsc33/arch-opensolaris-pkgs-opt/include -I/export/home/petsc/soft/mpich2-1.2.1p1/include -c /export/home/petsc/petsc33/src/sys/objects/f2003-src/fsrc/optionenum.F -o CMakeFiles/petsc.dir/src/sys/objects/f2003-src/fsrc/optionenum.F.o > > > > CArray = (/(c_loc(list1(i)),i=1,Len),c_loc(nullc)/) > > ^ > > "/export/home/petsc/petsc33/src/sys/objects/f2003-src/fsrc/optionenum.F", Line = 33, Column = 25: ERROR: C_LOC function argument must be a variable that has the TARGET attribute and is interoperable, or an allocated allocatable variable that has the target attribute and has interoperable type and type parameters. > > ^ > > "/export/home/petsc/petsc33/src/sys/objects/f2003-src/fsrc/optionenum.F", Line = 33, Column = 50: ERROR: C_LOC function argument must be a variable that has the TARGET attribute and is interoperable, or an allocated allocatable variable that has the target attribute and has interoperable type and type parameters. > > > > f90comp: 3218 SOURCE LINES > > f90comp: 2 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI > > *** Error code 1 > > <<<<<<<<<<<<<< > > > > How to fix? > > What compiler is this? petsc@n-gage:~/petsc33$ f90 -V f90: Sun Fortran 95 8.3 SunOS_i386 Patch 127002-07 2009/05/18 Usage: f90 [ options ] files. Use 'f90 -flags' for details petsc@n-gage:~/petsc33$ > 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? Don't have to commit experimental changes. If you give me diffs [via e-mail] - I can compile and check the outcome. Or I can make the configure test much stricter so that this compiler is rejected [for PETSC_USE_F2003] Satish > > 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). 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 > >> > > > >

1 0

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

01 Jun '12

On Fri, Jun 1, 2012 at 1:05 PM, Aron Ahmadia <aron.ahmadia(a)kaust.edu.sa>wrote: > Broken on BG/P with XL compilers, but this is a BuildSystem issue. > I recall you were fighting with this recently. Did you figure out what was wrong? Does it really make sense for any normal user to build with shared libs there? I agree with Barry about the user experience building on most common hardware: laptops, desktops, and small servers. > > A > > On Fri, Jun 1, 2012 at 9:03 PM, Barry Smith <bsmith(a)mcs.anl.gov> 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] switch petsc-dev to use --with-shared-libraries by default?
by Aron Ahmadia 01 Jun '12

01 Jun '12

Broken on BG/P with XL compilers, but this is a BuildSystem issue. A On Fri, Jun 1, 2012 at 9:03 PM, Barry Smith <bsmith(a)mcs.anl.gov> 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

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

01 Jun '12

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