Thanks for the feedback. This problem was me writing to the wrong matrix
elements, and I'm so close to having a working prototype of this code. I
think the (hopefully last) bug is in this section of code:
dof_handler.clear();
dof_handler.distribute_dofs(fe);
locally_owned_dofs = dof_handler.locally_owned_dofs();
DoFTools::extract_locally_relevant_dofs(dof_handler, locally_relevant_dofs);
DynamicSparsityPattern dsp(locally_relevant_dofs);
DoFTools::make_sparsity_pattern(dof_handler, dsp);
SparsityTools::distribute_sparsity_pattern(
dsp, dof_handler.n_locally_owned_dofs_per_processor(),
MPI_COMM_WORLD, locally_relevant_dofs);
system_matrix.reinit(locally_owned_dofs, locally_owned_dofs,
dsp, MPI_COMM_WORLD);
current_solution.reinit(locally_owned_dofs,
locally_relevant_dofs, MPI_COMM_WORLD);
right_hand_side.reinit(locally_owned_dofs, MPI_COMM_WORLD);
I get a runtime exception from the TrilinosWrappers module when I call
SparseMatrix::add() on more than one processor, and I suspect that I've set
up the sparsity pattern incorrectly (maybe the system_matrix doesn't know
how to distribute entries, or it gets the wrong indices?). Is there
anything obviously wrong with what I've done here? There are a lot of notes
in the doxygen about setting up the Trilinos sparsity pattern, but nothing
I've tried (like calling compress() after setting up the matrix) works.
Ellen
On Friday, December 20, 2019 at 10:24:23 PM UTC-6, Wolfgang Bangerth wrote:
>
> On 12/20/19 6:42 PM, Ellen M. Price wrote:
> > I did eventually solve this problem, but I ran into another one. I think
> I'm
> > close, I just need a little guidance. The problems occur in assembling
> the
> > system. I've checked the right-hand side vector and it has some odd
> features.
> > I'm running the "slide" problem, just like step-33 does. I suppose my
> question
> > is, how should the system assembly routine be changed to accommodate
> > parallelization? All I did was add an if statement to check whether a
> cell is
> > locally owned before computing on it. Conceptually, what else needs to
> change?
>
> Ellen,
> not actually very much: You need a non-ghosted (writable) vector, which
> apparently you have, for your right hand side. Then you loop over the
> locally
> owned cells (which you do), and the only other thing you have to do is to
> call
> compress() at the end of the assembly.
>
> There are many other things one can do to test whether things work
> correctly,
> but "has some odd features" is not enough of a hint to allow for more
> concrete
> suggestions :-)
>
> Best
> WB
>
>
> --
> ------------------------------------------------------------------------
> Wolfgang Bangerth email: [email protected]
> <javascript:>
> www: http://www.math.colostate.edu/~bangerth/
>
>
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
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
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/9b404d3e-cd78-4290-b4d0-11b36edcc692%40googlegroups.com.
