On Thu, Sep 20, 2012 at 9:43 AM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:

libMesh currently supports overlapping boundary ids (which is good:
e.g. the same boundary can be labeled with your application's
NO_SLIP_FLOW id and with it's ISOTHERMAL_TEMP id).  The easiest way to
access boundary ids on sides has always been with
BoundaryInfo::boundary_id(elem,side) (which is bad: boundary_id()
returns the first id it sees and ignores all the rest) - looking at
every id properly required getting a vector from boundary_ids() and
then searching the vector.

Wait.  Are you saying that you consider boundary_ids() difficult?

// pseudo code
ids = boundary_info.boundary_ids(elem, side)
for id in ids:
  if id == right_boundary:
    add_right_boundary_contributions()
  elif id == left_boundary:
    add_left_boundary_contributions()

// or, even better

ids = boundary_info.boundary_ids(elem, side)
for id in ids:
  boundary_condition_map[id].add_contributions()
... 
 
We've now got a new API that's as easy to use for most simple cases:
BoundaryInfo::has_boundary_id() (and something similar in FEMContext),
which takes an id and returns true or false depending on whether that
id is on the side.  This has the advantage of letting you write one
simple boundary-id-dependent physics class but not have that class
break when it's composed with another physics class using different
ids.

You prefer to loop over all possible boundary ids on each side calling "has_boundary_id()" over just getting the ids for that side and doing the correct thing directly?  I don't really understand that...
 
Is it time to mark BoundaryInfo::boundary_id() with
libmesh_deprecated(), then get rid of it in a couple years?

Yes.  I would say so.  It could definitely lead to bugs and odd behavior.

Derek