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

Using ndim/2 for analytical vs simulated comparison misleading - higher errors at specific slices #37

Open
mathieuboudreau opened this issue Jan 22, 2025 · 1 comment

Comments

@mathieuboudreau
Copy link
Member

  • Note, this is using the main branch, I'll look into if our general fixes in the mb/custom pad improved or not soon.

Working on #31, I encountered an unexpectedly high mean difference between analytical and simulations of a sphere when considering the whole 3D volume instead of just specific slices.

In the README, only three slices are ploted, ndim/2 for all three axes,

Image

I first exported about half of the volume (reshaped to 1D) to excel from CSV (the entire volume was too large for Excel), and then plotted the difference between the simulation and analytical solution, and saw these odd spikes:

Image

After finding one of the slices (xdim) where one of these "peaks" happens, I ploted the comparison:

Image

Looks like overshoots/Gibbs ringing from FFT's when there is a step function/square function.

Looking at a gif of going through all the slices, we see this happens very close to the boundary, i.e. where the analytical solution inside the sphere becomes 0.

Image

Look here at five slices around that boundary

Image
Image
Image
Image
Image

This was missed before because as we see in the above slices, the simulation at "0" slice dimension on the x-axis is always fairly close to the analytical, and for all three ndim/2 we cross that zero. A slice a bit off center would have revealed this.

There's likely a thick "shell" around and inside the sphere where this ringing occurs (I havent tried to illustrate this), which explains why my mean error became so high when calculated.

Tagging @evaalonsoortiz so you're aware of these plots.

@mathieuboudreau
Copy link
Member Author

  • Note, this is using the main branch, I'll look into if our general fixes in the mb/custom pad improved or not soon.

For completeness I just checked and it's also there with our fixes form that branch (which I expected, since the default parameters of the main branch were setup to work properly, it's when we changed matrix to odd pairities that issues would pop up).

I guess this is just something we have to live with, unless we want to apply an apodizing filter to the geometry / tissue masks

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

No branches or pull requests

1 participant