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

Use of GridClean in FInterp #76

Open
jbschroder opened this issue Jun 9, 2021 · 2 comments
Open

Use of GridClean in FInterp #76

jbschroder opened this issue Jun 9, 2021 · 2 comments

Comments

@jbschroder
Copy link
Member

GridClean is called in FInterp at line 143 with
_braid_GridClean(core, grids[level]);
and this deletes the state vector at that level. This seems (possibly) counter to the storage options in the code that stipulate that we preserve storage on coarse levels (if the "int storage" is the right value).

Do we want to only call GridClean if storage == -1 or storage < level ? Or perhaps put this logic inside of GridClean?

This came up in TorchBraid, where we set storage==0 and then wanted access to the coarse ua vectors after braid_Drive was finished.

What do you think Rob @rfalgout ?

@rfalgout
Copy link
Collaborator

rfalgout commented Jun 9, 2021

Hi @jbschroder . By "cleaning" everything on a coarse level after interpolation, we allow users to modify their spatial coarsening strategy during the solve. However, I suppose we could call GridClean in FRestrict instead, just before restricting values to the coarse grid. We would also need to be careful about calling InitHierarchy in FRefine to make sure the previous coarse levels in the hierarchy are all clean.

Is there another solution to the TorchBraid issue?

@jbschroder
Copy link
Member Author

Hi @rfalgout, Ahh...that makes sense. We have to allow for users' complete freedom to coarsen spatially.

We did find a work-around in TorchBraid (spatially restricted fine-grid state vectors will probably work), but I thought this was a question worth asking.

I'm happy to look into calling GridClean in FRestrict, but maybe it's not worth it, unless this becomes a real problem for us. I probably lean a bit in this direction, but let me know if you disagree.

Cheers,

Jacob

[[ David ran into this, so I'll tag him here, too. @cadaverous-lives ]]

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

No branches or pull requests

2 participants