Hi Denis,
Hi Daniel,
On 3 Jan 2017, at 15:09, Daniel Arndt <[email protected]> wrote:
Do you have a minimal working example that shows this problem?
I don’t have a MWE for this, not yet at least. The tricky part is that this
happens for some usage cases,
but the same code runs fine in other, more-or-less as complicated, usage cases.
Some ideas:
Can you confirm that the output vector you are using is "clean" in the sense
that there are no spurious ghost values before handing it to interpolate?
I call interpolate() right after calling setup_system() in my application,
which in turn does NOT assign any values to those vectors.
Within the setup_system() the initialization of output vectors is done via
MatrixFree<dim,double>::initialize_dof_vector(solution_vectors[i]);
I added
solution_vectors[i] = 0.;
right after initialization but this does not change anything, neither does
solution_vectors[i].zero_out_ghosts()
In other words: Does output.zero_out_ghosts() or output=0. help? Do you get the
same error if you are using a Trilinos or PETSc vector as output?
Luckily I have a version of the main class which uses Trilinos (same
p::d::Tria, 4 MPI cores and 2 threads each), when using it I
do not have this error. BUT it does not mean this is not happening, maybe
Trilinos parallel vectors don’t have this assert at all?
Indeed, Trilinos vectors do not have this assertion at all and happily
overwrite the values, and the contribution that happens to come last in
whatever communication pattern is chosen by Trilinos takes precedence.
The question here is whether the original check might be too rigid such
that different roundoff behavior from different sides of an
interpolation operation get different contributions. Looking at the entries:
|> value 2.059635156599626e-06,does notmatch withthe value
2.059635156600494e-06on the owner processor 2
|
the difference appears in the 13th digit. I guess that's within the
limits of the use of the vector and we might use 1e4 rather than 1e3 in
the amount of admissible deviance. Feel free to propose a patch that
changes the check.
Best,
Martin
--
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].
For more options, visit https://groups.google.com/d/optout.
