Re: [Libmesh-devel] [Libmesh-users] exodusII write fails for example #9

[Roy S. <roy...@ic...>]

On Tue, 21 Apr 2009, Derek Gaston wrote:

> On Apr 21, 2009, at 3:15 PM, Roy Stogner wrote:
>
>> We've got lots of places where we generate meshes that will default to
>> subdomain ids 0, boundary ids 0.  So we need a convenient way to
>> change those ids.  A separate function is the most flexible way.  And
>> if we have a separate function with a clean enough API, there's no
>> reason to change all the stuff that might precede it from
>> functionA(argsA) to functionA(argsA, then_do_function_B=true).
>
> The trouble is that it's somewhat difficult to change the boundary ids after 
> they have been set.

Which is something we ought to fix, but since by "we" I mean "someone
other than me", I won't push for this as a solution to your immediate
problem.

> Your suggestion was my original thought as well... but 
> once you look at boundary_info you realize it's kind of non-trivial to 
> wholesale bump all of the boundary ids up by one... they are kept track of in 
> a couple of different places.

Loop from elem iterator first to last; on each element, call
BoundaryInfo::remove(elem) and then loop over all boundary sides and
call BoundaryInfo::add_side() for each side?  I must be missing
something - this seems easier than adding new build_* arguments would
have been.

>> Also: this was all prompted by the discovery that Exodus doesn't allow
>> 0 as a valid id?  What if we pick the largest valid id they do support
>> and map 0 to/from that?  It's kind of a hack, but then most users
>> would be able to use Exodus IO on arbitrary meshes without changing
>> their code at all.
>
> Now this is something I completely agree with.  The reason I didn't go down 
> this path is because it would cause breakages in everyone's code that uses 
> build_cube and boundary_ids currently... and it would do so silently (ie you 
> would just quietly be enforcing BC's on the wrong sides of your domain).

It shouldn't break any existing code.  If they write out meshes with
bcid=0, existing code is already broken, and getting *some* unique id
for the bcid=0 boundaries is better than failing to write the file.
If they read in meshes, the fact that bcid=0 isn't supported means we
know they're not reading in bcid=0.  If they read in bcid=(uint)(-1)
meshes... well, that will break silently.  But I'll bet it never
really happens: who's using 2^whatever-1 as a meaningful bcid?

> If this is acceptable.... and we can just make it clear this this change is 
> coming to our user community... I'm all for it.

I'd like to hear from Ben, but while this doesn't sound like an ideal
solution to me (ideal would be if Exodus natively supported bcid=0
somehow) it sounds optimal under the circumstances.
---
Roy