Daniel,
in addition to Philip's answer that I think both summarizes how to do
this in serial and the difference between interpolation and projections,
here are a couple other considerations:
I am attempting to write a program which projects a solution vector from
mesh A to mesh B. Both meshes are parallel distributed and have
different geometries (the first is adaptively refined, the latter has
uniform grid size).
This sentence already captures the key issue you are up against: If you
have two parallel triangulations, even if they cover the same geometry,
they are generally partitioned in different ways among the processes.
What that implies that if a process with mesh B needs information about
a point x on one of its locally owned cells, it needs to ask A for that
information. But x may not be part of the locally owned cells of mesh A,
and so the information is not available on the current process.
In other words, you cannot do interpolation (or projection) from one
parallel mesh to another without (a lot of) communication. Machinery
such as FEFieldFunction or...
- - I create a child of the Function class which takes in a
solution vector and its corresponding mesh (both parallel distributed).
This function allows the solution vector to be evaluated at any
coordinate within the domain (and should also consider ghost elements).
...the function you describe is likely not prepared to do this kind of
communication. As a consequence...
The resulting vector correctly projects to some elements, however other
*elements appear to be set to 0* (incorrectly).
...I suspect that the zeros you get have something to do with querying
the other mesh at points that are simply not locally owned, and about
which you therefore don't know anything. I don't know, without seeing
the implementation, why you get zeros when I would have assumed that the
right answer should be to get an exception that simply terminates the
program because there is nothing you can do about the situation. But you
probably get what I'm getting at.
In addition, the number
of elements that are zero and their *locations vary with the number of
processors used*. I suspect that it may be something to do with
project() not being able to handle ghost elements but I’m not sure. It
is very possible that the Function used to evaluate the input vector at
any coordinate is incorrect, i have included it in a text file below. I
have tried using both FEFieldFunction() and later
find_all_active_cells_around_point() but to no avail (the latter appears
to return empty for these zeroed elements, even after I perturb the
coordinate by a significant amount when no cell is found or use a high
tolerance).
Right. If you're looking for the cells that surround a point, but there
is no locally owned (or ghost) cell that does so, it rightly returns an
empty list.
What you want to do does not have an easy solution. The
FERemovePointEvaluation framework can help you with it, however. You
probably want to read through step-87 and step-89 and see how that can
be helpful to you.
Best
W.
--
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/e698edda-737f-4f83-9b74-d9a74fdbf32c%40colostate.edu.
