Open apkille opened 3 months ago
Maybe I've got some time tomorrow to test.
I think right now there is a bit of a mess, for example the code works for AngularSpectrum(array_3D, z_1Dvector, lambda, L)
which means that the output will be a 3D array where the 3D dimension is just the different distances.
But I don't understand the full details myself right now.
I think it would be fine to assume, that if it's a 3D array, there third dimension is going to represent a batch dimension (such as different polarizations or wavelengths). Not sure how hard it would be to get the code also generically running for 4D arrays. Maybe it's good to assume that everything is 4D as array? And then we just allocate everything as 4D arrays and the special cases of 2D inputs or 3D inputs we just write small dispatch wrappers which extract the dimensions?
See here, there is some mess haha https://github.com/JuliaPhysics/WaveOpticsPropagation.jl/blob/main/src/angular_spectrum.jl#L23
Thought about it more, maybe a convention like (x, y, z, polarizations, wavelength, batch)
.
And then all methods could be based on this 6 dimensional scheme?
Otherwise it' s confusing and requires a lot special handling if the input is 3D and whether this means x,y, polarizations or x,y,z.
or, we could adapt the way that Chromatix does this.
How does chromatix do it? I've seen they also use a 5D array https://chromatix.readthedocs.io/en/latest/higher_rank/#creating-fields-with-more-than-one-batch-dimension
As far as I remember, almost like your suggestion. Just the other way round because of python. Batch is, of course, configure multidimensional, which means any number of trailing dimensions are allowed. However, they put polarization (the 3 field components) as innermost dimensions which is for efficiency reasons I guess (e.g. calculating intensity from field in a sub-area). I actually somewhat prefer your suggestion as scalar code would then run out-of-the box.
Yeah their dimension arrangement is odd.
(x,y,z, polarization,wavelength,batch) sounds good to me. Most of time, z=1 anyway.
See this.
Dimension arrangement is critical. And since we perform mostly FFTs over (x,y), I believe we should have those dimension as tightest. z as next dimension just seems natural.
Sorry I haven't done much yet.
But for my own work I probably redesign everything to be a 6D array. Then the polarization dimension would be reserved for the different vectorial components.
In the long-term, I'm trying to get some financial support to work more on this package. But this won't happen before next year. Until then it'll be definitely changing a lot.
No problem, I haven't had time to really look into this either. In the future I'm hopeful that I can introduce some optics packages for Julia. It amazes me that there's no official packages for things like FDTD or the beam propagation method yet.
For FTDT there is https://discourse.julialang.org/t/pre-ann-differentiable-fdtd-for-inverse-design-in-photonics-acoustics-and-rf/105405
Beam propagation is what I'm aiming for, yes :)
Firstly, from what I've seen so far, this package is quite impressive! It's nice to see that optics packages for Julia are being developed.
I think it would be useful and not too hard, as you remarked in the README, to implement the angular spectrum method for vectorial fields, as it is used quite often for structured light applications and nonparaxial optics. If you're interested, I can create a PR that allows users to do this. We can also discuss simple examples that illustrate the method.