October 2012 - moab-dev - mailman3.cels.anl.gov

Moab Paraview plugin will not compile
by Cook, Rich 21 Dec '12

21 Dec '12

My apologies for posting here if it's not the right venue. I could not find another resource through Google or locally. BTW, the pointers to the package owners in the README leads to a dead link: "Users are encouraged to check http://cubit.sandia.gov/moab often for news and updates." Riiight. Anyhow, I found you! Ha. A user of our clusters at LLNL has asked if I would compile the MOAB Paraview plugin. So I tried this: tar -xzf moab-4.5.0.tar.gz pushd moab-4.5.0 ./configure --prefix=/nfs/tmp2/rcook/ParaView/moab-plugin/install-dir make -j pushd tools/vtkMOABReader/ cmake -DParaView_DIR=/nfs/tmp2/rcook/ParaView/moab-plugin/Paraview-BuildDir/src/ParaView-3.14.0-Build/ . When I did so, I got the following error. Can someone help me? :-) Thanks! + cmake -DParaView_DIR=/nfs/tmp2/rcook/ParaView/moab-plugin/Paraview-BuildDir/src/ParaView-3.14.0-Build/ . -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/local/bin/gcc -- Check for working C compiler: /usr/local/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at CMakeLists.txt:8 (INCLUDE): include could not find load file: /tmp/dpkg-mkdeb.eHKBP8GXWA/src/ParaView-3.14.0-Source/ParaViewUse.cmake CMake Error at CMakeLists.txt:9 (ADD_PARAVIEW_PLUGIN): Unknown CMake command "ADD_PARAVIEW_PLUGIN". -- Configuring incomplete, errors occurred! -- ✐Richard Cook ✇ Lawrence Livermore National Laboratory Bldg-453 Rm-4024, Mail Stop L-557 7000 East Avenue, Livermore, CA, 94550, USA ☎ (office) (925) 423-9605 ☎ (fax) (925) 423-6961 --- Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept. (opinions expressed herein are mine and not those of LLNL)

2 7

Re: [MOAB-dev] Representation of spectral meshes, opinions wanted
by Lorenzo Botti 01 Nov '12

01 Nov '12

Option 5 is very very close to what I consider an agglomerated element, with a strong restriction on the element shape in this case. Actually I store agglomerated elements as entity sets. Some time ago I submitted a patch to partition such agglomerated elements meshes based on an arbitrary tag associated to each set. I can resubmit it if someone is interested. It would be interesting to have the ability to generate high order spectral elements starting from block structured meshes. Is it possible to do such a thing using the structured mesh MOAB interface? Regarding the spectral meshes storage I have to say I use nodes only to define the domain discretization, then I use modal basis functions for the discrete spaces. For lagrangian elements I don't need a tag for dofs storage since the dofs are the nodes coordinates themselves. I'm interested in considering other possibilities like splines, nurbs... In this context I think that the ability to easily obtain all (low and high order) nodes for each side is important, so option 2 I guess. This also allows to easily get the nodes required to define a high order serendipity element. Thanks for the opportunity to share ideas. Best regards. Lorenzo Tim Tautges <tautges(a)mcs.anl.gov> wrote: >Aha, right, forgot to mention the current solution, which is to construct fine mesh from GLL points in each element. >Your option 5 would be to do that then link those elements to coarse elements somehow. Would probably be easiest using >a tag with start/end of a coarse element's refined elements. This would also work for h-refined meshes. > >- tim > >On 10/31/2012 12:07 PM, Iulian Grindeanu wrote: >> >> >> ------------------------------------------------------------------------------------------------------------------------ >> >> Hi all, >> We're now supporting with MOAB two different applications that use spectral meshes (Nek5000, an ANL CFD code, and >> HOMME, an SNL/NCAR climate code). As is usually the case, we not only have to represent these meshes in MOAB, but >> support meshes of those types in tools working on MOAB (viz, partitioning, etc). Spectral meshes are challenging >> because there are many ways to represent and order them, with applications typically using a lexicographic ordering and >> mesh-based tools preferring something more akin to higher-order element ordering. >> I've written the attached document that describes the problem, along with a few possible options for representation >> of these meshes. I'd welcome comments if you have them. Thanks. >> >> - tim >> >> Hello, >> There is another option, which is actually close to what we do now in Homme meshes: store the "finer" mesh, formed by >> spectral points, in a >> very regular grid, on each "coarse" element. And maybe have a method to group the "finer elements" on each "coarse" >> (spectral ) element. >> >> It is much more expensive for 3d (homme is basically 2d manifold), so maybe it is not worth mentioning. The only >> advantage to this (5th) option is that is probably the easiest in terms of development, and we could even use the >> existing visu tools. (actually, there is a visit plugin to display nek meshes directly, using this concept) >> >> All other options will need some working on the visu side. >> >> Iulian >> >> -- >> ================================================================ >> "You will keep in perfect peace him whose mind is >> steadfast, because he trusts in you." Isaiah 26:3 >> >> Tim Tautges Argonne National Laboratory >> (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) >> phone (gvoice): (608) 354-1459 1500 Engineering Dr. >> fax: (608) 263-4499 Madison, WI 53706 >> >> > >-- >================================================================ >"You will keep in perfect peace him whose mind is > steadfast, because he trusts in you." Isaiah 26:3 > > Tim Tautges Argonne National Laboratory > (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) > phone (gvoice): (608) 354-1459 1500 Engineering Dr. > fax: (608) 263-4499 Madison, WI 53706 >

