December 2016 - moab-dev - mailman3.cels.anl.gov

a bug in Coupler::locate_points
by Huayi Wei 17 Apr '17

17 Apr '17

Hi, Moab Dev, In the following member function, I think it is a bug for line ` tl = new TupleList(3, 0, 0, 0, num_points);`. Here create new TupleList which address will cover the address tl passed by user, and then user can not accsess it. I think it should be ' tl->initialize(3, 0, 0, 0, num_points)`, ```` ErrorCode Coupler::locate_points(double *xyz, unsigned int num_points, double rel_eps, double abs_eps, TupleList *tl, bool store_local) { ....... // Copy into tl if passed in and storing locally if (tl && store_local) { tl = new TupleList(3, 0, 0, 0, num_points); tl->enableWriteAccess(); memcpy(tl->vi_wr, tl_tmp->vi_rd, 3 * tl_tmp->get_n() * sizeof(int)); tl->set_n(tl_tmp->get_n()); tl->disableWriteAccess(); } .... } ``` Best Huayi

4 6

clang compilation problem
by Lukasz Kaczmarczyk 22 Dec '16

22 Dec '16

Hello, I spot compilation problem with clang and mac os x. On gcc works ok, with clang I have following error. Is is hard to me to understand what is wrong. Error is for develop and master branch, CXX OrientedBoxTreeTool.lo In file included from OrientedBox.cpp:36: ./moab/OrientedBox.hpp:244:15: error: no member named 'col' in 'moab::Matrix3' return axes.col(index); ~~~~ ^ ./moab/OrientedBox.hpp:250:31: error: no member named 'col' in 'moab::Matrix3' return length[index] * axes.col(index); ~~~~ ^ OrientedBox.cpp:48:22: error: no member named 'col' in 'moab::Matrix3' << b.axes.col(0) ~~~~~~ ^ OrientedBox.cpp:53:22: error: no member named 'col' in 'moab::Matrix3' << b.axes.col(1) ~~~~~~ ^ OrientedBox.cpp:58:22: error: no member named 'col' in 'moab::Matrix3' << b.axes.col(2) ~~~~~~ ^ OrientedBox.cpp:97:7: error: no member named 'swapcol' in 'moab::Matrix3' axes.swapcol( 0, 2 ); ~~~~ ^ OrientedBox.cpp:102:10: error: no member named 'swapcol' in 'moab::Matrix3' axes.swapcol( 0, 1 ); ~~~~ ^ OrientedBox.cpp:106:10: error: no member named 'swapcol' in 'moab::Matrix3' axes.swapcol( 1, 2 ); ~~~~ ^ OrientedBox.cpp:112:12: error: no member named 'colscale' in 'moab::Matrix3' axes.colscale(0, 1.0/len[0]); ~~~~ ^ OrientedBox.cpp:114:12: error: no member named 'colscale' in 'moab::Matrix3' axes.colscale(1, 1.0/len[1]); ~~~~ ^ OrientedBox.cpp:116:12: error: no member named 'colscale' in 'moab::Matrix3' axes.colscale(2 ,1.0/len[2]); ~~~~ ^ OrientedBox.cpp:128:10: error: no matching constructor for initialization of 'moab::Matrix3' axes = Matrix3( axes_in[0], axes_in[1], axes_in[2], false ); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /opt/petsc/arch-darwin-c-opt/include/moab/Matrix3.hpp:298:10: note: candidate constructor template not viable: requires single argument 'diagonal', but 4 arguments were provided inline Matrix3( const std::vector< T> & diagonal ){ ^ /opt/petsc/arch-darwin-c-opt/include/moab/Matrix3.hpp:320:10: note: candidate constructor template not viable: requires 3 arguments, but 4 were provided inline Matrix3( const Vector & row0, ^ /opt/petsc/arch-darwin-c-opt/include/moab/Matrix3.hpp:280:10: note: candidate constructor not viable: requires single argument 'diagonal', but 4 arguments were provided inline Matrix3( double diagonal ){ ^ /opt/petsc/arch-darwin-c-opt/include/moab/Matrix3.hpp:285:10: note: candidate constructor not viable: requires single argument 'diagonal', but 4 arguments were provided inline Matrix3( const CartVect & diagonal ){ ^ /opt/petsc/arch-darwin-c-opt/include/moab/Matrix3.hpp:315:3: note: candidate constructor not viable: requires single argument 'f', but 4 arguments were provided Matrix3 ( const Matrix3 & f){ ^ /opt/petsc/arch-darwin-c-opt/include/moab/Matrix3.hpp:330:10: note: candidate constructor not viable: requires single argument 'v', but 4 arguments were provided inline Matrix3( const double* v ){ ^ /opt/petsc/arch-darwin-c-opt/include/moab/Matrix3.hpp:275:10: note: candidate constructor not viable: requires 0 arguments, but 4 were provided inline Matrix3(){ ^ /opt/petsc/arch-darwin-c-opt/include/moab/Matrix3.hpp:306:8: note: candidate constructor not viable: requires 9 arguments, but 4 were provided inline Matrix3( double v00, double v01, double v02, ^ OrientedBox.cpp:137:30: error: no member named 'col' in 'moab::Matrix3' order_axes_by_length( axes.col(0).length(), axes.col(1).length(), axes.col(2).length() ); ~~~~ ^ OrientedBox.cpp:137:52: error: no member named 'col' in 'moab::Matrix3' order_axes_by_length( axes.col(0).length(), axes.col(1).length(), axes.col(2).length() ); ~~~~ ^ OrientedBox.cpp:137:74: error: no member named 'col' in 'moab::Matrix3' order_axes_by_length( axes.col(0).length(), axes.col(1).length(), axes.col(2).length() ); ~~~~ ^ OrientedBox.cpp:191:71: error: no member named 'col' in 'moab::Matrix3' const double t = point_perp( coords, result.center, result.axes.col(d) ); ~~~~~~~~~~~ ^ OrientedBox.cpp:206:41: error: no member named 'col' in 'moab::Matrix3' result.center += mid[0] * result.axes.col(0) + ~~~~~~~~~~~ ^ OrientedBox.cpp:207:41: error: no member named 'col' in 'moab::Matrix3' mid[1] * result.axes.col(1) + ~~~~~~~~~~~ ^ OrientedBox.cpp:208:41: error: no member named 'col' in 'moab::Matrix3' mid[2] * result.axes.col(2); ~~~~~~~~~~~ ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. make[2]: *** [OrientedBox.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... OrientedBoxTreeTool.cpp:364:18: error: called object type 'moab::CartVect [3]' is not a function or function pointer if ((box.axis(axis) % (centroid - box.center)) < 0.0) ~~~~~~~~^ OrientedBoxTreeTool.cpp:384:15: error: no matching constructor for initialization of 'moab::OrientedBox' tmp_box = OrientedBox( axis, CartVect(0.) ); ^ ~~~~~~~~~~~~~~~~~~ /opt/petsc/arch-darwin-c-opt/include/moab/OrientedBox.hpp:54:3: note: candidate constructor not viable: no known conversion from 'moab::Matrix3' to 'const moab::CartVect *' for 1st argument OrientedBox( const CartVect axis[3], const CartVect& center ); ^ /opt/petsc/arch-darwin-c-opt/include/moab/OrientedBox.hpp:40:7: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 2 were provided class OrientedBox ^ /opt/petsc/arch-darwin-c-opt/include/moab/OrientedBox.hpp:52:10: note: candidate constructor not viable: requires 0 arguments, but 2 were provided inline OrientedBox() : radius(0.0) {} ^ OrientedBoxTreeTool.cpp:475:18: error: called object type 'moab::CartVect [3]' is not a function or function pointer if ((box.axis(axis) % (centroid - box.center)) < 0.0) ~~~~~~~~^ OrientedBoxTreeTool.cpp:1918:34: error: called object type 'moab::CartVect [3]' is not a function or function pointer << '+' << box.axis(0) << " : " << length[0] << std::endl ~~~~~~~~^ OrientedBoxTreeTool.cpp:1919:34: error: called object type 'moab::CartVect [3]' is not a function or function pointer << 'x' << box.axis(1) << " : " << length[1] << std::endl ~~~~~~~~^ OrientedBoxTreeTool.cpp:1920:34: error: called object type 'moab::CartVect [3]' is not a function or function pointer << 'x' << box.axis(2) << " : " << length[2] << std::endl; ~~~~~~~~^ 6 errors generated. make[2]: *** [OrientedBoxTreeTool.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1

2 2

Digging into ray_intersect_* in the OBBTreeTool - proposing an interface change
by Paul Wilson 14 Dec '16

14 Dec '16

Hello all, I have been spending a lot of quality time with the ray_intersect_* methods of the OrientedBoxTreeTool over the last few weeks. I think I have (re)learned all the subtleties of the additional code that exists in RayIntersectSets::leaf() (invoked with API function ray_intersect_sets). In general, these are all additional tests that make sense only in the context of a call from DagMC: * is this facet in a list of previous facets intersected by this ray prior to this call * is this facet in a list of previous facets (or their neighborhood) encountered during this call * is this intersection a piercing or glancing intersection as defined by notions of surface sense known to DagMC There is then a complex logic related to how many intersections to keep based on three quantities: two are a "window" in which the distance to distance to intersection must fall and the third is a count of how many intersections to keep. The logic for ray_intersect_triangles() includes none of this. I was contemplating an interface change to ray_intersect_triangles() that would add enough information to include the same tests, and modularizing those tests to reuse code in both places. However, (a) the interface for that would be awkward and (b) it would be imposing DagMC conventions on even more code. Instead I propose the reduce the interface of all ray_intersect_* methods to include only the following: * const EntityHandle root_set: points to the root of the OBB Tree * const double tolerance: for use in searching for intersections (largely unused at the moment, I think) * const double ray_point[3]: starting point of ray * const double unit_vector[3]: direction of ray * std::pair<double*, double*> window: window to narrow search for interesting intersections * std::pair<double*, double*> register_intersection(...): call back function to perform application specific filtering/disambiguation of possible intersection, returning an updated window These methods would no longer return lists of intersections, but would return them one at a time for consideration by the calling application. Since this is such a major interface change, I thought I'd solicit feedback before embarking upon it. It won't necessarily bee that much code change, but who knows how it impacts other possible users of this code??? Paul -- -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- Paul P.H. Wilson Grainger Professor of Nuclear Engineering 608-263-0807 paul.wilson(a)wisc.edu 419 Engineering Research Bldg 1500 Engineering Dr, Madison, WI 53706 calendar: http://go.wisc.edu/pphw-cal Computational Nuclear Engineering Research Group cnerg.engr.wisc.edu Faculty Director, Advanced Computing Initiative aci.wisc.edu

4 5