Denis, Do you have a minimal working example that shows this problem?
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? 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? Given that we test SolutionTransfer in the testsuite, I would suspect that this is related to your setup of the output vector. Best, Daniel Am Dienstag, 3. Januar 2017 09:19:55 UTC+1 schrieb Denis Davydov: > > Relevant backtrace is: > > frame #4: 0x00000001085b8c86 libdeal_II.g.8.5.0-pre.dylib`void > dealii::deal_II_exceptions::internals::issue_error<dealii::LinearAlgebra::distributed::Vector<double>::ExcNonMatchingElements>(handling=abort_on_exception, > > file="/Users/davydden/libs-sources/deal.ii/davydden/include/deal.II/lac/la_parallel_vector.templates.h", > > line=686, function="void > dealii::LinearAlgebra::distributed::Vector<double>::compress_finish(::dealii::VectorOperation::values)", > > cond="*read_position == Number() || std::abs(local_element(j) - > *read_position) <= std::abs(local_element(j)) * 1000. * > std::numeric_limits<real_type>::epsilon()", > exc_name="ExcNonMatchingElements(*read_position, local_element(j), > part.this_mpi_process())", e=ExcNonMatchingElements @ 0x00007fff5fbfa5e0) + > 134 at exceptions.h:285 > frame #5: 0x00000001085b6d41 > libdeal_II.g.8.5.0-pre.dylib`dealii::LinearAlgebra::distributed::Vector<double>::compress_finish(this=0x00000001261087c8, > > operation=insert) + 2401 at la_parallel_vector.templates.h:681 > frame #6: 0x00000001085b516f > libdeal_II.g.8.5.0-pre.dylib`dealii::LinearAlgebra::distributed::Vector<double>::compress(this=0x00000001261087c8, > > operation=insert) + 47 at la_parallel_vector.templates.h:494 > frame #7: 0x000000010a150a73 > libdeal_II.g.8.5.0-pre.dylib`dealii::parallel::distributed::SolutionTransfer<3, > > dealii::LinearAlgebra::distributed::Vector<double>, dealii::DoFHandler<3, > 3> >::interpolate(this=0x00007fff5fbfb5b8, all_out=size=120) + 2451 at > solution_transfer.cc:183 > > but that's not really helpful. > > On Monday, January 2, 2017 at 5:50:32 PM UTC+1, Denis Davydov wrote: >> >> Hi all, >> >> I came across a very weird problem today. When using >> p::d::SolutionTransfer during refinement I get the following error >> during interpolate step at the second refinement cycle: >> >> 61: An error occurred in line <686> of file </Users/davydden/spack/var/ >> spack/stage/dealii-develop-7douosfpwd62254laf4et7n6x64b62fh/dealii/ >> include/deal.II/lac/la_parallel_vector.templates.h> in function >> 61: void dealii::LinearAlgebra::distributed::Vector<double>:: >> compress_finish(::dealii::VectorOperation::values) >> 61: The violated condition was: >> 61: *read_position == Number() || std::abs(local_element(j) - * >> read_position) <= std::abs(local_element(j)) * 1000. * std:: >> numeric_limits<real_type>::epsilon() >> 61: Additional information: >> 61: Called compress(VectorOperation::insert), but the element >> received from a remote processor, value 2.059635156599626e-06, does not >> match with the value 2.059635156600494e-06 on the owner processor 2 >> >> I am quite certain that SolutionTransfer gets parallel vectors with (i) >> constraints distributed (ii) ghosted, That is accomplished by >> >> constraints.distribute (solution_vectors[i]); >> solution_vectors[i].update_ghost_values(); >> >> >> and a minor trick (prior to those lines) to change ghost index set when >> combining matrix-free and Kelly, as discussed here >> https://groups.google.com/d/msg/dealii/-FMHGdn18fE/w6YotFXRAAAJ >> >> Between this point and the usage of solution transfer, there is only >> Kelly estimator / DataOutput and cell marking involved. >> >> >> The issue appears for a very specific problem and does not happen always. >> So far it looks like a hidden *Heisenbug*, which gets triggered in >> certain cases. >> Not knowing the details of p::d::SolutionTransfer class, I am not quite >> sure where to dig next. >> Given the fact that ghost values should be consistent among MPI >> processes, I don't see a way how the interpolation during solution transfer >> could lead to such discrepancies. >> >> 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.
