Hi Martin, > On 3 Jan 2017, at 17:49, Martin Kronbichler <[email protected]> > wrote: >>> 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 not match with the value > > 2.059635156600494e-06 on the owner processor 2
Can you please elaborate? My naïve understanding would be: 1. before doing interpolation, all ghost values are syncrhonized between the MPI processors 2. solution transfer would, roughly, take local values on each element, apply transformation matrices corresponding to each child and ship, if needed, interpolated values to new MPI owners of cells. 3. Each MPI would go through its cells and set values of vectors at locally active DoFs which, of course, means that at the interface between the two paritions different MPI processes may be trying to write to the same global DoF entry in the vector. In the above, i fail to see what could influence the order of operations and result in round-off errors between different MPI cores. Maybe Timo, being an author of p::d::SolutionTransfer, could comment on this? > 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. Thanks, will do. p.s. I would be happy to admit that this is not an issue at all, just wanted to have some peace of mind ;-) Regards, Denis. -- 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.
