Dear All,
I compiled the library "SuperLU_MT" and got the "libsuperlu_mt_PTHREAD.a"
and "libsuperlu_mt_PTHREAD.a" to /usr/lib to /usr/lib. I am using the
following file to link but not working:
CC = gcc
CXX = g++
F77 = gfortran
LINKER = ${CXX}
WARNINGS = -Wall -pedantic -Wextra -Weffc++
Hmm, there could be a bug in our handling of the stack when reaches the
maximum. It is suppose to just stop collecting additional levels at that point
but likely it has not been tested since a lot of refactorizations.
What are you doing to have so many stack frames?
> On Feb 22, 2023,
Via a checkpoint in `PetscOptionsCheckInitial_Private`, I can confirm that
`checkstack` is set to `PETSC_TRUE` and this leads to no (additional)
information about erroneous stack handling.
Thank You,
Sajid Ali (he/him) | Research Associate
Data Science, Simulation, and Learning Division
Fermi
Hi Matt,
This is a trace from the same crash, but with `-checkstack` included in
.petscrc : https://gist.github.com/s-sajid-ali/455b3982d47a31bff9e7ee211dd43991
I don't see any additional information regarding the possible cause.
Thank You,
Sajid Ali (he/him) | Research Associate
Data
On Wed, Feb 22, 2023 at 6:32 PM Sajid Ali Syed wrote:
> Hi Matt,
>
> Adding `-checkstack` does not prevent the crash, both on my laptop and on
> the cluster.
>
It will not prevent a crash. The output is intended to show us where the
stack problem originates. Can you send the output?
Thanks,
Hi Matt,
Adding `-checkstack` does not prevent the crash, both on my laptop and on the
cluster.
What does prevent the crash (on my laptop at least) is changing
`PETSCSTACKSIZE` from 64 to 256 here :
https://github.com/petsc/petsc/blob/main/include/petscerror.h#L1153
Thank You,
Sajid Ali
On Wed, Feb 22, 2023 at 6:18 PM Sajid Ali Syed via petsc-users <
petsc-users@mcs.anl.gov> wrote:
> One thing to note in relation to the trace attached in the previous email
> is that there are no warnings until the 36th call to KSP_Solve. The first
> error (as indicated by ASAN) occurs somewhere
One thing to note in relation to the trace attached in the previous email is
that there are no warnings until the 36th call to KSP_Solve. The first error
(as indicated by ASAN) occurs somewhere before the 40th call to KSP_Solve (part
of what the application marks as turn 10 of the propagator).
Hi Barry,
Thanks a lot for fixing this issue. I ran the same problem on a linux machine
and have the following trace for the same crash (with ASAN turned on for both
PETSc (on the latest commit of the branch) and the application) :
On Wed, Feb 22, 2023 at 5:45 PM Paul Grosse-Bley <
paul.grosse-b...@ziti.uni-heidelberg.de> wrote:
> I thought to have observed the number of cycles
> with -pc_mg_multiplicative_cycles to be dependent on rtol. But I might have
> seen this with maxits=0 which would explain my missunderstanding of
I thought to have observed the number of cycles with
-pc_mg_multiplicative_cycles to be dependent on rtol. But I might have seen
this with maxits=0 which would explain my missunderstanding of richardson.
I guess PCAMGX does not use this PCApplyRichardson_MG (yet?). Because I still
see the
Preonly means exactly one application of the PC so it will never converge by
itself unless the PC is a full solver.
Note there is a PCApplyRichardson_MG() that gets used automatically with
KSPRICHARSON. This does not have an"extra" application of the preconditioner so
2 iterations of
On Wed, Feb 22, 2023 at 4:57 PM Paul Grosse-Bley <
paul.grosse-b...@ziti.uni-heidelberg.de> wrote:
> Hi again,
>
> I now found out that
>
> 1. preonly ignores -ksp_pc_side right (makes sense, I guess).
> 2. richardson is incompatible with -ksp_pc_side right.
> 3. preonly gives less output for
Hi again,
I now found out that
1. preonly ignores -ksp_pc_side right (makes sense, I guess).
2. richardson is incompatible with -ksp_pc_side right.
3. preonly gives less output for -log_view -pc_mg_log than richardson.
4. preonly also ignores -ksp_rtol etc..
5. preonly causes -log_view to
I was using the Richardson KSP type which I guess has the same behavior as
GMRES here? I got rid of KSPSetComputeInitialGuess completely and will use
preonly from now on, where maxits=1 does what I want it to do.
Even BoomerAMG now shows the "v-cycle signature" I was looking for, so I think
Hi Barry,
the picture keeps getting clearer. I did not use KSPSetInitialGuessNonzero or
the corresponding option, but using KSPSetComputeInitialGuess probably sets it
automatically (without telling one in the output of -help).
I was also confused by the preonly KSP type not working which is
> On Feb 22, 2023, at 2:56 PM, Paul Grosse-Bley
> wrote:
>
> Hi Barry,
>
> I think most of my "weird" observations came from the fact that I looked at
> iterations of KSPSolve where the residual was already converged. PCMG and
> PCGAMG do one V-cycle before even taking a look at the
Hi Barry,
I think most of my "weird" observations came from the fact that I looked at
iterations of KSPSolve where the residual was already converged. PCMG and
PCGAMG do one V-cycle before even taking a look at the residual and then
independent of pc_mg_multiplicative_cycles stop if it is
> On Feb 22, 2023, at 2:19 PM, Paul Grosse-Bley
> wrote:
>
> Hi again,
>
> after checking with -ksp_monitor for PCMG, it seems my assumption that I
> could reset the solution by calling KSPSetComputeInitialGuess and then
> KSPSetupwas generally wrong and BoomerAMG was just the only
Hi again,
after checking with -ksp_monitor for PCMG, it seems my assumption that I could
reset the solution by calling KSPSetComputeInitialGuess and then KSPSetupwas
generally wrong and BoomerAMG was just the only preconditioner that cleverly
stops doing work when the residual is already
> On Feb 22, 2023, at 1:10 PM, Paul Grosse-Bley
> wrote:
>
> Hi Mark,
>
> I use Nvidia Nsight Systems with --trace
> cuda,nvtx,osrt,cublas-verbose,cusparse-verbose together with the NVTX markers
> that come with -log_view. I.e. I get a nice view of all cuBLAS and cuSPARSE
> calls (in
OK, Nsight Systems is a good way to see what is going on.
So all three of your solvers are not traversing the MG hierching with the
correct logic.
I don't know about hypre but PCMG and AMGx are pretty simple and AMGx dives
into the AMGx library directly from out interface.
Some things to try:
*
Hi Mark,
I use Nvidia Nsight Systems with --trace
cuda,nvtx,osrt,cublas-verbose,cusparse-verbose together with the NVTX markers
that come with -log_view. I.e. I get a nice view of all cuBLAS and cuSPARSE
calls (in addition to the actual kernels which are not always easy to
attribute). For
Hi Matt,
Sorry for the late answer, it was holiday time.
Just to clarify, if you call SetIS() 3 times, and then give
-pc_fieldsplit_0_fields 0,2
then we should reduce the number of fields to two by calling
ISConcatenate() on the first and last ISes?
Exactly
I think this should not be
On Wed, Feb 22, 2023 at 11:15 AM Paul Grosse-Bley <
paul.grosse-b...@ziti.uni-heidelberg.de> wrote:
> Hi Barry,
>
> after using VecCUDAGetArray to initialize the RHS, that kernel still gets
> called as part of KSPSolve instead of KSPSetup, but its runtime is way less
> significant than the
On Tue, Feb 7, 2023 at 6:40 AM Matthew Knepley wrote:
> On Tue, Feb 7, 2023 at 6:23 AM Mark Adams wrote:
>
>> I do one complete solve to get everything setup, to be safe.
>>
>> src/ts/tutorials/ex13.c does this and runs multiple solves, if you like
>> but one solve is probably fine.
>>
>
> I
Hi Barry,
after using VecCUDAGetArray to initialize the RHS, that kernel still gets
called as part of KSPSolve instead of KSPSetup, but its runtime is way less
significant than the cudaMemcpy before, so I guess I will leave it like this.
Other than that I kept the code like in my first
27 matches
Mail list logo
