<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Patrick,<br>
<br>
I think you should patch against 'master' rather than 'develop'.
The 'develop' branch may requires an update to CMake? It is using
something called <a
href="http://www.cmake.org/cmake/help/v3.0/module/GenerateExportHeader.html">GenerateExportHeader</a><br>
<br>
Paul<br>
<br>
<div class="moz-cite-prefix">On 08/18/2015 08:48 PM, Patrick
Shriwise wrote:<br>
</div>
<blockquote cite="mid:55D3E065.8050804@wisc.edu" type="cite">Cool! I
hope it helps. We'll fine out soon. I actually found some time to
get the fix into a branch tonight but I'm actually having trouble
compiling with the develop branch.
<br>
<br>
Getting an error like:
<br>
<br>
In file included from
../../../src/test/dagmc/dagmc_pointinvol_test.cpp:10:0:
<br>
../../../src/tools/dagmc/DagMC.hpp:4:26: fatal error:
dagmc_export.h: No such file or directory
<br>
#include "dagmc_export.h"
<br>
<br>
These export headers are new to me. Any ideas?
<br>
<br>
Cheers,
<br>
<br>
Patrick
<br>
<br>
On 08/18/2015 08:16 PM, Grindeanu, Iulian R. wrote:
<br>
<blockquote type="cite">So it was a message from Steve Jackson, in
March 2010 :)
<br>
The link is not working anymore, but maybe someone still has
that presentation.
<br>
<br>
Anyway, GeomTopoTool is using obb tree, and FBEngine is using
GeomTopoTool, so the implications of this bug are many.
<br>
<br>
thanks for finding it!
<br>
<br>
Iulian
<br>
<br>
"
<br>
Cc:
<br>
<a class="moz-txt-link-abbreviated" href="mailto:fathom@lists.mcs.anl.gov">fathom@lists.mcs.anl.gov</a>
<br>
Tuesday, March 02, 2010 10:44 AM
<br>
I will be presenting some slides on OBB tree performance
profiling at this meeting. They can be found here:
<a class="moz-txt-link-freetext" href="http://mywebspace.wisc.edu/stjackson/web/fathom_slides_march2.pdf">http://mywebspace.wisc.edu/stjackson/web/fathom_slides_march2.pdf</a>
<br>
<br>
~S
<br>
"
<br>
________________________________________
<br>
From: Patrick Shriwise [<a class="moz-txt-link-abbreviated" href="mailto:shriwise@wisc.edu">shriwise@wisc.edu</a>]
<br>
Sent: Tuesday, August 18, 2015 7:26 PM
<br>
To: Paul Wilson; Grindeanu, Iulian R.; <a class="moz-txt-link-abbreviated" href="mailto:moab-dev@mcs.anl.gov">moab-dev@mcs.anl.gov</a>
<br>
Subject: Re: [MOAB-dev] Matrix3 EigenDecomp Bug
<br>
<br>
Hi all,
<br>
<br>
As Paul said, nothing for sure as to the improvement for
scaling, but it
<br>
would make sense. As the number of triangles goes up, deeper
trees, more
<br>
boxes.
<br>
<br>
And you're right, this is only used in the OBB Tree. That makes
sense as
<br>
it's the only relatively complex linear algebra capability we
need so
<br>
far. Otherwise we'd be accessing a known library for that I
assume.
<br>
<br>
I'll submit a PR to fix the problem this week (my sister is
visiting or
<br>
I'd do it tomorrow) and report back on the scaling asap.
<br>
<br>
Cheers,
<br>
<br>
Patrick
<br>
<br>
On 08/18/2015 05:47 PM, Paul Wilson wrote:
<br>
<blockquote type="cite">Hi Iulian,
<br>
<br>
On 08/18/2015 05:16 PM, Grindeanu, Iulian R. wrote:
<br>
<blockquote type="cite">Ouch
<br>
only obb tree is using it.
<br>
So only obb tree is affected by it
<br>
<br>
indeed, it is returning cartVect's as you said
<br>
It should be returning the transpose
<br>
<br>
strange nobody noticed
<br>
<br>
I remember somebody did a study of our obb tree and it was
not
<br>
scaling properly
<br>
<br>
Could this be the reason?
<br>
</blockquote>
This is almost certainly true. Patrick discovered this while
trying
<br>
to understand why some DAGMC problems were so slow. He
visualized the
<br>
OBB trees from that problem and they didn't really make any
sense. It
<br>
was a problem with many long high aspect triangles that were
aligned
<br>
to an axis, but the OBB was not aligned to that axis.
<br>
<br>
Early indications are that it will make an improvement - we'll
know
<br>
more soon.
<br>
<br>
Paul
<br>
<br>
<blockquote type="cite">
<br>
________________________________________
<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:moab-dev-bounces@mcs.anl.gov">moab-dev-bounces@mcs.anl.gov</a>
[<a class="moz-txt-link-abbreviated" href="mailto:moab-dev-bounces@mcs.anl.gov">moab-dev-bounces@mcs.anl.gov</a>] on
<br>
behalf of shriwise [<a class="moz-txt-link-abbreviated" href="mailto:shriwise@wisc.edu">shriwise@wisc.edu</a>]
<br>
Sent: Tuesday, August 18, 2015 3:56 PM
<br>
To: <a class="moz-txt-link-abbreviated" href="mailto:moab-dev@mcs.anl.gov">moab-dev@mcs.anl.gov</a>
<br>
Subject: [MOAB-dev] Matrix3 EigenDecomp Bug
<br>
<br>
Hey all,
<br>
<br>
After a day or so of working on this, I found an error in
the Eigenvalue
<br>
decomposition function provided by Matrix3.
<br>
<br>
I believe that its computation is correct, but the way that
it returns
<br>
the Eigenvectors is at the very least ambiguous, and I would
argue that
<br>
it is simply incorrect.
<br>
<br>
Typically the matrix produced by this decomposition contains
the vectors
<br>
in a column-based manner, but the vectors are being returned
in an array
<br>
of CartVects where each CartVect contains a row of the
resulting matrix.
<br>
The problem being that the solution matrix in this case is
indeed column
<br>
based. So while the correct information is available, it is
returned in
<br>
such a way that leads one to believe each CartVect contains
one of the
<br>
EigenVectors when this is not the case.
<br>
<br>
I found this by comparing the results of this function to
that of a
<br>
common linear algebra library, Armadillo.
<br>
<br>
I've attached the test program I was using if anyone is
curious.
<br>
<br>
Normally, I would simply fix it and create a PR but I'm not
quite
<br>
certain how to proceed. I think probably the best way is to
fix this at
<br>
the source in Matrix3.hpp but I don't want any reliant
functionality to
<br>
be affected without notice. This is a long standing bug
affecting the
<br>
OBBTree. I'll start working on a fix tomorrow morning,
perhaps by
<br>
finding anywhere this is used and double checking the use of
the
<br>
returned Eigenvectors. Does that sound amenable to all?
<br>
<br>
Cheers,
<br>
<br>
--
<br>
Patrick C. Shriwise
<br>
Research Fellow
<br>
University of Wisconsin - Madison
<br>
Engineering Research Building - Rm. 428
<br>
1500 Engineering Drive
<br>
Madison, WI 53706
<br>
(608) 446-8173
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: <a class="moz-txt-link-freetext" href="http://go.wisc.edu/pphw-cal">http://go.wisc.edu/pphw-cal</a>
Professor, Engineering Physics. ~ <a class="moz-txt-link-freetext" href="http://cnerg.engr.wisc.edu">http://cnerg.engr.wisc.edu</a>
Faculty Director, Advanced Computing Infrastructure ~ <a class="moz-txt-link-freetext" href="http://aci.wisc.edu">http://aci.wisc.edu</a></pre>
</body>
</html>