Re: [petsc-users] Output cell data related to DMDA

I see, thank you Barry. I will try to go this 1DoF route to visualize the data. Sincerely, Denis > Am 18.12.2020 um 12:46 schrieb Barry Smith : > >  > >>> On Dec 18, 2020, at 5:33 AM, Denis Davydov wrote: >>> >>> Thanks Barry, >>> >>

Re: [petsc-users] Output cell data related to DMDA

and cell-centered > values you might find DMSTAG is more useful for your needs. > > Barry > > > > >> On Dec 18, 2020, at 4:05 AM, Denis Davydov wrote: >> >> Hi Barry, >> >> What I am after is to output one scalar per cell of DMDA (for example he

Re: [petsc-users] Output cell data related to DMDA

easier to visualize in MATLAB). Sincerely, Denis > Am 18.12.2020 um 10:03 schrieb Barry Smith : > >  > >>> On Dec 18, 2020, at 2:29 AM, Denis Davydov wrote: >>> >>> Hi Matt, >>> >>> By global vector you mean one cre

Re: [petsc-users] Output cell data related to DMDA

clarify what PETSc expect as a “global” vector in case of cell-based quantities as opposed to unknowns/fields associated with the DMDA discretization? Sincerely, Denis > Am 17.12.2020 um 18:58 schrieb Matthew Knepley : > >  >> On Thu, Dec 17, 2020 at 12:18 PM Denis Davydov wr

[petsc-users] Output cell data related to DMDA

Dear all, I would like to output cell data (eg conductivity coefficient) in VTK for DMDA setup. Given that I know how many elements/cells are owned locally, I hoped that PetscViewerVTKAddField with PETSC_VTK_CELL_FIELD would do the job. However I am not sure whether provided vector should be

Re: [petsc-users] Elemental support is outdated?

-3.7.6 > > Satish > > On Tue, 5 Sep 2017, Denis Davydov wrote: > >> I already tried building PETSc with 0.87.7, the error is: >> >> petsc-3.7.6/src/mat/impls/elemental/matelem.cxx:653:7: error: no matching >> function for call to 'SolveAfter' >

Re: [petsc-users] Elemental support is outdated?

gt; > Latest elemental master appears to have major changes [including C++14 > reqirement] - so that might require more work.. > > Satish > > On Tue, 5 Sep 2017, Denis Davydov wrote: > >> Hi Karl, >> >> Thanks for the prompt reply, >> I did not notic

Re: [petsc-users] Elemental support is outdated?

Hi Karl, Thanks for the prompt reply, I did not notice that I was not looking at the master branch. I will try with 0.87.4... It would still be good if PETSc supports the most recent Elemental. Regards, Denis. > On 5 Sep 2017, at 15:10, Karl Rupp wrote: > > Hi Denis, >

[petsc-users] Elemental support is outdated?

Dear developers, I just tried compiling PETSc with Elemental 0.87.7 and got compiler errors (see below) which suggests that the interface in PETSc is outdated. Looking at the “elemental.py”

Re: [petsc-users] [3.7.5] strange config error on macOS with XCode 8.3 and Clang 8.1.0

he right order; in my case, I have to > reinstall Fortran, MPI, HDF5 and PETSc. When one doesn't do it in the right > order, it appears problems like what you reported. > > Santiago > >> On 29 Mar 2017, at 07:26, Denis Davydov <davyd...@gmail.com> wrote: >&g

Re: [petsc-users] [3.7.5] strange config error on macOS with XCode 8.3 and Clang 8.1.0

Thanks Barry, I can confirm that an adaptation of your patch to 3.7.5 allows to compile PETSc. Regads, Denis. > On 29 Mar 2017, at 06:23, Barry Smith wrote: > > > I have added the commit >

[petsc-users] [3.7.5] strange config error on macOS with XCode 8.3 and Clang 8.1.0

Dear all, Yesterday I updated to the latest XCode and now have problems configuring PETSc (see below). I must say that a number of other packages which need MPI fortran wrappers compiled fine. Regards, Denis. == Executing:

