April 2011 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] About the future XXXDestroy(&obj) change
by Matthew Knepley 11 Apr '11

11 Apr '11

On Mon, Apr 11, 2011 at 10:45 AM, Jed Brown <jed(a)59a2.org> wrote: > On Mon, Apr 11, 2011 at 17:43, Matthew Knepley <knepley(a)gmail.com> wrote: > >> Lisandro, this is now include/petsccompat.h > > > The file exists, but its contents are not currently useful. > Not only is it useful, its needed by petsc4py :) Matt -- 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] About the future XXXDestroy(&obj) change
by Jed Brown 11 Apr '11

11 Apr '11

On Mon, Apr 11, 2011 at 17:43, Matthew Knepley <knepley(a)gmail.com> wrote: > Lisandro, this is now include/petsccompat.h The file exists, but its contents are not currently useful.

1 0

Re: [petsc-dev] About the future XXXDestroy(&obj) change
by Matthew Knepley 11 Apr '11

11 Apr '11

On Mon, Apr 11, 2011 at 10:39 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > On 11 April 2011 12:23, Chen Shen <hashhsah(a)gmail.com> wrote: > > The message about xxxDestroy was posted on 1st April... > > > > Interesting, I did not notice it was posted on 1st April. You know, in > my country > > > I sincerely hope the > > message was meant for that day alone. > > > > Well, I think Barry was serious about this. But do not worry, such > change is very easy to handle by including a backward compatibility > header. We could even make petsc.h to automatically include this > header under the control of a preprocessor define, let say > -DPETSC_BACKWARD. > Lisandro, this is now include/petsccompat.h Matt > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169 > -- 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] regression in petsc4py
by Lisandro Dalcin 11 Apr '11

11 Apr '11

On 11 April 2011 11:38, Hong Zhang <hzhang(a)mcs.anl.gov> wrote: > Pushed a fix. Let me know if the issue remains. > Hong > Back to normal. Many thanks! -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] About the future XXXDestroy(&obj) change
by Lisandro Dalcin 11 Apr '11

11 Apr '11

On 11 April 2011 12:23, Chen Shen <hashhsah(a)gmail.com> wrote: > The message about xxxDestroy was posted on 1st April... > Interesting, I did not notice it was posted on 1st April. You know, in my country > I sincerely hope the > message was meant for that day alone. > Well, I think Barry was serious about this. But do not worry, such change is very easy to handle by including a backward compatibility header. We could even make petsc.h to automatically include this header under the control of a preprocessor define, let say -DPETSC_BACKWARD. -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] About the future XXXDestroy(&obj) change
by Chen Shen 11 Apr '11

11 Apr '11

The message about xxxDestroy was posted on 1st April... I sincerely hope the message was meant for that day alone. shenchen On Mon, Apr 11, 2011 at 11:07 PM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > Barry, I'm working on getting petsc4py ready for our XXXDestroy > change. A quick question: Are the XXXDestroy_YYY functions of subtypes > going to change? I would ask you to NOT change them (it's harder for > you to implement, it's harder for me to provide backward > compatibility, IMHO there is not a compelling reason as these > destructors should not set the pointer to zero, etc.). > > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169 >

1 0

Re: [petsc-dev] Compilation error with umfpack.c
by Vijay S. Mahadevan 11 Apr '11

11 Apr '11

Jed, My UMFPACK version was V5.4.0 (May 20, 2009). I've removed the umfpack directory and have reconfigured. And make went through successfully ! Thanks for the quick reply. Vijay On Mon, Apr 11, 2011 at 10:09 AM, Jed Brown <jed(a)59a2.org> wrote: > On Mon, Apr 11, 2011 at 17:00, Vijay S. Mahadevan <vijay.m(a)gmail.com> wrote: >> >> Hi, >> >> I am working with the development version of petsc and updated the >> files recently. After reconfiguration, make gave the following errors. > > changeset: 18670:8990aa4897ee > user: Jed Brown <jed(a)59A2.org> > date: Sat Mar 26 12:24:03 2011 +0300 > summary: Update Umfpack interface to 5.5.1 > You need to use Umfpack-5.5.1 with petsc-dev. If you installed Umfpack with > --download-umfpack, then you should > rm -r $PETSC_ARCH/conf/UMFPACK $PETSC_ARCH/include/umfpack* > $PETSC_ARCH/lib/libumfpack* externalpackages/UMFPACK* > and reconfigure.

1 0

Re: [petsc-dev] Compilation error with umfpack.c
by Jed Brown 11 Apr '11

