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

Pixelization interferometer search reconstructs negative fluxes #260

Open
AstroAaron opened this issue Mar 24, 2024 · 4 comments
Open

Pixelization interferometer search reconstructs negative fluxes #260

AstroAaron opened this issue Mar 24, 2024 · 4 comments

Comments

@AstroAaron
Copy link

Hello,
During the slam run for my interferometric dataset, I get both positive and negative fluxes in the pixelated source reconstruction. This applies to both source_pix[1] and the source_pix[2] reconstructions.
source_pix[1]: source reconstruction
image
reconstruction

source_pix[2]: source reconstruction
image
reconstruction

Is this behavior intended that for interferometric pixelated searches, the reconstructions can include negative pixels?

For my settings, PyAutoArray's general.yaml is as follows:

inversion:
  check_reconstruction: true          # If True, the inversion's reconstruction is checked to ensure the solution of a meshs's mapper is not an invalid solution where the values are all the same.
  use_positive_only_solver: true      # If True, inversion's use a positive-only linear algebra solver by default, which is slower but prevents unphysical negative values in the reconstructed solutuion.
  no_regularization_add_to_curvature_diag_value : 1.0e-3 # The default value added to the curvature matrix's diagonal when regularization is not applied to a linear object, which prevents inversion's fai$
  positive_only_uses_p_initial: true  # If True, the positive-only solver of an inversion's uses an initial guess of the reconstructed data's values as which values should be positive, speeding up the so$
  relocate_pix_border: false          # If True, by default a pixelization's border is used to relocate all pixels outside its border to the border.
  reconstruction_vmax_factor: 0.5     # Plots of an Inversion's reconstruction use the reconstructed data's bright value multiplied by this factor.

And I am using VoronoiNN as the image mesh for the pixelization runs.

@Jammy2211
Copy link
Owner

We implemented the positive-only solver ~6 months ago, but I never did thorough tests on the interferometer implementation.

This could imply theres a bug in the code and I need to correctly swap-out the code for the positive-only solution. I'll do some checks this afternoon.

Most our interferometer analysis has been performed on a positive-negative solver, and we trust the results, so I think these results are reliable. I have for a while been wondering if the positive only solver would make any difference to interferometry...so it'll be nice to find out.

@AstroAaron
Copy link
Author

Hey,
Any updates on this?

I have for a while been wondering if the positive only solver would make any difference to interferometry...so it'll be nice to find out.

So, by default is it not even applied in the interferometric analysis? Testing the run time for use_positive_only_solver true and false, I found no net increase (or decrease) in run time. The time it takes for the figure_of_merit with use_positive_only_solver=false is shorter by ~30s but the fit_time increased by ~30s compared to leaving it on.

Having negative pixels in the source reconstruction doesn't seem physical at all. Especially, since the input is continuum data.

@Jammy2211
Copy link
Owner

Not had time to check, but its on my to do list.

Having negative pixels in the source reconstruction doesn't seem physical at all. Especially, since the input is continuum data.

I agree, albeit I would note that every single lensing paper analysing interferometer data ever has used a positive-negative solver, so its pretty much the norm!

I'll try check asap, I've got a big source code refactor on the go which I need to get stable first lol.

@AstroAaron
Copy link
Author

Not had time to check, but its on my to do list.

Alright, just checking if it fell through the cracks. Thanks for working on it.

I agree, albeit I would note that every single lensing paper analysing interferometer data ever has used a positive-negative solver, so its pretty much the norm!

I expected as much, though I was wondering whether this was normal behavior for PyAutoLens. After all, it does have that feature but it could also have been something wrong with my code/input.

I'll try check asap, I've got a big source code refactor on the go which I need to get stable first lol.

No worries and good luck ;)

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

No branches or pull requests

2 participants