Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pmb->loc broken? #1061

Open
pgrete opened this issue Apr 22, 2024 · 3 comments
Open

pmb->loc broken? #1061

pgrete opened this issue Apr 22, 2024 · 3 comments
Labels
question Further information is requested

Comments

@pgrete
Copy link
Collaborator

pgrete commented Apr 22, 2024

@lroberts36 I'm trying to calculate the effective offsets for each block for writing outputs.

Within a block like (on a mesh with 64x96 and blocks of 32x32)

    for (auto &pmb : pm->block_list) {
...
              std::cout << "Block " << pmb->gid << " writes chunk of [" << chunk_extent[0]
                        << " " << chunk_extent[1] << " "
                        << "] with offset [" << chunk_offset[0] << " " << chunk_offset[1]
                        << "] and logical locs [" << pmb->loc.lx2() << " "
                        << pmb->loc.lx1() << "]\n";
...

I get the following output:

Block 0 writes chunk of [32 32 ] with offset [0 0] and logical locs [0 0]
Block 1 writes chunk of [32 32 ] with offset [0 0] and logical locs [0 0]
Block 2 writes chunk of [32 32 ] with offset [0 0] and logical locs [0 0]
Block 3 writes chunk of [32 32 ] with offset [0 0] and logical locs [0 0]
Block 4 writes chunk of [32 32 ] with offset [0 0] and logical locs [0 0]
Block 5 writes chunk of [32 32 ] with offset [0 0] and logical locs [0 0]


Am I missing sth? IIRC previously `loc.lx#` returned the effective logical location in a global mesh at a given level.
This is with all changes from current `develop`.
@pgrete pgrete added bug Something isn't working enhancement New feature or request question Further information is requested and removed enhancement New feature or request labels Apr 22, 2024
@lroberts36
Copy link
Collaborator

lroberts36 commented Apr 22, 2024

No, this is the expected behavior as the grid you are using results in a forest of six trees. Each block has a logical location relative to the tree it is in, but 'LogicalLocation' now also contains the index of the tree in which it is contained accessible via 'LogicalLocation::tree()'. Getting on a plane now (and writing this from my phone), I will look at how to extract the offsets you want tomorrow morning. They are probably already contained in the neighbor block information.

@lroberts36
Copy link
Collaborator

lroberts36 commented Apr 22, 2024

For now, you could use Forest::GetLegacyTreeLocation using the locations stored in the MeshBlocks to get the old global logical location, but this will not work with general forests.

@lroberts36 lroberts36 removed the bug Something isn't working label Apr 22, 2024
@pgrete
Copy link
Collaborator Author

pgrete commented Apr 23, 2024

Perfect, that did the job! Thanks for the quick reply.
Now I also understand why this showed up in downstream testing (as I previously used a mesh that was part of a single tree in Parthenon).
One more reminder to add downstream testing of more complex mesh structures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants