fmihpc / vlasiator

Vlasiator - ten letters you can count on
https://www.helsinki.fi/en/researchgroups/vlasiator
Other
43 stars 35 forks source link

Advection in an AMR mesh #55

Open sandroos opened 9 years ago

sandroos commented 9 years ago

This issue is a collection of accumulated wisdom related to propagating distribution functions in an AMR mesh.

amr_mesh_fin amr_mesh_ini amr_line_fin amr_line_ini

The current "issue" is that the monotonicity is not preserved, as evidenced by the figures above which depict the initial and final stages after x-propagation only (the location of the 3rd curve is not shown). The most likely reason is that coarse blocks, if their values end up in a refined block, need to be split to finer blocks prior to propagation.

sandroos commented 9 years ago

New images. Target mesh was first generated using forward mapping. Then the target mesh was mapped backwards, and simple integrations (no reconstructions whatsoever) were used to obtain the new volume averages. Smooth like babies butts across mesh resolution changes!

amr_backward_mesh amr_backward_curve

galfthan commented 9 years ago

Excellent!

iljah commented 9 years ago

So was it reconstruction that broke monotonicity or something else?

galfthan commented 9 years ago

No it was not the reconstruction. I guess Arto here left it off to avoid any complications. When you map forward the cells (in 1D as you do in slice-3D), then neighboring cells (in e.g. z direction) with different size will be shifted by an unequal amount (in z) as the shifting is based on the coordinate of the cell center. This means they will overlap, or leave gaps in-between. A picture would probably make this clearer....

The other benefit of first creating the target grid, and then doing the mapping backwards is that the latter step can now be threaded over as the target grid is fixed.

sandroos commented 9 years ago

One full rotation with AMR (no reconstruction) vs. master (PQM). Coarsening is obviously needed in AMR, otherwise the mesh will eventually end up in the finest allowed level. amr_ini amr_fin master_ini master_fin

sandroos commented 9 years ago

So the AMR without reconstruction is a bit more diffusive than PQM (surprise!), but still it's a pretty darn good result, and I don't see any artifacts.

galfthan commented 9 years ago

Good! How did total mass behave?

sandroos commented 9 years ago

Ilja, as Sebastian already mentioned it was not the reconstructions this time. They may still end up causing trouble, though.

sandroos commented 9 years ago

amr_propagation

Here's a figure of a single x-propagation step. There's still a problem with the AMR propagation, it is creating these "fingers" which get worse with larger timesteps. I do not think that this is due to the mass conservation / overlapping integration boundaries as we discussed with Sebastian. Instead, I suspect these are there because we do not reconstruct the coarse cell values in yz-directions.

If you look at the initial state, you can see that the small cell values change in y-direction, i.e., the cell on the bottom has a larger value than the cell on top. On the other hand, the value in the neighboring large cell is something in between the small cell values because of the volume averaging. If you now translate this structure in x-direction, and do not reconstruct the large cell value in y-direction, you end up dumping "too much" mass into the fine cells on top. Or that is what I suspect is happening.

So in other words, we might have to do 3D reconstruction for the distribution function before it is propagated or something.

galfthan commented 9 years ago

Perhaps it's worth trying, first doing one reconstruction (2D is enough I guess), and then based on those we do another one (higher order 1D).

This was after one 1D mapping in x, I still do not get why you would have more mass in the upper two, than in the lower two, due to not having reconstruction in y. Mapping the big ones on the small ones should put as much mass into both of them if they were shifted an equal amount, and since originally there was less in the upper one there should be at most the same amount.

Could it not be related to the fact that in the backward propagation the two upper small cells go deeper into the core than the lower two once, and therefore get more mass? yz plane reconstruction would help here also. Or can there be some bug with the integration boundaries when the small cell intersects with the integration boundary of the large cell (as happens here).

For reference: we think with Arto that the current scheme is not conservative as the integratoin boundaries do not cover uniqly the original distribution function. By doing it in "columns" this would be restored, at some performance and complexity cost.

sandroos commented 9 years ago

I'm not ruling out a bug somewhere in the mapping :) It is done at the highest refinement level, however, and then mapped down to the actual block that exists at that location, so in that sense it does not care whether there is an interface between blocks (of different ref levels) or not.

sandroos commented 9 years ago

More tests, this time 10 full rotations of a uniform "cross" density. The AMR does not seem to be creating any artifacts here, so it seems that the integration limits and mapping as such are ok. This was a good test, made me fix stuff happening at the velocity box boundaries.

amr_test_cross

sandroos commented 9 years ago

The inset in figure above shows a lineout along one of the branches (initial vs final)

ykempf commented 9 years ago

You meant "across", no?

sandroos commented 9 years ago

Looks a lot like a cross (pattern) to me :)

ykempf commented 9 years ago

Yes, you went across a cross, don't get cross. ;)

Why is the initial refinement pattern asymmetric, btw?

sandroos commented 9 years ago

The density is not exactly symmetric about the origin, so that's fine.

sandroos commented 9 years ago

So here's the thing I think is causing the problems at the moment. The figure shows the (correctly sampled) initial state. I set the initial phase-space density to be linearly proportional to v, i.e., f ~ A - B v/v_max. You get these "bumps" when sampling along the coordinate directions simply due to the fact that the cell values are averages, and that f is larger closer to origin.

amr_reconstruction

The largest jump occurs here at the interface between the coarsest (reflevel=0) and the next level (reflevel=1) block. If this is the reason behind the "fingers" I'm sometimes seeing, then we cannot get away without 3D reconstructions.. This effect should only get worse with more rapidly dropping distribution functions, such as Gaussians.

(and VisIt really wanted to offset those curves with respect to each others for some reason)

sandroos commented 9 years ago

Whoa the animated gif works!

Here I intentionally initialized an illegal AMR mesh. On horizontal axis are spatial cells in x-direction, and on vertical axis velocity blocks in vx-direction. The mesh is recursively refined until it becomes valid. No-content blocks are created at the last step. No-content blocks created during the initialization and mesh validation are dumped as they appear. This works with MPI and OpenMP.

amr

So the difference to a case happens during propagation is that here I recalculate the distribution functions using the project class instead of interpolating from coarse block (that is refined).

ykempf commented 9 years ago

Cool animation! ;)