> The DofObject encapsulation is pretty good; that should be the only
> change you require.  If you'd like to make that change a compile-time
> option (defaulting to unsigned char - the memory usage isn't trivial),
> we'd appreciate a patch.

When you mean it isn't trivial, are you talking about the case when
you want to use say unsigned int ? Or is it non-trivial already ? I'll
look in to making this a compile time option (and will send you the
patch) but if the memory cost becomes overwhelming, I will need to
think of a better way to handle this.

Vijay

On Wed, Apr 21, 2010 at 4:12 AM, Roy Stogner <[email protected]> wrote:
>
> On Wed, 21 Apr 2010, Vijay S. Mahadevan wrote:
>
>> I probably never noticed this before but a weird bug hit me while
>> trying to run a system that has more than or equal to 256 variables.
>> The Debug assert in line 256 of DofObject.C, is responsible for this.
>> This check throws an error in Debug mode (not in other modes of
>> course). I do understand that the unsigned char is there for
>> efficiency sake but is it possible somehow to break this variable
>> limit ?
>>
>> I was originally planning on changing this data type for _n_v_comp to
>> do this but wasn't sure if that would be the only change needed and if
>> there are some dire consequences due to it.
>
> The DofObject encapsulation is pretty good; that should be the only
> change you require.  If you'd like to make that change a compile-time
> option (defaulting to unsigned char - the memory usage isn't trivial),
> we'd appreciate a patch.
>
>> Also, if anyone has solved some system with these strange
>> requirements, I'd be happy to hear about your experience.
>
> Likewise.  We're not going to hit 256 variables ourselves unless we
> really go crazy with radiation discretization in direction and
> spectra.
> ---
> Roy
>

------------------------------------------------------------------------------
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to