3 2

r5847 - MOAB/trunk
by tautges＠mcs.anl.gov 31 Oct '12

31 Oct '12

Author: tautges Date: 2012-10-31 17:27:21 -0500 (Wed, 31 Oct 2012) New Revision: 5847 Modified: MOAB/trunk/RELEASE_NOTES Log: Forgot to update this. Modified: MOAB/trunk/RELEASE_NOTES =================================================================== --- MOAB/trunk/RELEASE_NOTES 2012-10-31 22:25:00 UTC (rev 5846) +++ MOAB/trunk/RELEASE_NOTES 2012-10-31 22:27:21 UTC (rev 5847) @@ -1,3 +1,7 @@ +Version 4.6pre: +* Added Interface::adjacencies_iterate, whose behavior is much like tag_iterate. +* Extended Interface::get_coords, to return entity centroids (avg vertex position) for non-vertex entities instead of failing + Version 4.5: * ITAPS: added iMesh_stepEntIter, iMesh_stepEntArrIter, iMesh_tagIterate, iMesh_createTagWithOptions (see iMesh_extensions.h) * More partitioning options for structured mesh (see ScdInterface::compute_partition functions, and doc/metadata_info.doc)

1 0

r5846 - in MOAB/trunk: src src/moab test
by tautges＠mcs.anl.gov 31 Oct '12

31 Oct '12

Author: tautges Date: 2012-10-31 17:25:00 -0500 (Wed, 31 Oct 2012) New Revision: 5846 Modified: MOAB/trunk/src/Core.cpp MOAB/trunk/src/moab/Range.hpp MOAB/trunk/test/MBTest.cpp Log: Modify behavior of moab::get_coords, to return centroids of non-vertex entities instead of failing. Tested in moab_test, and passes make check in serial and parallel. Sorry for the long recompile... test/MBTest.cpp: test get_coords for non-vertex entities. src/moab/Range.hpp: make const_pair_iterator::operator* and operator-> return const PairNode* instead of const std::pair<EH, EH>; the former is derived from the latter, so in the case where the calling application wants just a std::pair, that's what it'll see. Needed so I can construct a Range::const_iterator from a const_pair_iterator. src/Core.cpp: extend all get_coords functions to work for non-vertex entities; coordinates of non-vertex entities is defined as the centroid of the entity (avg of all vertex positions). Modified: MOAB/trunk/src/Core.cpp =================================================================== --- MOAB/trunk/src/Core.cpp 2012-10-31 22:03:37 UTC (rev 5845) +++ MOAB/trunk/src/Core.cpp 2012-10-31 22:25:00 UTC (rev 5846) @@ -940,7 +940,7 @@ Range::const_pair_iterator i = entities.const_pair_begin(); EntityHandle first = i->first; - while (i != entities.const_pair_end()) { + while (i != entities.const_pair_end() && TYPE_FROM_HANDLE(i->first) == MBVERTEX) { seq_iter = vert_data.lower_bound( first ); if (seq_iter == vert_data.end() || first < (*seq_iter)->start_handle()) @@ -974,8 +974,16 @@ } coords=&coords[ 3*count ]; } - - return MB_SUCCESS; + + // for non-vertices... + ErrorCode rval = MB_SUCCESS; + for (Range::const_iterator rit(&(*i), i->first); rit != entities.end(); rit++) { + rval = get_coords(&(*rit), 1, coords); + if (MB_SUCCESS != rval) return rval; + coords += 3; + } + + return rval; } /**\author Jason Kraftcheck <kraftche(a)cae.wisc.edu> - 2007-5-15 */ @@ -989,7 +997,7 @@ Range::const_pair_iterator i = entities.const_pair_begin(); EntityHandle first = i->first; - while (i != entities.const_pair_end()) { + while (i != entities.const_pair_end() && TYPE_FROM_HANDLE(i->first) == MBVERTEX) { seq_iter = vert_data.lower_bound( first ); if (seq_iter == vert_data.end() || first < (*seq_iter)->start_handle()) @@ -1027,46 +1035,74 @@ } } - return MB_SUCCESS; + // for non-vertices... + ErrorCode rval = MB_SUCCESS; + double xyz[3]; + for (Range::const_iterator rit(&(*i), i->first); rit != entities.end(); rit++) { + rval = get_coords(&(*rit), 1, xyz);

