Thank you for your help. what is strange to me is that the assembly part
has not changed for parallelization except an "if
(cell->is_locally_owned())" command at the beginning of the loop over
cells. So since the non-parallel code with the same assembly is solved with
SolverCG, the parallel one should be solved as well !!!. I don't know what
is affected by parallelization which incapacitates the SolverCG.!!
which solvers do you think I can examin and see if they can be used instead
On Monday, October 17, 2016 at 8:57:47 AM UTC-5, Daniel Arndt wrote:
> running your code with a Trilinos installation alone fails for me in line
> 1617 with
> An error occurred in line <279> of file
> </mnt/data/darndt/Sources/dealii/source/lac/trilinos_solver.cc> in function
> void dealii::TrilinosWrappers::SolverBase::do_solve(const
> The violated condition was:
> Additional information:
> AztecOO::Iterate error code -2: numerical breakdown
> and the same for no preconditioner. The same holds for PETSc. It seems
> that you should review if this matrix is assembled correctly and that CG is
> appropriate, i.e. is this matrix symmetric and positive definite?
> I can't reproduce your error
> "PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation,
> probably memory access out of range"
> running with a developer version.
> Am Montag, 17. Oktober 2016 04:47:32 UTC+2 schrieb Wolfgang Bangerth:
>> On 10/16/2016 03:46 PM, Hamed Babaei wrote:
>> > Another point I need to mention is that I had the same problem when as
>> > first try of parallelization, I paralleled a much simpler code, the
>> > based on the step-40 .
>> > I received the same Segmentation Violation error from Petsc. At that
>> time, I
>> > replaced PreconditionerAMG with PreconditionerJacobi and the problem
>> This does not help right now, but as a general rule, it is far simpler to
>> debug things when you have a small, simple program that when you have a
>> complicated one. In your case, you had a problem you didn't understand,
>> you chose to address it in a way that papered over it, rather than
>> fixed it based on an understanding of what is going on. It is a truism
>> this sort of issue will come back at some time.
>> In other words, if you have a problem, debug it until you understand what
>> problem is, and then fix it the right way. Don't paper over it.
>> Wolfgang Bangerth email: bang...@colostate.edu
>> www: http://www.math.colostate.edu/~bangerth/
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.