[BUG]: Quadtree only considers nBlocks for the geo grid

[abukowski21]

Quadtree is not splitting blocks as I would expect

When running with dipole4 and sphere, the quadtree sees that it needs to split the geographic grid, as expected. But then it also divides the magnetic grid into 4ths, leading to the magnetic grid only covering 1/4 of the globe.

---

from init_parallel

[...]
  int64_t nProcsPerNode = nGrids / quadtree.nRootNodes;


  quadtree.max_depth = round(log(nProcsPerNode) / log(4));
  quadtree_ion.max_depth = round(log(nProcsPerNode) / log(4));

  // Check to see if we have enough processors to do this stuff:
  int nBlocksLonGeo = pow(2, quadtree.max_depth); // input.get_nBlocksLonGeo();
  int nBlocksLatGeo = pow(2, quadtree.max_depth); // input.get_nBlocksLatGeo();
  nGrids = nBlocksLonGeo * nBlocksLatGeo * quadtree.nRootNodes;
  int nProcsNeeded = nMembers * nGrids;

  if (nProcsNeeded == nProcs) {

    // Get Ensemble member number and grid number:
    iMember = iProc / nGrids;
    iGrid = iProc % nGrids;
[...]

    quadtree.build("neuGrid"); 
    quadtree_ion.build("ionGrid");

  } else {
    if (iProc == 0) {
      std::cout << "Number of processors needed is not set correctly!\n";

It appears that we only check the geographic grid to determine if blocks need to be split. I can imagine a solution where we either:

1. Check both the geographic and magnetic grids, or
2. close the dipole 4/6 options off from the user and just pick which one is most appropriate. Or,
3. something else?

Quick fix:

This needed quick attention, so I put in a hacky solution. I put in a "Sphere4" with the same structure as "Dipole4". That's 4 blocks in latitude, with one longitudinal block.

SO this isn't too urgent, but might need some attention eventually...

my commit: d64be6b

[aaronjridley]

This is weird. I have never tested one grid with one root and one grid with four roots. I had thought that it would just work. Hmmm, since they should be disconnected. Weird.

On Wed, Mar 19, 2025 at 1:04 PM Aaron Bukowski @.***> wrote:

Quadtree is not splitting blocks as I would expect

When running with dipole4 and sphere, the quadtree sees that it needs to split the geographic grid, as expected. But then it also divides the magnetic grid into 4ths, leading to the magnetic grid only covering 1/4 of the globe.

from init_parallel https://github.com/AetherModel/Aether/blob/7bd131846b87f7443a4255712c5f8f4eb56fc43e/src/init_parallel.cpp#L61

[...] int64_t nProcsPerNode = nGrids / quadtree.nRootNodes;

quadtree.max_depth = round(log(nProcsPerNode) / log(4)); quadtree_ion.max_depth = round(log(nProcsPerNode) / log(4));

// Check to see if we have enough processors to do this stuff: int nBlocksLonGeo = pow(2, quadtree.max_depth); // input.get_nBlocksLonGeo(); int nBlocksLatGeo = pow(2, quadtree.max_depth); // input.get_nBlocksLatGeo(); nGrids = nBlocksLonGeo * nBlocksLatGeo * quadtree.nRootNodes; int nProcsNeeded = nMembers * nGrids;

if (nProcsNeeded == nProcs) {

// Get Ensemble member number and grid number:
iMember = iProc / nGrids;
iGrid = iProc % nGrids;

[...]

quadtree.build("neuGrid");
quadtree_ion.build("ionGrid");

} else { if (iProc == 0) { std::cout << "Number of processors needed is not set correctly!\n";

It appears that we only check the geographic grid to determine if blocks need to be split. I can imagine a solution where we either:

1. Check both the geographic and magnetic grids, or
2. close the dipole 4/6 options off from the user and just pick which one is most appropriate. Or,
3. something else?

Quick fix:

This needed quick attention, so I put in a hacky solution. I put in a "Sphere4" with the same structure as "Dipole4". That's 4 blocks in latitude, with one longitudinal block.

SO this isn't too urgent, but might need some attention eventually...

my commit: d64be6b https://github.com/AetherModel/Aether/commit/d64be6bd6755dd44fe852ca4914d98d5efa49521

— Reply to this email directly, view it on GitHub https://github.com/AetherModel/Aether/issues/170, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOYHCTJXVLY2F3HXGW3PF32VGPS3AVCNFSM6AAAAABZLMMRFCVHI2DSMVQWIX3LMV43ASLTON2WKOZSHEZTENJUHEYDSNY . You are receiving this because you are subscribed to this thread.Message ID: @.***> [image: abukowski21]abukowski21 created an issue (AetherModel/Aether#170) https://github.com/AetherModel/Aether/issues/170 Quadtree is not splitting blocks as I would expect

When running with dipole4 and sphere, the quadtree sees that it needs to split the geographic grid, as expected. But then it also divides the magnetic grid into 4ths, leading to the magnetic grid only covering 1/4 of the globe.

from init_parallel https://github.com/AetherModel/Aether/blob/7bd131846b87f7443a4255712c5f8f4eb56fc43e/src/init_parallel.cpp#L61

[...] int64_t nProcsPerNode = nGrids / quadtree.nRootNodes;

quadtree.max_depth = round(log(nProcsPerNode) / log(4)); quadtree_ion.max_depth = round(log(nProcsPerNode) / log(4));

// Check to see if we have enough processors to do this stuff: int nBlocksLonGeo = pow(2, quadtree.max_depth); // input.get_nBlocksLonGeo(); int nBlocksLatGeo = pow(2, quadtree.max_depth); // input.get_nBlocksLatGeo(); nGrids = nBlocksLonGeo * nBlocksLatGeo * quadtree.nRootNodes; int nProcsNeeded = nMembers * nGrids;

if (nProcsNeeded == nProcs) {

// Get Ensemble member number and grid number:
iMember = iProc / nGrids;
iGrid = iProc % nGrids;

[...]

quadtree.build("neuGrid");
quadtree_ion.build("ionGrid");

} else { if (iProc == 0) { std::cout << "Number of processors needed is not set correctly!\n";

It appears that we only check the geographic grid to determine if blocks need to be split. I can imagine a solution where we either:

1. Check both the geographic and magnetic grids, or
2. close the dipole 4/6 options off from the user and just pick which one is most appropriate. Or,
3. something else?

Quick fix:

This needed quick attention, so I put in a hacky solution. I put in a "Sphere4" with the same structure as "Dipole4". That's 4 blocks in latitude, with one longitudinal block.

SO this isn't too urgent, but might need some attention eventually...

my commit: d64be6b https://github.com/AetherModel/Aether/commit/d64be6bd6755dd44fe852ca4914d98d5efa49521

— Reply to this email directly, view it on GitHub https://github.com/AetherModel/Aether/issues/170, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOYHCTJXVLY2F3HXGW3PF32VGPS3AVCNFSM6AAAAABZLMMRFCVHI2DSMVQWIX3LMV43ASLTON2WKOZSHEZTENJUHEYDSNY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Aaron Ridley, Professor University of Michigan 1416 Space Research Building Ann Arbor, MI 48109-2143 (734) 764-5727