hcipy
hcipy copied to clipboard
ehpor
Instrument models
In #134 @vkooten discusses implementing a full instrument model for the Keck AO system as an example. This made me wonder.
Do we want full instrument models in the core code of hcipy? Do we make it a separate package? And if we do add it. What interface do we want? We probably want to add an additional folder in the hcipy structure for actual instruments.
I am very positive to the idea of adding actual instrument models in hcipy. That would make development of new control algorithms for example pretty quick. And it would also be relatively easy for new people to pick up full AO simulations.
This question has come up a few times from different people/groups. My stance has been the same each time so far, but I could be convinced otherwise by good argumentation.
I get that having realistic instrument models available is a nice thing for rapid prototyping. The problem lies in accuracy and maintenance. Accurate models take a lot of time to get right, and even more time to keep accurate and keep working properly. Even if a full model for an instrument was implemented and added to hcipy, it needs to be kept up to date with any physical changes in that instrument/better calibration of that instrument. This maintenance is not free.
Tutorials on the other hand do not need to be kept fully up to date, since they are there to showcase functionality of hcipy and provide a starting point for others if they want to try out something similar. While it is nice if the more elaborate tutorials could be kept up-to-date with the actual instrument that they purport to simulate, this is not a requirement for them to be a good tutorial.
Edge cases for me include realistic telescope apertures, atmospheric layer models and the like. I personally see these as components or reference implementations that are useful for a quick simulation and for comparison to existing papers. They may not always be the most up to date, which is why I'm always stressing that we need to have references/citations in the docstrings for those functions/classes.
TLDR: I'd much rather have separate packages for each instrument, that depend on hcipy for their optical propagation needs, rather than directly implementing them in hcipy. Don't let my opinion stifle the discussion. I'd like to hear other's opinions on this as well.
I agree that we should not have full instrument models because maintaining them is a lot of work and not really what we should be doing. I do think that we need to expand our examples / tutorials. This should help startup new people a lot. Especially if we can make the examples close to actual instruments. This is what I was thinking initially.