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,
>>>
>>
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
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 created with
>>&
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
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 fu
t; 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 'SolveA
e not viable: requires 5 arguments, but 4 were
provided
void SolveAfter
^
Regards,
Denis
> On 5 Sep 2017, at 16:43, Satish Balay wrote:
>
> You could try (with petsc master):
>
> --download-elemental-commit=v0.87.7
>
> Latest elemental master appears to have majo
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,
>
>> I just tried compil
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”
https://bitbucket.org/petsc/petsc/src/90564b43f6b05485163c147b464b5d6d28cde3ef/config/BuildSystem/config/p
n 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 wrote:
>>
>> Thanks Barry, I can confir
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
> https://bitbucket.org/petsc/petsc/commits/4f290403fdd060d09d5cb07345cbfd52670e3cbc
> to the maint,
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:
/Users/davydden/spack/opt/spack/darwin-sierr
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 num
> 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 python scripts. See
PC_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?
>
> Jose
>
works.
Kind regards,
Denis
> On 11 Jul 2016, at 00:29, Denis Davydov 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 cause...
>
> Kind
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 wrote:
>
> I debuged a bit your code, install_name
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 wrote:
>
> Hi Jose,
>
rting this.
> Jose
>
>
>> El 10 jul 2016, a las 18:36, Denis Davydov escribió:
>>
>> Dear developers,
>>
>> Slepc 3.6.3 used to produce the following result of install names:
>>
>> $ otool -lv libslepc.dylib | grep slepc
>> libslepc.dylib
Dear developers,
Slepc 3.6.3 used to produce the following result of install names:
$ otool -lv libslepc.dylib | grep slepc
libslepc.dylib:
name
/Users/davydden/spack/opt/spack/darwin-elcapitan-x86_64/clang-7.3.0-apple/slepc-3.6.3-b35zhzknp4lrt5r2iksagql2jkya2vfl/lib/libslepc.3.6.3.dyli
> 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 build a package
http:/
> On 19 Mar 2016, at 18:20, Satish Balay 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 Mar 2016, De
> On 19 Mar 2016, at 18:15, Satish Balay wrote:
>
> On Sat, 19 Mar 2016, Denis Davydov wrote:
>
>>
>>> On 19 Mar 2016, at 17:38, Matthew Knepley wrote:
>>>
>>> On Sat, Mar 19, 2016 at 11:29 AM, Satish Balay >> <mailto:ba...@
be static
>def getPreprocessorFlagsName(self, language):
> -if language in ['C', 'Cxx', 'FC']:
> +if language == 'C':
>flagsArg = 'CPPFLAGS'
> +elif language == 'Cxx':
> + flagsArg =
x27;'
> > > self.includeDirectories = sets.Set()
> > > return
> > >
> > > And then [I'm not sure where this gets used..]
> > >
> > > $ git diff config/BuildSystem/config/base.py |cat
> > > diff --git a/config/BuildSystem
aqnz2iltdo7fdhlayvuaxel/lib'
>> clang: warning: argument unused during compilation:
>> '-L/Users/davydden/spack/opt/spack/darwin-x86_64/clang-7.0.2-apple/metis-5.1.0-i5y5b6r5ca4f77u5tketagpkn6joxasp/lib'
>> clang: warning: argument unused during compilation:
>
sers/davydden/spack/opt/spack/darwin-x86_64/clang-7.0.2-apple/ncurses-6.0-sabhdwxbdbbapfo6wodglfmyo6u3c3hj/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&#
'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:
>
>> Hi Satish,
>>
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 t
> 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
> normalization. This means t
> On 8 Mar 2016, at 11:39, Jose E. Roman wrote:
>
>
>> El 8 mar 2016, a las 11:28, Denis Davydov escribió:
>>
>> Dear all,
>>
>> I have some issues with Krylov-Schur applied to GHEP, namely, that different
>> runs on the same machine with th
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
eigenfunction[1].l
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 wrote:
>
> Dear all,
>
> I call Mat
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 iss
> On 29 Feb 2016, at 18:50, Jose E. Roman wrote:
>
>
>> El 29 feb 2016, a las 7:45, Denis Davydov escribió:
>>
>> Dear all,
>>
>> It would be good if SLEPc would store a location of PETSc used during the
>> build in some
>> config file,
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
differen
> On 19 Nov 2015, at 11:19, Jose E. Roman wrote:
>
>>
>> El 19 nov 2015, a las 10:49, Denis Davydov escribió:
>>
>> Dear all,
>>
>> I was trying to get some scaling results for the GD eigensolver as applied
>> to the density functional the
> On 19 Nov 2015, at 11:19, Jose E. Roman wrote:
>
>>
>> El 19 nov 2015, a las 10:49, Denis Davydov escribió:
>>
>> Dear all,
>>
>> I was trying to get some scaling results for the GD eigensolver as applied
>> to the density functional the
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 cas
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
suppression file),
> 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 rapidly
That I understa
> 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 with
zero Dirichle
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 the
> direct solver,
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.
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) /usr/local/opt/slepc/real/lib/
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 the
same number of M
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
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
SONAME_FU
Thanks Jose for the prompt (as always) reply.
I will post further questions if I encounter any issues with the outlined
approach.
Kind regards,
Denis
> On 29 Oct 2015, at 18:39, Jose E. Roman wrote:
>
>>
>> El 29/10/2015, a las 13:32, Denis Davydov > <mailto:davyd
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 w
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 .linuxbrew_openblas/opt/sle
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 if anything
> does no
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, const_cast(EPSKRYLOVSCHUR)
Oh, I see.
Thanks for clarifying it, Barry.
Regards,
Denis.
> On 12 Jul 2015, at 20:17, Barry Smith 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.
>
>
> Barry
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 id
> On 18 Jan 2015, at 17:49, Jose E. Roman 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
> used for the
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 EPSWh
>
> 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 se
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
>
> I would not recommend that, since it is not implemented in all solvers.
I see, thanks.
Regards,
Denis.
> 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.
> 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 ma
> 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
> 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
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
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 wrote:
>
> This case is discussed in section 3.4.2 of SLEPc's users guide. Basically,
> the
Dear all,
I am solving a generalised eigenvalue problem
S \cdot v = a M \cdot v (1)
using Krylov-Schur eigensolver with the shift-and-invert transformation.
Now I would like to expand the problem to the case
[S + c^\ast \otimes c ] \cdot v = a M \cdot v (2),
where “c” is s
67 matches
Mail list logo