[petsc-users] pc gamg did not converge in sinv where it used to

Dear all, I rerun calculations (unit tests) which used to work with slightly older versions of PETSc/SLEPc (a year ago, or so) and see the "KSPSolve has not converged” error for shift and invert transformation with gamg preconditioner (below). Shifted matrix is SPD, could have bad condition

Re: [petsc-users] [Slepc 3.7.1][macOS] install name is set to build folder instead of prefix

> On 11 Jul 2016, at 21:06, Jose E. Roman wrote: > > I don't understand why I don't get this warning. > Still I don't see where the problem is. Please tell me exactly what you want > me to change, or better make a pull request. The problem has to do with the assumptions in

Re: [petsc-users] [Slepc 3.7.1][macOS] install name is set to build folder instead of prefix

gt; $ cd ~/tmp > $ ln -s $SLEPC_DIR . > $ cd slepc-3.7.1 > $ ./configure > $ make > $ otool -lv $PETSC_ARCH/lib/libslepc.dylib | grep slepc > > I don't get a warning, and the output of otool is the same that would result > if done on $SLEPC_DIR. > Which warning are you getting? &

Re: [petsc-users] [Slepc 3.7.1][macOS] install name is set to build folder instead of prefix

works. Kind regards, Denis > On 11 Jul 2016, at 00:29, Denis Davydov <davyd...@gmail.com> wrote: > > Hi Jose, > > Please, disregard my last email. The order of arguments is correct. > I still have an issue, though. I will debug it further and try to find what’s > the

Re: [petsc-users] [Slepc 3.7.1][macOS] install name is set to build folder instead of prefix

Hi Jose, Please, disregard my last email. The order of arguments is correct. I still have an issue, though. I will debug it further and try to find what’s the cause... Kind regards, Denis > On 10 Jul 2016, at 22:26, Denis Davydov <davyd...@gmail.com> wrote: > > I debuged

Re: [petsc-users] [Slepc 3.7.1][macOS] install name is set to build folder instead of prefix

I debuged a bit your code, install_name should be used as follows: install_name_tool -id That is, you need to change around “installName” variable and “dst” and then it works as expected. Kind regards, Denis > On 10 Jul 2016, at 18:56, Denis Davydov <davyd...@gmail.com> wrote

Re: [petsc-users] [Slepc 3.7.1][macOS] install name is set to build folder instead of prefix

week or so. > Thanks for reporting this. > Jose > > >> El 10 jul 2016, a las 18:36, Denis Davydov <davyd...@gmail.com> escribió: >> >> Dear developers, >> >> Slepc 3.6.3 used to produce the following result of install names: >> >> $ otool -lv

[petsc-users] [Slepc 3.7.1][macOS] install name is set to build folder instead of prefix

Dear developers, Slepc 3.6.3 used to produce the following result of install names: $ otool -lv libslepc.dylib | grep slepc libslepc.dylib: name

Re: [petsc-users] Cannot find a C preprocessor OSX

> On 19 Mar 2016, at 20:00, Satish Balay wrote: > > But I would think 'mpicc -show' should show this. [if spack is setting > up these options via MPI wrappers] they set up compiler wrappers (clang in this case), where they pass -L and -I flags for all libraries used to

Re: [petsc-users] Cannot find a C preprocessor OSX

> On 19 Mar 2016, at 18:20, Satish Balay <ba...@mcs.anl.gov> wrote: > > If '-show' is not listing these -L options - where is mpicc picking them up > from? that’s how Spack does things somewhere behind the curtains. Regards, Denis. > > Satish > > On Fri, 18

Re: [petsc-users] Cannot find a C preprocessor OSX

> On 19 Mar 2016, at 18:15, Satish Balay <ba...@mcs.anl.gov> wrote: > > On Sat, 19 Mar 2016, Denis Davydov wrote: > >> >>> On 19 Mar 2016, at 17:38, Matthew Knepley <knep...@gmail.com> wrote: >>> >>> On Sat, Mar 19, 2016 at

