On 04/08/2013 12:49 PM, Derek Gaston wrote:
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.
This was going to be for libMesh-based mesh processing prior to a solve,
so the output format wouldn't have been an issue.
But I agree that incompatibility with Exodus is another entry in the
"cons" column.
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.
Sure, that'll work. I just raised this idea because I don't find
multiple subdomain IDs unreasonable in principle, since it's analogous
to having multiple boundary IDs, and we all agree that multiple boundary
IDs is a Good Thing.
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.
Thanks for the comments, I'll do something like this.
Best,
David
On Mon, Apr 8, 2013 at 10:20 AM, David Knezevic
<dkneze...@seas.harvard.edu <mailto: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
<mailto: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
