[MOAB-dev] Matrix3 EigenDecomp Bug

[Patrick Shriwise]

Hi all,

As Paul said, nothing for sure as to the improvement for scaling, but it 
would make sense. As the number of triangles goes up, deeper trees, more 
boxes.

And you're right, this is only used in the OBB Tree. That makes sense as 
it's the only relatively complex linear algebra capability we need so 
far. Otherwise we'd be accessing a known library for that I assume.

I'll submit a PR to fix the problem this week (my sister is visiting or 
I'd do it tomorrow) and report back on the scaling asap.

Cheers,

Patrick

On 08/18/2015 05:47 PM, Paul Wilson wrote:
> Hi Iulian,
>
> On 08/18/2015 05:16 PM, Grindeanu, Iulian R. wrote:
>> Ouch
>> only obb tree is using it.
>> So only obb tree is affected by it
>>
>> indeed, it is returning cartVect's as you said
>> It should be returning the transpose
>>
>> strange nobody noticed
>>
>> I remember somebody did a study of our obb tree and it was not 
>> scaling properly
>>
>> Could this be the reason?
>
> This is almost certainly true.  Patrick discovered this while trying 
> to understand why some DAGMC problems were so slow.  He visualized the 
> OBB trees from that problem and they didn't really make any sense.  It 
> was a problem with many long high aspect triangles that were aligned 
> to an axis, but the OBB was not aligned to that axis.
>
> Early indications are that it will make an improvement - we'll know 
> more soon.
>
> Paul
>
>>
>>
>> ________________________________________
>> From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on 
>> behalf of shriwise [shriwise at wisc.edu]
>> Sent: Tuesday, August 18, 2015 3:56 PM
>> To: moab-dev at mcs.anl.gov
>> Subject: [MOAB-dev] Matrix3 EigenDecomp Bug
>>
>> Hey all,
>>
>> After a day or so of working on this, I found an error in the Eigenvalue
>> decomposition function provided by Matrix3.
>>
>> I believe that its computation is correct, but the way that it returns
>> the Eigenvectors is at the very least ambiguous, and I would argue that
>> it is simply incorrect.
>>
>> Typically the matrix produced by this decomposition contains the vectors
>> in a column-based manner, but the vectors are being returned in an array
>> of CartVects where each CartVect contains a row of the resulting matrix.
>> The problem being that the solution matrix in this case is indeed column
>> based. So while the correct information is available, it is returned in
>> such a way that leads one to believe each CartVect contains one of the
>> EigenVectors when this is not the case.
>>
>> I found this by comparing the results of this function to that of a
>> common linear algebra library, Armadillo.
>>
>> I've attached the test program I was using if anyone is curious.
>>
>> Normally, I would simply fix it and create a PR but I'm not quite
>> certain how to proceed. I think probably the best way is to fix this at
>> the source in Matrix3.hpp but I don't want any reliant functionality to
>> be affected without notice. This is a long standing bug affecting the
>> OBBTree. I'll start working on a fix tomorrow morning, perhaps by
>> finding anywhere this is used and double checking the use of the
>> returned Eigenvectors. Does that sound amenable to all?
>>
>> Cheers,
>>
>> -- 
>> Patrick C. Shriwise
>> Research Fellow
>> University of Wisconsin - Madison
>> Engineering Research Building - Rm. 428
>> 1500 Engineering Drive
>> Madison, WI 53706
>> (608) 446-8173
>>
>