Re: [petsc-users] Cannot find a C preprocessor OSX

: > +if language == 'C': >flagsArg = 'CPPFLAGS' > +elif language == 'Cxx': > + flagsArg = 'CXXCPPFLAGS' > +elif language == 'FC': > + flagsArg = '' > elif language == 'CUDA': >flagsArg = 'CUDAPPFLAGS' > else: > > > S

Re: [petsc-users] Cannot find a C preprocessor OSX

glfmyo6u3c3hj/lib' >> clang: warning: argument unused during compilation: >> '-L/Users/davydden/spack/opt/spack/darwin-x86_64/clang-7.0.2-apple/openssl-1.0.2g-answvmhu3lodpmgulgzryygkkimmsn34/lib' >> clang: warning: argument unused during compilation: >> '-L/Users/davydden/spack/opt/spack/darwin-x86_64/clang-7.0.2-apple/parmetis-4.0.3-auubrjcwhqmqnpoqjwgwgz4bcjnxzunx/lib' >> >> On Fri, 18 Mar 2016, Denis Davydov wrote: >> >>> Dear all, >>> >>> Although I saw this issue on the mailing list, that was related to broken >>> compilers, i don’t think it’s the case here as `mpicc -E` seems to be ok. >>> Log is attached. >>> >>> Kind regards, >>> Denis >>> >>> >>

Re: [petsc-users] Cannot find a C preprocessor OSX

dbbapfo6wodglfmyo6u3c3hj/lib' > clang: warning: argument unused during compilation: > '-L/Users/davydden/spack/opt/spack/darwin-x86_64/clang-7.0.2-apple/openssl-1.0.2g-answvmhu3lodpmgulgzryygkkimmsn34/lib' > clang: warning: argument unused during compilation: > '-L/Users/davydden/spack/opt/spack/d

Re: [petsc-users] build with Scalapack/Blacs from MKL (failed to compile a test)

> > Sorry - I don't have a good answer for this issue.. Could this be related to the usage of GNU compilers? But since MUMPS linked and tests run, i don’t see how this is possible. Regards, Denis. > > Satish > > > On Mon, 14 Mar 2016, Denis Davydov wrote: &g

[petsc-users] build with Scalapack/Blacs from MKL (failed to compile a test)

Dear all, What is the correct way to build PETSc with Scalapack/Blacs from MKL? I tried: —with-scalapack-lib=/path/to/mkl/lib/intel64/libmkl_scalapack_lp64.so /path/to/mkl/lib/intel64/libmkl_blacs_openmpi_lp64.so —with-scalapack-include=/path/to/mkl/include but PETSc config fails to compile a

Re: [petsc-users] [SLEPc] non-deterministic behaviour in GHEP with Krylov-Schur

> On 8 Mar 2016, at 12:38, Jose E. Roman wrote: > > As you can see, the eigenvector for the first eigenvalue (which is simple) is > the same in both runs. The rest are multiple eigenvalues, so the > corresponding eigenvectors are not uniquely determined simply by >

Re: [petsc-users] [SLEPc] non-deterministic behaviour in GHEP with Krylov-Schur

> On 8 Mar 2016, at 11:39, Jose E. Roman <jro...@dsic.upv.es> wrote: > > >> El 8 mar 2016, a las 11:28, Denis Davydov <davyd...@gmail.com> escribió: >> >> Dear all, >> >> I have some issues with Krylov-Schur applied to GHEP, namely, that diff

[petsc-users] [SLEPc] non-deterministic behaviour in GHEP with Krylov-Schur

Dear all, I have some issues with Krylov-Schur applied to GHEP, namely, that different runs on the same machine with the same number of MPI cores gives different eigenvectors results. Here is an example: mass.InfNorm =15.625 stiff.InfNorm=726.549 eigenfunction[0].linf=0.459089

