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

Compilation error with umfpack.c
by Vijay S. Mahadevan 11 Apr '11

11 Apr '11

Hi, I am working with the development version of petsc and updated the files recently. After reconfiguration, make gave the following errors. libfast in: /usr/local/lib/petsc-dev/src/mat/impls/aij/seq/umfpack umfpack.c(312): error: identifier "UMFPACK_ORDERING" is undefined ierr = PetscViewerASCIIPrintf(viewer," Control[UMFPACK_ORDERING]: %s (not using the PETSc ordering)\n",UmfpackOrderingTypes[(int)lu->Control[UMFPACK_ORDERING]]);CHKERRQ(ierr); ^ umfpack.c(431): error: identifier "UMFPACK_ORDERING" is undefined ierr = PetscOptionsEList("-mat_umfpack_ordering","Internal ordering method","None",UmfpackOrderingTypes,sizeof UmfpackOrderingTypes/sizeof UmfpackOrderingTypes[0],UmfpackOrderingTypes[(int)lu->Control[UMFPACK_ORDERING]],&idx,&flg);CHKERRQ(ierr); ^ compilation aborted for umfpack.c (code 2) /usr/bin/ar: umfpack.o: No such file or directory I've sent the entire make.log and configure.log to petsc_maint which also includes few other minor warnings in hypre.c and supportgraph (backwards compatibility). The compiler used is ifort through openmpi wrappers. It looks like a header definition UMFPACK_ORDERING might be missing. I see that umfpack.h only has UMFPACK_ORDERING_USED. Am am not sure whether I should update the umfpack externalpackage or the code to get this working. Any help would be appreciated. Vijay

1 0

Re: [petsc-dev] [buildsystem] fortranlib-autodetection
by Satish Balay 11 Apr '11

11 Apr '11

right now - you can do this with: --with-clib-autodetect=0 --with-fortranlib-autodetect=0 --with-cxxlib-autodetect=0 LIBS="-Bstatic -lfoo -Bdynamic" or whatever the correct interlanguage library interoperability list is.. Satish On Mon, 11 Apr 2011, Chen Shen wrote: > Hi all, > > In config/compilers: checkFortranLibraries(), we run the fortran linker with > -v options, and detect the list of fortran libraries to be linked. I can see > that -L -l and -rpath options are parsed, and finally added to the > PCC_LINKER_LIBS macro. > > The default behavior of ifort/icc is to link to the static version of the > following libs: imf, svml, ifport, ifcore, etc, so ifort -v will output the > -Bstatic option for these libraries. > > However, -Bstatic and -Bdynamic options are ignored in > checkFortranLibraries(). Because -Bdynamic is the default for GCC/ICC, the > dynamic library will be linked to the final application program. It is > therefore impossible to link to the static version of intel libraries. > > Currently I ignore PCC_LINKER_LIBS and do my own detection. Fortunately I am > dealing with fewer systems/compilers, and a dirty script sufficed. > But I guess it's best to detect -Bstatic/-Bdynamic > in checkFortranLibraries(). The same comments apply to clib-autodetection. > Do you think this is the way to go? Thanks! > > > Best regards, > Shen Chen >

1 0

Re: [petsc-dev] regression in petsc4py
by Hong Zhang 11 Apr '11

11 Apr '11

Pushed a fix. Let me know if the issue remains. Hong On Mon, Apr 11, 2011 at 9:15 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > My testsuite catched an issue when creating zero-sized BASIC AO's. It > is easy to reproduce (at least from Pyhon). > > In [1]: from petsc4py import PETSc > > In [2]: ao = PETSc.AO().createBasic([],[]) > --------------------------------------------------------------------------- > Error Traceback (most recent call last) > > /home/dalcinl/Devel/petsc4py-dev-tmp/<ipython console> in <module>() > > /home/dalcinl/lib64/python/petsc4py/lib/arch-linux2-c-debug/PETSc.so > in petsc4py.PETSc.AO.createBasic (src/petsc4py.PETSc.c:112438)() > > Error: error code 62 > [0] AOCreateBasic() line 341 in > /home/devel/petsc/dev/src/dm/ao/impls/basic/aobasic.c > [0] AOCreateBasicIS() line 383 in > /home/devel/petsc/dev/src/dm/ao/impls/basic/aobasic.c > [0] AOSetType() line 47 in /home/devel/petsc/dev/src/dm/ao/interface/aoreg.c > [0] AOCreate_Basic() line 294 in > /home/devel/petsc/dev/src/dm/ao/impls/basic/aobasic.c > [0] ISRestoreIndices() line 416 in > /home/devel/petsc/dev/src/vec/is/interface/index.c > [0] ISRestoreIndices_General() line 149 in > /home/devel/petsc/dev/src/vec/is/impls/general/general.c > [0] Invalid argument > [0] Must restore with value from ISGetIndices() > > > -- > 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 Satish Balay 11 Apr '11

11 Apr '11

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

regression in petsc4py
by Lisandro Dalcin 11 Apr '11

11 Apr '11