1 0

r5845 - MOAB/trunk/config
by tautges＠mcs.anl.gov 31 Oct '12

31 Oct '12

Author: tautges Date: 2012-10-31 17:03:37 -0500 (Wed, 31 Oct 2012) New Revision: 5845 Modified: MOAB/trunk/config/damsel.m4 Log: Adding check for required hdf5 libs. Modified: MOAB/trunk/config/damsel.m4 =================================================================== --- MOAB/trunk/config/damsel.m4 2012-10-31 21:56:08 UTC (rev 5844) +++ MOAB/trunk/config/damsel.m4 2012-10-31 22:03:37 UTC (rev 5845) @@ -68,6 +68,16 @@ DAMSEL_LIBS="-ldamsel" fi + # DAMSEL requires HDF5 too + if test "xno" == "x$HAVE_HDF5"; then + if test "x" == "x$DAMSEL_ARG"; then + DAMSEL_ARG=no + elif test "xno" != "xDAMSEL_ARG"; then + AC_MSG_ERROR([Damsel requires --with-hdf5]) + fi + HAVE_DAMSEL=no + fi + fi ]) # FATHOM_HAVE_DAMSEL

1 0

r5844 - MOAB/trunk/src/io
by tautges＠mcs.anl.gov 31 Oct '12

31 Oct '12