Re: [petsc-users] MatIsSymmetric / MatIsHermitian issues for MPI+complex

Nevermind, i should have check the error code: 45: [1]PETSC ERROR: No support for this operation for this object type 45: [1]PETSC ERROR: Matrix of type does not support checking for symmetric > On 7 Mar 2016, at 11:21, Denis Davydov <davyd...@gmail.com> wrote: > > Dear a

[petsc-users] MatIsSymmetric / MatIsHermitian issues for MPI+complex

Dear all, I call MatIsSymmetric and MatIsHermitian for MPI complex-valued matrix in PETSc. For a moment, i store a mass matrix (real-valued, symmetric) in a matrix. However, the result of both functions is NOT PETSC_TRUE. The same program works fine with a single MPI core. Are there any known

Re: [petsc-users] [SLEPc] record against which PETSc installation it was compiled

> On 29 Feb 2016, at 18:50, Jose E. Roman <jro...@dsic.upv.es> wrote: > > >> El 29 feb 2016, a las 7:45, Denis Davydov <davyd...@gmail.com> escribió: >> >> Dear all, >> >> It would be good if SLEPc would store a location of PETSc use

[petsc-users] [SLEPc] record against which PETSc installation it was compiled

Dear all, It would be good if SLEPc would store a location of PETSc used during the build in some config file, e.g. `slepcconf.h`, so that this information could be retrieved by external libraries (e.g. deal.ii) to prevent configuring with PETSc and SLEPc while SLEPc was linking to a

Re: [petsc-users] [SLEPc] GD is not deterministic when using different number of cores

> On 19 Nov 2015, at 11:19, Jose E. Roman <jro...@dsic.upv.es> wrote: > >> >> El 19 nov 2015, a las 10:49, Denis Davydov <davyd...@gmail.com> escribió: >> >> Dear all, >> >> I was trying to get some scaling results for the GD eigen

Re: [petsc-users] [SLEPc] GD is not deterministic when using different number of cores

> On 19 Nov 2015, at 11:19, Jose E. Roman <jro...@dsic.upv.es> wrote: > >> >> El 19 nov 2015, a las 10:49, Denis Davydov <davyd...@gmail.com> escribió: >> >> Dear all, >> >> I was trying to get some scaling results for the GD eigen

[petsc-users] [SLEPc] GD is not deterministic when using different number of cores

Dear all, I was trying to get some scaling results for the GD eigensolver as applied to the density functional theory. Interestingly enough, the number of self-consistent iterations (solution of couple eigenvalue problem and poisson equations) depends on the number of MPI cores used. For my

Re: [petsc-users] CG+GAMG convergence issues in GHEP Krylov-Schur for some MPI runs

