libMesh: A C++ Finite Element Library

On Sun, 11 Jan 2009, Kirk, Benjamin (JSC-EG) wrote:

> So I have a need to add variables to a system which exist in only
> part of the domain.  The natural way to implement it would seem to
> be using subdomain element flags which define what lives where.
>
> Now, for the API...
>
> we currently have
> System::add_variable(name, type)
>
> what do you think about
> System::add_variable(name, type, active_subdomain_bitmask)
>
> where the active subdomain bitmask is just that, and could be a
> default value to the method which indicates active everywhere?
>
> Seems a little low tech, but preserves the API and should do the
> trick nicely(?)

An optional add_variable argument is definitely the right way to do
it; the only question is what data type to use for it.  A vector<bool>
would be inefficient for users who already encode other information in
high subdomain numbers.  A set of subdomain ids would work, but the
default empty set would intuitively correspond to "this variable goes
nowhere", whereas we need an efficient default for "this variable goes
everywhere".  An actual bitmask (where you do a bitwise or with the
subdomain id) would be very efficient but would be too restrictive on
existing subdomain numbering.

I guess I'd go with a set<unsigned char> (or set<subdomain_t> when we
ever get around to that), but with the special understanding in the
code that an empty set means "put this variable everywhere".  I can't
think of an efficient way to make that more intuitive but not too much
more complex.
---
Roy

On Sun, Jan 11, 2009 at 7:52 PM, Roy Stogner <roystgnr@...:

>
> On Sun, 11 Jan 2009, Kirk, Benjamin (JSC-EG) wrote:
>
> I guess I'd go with a set<unsigned char> (or set<subdomain_t> when we
> ever get around to that), but with the special understanding in the
> code that an empty set means "put this variable everywhere".  I can't
> think of an efficient way to make that more intuitive but not too much
> more complex.


This gets my vote.  I can't see why you would ever want to call
add_variable() and have that variable applied _nowhere_... so I think it's
ok to infer that an empty set means everywhere.

Ben, if you add this capability.... it will be a godsend for us.  We're just
getting ready to need this in our own codes... (specifically for fluid
structure interaction problems).

Derek

Not a bad idea... But it feels counterintuitive when you are calling  
add_variable()... Personally it would feel backward.

That said I'm not against the idea.

Sent from my iPhone

On Jan 12, 2009, at 12:12 AM, Tim Kroeger <tim.kroeger@... 
 > wrote:

> Dear Derek/Roy,
>
> On Sun, 11 Jan 2009, Derek Gaston wrote:
>
>> On Sun, Jan 11, 2009 at 7:52 PM, Roy Stogner <roystgnr@... 
>> >wrote:
>>
>>> On Sun, 11 Jan 2009, Kirk, Benjamin (JSC-EG) wrote:
>>>
>>> I guess I'd go with a set<unsigned char> (or set<subdomain_t> when  
>>> we
>>> ever get around to that), but with the special understanding in the
>>> code that an empty set means "put this variable everywhere".  I  
>>> can't
>>> think of an efficient way to make that more intuitive but not too  
>>> much
>>> more complex.
>>
>> This gets my vote.  I can't see why you would ever want to call
>> add_variable() and have that variable applied _nowhere_... so I  
>> think it's
>> ok to infer that an empty set means everywhere.
>
> Just an idea from me: What about the other way around: You use a  
> set<subdomain_t> that specifies all the subdomains on which the  
> variable is *not* added.  Then, an empty set naturally corresponds  
> to adding the variable everywhere.
>
> Best Regards,
>
> Tim
>
> -- 
> Dr. Tim Kroeger
> tim.kroeger@...            Phone +49-421-218-7710
> tim.kroeger@...            Fax   +49-421-218-4236
>
> Fraunhofer MEVIS, Institute for Medical Image Computing
> Universitaetsallee 29, 28359 Bremen, Germany
>

Dear Derek/Roy,

On Sun, 11 Jan 2009, Derek Gaston wrote:

> On Sun, Jan 11, 2009 at 7:52 PM, Roy Stogner <roystgnr@...:
>
>> On Sun, 11 Jan 2009, Kirk, Benjamin (JSC-EG) wrote:
>>
>> I guess I'd go with a set<unsigned char> (or set<subdomain_t> when we
>> ever get around to that), but with the special understanding in the
>> code that an empty set means "put this variable everywhere".  I can't
>> think of an efficient way to make that more intuitive but not too much
>> more complex.
>
> This gets my vote.  I can't see why you would ever want to call
> add_variable() and have that variable applied _nowhere_... so I think it's
> ok to infer that an empty set means everywhere.