Author: tautges Date: 2012-10-31 16:56:08 -0500 (Wed, 31 Oct 2012) New Revision: 5844 Modified: MOAB/trunk/src/io/DamselUtil.hpp MOAB/trunk/src/io/ReadDamsel.cpp MOAB/trunk/src/io/WriteDamsel.cpp Log: Update the damsel stuff to account for recent changes to the Damsel implementation. Modified: MOAB/trunk/src/io/DamselUtil.hpp =================================================================== --- MOAB/trunk/src/io/DamselUtil.hpp 2012-10-31 16:13:51 UTC (rev 5843) +++ MOAB/trunk/src/io/DamselUtil.hpp 2012-10-31 21:56:08 UTC (rev 5844) @@ -86,11 +86,11 @@ class tinfo { public: - tinfo(Tag mt, damsel_tag dt, TagType tt) : mTagh(mt), dTagh(dt), tagType(tt) {}; - tinfo() : mTagh(0), dTagh(DAMSEL_TAG_INVALID), tagType(MB_TAG_ANY) {}; + tinfo(Tag mt, damsel_handle dt, TagType tt) : mTagh(mt), dTagh(dt), tagType(tt) {}; + tinfo() : mTagh(0), dTagh(0), tagType(MB_TAG_ANY) {}; Tag mTagh; - damsel_tag dTagh; + damsel_handle dTagh; TagType tagType; }; template<class T> struct MtagP : std::unary_function<T, bool> { @@ -103,15 +103,9 @@ template<class T> struct DtagP : std::unary_function<T, bool> { public: DtagP(const damsel_handle &th) {tH = th;}; - bool operator() (const T &tclass) {return tclass.dTagh == (damsel_tag)tH;}; + bool operator() (const T &tclass) {return tclass.dTagh == tH;}; damsel_handle tH; }; - - - - - - private: //! damsel library id Modified: MOAB/trunk/src/io/ReadDamsel.cpp =================================================================== --- MOAB/trunk/src/io/ReadDamsel.cpp 2012-10-31 16:13:51 UTC (rev 5843) +++ MOAB/trunk/src/io/ReadDamsel.cpp 2012-10-31 21:56:08 UTC (rev 5844) @@ -276,8 +276,7 @@ tagh, MB_TAG_CREAT | MB_TAG_DENSE); if (MB_SUCCESS != tmp_rval) rval = tmp_rval; else { - dU.tagMap.push_back(DamselUtil::tinfo(tagh, *(reinterpret_cast<damsel_tag*>((*tit).tag_handle)), - MB_TAG_DENSE)); + dU.tagMap.push_back(DamselUtil::tinfo(tagh, 0, MB_TAG_DENSE)); // also store predefined tags specially... if (!strncmp((*tit).name, "mbdmsl_", 7)) { // predefined tag name, store the handle

1 0

Representation of spectral meshes, opinions wanted
by Tim Tautges 31 Oct '12

31 Oct '12

Hi all, We're now supporting with MOAB two different applications that use spectral meshes (Nek5000, an ANL CFD code, and HOMME, an SNL/NCAR climate code). As is usually the case, we not only have to represent these meshes in MOAB, but support meshes of those types in tools working on MOAB (viz, partitioning, etc). Spectral meshes are challenging because there are many ways to represent and order them, with applications typically using a lexicographic ordering and mesh-based tools preferring something more akin to higher-order element ordering. I've written the attached document that describes the problem, along with a few possible options for representation of these meshes. I'd welcome comments if you have them. Thanks. - tim -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706

2 3

r5843 - in MOAB/trunk: src/lotte src/moab/point_locater/lotte test/parallel tools/mbcoupler tools/mbcslam
by iulian＠mcs.anl.gov 31 Oct '12

31 Oct '12

Author: iulian Date: 2012-10-31 11:13:51 -0500 (Wed, 31 Oct 2012) New Revision: 5843 Modified: MOAB/trunk/src/lotte/findpt.c MOAB/trunk/src/moab/point_locater/lotte/extrafindpt.h MOAB/trunk/test/parallel/ucdtrvpart.cpp MOAB/trunk/tools/mbcoupler/ElemUtil.cpp MOAB/trunk/tools/mbcoupler/ElemUtil.hpp MOAB/trunk/tools/mbcoupler/ElementTest.cpp MOAB/trunk/tools/mbcslam/IntxUtils.cpp MOAB/trunk/tools/mbcslam/IntxUtils.hpp Log: compute gl points for a spectral quad add a test in ElementTest in mbcoupler add some utilities in mbcslam, not tested yet, to convert to/from spherical coordinates Modified: MOAB/trunk/src/lotte/findpt.c =================================================================== --- MOAB/trunk/src/lotte/findpt.c 2012-10-30 16:52:27 UTC (rev 5842) +++ MOAB/trunk/src/lotte/findpt.c 2012-10-31 16:13:51 UTC (rev 5843) @@ -1580,34 +1580,8 @@ #undef DIAGNOSTICS -/*-------------------------------------------------------------------------- - - 2 - D - - --------------------------------------------------------------------------*/ -typedef struct { - unsigned constraints; - unsigned de, d1; - real *x[2], *fd1[2]; -} opt_edge_data_2; - -typedef struct { - unsigned constraints; - real x[2], jac[4]; -} opt_point_data_2; - -typedef struct { - lagrange_data *ld; - unsigned size[3]; - const real *elx[2]; - opt_edge_data_2 ed; - opt_point_data_2 pd; - real *work; - real x[2], jac[4]; -} opt_data_2; - -static void opt_alloc_2(opt_data_2 *p, lagrange_data *ld) +void opt_alloc_2(opt_data_2 *p, lagrange_data *ld) { const unsigned nr = ld[0].n, ns = ld[1].n, ne = umax_2(nr,ns), @@ -1623,7 +1597,7 @@ p->ed.fd1[1] = p->ed.fd1[0] + ne; } -static void opt_free_2(opt_data_2 *p) +void opt_free_2(opt_data_2 *p) { free(p->work); } @@ -1758,7 +1732,7 @@

1 0

buildbot failure in moab-occ-par-sta: failed test
by moab-dev＠mcs.anl.gov 31 Oct '12

31 Oct '12

1 0

r5842 - MOAB/trunk/tools/mbcoupler
by tautges＠mcs.anl.gov 30 Oct '12

30 Oct '12

Author: tautges Date: 2012-10-30 11:52:27 -0500 (Tue, 30 Oct 2012) New Revision: 5842 Modified: MOAB/trunk/tools/mbcoupler/Coupler.cpp Log: Fixing error in memcpy, specified # values, not # bytes. TODO: need to write a test that catches this... Modified: MOAB/trunk/tools/mbcoupler/Coupler.cpp =================================================================== --- MOAB/trunk/tools/mbcoupler/Coupler.cpp 2012-10-30 15:20:17 UTC (rev 5841) +++ MOAB/trunk/tools/mbcoupler/Coupler.cpp 2012-10-30 16:52:27 UTC (rev 5842) @@ -570,10 +570,10 @@ if(LINEAR_FE == method || QUADRATIC_FE == method){ result = interp_field(mappedPts->vul_rd[mindex], CartVect(mappedPts->vr_wr+3*mindex), - tag, tinterp.vr_rd[i]); + tag, tinterp.vr_wr[i]); }else if (CONSTANT == method){ result = constant_interp(mappedPts->vul_rd[mindex], - tag, tinterp.vr_rd[i]); + tag, tinterp.vr_wr[i]); } if (MB_SUCCESS != result) return result; @@ -584,7 +584,7 @@ } // copy the interpolated field as a unit - memcpy(interp_vals, tinterp.vr_rd, tinterp.get_n()); + memcpy(interp_vals, tinterp.vr_rd, tinterp.get_n()*sizeof(double)); // done return MB_SUCCESS;

1 0