So... I just committed the initial round of changes to allow attaching a
Preconditioner object to either a linear or nonlinear solver and it
works!
I'm already using this in my code with a special preconditioner object to do
fairly complicated solver library (petsc/trilinos) agnostic preconditi
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
Dear Derek,
On Mon, 9 Feb 2009, Derek Gaston wrote:
> On Feb 9, 2009, at 9:18 AM, John Peterson wrote:
>
>> Short answer: check out aclocal.m4 around line 869. We just use grep
>> and sed to figure out what the petsc version is during configure. You
>> could probably do the same for HYPRE_foo..
13 matches
Mail list logo
