xbraid icon indicating copy to clipboard operation
xbraid copied to clipboard

Use of GridClean in FInterp

Open jbschroder opened this issue 4 years ago • 2 comments
trafficstars

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 ?

jbschroder avatar Jun 09 '21 16:06 jbschroder

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?

rfalgout avatar Jun 09 '21 16:06 rfalgout

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 ]]

jbschroder avatar Jun 09 '21 21:06 jbschroder