July 2010 - moab-dev - mailman3.cels.anl.gov

portability issue/question
by Paul Wilson 02 Aug '10

02 Aug '10

Hello, I am integrating MOAB/DAGMC into a c++ code that includes a header that defines index() as a macro, apparently through some combination of system headers. This creates a problem with including moab/Range.hpp because it attempts to define a member function index(). Fortunately it creates a compile time failure because the signature of the Range::index() is different from the macro, otherwise who knows what would happen??? I haven't bothered to track it down yet, but the short solution has been to add the following immediately prior to the include: #ifdef index #undef index #endif I have resisted committing this to the repo because it seems like a little presumptious/overbearing. Any other solutions? Paul -- Paul Wilson -- ------------------------------------------------------------------ -- Paul P.H. Wilson 419 Engineering Research Building wilsonp(a)engr.wisc.edu 1500 Engineering Dr ph/fax: 608/263-0807 Madison, WI 53706 My calendar: http://bit.ly/pphw-calendar Computational Nuclear Engineering Research Group http://cnerg.engr.wisc.edu Associate Professor, Nuclear Engineering Engineering Physics Department http://www.engr.wisc.edu/ep Chair, Energy Analysis & Policy Certificate Nelson Institute for Environmental Studies http://nelson.wisc.edu/eap/ Contributing to the joy and improvement of all those around me

3 3

buildbot failure in Fathom on moab-doc
by moab-dev＠mcs.anl.gov 31 Jul '10

31 Jul '10

The Fathomatic has detected a failed build of moab-doc on Fathom. Full details are available at: http://gnep.mcs.anl.gov:8010/builders/moab-doc/builds/120 Buildbot URL: http://gnep.mcs.anl.gov:8010/ Buildslave for this Build: gnep Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: None Blamelist: BUILD FAILED: failed svn LOG EXCERPT: svn: OPTIONS of 'https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk': could not connect to server (https://svn.mcs.anl.gov) svn: OPTIONS of 'https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk': could not connect to server (https://svn.mcs.anl.gov) sincerely, -The Fathomatic

1 0

buildbot failure in Fathom on moab-distcheck
by moab-dev＠mcs.anl.gov 31 Jul '10

31 Jul '10

The Fathomatic has detected a failed build of moab-distcheck on Fathom. Full details are available at: http://gnep.mcs.anl.gov:8010/builders/moab-distcheck/builds/222 Buildbot URL: http://gnep.mcs.anl.gov:8010/ Buildslave for this Build: gnep Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: None Blamelist: BUILD FAILED: failed svn LOG EXCERPT: svn: OPTIONS of 'https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk': could not connect to server (https://svn.mcs.anl.gov) svn: OPTIONS of 'https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk': could not connect to server (https://svn.mcs.anl.gov) sincerely, -The Fathomatic

1 0

buildbot failure in Fathom on moab-par
by moab-dev＠mcs.anl.gov 31 Jul '10

31 Jul '10

The Fathomatic has detected a failed build of moab-par on Fathom. Full details are available at: http://gnep.mcs.anl.gov:8010/builders/moab-par/builds/229 Buildbot URL: http://gnep.mcs.anl.gov:8010/ Buildslave for this Build: gnep Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: None Blamelist: BUILD FAILED: failed svn LOG EXCERPT: svn: OPTIONS of 'https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk': could not connect to server (https://svn.mcs.anl.gov) svn: OPTIONS of 'https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk': could not connect to server (https://svn.mcs.anl.gov) sincerely, -The Fathomatic

1 0

buildbot failure in Fathom on moab-32bit-handles
by moab-dev＠mcs.anl.gov 31 Jul '10

31 Jul '10

The Fathomatic has detected a failed build of moab-32bit-handles on Fathom. Full details are available at: http://gnep.mcs.anl.gov:8010/builders/moab-32bit-handles/builds/185 Buildbot URL: http://gnep.mcs.anl.gov:8010/ Buildslave for this Build: gnep Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: None Blamelist: BUILD FAILED: failed svn LOG EXCERPT: svn: OPTIONS of 'https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk': could not connect to server (https://svn.mcs.anl.gov) svn: OPTIONS of 'https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk': could not connect to server (https://svn.mcs.anl.gov) sincerely, -The Fathomatic

1 0

buildbot failure in Fathom on moab-serial
by moab-dev＠mcs.anl.gov 31 Jul '10

31 Jul '10

The Fathomatic has detected a failed build of moab-serial on Fathom. Full details are available at: http://gnep.mcs.anl.gov:8010/builders/moab-serial/builds/228 Buildbot URL: http://gnep.mcs.anl.gov:8010/ Buildslave for this Build: gnep Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: None Blamelist: BUILD FAILED: failed svn LOG EXCERPT: svn: OPTIONS of 'https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk': could not connect to server (https://svn.mcs.anl.gov) svn: OPTIONS of 'https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk': could not connect to server (https://svn.mcs.anl.gov) sincerely, -The Fathomatic

