Question regarding kzetafinder_equation

[Edenhofer]

ScatteringOptics.jl/src/kzetafinders/periodicboxcar.jl

Lines 18 to 21 in c730f8e

	#x = π ./ (1 .+ kzeta)
	#return sin.(x) ./ x .- finder.ζ0
	x = 1 ./ (1 .+ kzeta)
	return sinc.(x) .- finder.ζ0

The referenced formula (Equation 47 of Psaltis et al. 2018) contains an additional kzeta in the argument to sinus. Is that potentially missing here?

Part of openjournals/joss-reviews#6354 .

[Edenhofer]

A related question about kzetafinder_equation in src/kzetafinders/dipole.jl and src/kzetafinders/vonmises.jl , shouldn't the square difference be penalized instead of value - A^2?

[kazuakiyama]

We are very sorry that our response came very late. @annatartaglia had a career transition after we received the report and unfortunately, it took a long time for us to come back to work on the revision. The package revision is almost done and here we would like to answer your questions.

The referenced formula (Equation 47 of Psaltis et al. 2018) contains an additional kzeta in the argument to sinus. Is that potentially missing here?

Thanks for carefully going through the equation. Indeed, this implementation is slightly different from Equation 47 of Psaltis et al. 2018. To our knowledge, Equation 47 has a typo --- this extra kzeta you found is not required. Unfortunately, for some reason, the paper didn't complete the review process or have another revision, and the typo has been left in the arxiv posting for a while.

You can find the correct model implemented in the current community standard package (e.g. see l.106 of this code in eht-imaging library). This is a reference implementation of Psaltis et al. 2018. We added the clarification in the source code (commit: a619d55).

A related question about kzetafinder_equation in src/kzetafinders/dipole.jl and src/kzetafinders/vonmises.jl , shouldn't the square difference be penalized instead of value - A^2?

This came from the definition of NonlinearProblem in NonlinearSolve.jl used in the package. NonlinearProblem needs the actual equation to be solved rather than the cost function (e.g. squared differences) for the optimization. We tried other optimization packages available in Julia (e.g. Optim.jl and Optimization.jl), and we found NonlinearSolve was the fastest among the packages we tried. This leads to the current implementation choice and definition of the equation.

Please let us know if you have any additional questions. Again, we thank you for your thorough reading of the library.

[Edenhofer]

Thank you for your detailed reply! This all makes sense :)