Just an idea from me: What about the other way around: You use a 
set<subdomain_t> that specifies all the subdomains on which the 
variable is *not* added.  Then, an empty set naturally corresponds to 
adding the variable everywhere.

Best Regards,

Tim

-- 
Dr. Tim Kroeger
tim.kroeger@...            Phone +49-421-218-7710
tim.kroeger@...            Fax   +49-421-218-4236

Fraunhofer MEVIS, Institute for Medical Image Computing
Universitaetsallee 29, 28359 Bremen, Germany

On Mon, 12 Jan 2009, Tim Kroeger wrote:

> Just an idea from me: What about the other way around: You use a 
> set<subdomain_t> that specifies all the subdomains on which the variable is 
> *not* added.  Then, an empty set naturally corresponds to adding the variable 
> everywhere.

I thought about this, but it seemed too fragile to me: you've got
variable A defined on one subdomain, variable B defined on a second
subdomain, then you find you can't add a third subdomain to your mesh
without editing your add_variable() calls for A and B?
---
Roy

On Mon, 12 Jan 2009, Roy Stogner wrote:

> On Mon, 12 Jan 2009, Tim Kroeger wrote:
>
>> Just an idea from me: What about the other way around: You use a 
>> set<subdomain_t> that specifies all the subdomains on which the variable is 
>> *not* added.  Then, an empty set naturally corresponds to adding the 
>> variable everywhere.
>
> I thought about this, but it seemed too fragile to me: you've got
> variable A defined on one subdomain, variable B defined on a second
> subdomain, then you find you can't add a third subdomain to your mesh
> without editing your add_variable() calls for A and B?

Well, that's a good point.  What about using a pointer to 
std<subdomain_t> then a let a NULL pointer mean "all subdomains"?  I 
(as a user) would prefer this because it does not re-define the 
meaning of something that has a natural meaning.

Best Regards,

Tim

-- 
Dr. Tim Kroeger
tim.kroeger@...            Phone +49-421-218-7710
tim.kroeger@...            Fax   +49-421-218-4236

Fraunhofer MEVIS, Institute for Medical Image Computing
Universitaetsallee 29, 28359 Bremen, Germany

On Mon, 12 Jan 2009, Tim Kroeger wrote:

> On Mon, 12 Jan 2009, Roy Stogner wrote:
>
>> On Mon, 12 Jan 2009, Tim Kroeger wrote:
>> 
>>> Just an idea from me: What about the other way around: You use a 
>>> set<subdomain_t> that specifies all the subdomains on which the variable 
>>> is *not* added.  Then, an empty set naturally corresponds to adding the 
>>> variable everywhere.
>> 
>> I thought about this, but it seemed too fragile to me: you've got
>> variable A defined on one subdomain, variable B defined on a second
>> subdomain, then you find you can't add a third subdomain to your mesh
>> without editing your add_variable() calls for A and B?
>
> Well, that's a good point.  What about using a pointer to std<subdomain_t> 
> then a let a NULL pointer mean "all subdomains"?  I (as a user) would prefer 
> this because it does not re-define the meaning of something that has a 
> natural meaning.

It's up to Ben (don't look a gift horse in the code he's writing for
you, or something like that), but to me this sounds like the best idea
so far.
---
Roy

On Mon, 12 Jan 2009, Roy Stogner wrote:

> On Mon, 12 Jan 2009, Tim Kroeger wrote:
>
>> Well, that's a good point.  What about using a pointer to std<subdomain_t> 
>> then a let a NULL pointer mean "all subdomains"?  I (as a user) would 
>> prefer this because it does not re-define the meaning of something that has 
>> a natural meaning.
>
> It's up to Ben (don't look a gift horse in the code he's writing for
> you, or something like that), but to me this sounds like the best idea
> so far.

Well, I'm not looking a gift horse in anything for this situation 
because I won't be using this functionality in the near future.  I was 
just "on the fly" taking a hand in the discussion.

Best Regards,

Tim

-- 
Dr. Tim Kroeger
tim.kroeger@...            Phone +49-421-218-7710
tim.kroeger@...            Fax   +49-421-218-4236

Fraunhofer MEVIS, Institute for Medical Image Computing
Universitaetsallee 29, 28359 Bremen, Germany

>> It's up to Ben (don't look a gift horse in the code he's writing for
>> you, or something like that), but to me this sounds like the best idea
>> so far.
> 
> Well, I'm not looking a gift horse in anything for this situation
> because I won't be using this functionality in the near future.  I was
> just "on the fly" taking a hand in the discussion.

It shall be so.  Internally, I'll probably define a Variable class to
encapsulate some of these details, but the idea of an optional pointer to a
set seems like a good way to go.  An empty set will denote the standard
behavior - i.e. active everywhere.

-Ben