PABLO: Getting corner nodes along periodic boundaries

[mdelorme]

Hi there !

We've been using PABLO for a couple of months to build a new CFD simulation code but I've run into a slight problem as of late.

When I'm trying to extract corner neighbours of a cell using (for example) findNeighbours with codim=2 in 2D, the function will yield no result along periodic borders. Everything is ok inside the domain, the problem only arises at periodic boundaries.

Here is a MWE to see the problem:

int run_2d()
{
  ParaTree mesh(2);

  /** Periodic boundary conditions */
  mesh.setPeriodic(0);
  mesh.setPeriodic(1);
  mesh.setPeriodic(2);
  mesh.setPeriodic(3);

  /** Global refinement, once**/
  mesh.adaptGlobalRefine();
  mesh.adapt();
  mesh.updateConnectivity();

  uint32_t nOct = mesh.getNumOctants();
  std::cout << "Number of Octants : " << nOct << std::endl;
  std::cout << "Extracting the four corner neighbours of each Oct : " << std::endl;
  for (uint32_t iOct=0; iOct < nOct; ++iOct) {
    std::vector<uint32_t> neigh;
    std::vector<bool>     isGhost;
    std::cout << ". iOct = " << iOct << std::endl;
    for (uint8_t iCorner=0; iCorner<4; ++iCorner) {
      mesh.findNeighbours(iOct, iCorner, 2, neigh, isGhost);
      std::cout << " - For corner " << (int)iCorner << "; " << neigh.size() << " neighbours: [ ";
      for (auto iNeigh: neigh)
	std::cout << iNeigh << " ";
      std::cout << "]" << std::endl;
    }
  }

  std::cout << "Extracting the four face neighbours of each Oct : " << std::endl;
  for (uint32_t iOct=0; iOct < nOct; ++iOct) {
    std::vector<uint32_t> neigh;
    std::vector<bool>     isGhost;
    std::cout << ". iOct = " << iOct << std::endl;
    for (uint8_t iFace=0; iFace<4; ++iFace) {
      mesh.findNeighbours(iOct, iFace, 1, neigh, isGhost);
      std::cout << " - For face " << (int)iFace << "; " << neigh.size() << " neighbours: [ ";
      for (auto iNeigh: neigh)
	std::cout << iNeigh << " ";
      std::cout << "]" << std::endl;
    }
  }
    
  return 0;
}

In this example, we have 4 cells. Trying to extract the corner nodes of the cells will give us only one result for each node (the one that is inside the domain), while we should have 4 neighbours for each cell.

I don't know if it's easy to fix for you. For the moment, I'm switching to using multiple calls to findNeighbours along faces, but this is not ideal. So if you have a better recommendation I'd be glad to hear it :)

Thanks in advance !

[edoardolombardi]

Hi Maxime,
thank you for the warning.
We're glad of your interest in our library and we're working to solve your problem.
Indeed, the periodic conditions of PABLO meshes were introduced as a feature aimed to a cell/face based application where corner and edge neighbors were not involved.
We're testing a new branch that includes the needed developments, as soon as possible we will open a PR to fix the issue on master branch.

Please note that, in your example, you don't need to set as periodic all the boundary sides of the domain, but when you declare a face as periodic ( e.g setPeriodic(1) ) the opposite face ( 0 ) is imposed as periodic automatically.

Finally, I suggest you to consider to pass to the use of VolOctree class instead of work with PABLO module. The VolOctree module is a wrapper of PABLO octree but it can even interface with all the native container of bitpit; morevoer VolOctree class eases the mesh adapting with data defined on the mesh and allows to use the IO bitpit module with classes for VTK output.
The periodic conditions are currently supported in VolOctree class with some limitations, that we have to better investigate. Considering only your example, these limitations should not affect your application. However, in the next future we will work to introduce in VolOctree class a complete support for periodic condition on the mesh; we keep you informed on the developments.

Thanks again.
Best,

Edoardo

[mdelorme]

Hi Edoardo,

Thank you for your reply and for working on a fix :)
You're right, I didn't need to set everything periodic, this was just a reflex :)

As for VolOctree, we had an internal discussion and we are considering switching in the (near ?) future. Is switching from ParaTree to VolOctree easy (simple refactor of everything referring to ParaTree into VolOctree) or does it require a lot of work adaptation ?

Besides that, just a quick question regarding VolOctree, when you say :

The periodic conditions are currently supported in VolOctree class with some limitations, that we have to better investigate

Do you mean the same problem I'm talking about in this issue or are you talking about periodicity in general ?

[mdelorme]

Hi, just an additional point regarding, this, it seems that since balance21 is relying on findNeighbours (cf LocalTree), corner neighbours are not properly balanced along periodic boundaries as well.

Here's an image of a test case i've run (Sedov Blast in 2d, not centered).
If you zoom on the left you'll see two selected cells that should be refined due to 2:1 balance. Please also note that we're using block based AMR so the image does not directly show the AMR tree, each AMR leaf holds a 4x4 regular grid in our case.

[edoardolombardi]

Hi Maxime,

concerning the question on periodicity in VolOctree, I was talking about periodicity in general: we have to perform some tests and to identify functions and features that don't work properly with periodic conditions.

Switching to VolOctree is not a simple refactor, some functions work in a different way and the involved containers are not always the same, but it should not be a huge effort. The operations are substantially the same, moreover VolOctree allows to use functions and information that ParaTree doesn't own (@andrea-iob can give you more details on it).
If you have any doubt or you need some help to switch to VolOctree we are glad to provide you the required assistance.

Finally, you're right the 21-unbalanced behaviour through nodes on periodic boundaries is directly related to the wrong functioning of find neighbors functions.
Please, can you try the new branch PABLO.add.node.and.edge.periodic.neighbours that we pushed? This branch contains an implementation that should fix the issue.

Thank you for your feedback.

[mdelorme]

Hi Edoardo,

Thanks for the swift response. I've just tested the branch and the test now gives the correct neighbours !

For the switching to VolOctree, we'll maybe do it in a future version of the code but it's not our immediate priority :) That'll let me the time to read the examples and see how everything works, but be sure I'll come back to bother you if I need some assistance in switching !

Thanks for your help !

[edoardolombardi]

Good!

Thank you for your warning and useful assessments.