Sorry, I forgot the attachment.
--
David
David Andrs <[email protected]> wrote on 09/30/2010 09:53:33 AM:
> 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
------------------------------------------------------------------------------
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