My testsuite catched an issue when creating zero-sized BASIC AO's. It is easy to reproduce (at least from Pyhon). In [1]: from petsc4py import PETSc In [2]: ao = PETSc.AO().createBasic([],[]) --------------------------------------------------------------------------- Error Traceback (most recent call last) /home/dalcinl/Devel/petsc4py-dev-tmp/<ipython console> in <module>() /home/dalcinl/lib64/python/petsc4py/lib/arch-linux2-c-debug/PETSc.so in petsc4py.PETSc.AO.createBasic (src/petsc4py.PETSc.c:112438)() Error: error code 62 [0] AOCreateBasic() line 341 in /home/devel/petsc/dev/src/dm/ao/impls/basic/aobasic.c [0] AOCreateBasicIS() line 383 in /home/devel/petsc/dev/src/dm/ao/impls/basic/aobasic.c [0] AOSetType() line 47 in /home/devel/petsc/dev/src/dm/ao/interface/aoreg.c [0] AOCreate_Basic() line 294 in /home/devel/petsc/dev/src/dm/ao/impls/basic/aobasic.c [0] ISRestoreIndices() line 416 in /home/devel/petsc/dev/src/vec/is/interface/index.c [0] ISRestoreIndices_General() line 149 in /home/devel/petsc/dev/src/vec/is/impls/general/general.c [0] Invalid argument [0] Must restore with value from ISGetIndices() -- 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] Index sets in MatCreateNest
by Jed Brown 11 Apr '11

11 Apr '11

On Mon, Apr 11, 2011 at 08:43, Thomas Witkowski < thomas.witkowski(a)tu-dresden.de> wrote: > Could some of you give me a short explanation, what the index sets in > MatCreateNest can be used for? I already had a look to the examples and > tests, but all of them just put PETSC_NULL for the index sets or create the > standard contiguous index sets by hand (ksp/ksp/example/tests/ex11.c). Does > the index sets influence the row/column indices for the final MatNest? > The primary purpose I had in mind was enabling a matrix-free method to interlace fields in the residual and Krylov vectors (e.g. for better cache reuse) while splitting them apart in the field-split preconditioner without any copies. > The reason why I'm asking for is that I want to have a special order in my > MatNest. My scenario is as follows: I have a 2x2 MatNest. The first block > corresponds to all interior nodes on all subdomains. The second block > corresponds to the boundary nodes between all subdomains. This works fine, > also with the fieldsplit preconditioner! Now I would like to permute the > global index of the second block in that way, that all edge boundary nodes > are listed first and finally all vertex boundary nodes (its a 2D problem). > This is almost certainly a bad ordering because it will not reuse cache efficiently, thus decreasing the throughput that sparse matrix kernels achieve. > So each rank local matrix of the second block is no more contiguous. I'm > not sure, if I need to change the creation of the second block matrix or the > creation of the nested matrix. I thought may be it is possible to do it with > the index sets when creating the MatNest? > If I understand what you want correctly, then you can certainly do this. Order you unknowns however you want, give MatCreateNest the index sets for interior and boundary nodes and give the same index sets to PCFieldSplit. We have not yet implemented MatSetValuesLocal_Nest because our primary model was to use MatGetLocalSubMatrix and use MatSetValuesLocal to set values on each block separately. For your purposes, calling MatSetValuesLocal(Anest,...) would probably be more convenient (but if you are currently using MatNest, you must already be assembling the blocks separately).

1 0

Re: [petsc-dev] [buildsystem] fortranlib-autodetection
by Barry Smith 11 Apr '11

11 Apr '11

On Apr 11, 2011, at 1:40 AM, Chen Shen wrote: > Hi all, > > In config/compilers: checkFortranLibraries(), we run the fortran linker with -v options, and detect the list of fortran libraries to be linked. I can see that -L -l and -rpath options are parsed, and finally added to the PCC_LINKER_LIBS macro. > > The default behavior of ifort/icc is to link to the static version of the following libs: imf, svml, ifport, ifcore, etc, so ifort -v will output the -Bstatic option for these libraries. > > However, -Bstatic and -Bdynamic options are ignored in checkFortranLibraries(). Because -Bdynamic is the default for GCC/ICC, the dynamic library will be linked to the final application program. It is therefore impossible to link to the static version of intel libraries. > > Currently I ignore PCC_LINKER_LIBS and do my own detection. Fortunately I am dealing with fewer systems/compilers, and a dirty script sufficed. > But I guess it's best to detect -Bstatic/-Bdynamic in checkFortranLibraries(). The same comments apply to clib-autodetection. Do you think this is the way to go? Thanks! > > > Best regards, > Shen Chen > Shen Chen, This is a good suggestion. Do you think you could prepare a (working/tested) patch with your proposed changes? http://www.mcs.anl.gov/petsc/petsc-as/developers/index.html#Sending_patches… Generally it is much easier for us to accept a patch then to figure out exactly what change/addition someone is suggesting by email and put them in ourselves. Barry

1 0

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

11 Apr '11

On Mon, Apr 11, 2011 at 2:02 AM, Chen Shen <hashhsah(a)gmail.com> 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? > Is there a problem with just including these options in the list of libraries? I think we keep anything that begins with a '-'. Thanks, Matt > 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 > > > -- 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

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

11 Apr '11

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

Index sets in MatCreateNest
by Thomas Witkowski 11 Apr '11

11 Apr '11

Could some of you give me a short explanation, what the index sets in MatCreateNest can be used for? I already had a look to the examples and tests, but all of them just put PETSC_NULL for the index sets or create the standard contiguous index sets by hand (ksp/ksp/example/tests/ex11.c). Does the index sets influence the row/column indices for the final MatNest? The reason why I'm asking for is that I want to have a special order in my MatNest. My scenario is as follows: I have a 2x2 MatNest. The first block corresponds to all interior nodes on all subdomains. The second block corresponds to the boundary nodes between all subdomains. This works fine, also with the fieldsplit preconditioner! Now I would like to permute the global index of the second block in that way, that all edge boundary nodes are listed first and finally all vertex boundary nodes (its a 2D problem). So each rank local matrix of the second block is no more contiguous. I'm not sure, if I need to change the creation of the second block matrix or the creation of the nested matrix. I thought may be it is possible to do it with the index sets when creating the MatNest? Thomas

1 0