Prof. Wolfgang Bangerth,
Now the projection of initial values (rewrite the code by manually assemble
the matrix and system_rhs and calculate) run OK, but the time updating of T
is not correct, same phenomenon appears. I believe this may arise from the
fact that direct using matrix vmult (i.e.
mass_matrix_T.vmult (system_rhs, old_solution_T_cal);
) instead of assembling and distribute_local_to_global again may ignore
eliminating the constraint points in matrix or vector, when using
constriantMatrix and interporate_boundary_values to apply the boundary
condition, I am now checking of this.
Is there a simple way to update the RHS of old value using something simple
like vmult?
Best,
Mark
//---------------------------------------
//Updating of T in time domain------the old way, working in non-mpi version
//---------------------------------------
//
//time dependent
//assign right hand side
mass_matrix_T.vmult (system_rhs, old_solution_T_cal);
laplace_matrix_T.vmult (tmp, old_solution_T_cal);
system_rhs.add (-time_step * (1-theta), tmp);
assemble_rhs_T (time);
forcing_terms = dynamic_rhs_T;
forcing_terms *= time_step * theta;
assemble_rhs_T (time - time_step);
tmp = dynamic_rhs_T;
forcing_terms.add (time_step*(1-theta),tmp);
system_rhs.add (1,forcing_terms);
//assign system matrix
system_matrix.copy_from (mass_matrix_T);
system_matrix.add (time_step * theta, laplace_matrix_T);
在 2017年10月13日星期五 UTC+2下午4:43:30，Wolfgang Bangerth写道：
>
> On 10/13/2017 08:39 AM, Lucas Campos wrote:
> >
> > In general, using MatrixTools::apply_boundary_values() is not the
> way to go
> > with MPI programs. Rather, use a ConstraintMatrix and incorporate
> the
> > boundary
> > values into the same object as you do with hanging node constraints.
> >
> >
> > This is the way to go due to correctness, or in the sense of
> scalability?
>
> MatrixTools::apply_boundary_values() needs access to the elements of the
> matrix because it wants to modify elements after they have already been
> written into the matrix. That is already difficult if the matrix is owned
> by
> PETSc or Trilinos -- we can get access to these elements, but it is not
> efficient to do so.
>
> But the bigger issue is that the function wants to access elements not
> only
> for the rows of constrained DoFs, but also for the columns. That means
> that
> you may have to access elements that are actually stored on other
> processors
> -- something that can not be done efficiently. Consequently,
> MatrixTools::apply_boundary_values() does not attempt to eliminate columns
> of
> the matrix, and you will end up with a non-symmetric matrix even if your
> problem is symmetric.
>
> It is better to use the approach via ConstraintMatrix that deals with
> entries
> before they even get into the matrix (and therefore in particular before
> matrix entries are sent to other processors).
>
> Best
> W.
>
> --
> ------------------------------------------------------------------------
> Wolfgang Bangerth email: bang...@colostate.edu
> <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 dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
