use register_buffer so it works with .to()

I moved the registering from the init to here.

Is the device handling okay now? I'm not sure given the latest updates

From the latest PR #989, we should not rely on self.device internally in the future, since for example physics.to(device) with move buffers to device but not self.device. So either we add a dummy tensor _device_holder to dynamically update the device when calling update_parameters() or only register the buffer on the same device of the tensor and users are responsible for giving the tensor transmitter on the right device. Can you confirm that @romainvo?

Yes, exactly, the same is also true for self.dtype, it is not going to be updated appropriately when calling to(). Ideally, the _device_holder should just be a temporary measure to avoid breaking current workflows; I think newly implemented physics should not rely on this.

The deprecation of self.device also induces some changes in how parameters/buffers should be updated:

• in Fix #968 and remove self.device from internal LinearPhysics logic #989, when updating parameters inside A or A_adjoint, it is implied that the inputs are on the same device as the current buffers, and if new buffers are created, they are initialized on the device of the input (so update_parameters, if needed, takes a device kwarg as input.
• if some parameters should only be of a certain dtype, I suggest we hardcode it instead of setting self.dtype = torch.complex128. If multiple dtype precisions are supported (like float16 or float32), then it should be up to the user to initialize correctly first, and then to manage the dtype of the parameters (by allowing them to pass dtype as a kwarg in the update logic e.g.)
• a rule I've implemented in Fix #968 and remove self.device from internal LinearPhysics logic #989, is that when updating a parameters, the dtype and device of the current parameter takes precedence over those of the pushed tensor, in practice this is handled by the super class in Physics.update_parameters. This means that you need to ensure all parameters updates are done via super().update_parameters. Because we don't have access to self.dtype or self.device, this prevents discrepency between the set of buffers, i.e. all buffers have the same dtype/device at all time, and we only rely on the to() method to change it. (https://github.com/deepinv/deepinv/pull/989/changes#diff-69993452ba3f714d704e427f51b84732addeb9b5fe672965827d28725955fe93R270-R275

thanks for the clarifications.

I removed all the to.(self.device) and to(self.dtype) from update_parameters(). I chose not to include the dtype and device as optional arguments, as the user can do physics.to(device) instead of changing devices in update_parameters

I think we can remove this function. As of torch2.10 there is only bessel_j0 or bessel_j1 and no bessel_j or bessel_y

Many thanks for spotting this!

I prefer to keep it, since the most important calls are for n=0 and n=1 (except for the testing function). I've fixed the implementation and now check if n in (0,1)

So since pytorch don't have hankel or bessel function implemented for higher order, I'm not sure if we should keep these functions or just use the function from scipy directly.

same as above, I kept and added a check in (0,1)