On 08/28/2012 02:39 PM, John Peterson wrote:
> On Tue, Aug 28, 2012 at 12:16 PM, David Knezevic
> <dknezevic@...> wrote:
>> On 08/28/2012 01:23 PM, John Peterson wrote:
>>> On Tue, Aug 28, 2012 at 10:34 AM, David Knezevic
>>> <dknezevic@...> wrote:
>>>> I'm doing some domain decomposition stuff, and I want to "stitch"
>>>> distinct (conforming) meshes together into a single global mesh. The
>>>> first step is to implement a "mesh union" operation, and I'll deal with
>>>> merging "overlapping" nodes afterwards.
>>>> To do this, I wrote a function build_mesh_union, which is pasted below.
>>>> Worth adding to MeshTools, or somewhere like that?
>>> I'd say definitely yes, but by "deal with merging overlapping nodes
>>> afterwards" did you mean *this* function would eventually do that, or
>>> that will be up to the user/another function?
>>> It seems to me that this function will be most useful if it can handle
>>> the overlaps itself...
>> I agree, it'd be good to handle that in this function, but I was originally
>> planning to do that in user code. The main reason for that is that I wanted
>> to make use of extra info that I have, e.g. which mesh connects with which
>> other mesh, and the boundary IDs of the mesh interfaces. I don't really want
>> to put all the logic inside this union function...
> OK... I just worry that people will use this function and the
> resulting mesh without reading the documentation carefully, and get a
> nasty surprise.
I agree. I'll describe it in the header as:
"Build a new mesh that is the union of all the meshes in \p meshes. This
function currently does not attempt to merge the meshes, so in general
the mesh that is returned contains meshes.size() disconnected sub-meshes."
But I think it's also tricky to provide a general merging/stitching
implementation. What if someone wants to take the union of
non-conforming meshes, or even overlapping meshes? I think the current
implementation at least has the advantage of simplicity, and users can
then post-process as necessary.