-
Notifications
You must be signed in to change notification settings - Fork 30
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
Fix incorrect smoothing #19
base: master
Are you sure you want to change the base?
Conversation
@JBorrow asked for a quick code review so here it is. My main question, whithout having read the rest of the code is the consistency between the |
@MatthieuSchaller, I think the consistency between the h assumed by sphviewer and that used in SWIFT/GADGET should be checked and ensured by the user. More kernels can be added if needed. One way around this would be to create dedicated tools that make the corrections. |
31e573c
to
c0b15b1
Compare
I rebased this on my new kernel improvements branch, so it should be a clean merge. Unfortunately, the diff is still huge as I had to re-write the whole render function as it was doing some quite incorrect things:
At the moment, the smoothing lengths are expected to be the kernel cut-off radius. This is not ideal, no. I don't know how we would go about changing this without introducing huge breaking changes. I suppose what we could do is use a macro to compile multiple versions of the c_render function with different kernels, and then choose that at run-time with python code. |
I am now revising this. Below some comments. I tried your code with very low resolution and it gave me segmentation fault. Could you try too? e.g., 5x5 pixels? As I explain below, the fix for low-resolution images is not related to what you say, but to a very small fix that you introduced in your code (read below). This is now in master and it should make the image largely independent on the resolution.
I don't know what you mean by pixel-adding mode. Could you please expand on this?
Although the missing contribution of particles below the kernel size fixes the problems, if you make a plot of total mass recovered as a function of resolution you will see that there is still a difference of about 3% in mass at intermediate resolutions. This is due to some more fundamental problem. The solution will require to stop using a continuous kernel to do the calculation but introduce the relevant correction due to the discreteness of the image. One this is done and understood, I am happy to start considering code style. |
I've fixed the segfault bug. It was due to the variable
|
Please can you revert your minor change - it causes merge conflicts with this branch! |
OK. your branch works now. It doesn't seem to return the right mass for low-res images though. |
Can you provide example code? All of my code repdroduces exactly the mass that I put in. |
This is not extremely problematic. The particle is below the resolution, so that's fine to me. This is harmless.
We could have many more. That's not a problem. |
The particle is fundamentally not below the resolution limit though, its kernel overlaps with strictly two or more cells. |
This doesn't pass the test.
|
Putting the particle at the edge just moves the particle at the pixel level, i.e., the resolution limit of the image. So, it doesn't matter if the particle moves one pixel as long as the mass is conserved. So, I see this issue as occurring below the resolution of the image. |
Fixes incorrect smoothing on small scales as reported in #16.
This also includes the changes to the kernels in another MR (#18); please merge that one first, and then we'll review this.
It also is about 5% faster (with gcc9.1.0 on my Macbook Pro), as well as giving correct answers:
Old:
![image](https://user-images.githubusercontent.com/7839515/66091233-d328ac00-e53b-11e9-90de-6585c4a8e96b.png)
New:
![image](https://user-images.githubusercontent.com/7839515/66091226-cc9a3480-e53b-11e9-8691-6c5a576eb6e0.png)
I have also:
c_code.c
that was completely un-used.