Roy Stogner <[email protected]> wrote on 09/29/2010 03:51:25 PM:
>
> 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.
>
Attached is the patch that does it for boundary_id() and boundary_ids().
If you could check that I understood you correctly...
I also tried that with my little test code that I sent earlier and it
seems to work (I tried 1 and 2 levels of refinements)
What are the other 2 functions that need this fix?
> > 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
Right now we have only one inner boundary, so the ID set is not that much
bigger. Maybe later we get to something bigger.
> 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
--
David Andrs
------------------------------------------------------------------------------
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
