[MOAB-dev] Possible bug in moab::Core::get_coords

[Jason Kraftcheck]

On 07/27/2010 09:46 PM, Roman Putanowicz wrote:
> 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.
> 

I tried to reproduce this with the following two compilers:

$ g++ --version
g++ (Debian 4.4.4-7) 4.4.4
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-4.3 --version
g++-4.3 (Debian 4.3.5-1) 4.3.5
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I got the correct answer in both cases.  Running them in valgrind did not
provide any insight either.

> ( BTW why the vertices of the last edge are 1 4 and not 4 1 ? )
> 

Because you are putting them in a Range, they will always be ordered by
handle.  But they could also be ordered that way in the edge.  MOAB does not
require that an edge have the same direction as the side of its adjacent
element (that obviously wouldn't work if it was adjacent to more than one
higher-dimension element.)

> 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.

- jason