Hi everyone,
I have continued trying to fix the issue below on my own. First, I
discovered that the extrapolate function is thoroughly tested inside the
testsuite, so I went there to see how it is used to fix my MWE, but I
still get the exception. This led me to conclude that some
triangulations with certain refinement pattern triggers the compress
exception, while other do not, including the triangulation that is
created in the make_tria function of the file
"tests/mpi/fe_tools_extrapolate_common.h" of the deal.II repository. To
convince you of this I have attached a patch that changes the refinement
pattern in the aforementioned make_tria function. With the patch applied
on the v9.6.1 repository, running again the tests
"mpi/fe_tools_extrapolate_03***" will throw the same exception mentioned
in my previous mails for three mpi ranks.
*To summarize, I think there is a real bug involved since one can
trigger the exception just by changing the triangulation involved in the
"mpi/fe_tools_extrapolate*" tests*, touching nothing about the
interpolation and extrapolation code*.* Now, the problem is that I still
don't understand why some triangulations works and others don't.
Clearly, my affirmation on the triggering condition from my previous
emails is imperfect, ghost hanging nodes seems to be a sufficient but
not necessary condition to throw the exception. For example, the below
distributed triangulation on the left triggers the exception, while the
one on the right don't:
I will continue to investigate by diving into the internal functions of
extrapolate, but I would welcome some help on this since I am not really
familiar with the p4est code.
Best regards,
Guilhem
On 10/04/2025 14:31, Guilhem Poy wrote:
As a complement (I realized I should have put this in the first
email), here is (one of) the exception that is thrown with the
attached MWE from my first mail:
/An error occurred in line <738> of file
</home/gpoy/.local/share/deal-ii-candi/tmp/unpack/deal.II-v9.6.1/include/deal.II/base/partitioner.templates.h>
in function
void
dealii::Utilities::MPI::Partitioner::import_from_ghosted_array_finish(dealii::VectorOperation::values,
const dealii::ArrayView<const ElementType, MemorySpaceType>&, const
dealii::ArrayView<ElementType, MemorySpace>&, const
dealii::ArrayView<ElementType, MemorySpace>&,
std::vector<ompi_request_t*>&) const [with Number = double;
MemorySpaceType = dealii::MemorySpace::Host]
The violated condition was:
*read_position == Number() ||
internal::get_abs(locally_owned_array[j] - *read_position) <=
internal::get_abs(locally_owned_array[j] + *read_position) * 100000. *
std::numeric_limits<typename numbers::NumberTraits<
Number>::real_type>::epsilon()
Additional information:
Called compress(VectorOperation::insert), but the element received
from a remote processor, value 0.7071067811865476, does not match with
the value 0 on the owner processor 0
/
I also realized I was wrong below for the actual vector that fails to
compress when there are ghost hanging nodes: I think it corresponds to
the output vector "u2" in ExtrapolateImplementation<dim, spacedim,
OutVector>::extrapolate_parallel.
Best
Guilhem
On 10/04/2025 10:13, Guilhem Poy wrote:
Dear deal-ii users and developers,
I am trying to use the FETools::extrapolate method on a distributed
triangulation that is adaptively refined. However, I get an exception
inside this function every time my triangulation contains hanging
nodes at ghost interfaces. I have attached a minimal working example
that illustrates this on deal.II version 9.6.1. It should be compiled
in debug mode as for usual dealii example codes, and then run with
"mpirun -np 2 main" with two mpi ranks to generate the exception. The
macro NO_GHOST_HANGING_NODES can be commented out to check that
FETools::extrapolate works correctly when there are no hanging nodes
at ghost interfaces.
Before opening a bug, I would like to check with you that I am not
doing something wrong in this test program. I was careful to set up
my distributed vectors as large as possible (i.e. with all relevant
dofs) to see if the problem was coming from there, and of course I
updated the ghost values of the "coarse" vector before calling
FETools::extrapolate. If I am not mistaken, the exception is thrown
when an internal vector with all relevant dofs is compressed line
1455 of fe_tools_extrapolate.templates.h, but of course this internal
vector depends on the input vector I give to extrapolate so the
problem could very much come from my code. I am ready to provide any
further information that may be useful! Thanks in advance.
Best regards,
Guilhem
--
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.
To view this discussion visit
https://groups.google.com/d/msgid/dealii/d7dc9be5-a5c0-4fe4-b18f-46958934b7b5%40gmail.com.
diff --git a/tests/mpi/fe_tools_extrapolate_common.h b/tests/mpi/fe_tools_extrapolate_common.h
index 1271abc3f3..abd30e5f05 100644
--- a/tests/mpi/fe_tools_extrapolate_common.h
+++ b/tests/mpi/fe_tools_extrapolate_common.h
@@ -78,16 +78,13 @@ make_tria()
typename parallel::distributed::Triangulation<dim>::active_cell_iterator cell;
GridGenerator::hyper_cube(*tria, 0., 1.);
tria->refine_global(2);
- for (int i = 0; i < 2; ++i)
- {
- cell = tria->begin_active();
- cell->set_refine_flag();
- ++cell;
- if (cell != tria->end())
- cell->set_refine_flag();
-
- tria->execute_coarsening_and_refinement();
- }
+ cell = tria->begin_active();
+ for (unsigned int i = 0; i < 5; ++i)
+ if (cell!=tria->end())
+ ++cell;
+ if (cell!=tria->end())
+ cell->set_refine_flag();
+ tria->execute_coarsening_and_refinement();
return tria;
}
