[MOAB-dev] Matrix3 EigenDecomp Bug

[Paul Wilson]

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
>

-- 
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://go.wisc.edu/pphw-cal
Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu
Faculty Director, Advanced Computing Infrastructure ~ http://aci.wisc.edu