On a related note, you might also want to add the following lines in
copy_nodes_and_elements in UnstructuredMesh.
// assign the subdomain id from old element to current one
subdomain_id_type& newsbd = elem->subdomain_id() ;
subdomain_id_type oldsbd = old->subdomain_id() ;
newsbd = oldsbd ;
This i
On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
>> There was one spot you missed that should have been converted to
>> subdomain_id, and one spot you converted that shouldn't have been
>> (although I'm not surprised, it was in a subdomain-handling function
>> and tricked me too before I ran a cla
> I would like to hear your and Ben's views on what the default should
> be; it's probably inconvenient for you to keep it switched to unsigned
> int if we're still using unsigned char.
That is interesting. I would think that since unsigned char suited for
most users needs till now, that should be
> There was one spot you missed that should have been converted to
> subdomain_id, and one spot you converted that shouldn't have been
> (although I'm not surprised, it was in a subdomain-handling function
> and tricked me too before I ran a class object test through it).
Roy, just curious as to w
On Wed, 11 Feb 2009, Paulo Vieira wrote:
> I noticed a related problem in UnstructuredMesh::all_second_order. I'm
> sorry I don't have a patch file, but it's just one line you need to
> add:
If only that were the case! Similar bugs were in all_first_order,
add_tri, flatten, and create_submesh.
On Wed, 11 Feb 2009, Roy Stogner wrote:
> On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
>
>> Do have a look at the patch and if everything looks good (conventions
>> and definition placement), do commit this.
>
> Looks good so far; let me test a couple things and I'll commit it.
There was one s
Hi all,
Attached is the patch for changing the subdomain id to a typedef'd
unsigned int from unsigned char. It fits my needs well and have not
had problems dealing with 1000's of materials now. The typedef is
defined on top of Elem.h.
Do have a look at the patch and if everything looks good (conv
Good to hear that the patch works so far.
I remember seeing in either MeshBase or UnstructuredMesh some comment
that implies usage of subdomain_id in a way that could/might mess up
things with my implementation. I will check it again and see if the
subdomain information is really used for such pur
On Wed, 11 Feb 2009, Roy Stogner wrote:
> On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
>
>> Do have a look at the patch and if everything looks good (conventions
>> and definition placement), do commit this.
>
> Looks good so far; let me test a couple things and I'll commit it.
I would like to
On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote:
> Do have a look at the patch and if everything looks good (conventions
> and definition placement), do commit this.
Looks good so far; let me test a couple things and I'll commit it.
> One more question though. It occurred to me that while doing t
On Tue, 10 Feb 2009, Kirk, Benjamin (JSC-EG) wrote:
>> Once you've got a BlockDofObject working correctly, why would you want
>> to add a templated option to use the less efficient old DofObject?
>> Just call the new one DofObject and you're done.
>
> Well, I can still see the use for an EmptyDof
> To be clear, you mean a change to
>
> typedef unsigned short int subdoman_id_t;
>
> subdomain_id_t _sbd_id;
>
> or something like that?
>
Yes. I do intend to define subdomain_id_type as a unsigned int type.
All references to _sbd_id with actually use this type instead of the
hard-coded unsigned
> Once you've got a BlockDofObject working correctly, why would you want
> to add a templated option to use the less efficient old DofObject?
> Just call the new one DofObject and you're done.
Well, I can still see the use for an EmptyDofObject...
The problem I see with only a blocked DofObject i
On Tue, Feb 10, 2009 at 2:46 PM, Vijay S. Mahadevan
wrote:
> Alright. First, I'll make the change of type for sbd_id to unsigned
> int in Elem.h and all other relevant files. I will include a patch of
> this once I have tested that it works with my code.
>
Not to look a gift horse in the mouth, b
> Alright. First, I'll make the change of type for sbd_id to unsigned
> int in Elem.h and all other relevant files. I will include a patch of
> this once I have tested that it works with my code.
To be clear, you mean a change to
typedef unsigned short int subdoman_id_t;
subdomain_id_t _sbd_id;
On Tue, 10 Feb 2009, Kirk, Benjamin (JSC-EG) wrote:
> The savings with 0 variables will be minor, but as you add variables the
> current DofObject allocates storage to keep track of how many components
> each variable has on the object, and that means for 20 variables with
> lagrange elements you
Alright. First, I'll make the change of type for sbd_id to unsigned
int in Elem.h and all other relevant files. I will include a patch of
this once I have tested that it works with my code.
And my next step would be to see if I can do something with MeshData.
Since no one is using this, from what
>>
>> But the benefit is that the user is free to implement derived
>> DofObject types which store whatever, implement additiona
>> packing/unpacking as required, then use
>> UnstructuredMeshImpl or whatever...
>>
>> Thoughts?
>
> Seems like a lot of complication to save what, a couple dozen byt
Hi Ben,
Although the idea sounds good to me at first glance, I really would
not want to inherit from one of the core objects such as DofObject and
end up messing something critical in my simulation. I had rather have
my needs as attributes or tags that can be attached and removed on
Elem's and Nod
On Tue, 10 Feb 2009, Kirk, Benjamin (JSC-EG) wrote:
> I'll dump some quick thoughts and then follow up some more later
>
>> From my perspective, the current DofObjects are too heavy. This
>> especially true in the common case of lagrange elements, as the
>> dof indexing is never used for el
I'll dump some quick thoughts and then follow up some more later
>From my perspective, the current DofObjects are too heavy. This especially
>true in the common case of lagrange elements, as the dof indexing is never
>used for elements. So I am hesitant to add anything...
At the same tim
21 matches
Mail list logo