Hi Mark, > On 12 Nov 2015, at 21:16, Mark Adams wrote: > > There is a valgrind for El Capitan now and I have it. It runs perfectly > clean. Do you compile it yourself or use Homebrew / MacPorts? I always seem to have some noise it valgrind at least from OpenMPI (even with

Re: [petsc-users] CG+GAMG convergence issues in GHEP Krylov-Schur for some MPI runs

After running in debug mode it seems that the GAMG solver indeed did not converge, however throwing the error leads to SIGABRT (backtrace and frames are below). It is still very suspicious why would solving for (unchanged) mass matrix wouldn't converge inside SLEPc's spectral transformation. p.s.

Re: [petsc-users] CG+GAMG convergence issues in GHEP Krylov-Schur for some MPI runs

Hi Hong, > On 6 Nov 2015, at 16:09, Hong wrote: > > Denis: > Do you use shift-and-invert method for solving eigenvalue problem? no, it’s just shift with zero value. So for GHEP one inverts B-matrix. > If so, the linear problems would be extremely ill-conditioned, for which

Re: [petsc-users] CG+GAMG convergence issues in GHEP Krylov-Schur for some MPI runs

> On 6 Nov 2015, at 16:22, Matthew Knepley wrote: > > Is it possible that the matrix is rank deficient? Jacobi will just chug along > and sometimes work, but > AMG will fail spectacularly in that case. It should not. It is just a mass (overlap) matrix coming from linear FEs

Re: [petsc-users] CG+GAMG convergence issues in GHEP Krylov-Schur for some MPI runs

> On 6 Nov 2015, at 17:39, Barry Smith wrote: > > > If it is a true mass matrix in the finite element sense of the word then it > should be very well conditioned and one definitely would not use something > like GAMG on. Jacobi + CG or maybe SSOR + CG should converge

[petsc-users] CG+GAMG convergence issues in GHEP Krylov-Schur for some MPI runs

Dear all, I experience strange convergence problems in SLEPc for GHEP with Krylov-Schur and CG + GAMG. The issue appears to be contingent on the number of MPI cores used. Say for 8 cores there is no issue and for 4 cores there is an issue. When I substitute GAMG with Jacobi for the problematic

Re: [petsc-users] CG+GAMG convergence issues in GHEP Krylov-Schur for some MPI runs

Hi Jose, > On 3 Nov 2015, at 12:20, Jose E. Roman wrote: > > I am answering the SLEPc-related questions: > - Having different number of iterations when changing the number of processes > is normal. the change in iterations i mentioned are for different preconditioners, but

Re: [petsc-users] CG+GAMG convergence issues in GHEP Krylov-Schur for some MPI runs

Jose, Even when I have PETSc --with-debugging=1 and SLEPc picks it up during configure, i don’t seem to have debug symbols in resulting SLEPc lib (make stage): warning: no debug symbols in executable (-arch x86_64) Same when starting a debugger: warning: (x86_64)

Re: [petsc-users] soname seems to be absent in OS-X

Hi Barry, I think you use it already. After configure /lib/petsc/conf/petscvariables : SL_LINKER_FUNCTION = -dynamiclib -install_name $(call SONAME_FUNCTION,$(1),$(2)) -compatibility_version $(2) -current_version $(3) -single_module -multiply_defined suppress -undefined dynamic_lookup

[petsc-users] create PC, KSP, ST separately and use in EPS

Dear all, I am currently looking at ways to extend deal.II PETSc/SLEPc wrappers classes to allow specification of linear solvers and preconditioners to be used in SLEPc eigensolvers using deal.II objects and NOT the command line arguments. All examples and unit tests I came across in SLEPc

[petsc-users] [SLEPc] any restriction on the calling order of EPS functions?

Dear developers, I wonder if there are any restriction (apart from obvious) on the calling order of EPS functions? Is the following logic correct: once I create EPS object (and specified it’s type) ierr = EPSCreate (mpi_communicator, eps); ierr = EPSSetType (eps,

Re: [petsc-users] [SLEPc] any restriction on the calling order of EPS functions?

Thanks Jose and Hong for the prompt reply. I will let you know if I encounter any issues due to calling function in different order. Kind regards, Denis > On 27 Oct 2015, at 15:39, Jose E. Roman wrote: > > Yes, in principle you can set options in any order. Let us know

[petsc-users] soname seems to be absent in OS-X

Dear developers, It seems that the compiled PETSc library does not have a soname (-Wl,-install_name=xyz.dylib in OS-X). I compile PETSc/SLEPc using Homebrew both on OS-X and Linux and judging from ldd/otool there is indeed a difference: Linux (soname is there): $ ldd

Re: [petsc-users] Hypre 2.10 lapack undefined symbols (OS-X)

Oh, I see. Thanks for clarifying it, Barry. Regards, Denis. On 12 Jul 2015, at 20:17, Barry Smith bsm...@mcs.anl.gov wrote: Denis, PETSc doesn't build hypre to used standalone, it builds hypre to be called from PETSc; hence those tests failing doesn't mean anything is wrong.

[petsc-users] Hypre 2.10 lapack undefined symbols (OS-X)

Dear all, I have Lapack-related undefined symbols errors when trying to run tests on Hypre, configured and compiled by PETSc (./configure --download-superlu_dist --download-metis --download-parmetis --with-cc=mpicc --with-cxx=mpicxx --with-fc=mpif90 --with-debugging=0 --download-hypre). Any

[petsc-users] set shift while not setting target

Dear all, What is the expected behaviour when a user set shift value via STSetShift() with shift or shift-and-invert transformations, but ignores setting target via EPSSetTarget ? From the Table 2.2 (chapter 2.3), it seems that Target are used only in conjunction with EPS_TARGET_XXX of

Re: [petsc-users] set shift while not setting target

On 18 Jan 2015, at 17:49, Jose E. Roman jro...@dsic.upv.es wrote: STSetShift() is a remnant of the old interface, before the target was introduced. The intended usage for the application is to use a target (set with EPSSetTarget) in combination with EPS_TARGET_XXX. STSetShift() could be

Re: [petsc-users] KrylovSchur solver diverges when setting EPS_GHEP

Hi Jose, A follow up question on KrylovSchur solver: One last thing, if I force EPSSetTrueResidual(eps, PETSC_TRUE) will that guarantee that EPSComputeRelativeError() will give the norm consistent to that, used internally by all SLEPc solvers? I would not recommend that, since it is not

Re: [petsc-users] KrylovSchur solver diverges when setting EPS_GHEP

sinvert should give you more that 2 eigenvalues if you set eps_nev 2. You may need to increase the number of iterations with eps_max_it i would expect that it should, but it is not the case. I tried setting number of iterations 10 times the number of DoFs, and no change. It does not seem

[petsc-users] KrylovSchur solver diverges when setting EPS_GHEP

Dear all, I was trying to set the problem type to EPS_GHEP as the matrices in the considered generalised eigenvalue problem are real and symmetric. However, this breaks the solver's convergence as compared to the default, non-symmetric case. The residual is quite small (~1e-9). I am puzzled

Re: [petsc-users] KrylovSchur solver diverges when setting EPS_GHEP

What do you mean by 'breaks convergence'? Are you sure your matrices are symmetric? Jose I mean the solver does not converge. Whereas if I do not specify that the matrices are symmetric and generalised non-symmetric eigenvalue problem is considered, everything is all right. However, i am

Re: [petsc-users] KrylovSchur solver diverges when setting EPS_GHEP

What do you mean by 'breaks convergence'? Are you sure your matrices are symmetric? Jose I shall clarify that the calculated by EPSComputeResidualNorm residual norm is bigger than the required tolerance, set by EPSSetTolerances. In light of your latest answer about B-norms, supposedly

Re: [petsc-users] KrylovSchur solver diverges when setting EPS_GHEP

Yes, EPSComputeResidualNorm uses the 2-norm. it is clear now, thanks for your prompt answers. Maybe it would be better if the stopping criterion in symmetric problems would be more similar to the non-symmetric case. I will think about it. It would be good if you could send me sample

Re: [petsc-users] KrylovSchur solver diverges when setting EPS_GHEP

Yes, EPSComputeResidualNorm uses the 2-norm. One last thing, if I force EPSSetTrueResidual(eps, PETSC_TRUE) will that guarantee that EPSComputeRelativeError() will give the norm consistent to that, used internally by all SLEPc solvers? Thanks. Regards, Denis.

Re: [petsc-users] KrylovSchur solver diverges when setting EPS_GHEP

I would not recommend that, since it is not implemented in all solvers. I see, thanks. Regards, Denis.

Re: [petsc-users] wrap MATMPIAIJ in MatShellSetOperation and use in SLEPc

Dear Jose, Thanks for your prompt answer. Now I see the problem. I will give it a try with -st_matmode shell” first and see how it goes... Kind regards, Denis On 13 Oct 2014, at 19:27, Jose E. Roman jro...@dsic.upv.es wrote: This case is discussed in section 3.4.2 of SLEPc's users guide.