11 Apr '11

On Mon, Apr 11, 2011 at 17:00, Vijay S. Mahadevan <vijay.m(a)gmail.com> wrote: > Hi, > > I am working with the development version of petsc and updated the > files recently. After reconfiguration, make gave the following errors. > changeset: 18670:8990aa4897ee user: Jed Brown <jed(a)59A2.org> date: Sat Mar 26 12:24:03 2011 +0300 summary: Update Umfpack interface to 5.5.1 You need to use Umfpack-5.5.1 with petsc-dev. If you installed Umfpack with --download-umfpack, then you should rm -r $PETSC_ARCH/conf/UMFPACK $PETSC_ARCH/include/umfpack* $PETSC_ARCH/lib/libumfpack* externalpackages/UMFPACK* and reconfigure.

1 0

About the future XXXDestroy(&obj) change
by Lisandro Dalcin 11 Apr '11

11 Apr '11

Barry, I'm working on getting petsc4py ready for our XXXDestroy change. A quick question: Are the XXXDestroy_YYY functions of subtypes going to change? I would ask you to NOT change them (it's harder for you to implement, it's harder for me to provide backward compatibility, IMHO there is not a compelling reason as these destructors should not set the pointer to zero, etc.). -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] [buildsystem] support for --start-group/--end-group
by Chen Shen 11 Apr '11

11 Apr '11

Yes. the LIBS way will certainly work. Thanks! Our previous solution to this is to combine all mkl .a libraries I want to use into a single mkl.a library. Looks stupid but works fine. I'm posting the question in the devep list, because I wish to looking beyond a quick fix. I am setting up an automatic building system in the company, and with it, we want to build many variants of Petsc and our application program for benchmarking/testing/release. That's why I become interested in the internals Petsc build system, and start thinking how it can work better. I'll read this part of the code a bit more, and dig deeper in the past discussions in this list... regards, shenchen On Mon, Apr 11, 2011 at 10:29 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > Currently things specified with LIBS option remain untouched by > configure.. > > so you could try > > LIBS="$(MKLROOT)/lib/intel64/libmkl_scalapack_lp64.a -Wl,--start-group \ > $(MKLROOT)/lib/intel64/libmkl_intel_lp64.a \ > $(MKLROOT)/lib/intel64/libmkl_sequential.a \ > $(MKLROOT)/lib/intel64/libmkl_core.a \ > $(MKLROOT)/lib/intel64/libmkl_blacs_intelmpi_lp64.a -Wl,--end-group \ > -lpthread " --with-scalapack=1 > > Satish > > On Mon, 11 Apr 2011, Chen Shen wrote: > > > Hi all, > > > > Currently, there is an option to specify the blas/lapack library > > files --with-scalapack-lib=[<list of .a files>]. This is indeed > necessary, > > because MKL provides a large choice of libraries to link against. > > > > However, MKL static libraries have object inter-dependencies, and > requires > > --start-group/--end-group linker options. All libraries in the group are > > searched repeatedly until all inter-dependencies resolved. > > For example, the following options is suggested for a configuration ( > > http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/) > > > > $(MKLROOT)/lib/intel64/libmkl_scalapack_lp64.a -Wl,--start-group > > $(MKLROOT)/lib/intel64/libmkl_intel_lp64.a > > $(MKLROOT)/lib/intel64/libmkl_sequential.a > > $(MKLROOT)/lib/intel64/libmkl_core.a > > $(MKLROOT)/lib/intel64/libmkl_blacs_intelmpi_lp64.a -Wl,--end-group > > -lpthread > > > > I'd like to propose an extension to the --with-scalapack-lib syntax to > > support start/end group. Consider the following example: > > --with-blas-lapack-lib=[ /xxx/scalapack_lp64.a, > [/xxx/libmkl_intel_lp64.a, > > /xxx/libmkl_sequential.a, libmkl_core.a, > /xxx/libmkl_blacs_intelmpi_lp64.a] > > ] > > > > The embedded list indicates a set of libraries to be grouped up. Would > this > > be possible? > > > > This isn't a problem if we link to dynamic libraries, because -l for > dynamic > > libraries doesn't have to be ordered as in the case of static libraries. > > I hate the wicked order rule for .a libraries, but have to live with > it... > > > > Further, I guess -Bstatic options are dropped somewhere (I haven't > checked > > it in detail). The final PACKAGES_LIBS macro never contains -Bstatic, so > end > > application will always link to the static libraries. > > > > > > Regards, > > Shen Chen > > > >

1 0