search

project-asgard / asgard

MIT License
27 stars 20 forks source link

fix the init of workspaces #678

Closed mkstoyanov closed 6 months ago

mkstoyanov commented 6 months ago

Avoiding excessive allocations, the workspace buffer does not shrink if the number of degrees of freedom is reduced. On the other hand, the workspace buffer for x needs to be padded with zeros for the padding cells that complete the hierarchy. If the buffer is not reset to zero every time the problem size-changes, then at some point we will be padding with the old entries for x from the previous time-step or previous refinement iteration, i.e., padding with non-zeros. Most of the time, using non-zeros for the padding will change the time-step significantly, which will trigger a refinement cycle that rejects the time-step and tries to repeat it on a different grid. If the grid is denser, the workspace vector will be resized and zeroed out, leaving no clearly observable problem. However, a small but non-zero entry can introduce a small enough change to fly below the refinement threshold, yet large enough to break the physics over several iterations.

TL;DR: Sometimes we were padding with non-zeros and that breaks the physics, but only over multiple iterations/timesteps.

closes #670

quantumsteve commented 6 months ago

I successfully ran our vlasov example with KRON_MODE_GLOBAL=ON

mkstoyanov commented 6 months ago

I successfully ran our vlasov example with KRON_MODE_GLOBAL=ON

Sounds great! Did you do adaptivity? The issue manifests only during adaptive refinement.

quantumsteve commented 6 months ago

I successfully ran our vlasov example with KRON_MODE_GLOBAL=ON

Sounds great! Did you do adaptivity? The issue manifests only during adaptive refinement.

./asgard -p vlasov -d 3 -l "6 5" -x -t 8e-4 -n 125 -m 6 --kron-mode dense --inner_it 50 --tol 1e-6 --adapt --max_adapt_levels "6 5" --thresh 1e-4

mkstoyanov commented 6 months ago

Thanks to both of you for checking this out.