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

Fix refine/coarsen logging #1036

Open
wants to merge 11 commits into
base: dev
Choose a base branch
from
Open

Fix refine/coarsen logging #1036

wants to merge 11 commits into from

Conversation

lkotipal
Copy link
Contributor

@lkotipal lkotipal commented Oct 9, 2024

Use correct datatype for logging coarsened cells. Oops...

@lkotipal lkotipal changed the title Fix coarsens Fix refine/coarsen logging Oct 9, 2024
@markusbattarbee
Copy link
Contributor

So the counts still don't quite add up.

According to this line:
https://github.com/fmihpc/dccrg/blob/d7a7746bcbcf53909acfd85d19dd29de8b0f123a/dccrg.hpp#L2495C6-L2495C7
each process tags only one of all siblings to unrefine. However, I guess if two siblings are on different processes, that would count as two unrefines, and if siblings exist on three different processes, then three.

The easiest workaround might be to actually store all siblings in this set, so that the reducet unrefine count would include all siblings, but change it so that when executing unrefines, siblings beyond the first are ignored. Thoughts?

@ykempf
Copy link
Contributor

ykempf commented Oct 21, 2024

I suppose one part of the question is: do we actually need the exact values? But I fear part of the answer is: as soon as we decide that "no", next week we'll start debugging a case that will require the actually correct values. So... I suppose we do want them?

@lkotipal
Copy link
Contributor Author

So the counts still don't quite add up.

According to this line: https://github.com/fmihpc/dccrg/blob/d7a7746bcbcf53909acfd85d19dd29de8b0f123a/dccrg.hpp#L2495C6-L2495C7 each process tags only one of all siblings to unrefine. However, I guess if two siblings are on different processes, that would count as two unrefines, and if siblings exist on three different processes, then three.

The easiest workaround might be to actually store all siblings in this set, so that the reducet unrefine count would include all siblings, but change it so that when executing unrefines, siblings beyond the first are ignored. Thoughts?

I could just refactor the loop on https://github.com/fmihpc/dccrg/blob/d7a7746bcbcf53909acfd85d19dd29de8b0f123a/dccrg.hpp#L3503 earlier on, like the end of override_unrefines?

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

Successfully merging this pull request may close these issues.

3 participants