From: Derek G. <fri...@gm...> - 2009-04-22 18:34:49
|
(Note... restricted to Devel list) On Apr 21, 2009, at 3:55 PM, Roy Stogner wrote: >> 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. Loop over what boundary sides? If you call remove(Elem) it removes all information about the sides from that element. If you mean loop over every element and look for sides with null neighbors... we could do that... but now you don't know what boundary number that side was supposed to have. Probably the easiest thing would be to add a method to BoundaryInfo... like increment_boundary_ids()... that would run through the multimaps and increment the boundary ids. The reason I didn't go this route is that it felt REALLY specialized. I could at least see someone who wasn't even using Exodus using the changes I made to build_cube... but it's hard to imagine anyone else calling this BoundaryInfo method. >>> 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? Oh - sorry I misunderstood what you were getting at. I thought you were saying that we just replace all of the mesh generation code all throughout the library to start numbering with 1 instead of zero... which would obviously break a lot of user code. I don't like this idea at all. We frequently read the solution (and subdomains AND bc_ids) out of Exodus files to start other calculations. This suggestion would have us running the original computation using subdomains of 0 and bc_ids of zero... and then we would have to know to change the input file for the next computation so that materials were matched with subdomain 65536 (or whatever) and BC's with boundary_ids of 65536. That's not much fun at all. > 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. I would like to hear from Ben as well. Unfortunately... I need this capability... like yesterday. My local code is already depending on this working... so I can't commit it to our local repositories.... Not a big deal for a little while.... but let's figure this out. Derek |