diatomic / tess2 Goto Github PK

Issue by Tom Peterka
Saturday Nov 22, 2014 at 22:48 GMT

Replace:

#!c++

  visited_tets.insert(t);

  for (int i = 0; i < 4; ++i) {
    int u = tets[t].verts[i];
    if (u != v) {
      nbrs.push_back(std::make_pair(u,t));
      visited_verts.insert(u);

      int next = tets[t].tets[i];
      if (next == -1)
    finite = false;
      else
    q.push(next);
    }
  }

With:

#!c++

  q.push(t);

It's not a bug, just a simple implementation, and this is the way that neighbor_tets() and complete() are already structured. A student pointed this out to me when he was using the code. It needs to be done in both tess1 and tess2. I would do it in the development forks first, and then it can get pushed to main line later after it is tested.

I can take care of it. Any reason why I should not do this?

Issue by Dmitriy Morozov
Saturday Nov 22, 2014 at 21:50 GMT

Much of the logic can be copied from diy/io/block.hpp, but I'm not sure how it would interact with pNetCDF.

Issue by Tom Peterka
Monday Nov 17, 2014 at 02:53 GMT

Don't forget to copy current version of dense from tess1 before starting this.

Issue by Tom Peterka
Monday Nov 17, 2014 at 02:53 GMT

When the number of total blocks is greater than the number of processes and the number of blocks keeping in memory is less
than the number of local blocks, an error is thrown for sending and receiving data between blocks. I have tried to run examples/pread-Voronoi in the out-of-core mode. Here is the input parameters in PREAD_VORONOI.
procs=2
infile=./unit-cube.h5
opts="-m 1 -b 4"
However, in the out-of-core mode, the redistribute() function in src/tess-regular.cpp which sorts and redistributes points in blocks threw an exception. The print information is as follows.
Saving block gid 0, points 32768
Saving block gid 2, points 32768
---------round=0-------------------
gid 1, points 32768
gid 3, points 32768
[1] Sent 16424 points to [0]
[3] Sent 16315 points to [2]
Saving block gid 3, points 16453
Saving block gid 1, points 16344
Loading block gid 2, points 32768
Loading block gid 0, points 32768
gid 2, srp.in_link().size=0, srp.incoming()->size()=0
gid 0, srp.in_link().size=0, srp.incoming()->size()=0

It seems that communication can only occur between blocks in memory. The blocks in storage (i.e. gid 0 and gid 2) cannot dequeue data that is enqueued by the blocks in memory.

I would be very grateful if you could take a moment to fix this bug.

Issue by Dmitriy Morozov
Saturday Nov 22, 2014 at 22:00 GMT

I think the general principle should be to minimize how much the user needs to know about DIY, while still allowing full access. This means on the one hand preserving tess(master), which assumes the blocks are prepared in the dblock_t format, while providing convenience functions that simply take points as input.

• Create a function akin to tess(world, points), which would set up its own master (from the world communicator), redistribute the points, and compute the Delaunay triangulation. The user would simply get the local points (resulting from the redistribution) and local tetrahedra in return. Or maybe it's Ok to return the local dblock_ts; that much exposure to the internals should be Ok.
• Move redistribute() from examples/pread-voronoi/pread-voronoi.cpp into the main tess library.
• Create a simpler tess(master) that sets up its own quants and times. As interesting as those are to us, the users probably wouldn't care about them, so no need to expose them in an API.