On Wed, 29 Sep 2010, David Andrs wrote:
Roy Stogner <[email protected]> wrote on 09/29/2010 02:42:58 PM:
> A workaround for some types of internal boundaries is to use subdomain
> ids: i.e. if you're in subdomain 1 and your neighbor is in subdomain 3
> then you apply whatever interface condition is associated with
> std::pair<>(1,3).
Our boundary ids come as a sideset ids from exodus file. So as long I'm able to
iterate over the sideset and figure out the neighboring
subdomain id, this would be a way to go.
Good to hear. But sounds like supporting internal boundary IDs would
be more natural for your problem, though, no?
> If that workaround isn't sufficient for your case then we should talk
> about changing the API behavior. If internal boundary ids are all
> defined on the coarse mesh, then additional cases to handle that would
> be quick and easy. If you need to change boundary ids as you refine
> then life gets harder.
So far, we do not need to change the boundary ids as we refine the mesh.
In that case the solution's pretty easy: instead of calling
top_parent(), we'd iterate ourselves until parent() is NULL, but give
up and return invalid_id if is_child_on_side(which_child_am_i(..),..)
is false first. Maybe optimize for the common case by just calling
top_parent() if elem->side() is NULL.
Looks like there'd be 4 functions which need changing in
boundary_info.C. I'll look over the patch if you want to take a crack
at it, otherwise I'll probably be able to code it up myself a few
weeks from now, after our upcoming big deadline passes and after my
stuff-to-postpone-until-after-deadline queue clears up.
One more thought: I'm not really familiar with libMesh internals,
but as long as the local edge/face ids are preserved (I suspect they
are, from what I saw so far)
They are where possible; things get a little tricky for pyramids and
tets.
it should be possible to not copy the references for new internal
edges that were created by the refinement and copy only the "outer"
ones. Or not?
No copies at all necessary, not if we're still happy with boundary ids
that don't change with refinement. Even in that latter case we could
get away with just storing the changed ids and falling back on parent
values when no changed id exists.
On a somewhat-related note: if you're using internal boundary ids it's
possible that you've got a somewhat larger ID set (and are querying it
much more often) than most people. You might want to check and see if
std::unordered_multimap gives you any better performance than
std::multimap in the two containers in boundary_info.h. I suspect the
differences will be trivial, but it couldn't hurt to have someone test
and confirm that.
---
Roy
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
