donnaaboise
commented
9 years ago Original comment by Carsten Burstedde (Bitbucket: cburstedde, GitHub: cburstedde):
You are right, I too prefer saying remote for everything off-processor, and neighbor for topological adjacency no matter if applied to neighbor patches, neighbor cells, or neighbor processors. So it would be better to change the variable names to npatch, nblock, etc., as is actually done in p4est. Maybe I should keep this task open on the side.
Originally reported by: Donna Calhoun (Bitbucket: donnaaboise, GitHub: donnaaboise)
Could confusion result from the use of the term "remote" to mean both an item on a remote processor, and just a neighbor patch?
Of course a patch can be both a "neighbor" and a "remote patch", i..e a neighbor on a different proc. I use "remote_neighbor" to mean a neighbor on a different processor. But then it seems that 'rface', 'rcorner', and 'rblock' only mean the block number of a neighbor block.
There might not be any confusion, technically, but I think I would prefer to reserve "remote" for remote processors only. So a "remote patch", "remote block" are patches on different processor; local patches and blocks are on the same proc.
Use "neighbor patch", "neighbor block" for neighboring patches.
"remote" patches might not be neighbors; "neighbor patches" might not be remote.
This means I might want to come up with different names for 'rface', 'rblock', and 'rcorner'.