Re: [Libmesh-devel] Why do we use vector<vector> instead of a matrix in FE?

[Lei S. <sto...@gm...>]

Hi Ben,

Actually, It is not important to me. I'm trying to learn object oriented
design and meta-programming skills for scientific computing from libMesh.
Right now, I only use a very thin layer of encapsulation in my code.
Coupling is very tight there. I read some source code of libMesh and ask
several questions to you guys. Roy suggested me to do some tests. I think
the best way to learn a lib is to work on it. So this is the story. May be
I can work on some other stuffs. Thanks.

Sincerely Yours,

Lei Shi
----------


On Sat, Oct 27, 2012 at 7:01 AM, Kirk, Benjamin (JSC-EG311) <
ben...@na...> wrote:

> Lei, could you explain why this particular part is important to you?  As
> Roy pointed out, for implicit apps this never shows up as a bottleneck, and
> for JFNK work I think Derek agrees there are other hotspots? Why not
> address those if performance is an issue?
>
> I don't want to discourage the change, but there are other deficiencies in
> libMesh where development could have a much bigger impact. (I swear one of
> these days I'll get to that blocked matrix
> support!)
>
> Because finite element objects tend to have a lot of lifetime per
> computation (they get reused for a lot of elements) the allocation issue is
> not really a driver. The dereferencing is, but as profiling reveals it is
> not that big of a deal.
>
> To answer your original question, we use a vector<vector> mostly because
> this section of code dates back to 2002, well before portable high
> performance expression templates were reliable. And based on our recent
> discussion you can see that the API is a trap once it is in place...
>
> Since the allocation and storage part is currently a non-issue, I wonder
> if the simplest path to reduce the dereferencing hit is to store an Eigen
> object along side the vector<vector>, deprecate the old API, and move to
> the (i,j) scheme directly?  For the adventurous we could disable the
> backwards compatibility at configure time so only the Eigen storage
> existed...
>
> -Ben
>
>
> On Oct 26, 2012, at 6:31 PM, "Lei Shi" <sto...@gm...> wrote:
>
> Sorry for the late.
>
> It seems that in order to provide backward compatible APIs, we need such
> kind of shim class. Roy, What is your final decision?
>
> Sincerely Yours,
>
> Lei Shi
> ----------
>
>
> On Thu, Oct 25, 2012 at 1:21 PM, Roy Stogner <roy...@ic...>wrote:
>
>>
>> On Thu, 25 Oct 2012, Boyce Griffith wrote:
>>
>>  Libraries like Eigen and Blitz++ use operator() for accessors rather
>>> than operator[].  How horrible would it be to go ahead and change to
>>> operator() when making this change to LibMeshNArray?
>>>
>>
>> Hmmm... it would mean that we couldn't get away with starting with
>> just a typedef, we'd actually have to build a basic shim class right
>> from the start, and it would be much more of a pain in the neck for
>> user codes to upgrade.
>>
>> On the other hand, if we did want to keep operator[] support around
>> indefinitely and we end up with a target class that doesn't support
>> it, that would mean we'd have to keep a shim class around
>> indefinitely... *and* we'd make it much less convenient to use a
>> different-semantic operator[] from the target class, e.g. the Blitz++
>> component accessor.
>>
>> More opinions would be welcome; I'm not even sure what I'd prefer yet.
>> ---
>> Roy
>>
>
>
> ------------------------------------------------------------------------------
> WINDOWS 8 is here.
> Millions of people.  Your app in 30 days.
> Visit The Windows 8 Center at Sourceforge for all your go to resources.
> http://windows8center.sourceforge.net/
> join-generation-app-and-make-money-coding-fast/
>
> _______________________________________________
> Libmesh-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
>