Let me interject a practical thing: What output format are you going to
use? Exodus _can't_ have multiple block ids per element... no matter what.
I really think that this is better handled by the user code itself. You
just need to be more flexible about assigning material properties to
subdmain ids. Basically, don't hardcode somewhere that subdomain id #3 is
steel. Instead... have a map (either in your input file or elsewhere) that
says what material to assign to which subdomain id.
So, if you have two "components" and they each have two materials (steel
and tungsten say) you would have these subdomain ids:
Component0: 0 and 1
Component1: 2 and 3
Then in your input file you would tell your code to assign the "steel"
properties to subdomain ID's 0 and 2 and assign "tungsten" properties to 1
and 3.
I really don't think we need to have the ability to have multiple ids per
element. You can always just pick a new number and assign all the
properties you want to that new number.
Derek
On Mon, Apr 8, 2013 at 10:20 AM, David Knezevic
<dkneze...@seas.harvard.edu>wrote:
>
> On 04/08/2013 11:59 AM, Roy Stogner wrote:
> >
> > On Mon, 8 Apr 2013, David Knezevic wrote:
> >
> >> I have a use-case where it'd be helpful to store multiple subdomain IDs
> >> on elements (similar to what we do for boundary IDs now).
> >>
> >> The first thing that comes to mind is changing Elem to store a
> >> std::set<subdomain_id_type>, would that be of interest in general?
> >
> > Opposing that would probably be of interest in general. We typically
> > have sizeof(subdomain_id_type)==2; squeezing even a couple pointers in
> > there would lead to megabytes of extra RAM use on large problems. The
> > boundary is generally a "cheaper" case since a problem with a million
> > elements is likely to only have ~50,000 boundary elements, and only a
> > fraction of those are on the coarse grid.
>
> Yep, agreed. I figured that since we have multiple IDs in the boundary
> case it might be of interest in the subdomain case too. But yes, the
> extra memory for the boundary IDs isn't such a big deal...
>
> I can make user code (as Ben suggested) that'll work for me case with
> the single subdomain setup (I might do some bitwise AND'ing of subdomain
> IDs with "masks")
>
> David
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