1 0

Re: [MOAB-dev] Measuring memory
by Jason Kraftcheck 28 Jul '10

28 Jul '10

On 07/28/2010 03:25 PM, Steve Jackson wrote: > > On Jul 28, 2010, at 14:59 , Jason Kraftcheck wrote: >> >> Checking memory usage is basically a non-portable mess. Just getting the >> code to compile on all platforms and return useful information on at least >> those platforms that developers use is about the best that can be >> expected. > > I wonder if we should just replace the calls to non-portable system > functions with calls to MOAB's own estimated_memory_use() function. Is > anyone relying on having system-level memory use measurements in mbskin > and mbperf? MOAB's calls are a) not quite the same and b) not as accurate. They are not quite the same in that they will never measure peak transient memory required by some algorithm (e.g. the temporary memory used by the skinner.) They only measure the memory used for persistent data in the database. They are not as accurate because they can't know things like the overhead for chunks allocated via malloc, the fragmentation within the memory managed by malloc, etc. - jason

1 0

Measuring memory
by Steve Jackson 28 Jul '10

28 Jul '10

This code snippet is duplicated several times in moab: // estimate total program memory usage and store into tot_mem struct rusage r_usage; getrusage(RUSAGE_SELF, &r_usage); ... if( 0 != r_usage.ru_maxrss ){ tot_mem = r_usage.ru_idrss; } else{ // parse data from file /proc/self/stat } This code is used to estimate memory usage in mbskin and mbperf, as well as in dagmc's ray_fire_test. This code is broken under Linux kernel 2.6.32, because under this kernel, getrusage() does report ru_maxrss, but does not report ru_idrss. (Previous versions of the kernel reported neither value.) See http://www.kernel.org/doc/man-pages/online/pages/man2/getrusage.2.html . The result is that our tools always report a memory use of 0 with this kernel version. Should this be fixed by changing the if statement to check for data in ru_idrss instead of ru_maxrss? Or would a different approach be preferred? Also, ought we to move the get_time_mem function to a shared location, to reduce code duplication? ~S

2 2

Re: [MOAB-dev] Possible bug in moab::Core::get_coords
by Jason Kraftcheck 28 Jul '10

28 Jul '10

On 07/28/2010 11:59 AM, Jason Kraftcheck wrote: > On 07/27/2010 09:46 PM, Roman Putanowicz wrote: > >> Compiling the program >> g++ -I INC_PATH -L LIB_PATH coordsBug.cxx -lMOAB -o coordsBug >> > > I used non-optimized builds for my tests above. I'll try again with > optimized builds. > I still could not reproduce the problem using an optimized build of MOAB. - jason

1 0

Possible bug in moab::Core::get_coords
by putanowr＠l5.pk.edu.pl 28 Jul '10

28 Jul '10

Dear All, The same program, same data, two different machines and two different outputs. Could someone of you, please, confirm the results so I can exclude some stupid configuration bug (like wrong lib version though I have checked that :) In the attachment there is a simple program and data file. The program finds the length of a perimeter of a skin of a triangle mesh. I run it on two machines: machne A: gcc --version : gcc (Debian 4.4.4-6) 4.4.4 uname -srm : Linux 2.6.32-trunk-686 i686 machine B: gcc --version : gcc (Debian 4.3.2-1.1) 4.3.2 uname -srm : Linux 2.6.26-2-amd64 x86_64 MOAB svn version 4070 Running the program I got: Machine A: | Machine B ---------------------+--------------------------- V: 1 2 | V: 1 2 0 0 0 1 0 0 | 0 0 0 1 0 0 V: 2 3 | V: 2 3 1 0 0 1 1 0 | 1 0 0 1 1 0 V: 3 4 | V: 3 4 1 1 0 0 1 0 | 1 1 0 0 1 0 V: 1 4 | V: 1 4 0 1 0 0 1 0 | 0 0 0 0 1 0 <<--------- BINGO Perim length: 3 | Perim length: 4 For the test data (unit square mesh) correct anser is of course B. ( BTW why the vertices of the last edge are 1 4 and not 4 1 ? ) Compiling the program g++ -I INC_PATH -L LIB_PATH coordsBug.cxx -lMOAB -o coordsBug Running: coordsBug two_triangles.vtk Thanks in advance for any hint. Regards, Roman -- Roman Putanowicz, PhD < putanowr(a)l5.pk.edu.pl > Institute for Computational Civil Engng (L-5) Dept. of Civil Engng, Cracow Univ. of Technology www.l5.pk.edu.pl, tel. +48 12 628 2569, fax 2034

2 1