Ideas

This is a page for ideas. Please sign your suggestions or comments on other suggestions ("@" followed by your username).

GUI

@ddb: There's finally some better documentation on making widgets for jupyter notebooks. There's a particularly nice example of porting a flow chart software to JupyterLab. Drag and drop SVG stuff and such:

Units

@ddb: The python package 'pints' looks quite nice for this

@ssl: Support parsing and display of different units, e.g.:

Hz, rad/s
W, sqrt(A), photons/second (for fun!)
ohm, farad, henry, etc. for the circuit part

also scaling factors:

Furthermore, the parser could recognise common abbreviations, like "2k49" (2.49 k, e.g. for ohms), "2.49k", "1.2e6", etc. I've already implemented this in circuit.py so it would be straightforward to provide such a parser, but the work would be implementing this into the Finesse syntax parser.

For display, it would simply be a case of converting standard internal Finesse units to whatever the user wants, which is already possible in C Finesse. Maybe the Python version would be a bit more intelligent and not scale blindly (e.g. the "scale meter" command assumes the unit to be scaled is rad/s, but this isn't always the case).

Simulation output

@ssl: provide a "solution" class to the user as output, which contains not only methods to plot the results, but also metadata regarding the simulation such as the units, transfer function input and output port names, noise sources/sinks, etc., and tools to export the data to some standard file format (HDF5?). It could even contain the simulation code that produce the contained solution, such that the whole thing could be pickled and sent as one file to someone else to share/debug.

It's possible that we could reuse some PyGWINC noise budget code for this. As this should contain some way to create a noise hierarchy, it would also ideally be possible to plot only total noise of certain types (e.g. noise arising from resistors or op-amps in the loop) and individual noise from others (e.g. noise from each open port to each sensor). We could make this even smarter by recognising which noise sources are dominant (by looking for the noise sources that contribute more than say 10% of the total) and only plot these in the legend, and provide everything else as an "additional noise" curve.

Plotting

@ssl: allow automatic plotting of an SQL curve on sensitivity plots. Not sure how easy it would be to automatically calculate the SQL from the simulation if it's more complicated than just a Fabry-Perot, so the reduced mass might have to be manually provided.

Standard analyses

@ssl: Optickle has this nice function, showfdc. It prints the powers at every space in the interferometer. It would be nice to have something similar, where the user could just do e.g.

>>> from finesse.analyses import DCFields
>>> analysis = DCFields(model)
>>> analysis.run()
>>> analysis.print()
|---------------------------------------------------------------
|            | laser->{nout}--{n1}<-eom | eom->{n2}--{n3}<-bs1 |
| carrier    |          1.0 W           |         0.99 W       |
|   9 MHz    |            -             |           5 mW       |
|  -9 MHz    |            -             |           5 mW       |
|   etc...                                                     |
|---------------------------------------------------------------
>>> print(analysis.power_in(model.spaces["s1"])) # total power in all fields
1.0 W
>>> print(analysis.power_in(model.spaces["s1"], model.fields["carrier"])) # carrier power
1.0 W
>>> print(analysis.power_in(model.spaces["s1"], model.fields["9M"])) # upper sideband power
0

Sanity checking framework

@ssl: it would be great to have some kind of system that lets you quickly check an interferometer model for sanity, like checking if cavity powers are at design values etc. This would be a system that adds detectors in various places automatically and reads out their powers and compares to accepted ranges, e.g.

checker = SanityChecker(model)
checker.assert_cavity_power_within_range(model.cavities["xcav"], (80e3, 100e3))

Users could then define a test file that they can run whenever they make changes to their model, which will run this checker and see any exceptions it throws.

This should probably be used within unittest to take advantage of its setup/teardown methods, resetting of state etc. Maybe this sanity checker should just be a subclass of unittest.TestCase.

Mode matching

@ssl / @adf: may as well use the beam propagation routines already built in to Finesse for a separate mode matching library / CLI / GUI. It may be useful to leverage Scipy's optimisation toolkit to find optimal lenses or find waist positions from data.

Some discussion from chat channel occurred from 2018-10-17. Main points:

Current JamMt tool widely used, very easy to use but has its quirks. For example, its optimiser is quite simplistic and cannot handle constraints on e.g. lens positions. "Ideally, it would do some simulated annealing or something afterwards, as most of those "solutions" actually condense down to a single solution."
There is no reason why Finesse can't perform the same calculations using the beam tracing library functions.
If these are not easily accessible for a separate mode matching tool, they should be made to be.
The main reason why JamMt is used is because its GUI is intuitive and easy. We should try to replicate this if we attempt to make a Finesse-based mode matching tool.
Ideas for GUI:
- Web-based, so it can be used on any device, e.g. iPads in the lab.
  - How could lens libraries be handled there? YAML file upload? User accounts? Drag and drop lenses into the "workbench" from a list of standard lenses?
- Distributed as part of Finesse 3, using the console_scripts entry in setup.py to define the interface.
- Some combination of the above, using a toolkit that can generate JavaScript from Python, e.g. flexx.

Optimisation

The utility should handle constraints on lens positions, allowing one to define bounds in which lenses can be placed. Scipy contains optimisation algorithms which allow such bounds, such as scipy.optimize.minimize's L-BFGS-B, TNC, SLSQP and trust-constr algorithms. Another possibility is pybobyqa.

JupyterLab

@ssl / @adf: once JupyterLab is relatively stable, it might be worth investigating a JavaScript widget to provide the mode matching GUI.

Hints/warnings of subjective assumptions

@ssl: Occasionally users (including advanced users) run into problems where they think they understand how the simulation is working but it turns out there is some slightly hidden setting that changes what is going on. For example, the way that the "phase" commands works, or the way "abserr" and "relerr" are used in the context of aperture integrations. Here I think it is useful to use the logging system to tell the user whenever a potentially subjective assumption is being made. In the case of aperture integration for example, a warning could be raised saying "Numerical integration performed to abserr = 1e-3 / relerr = 1e-3. You may wish to increase this if you have large beams with respect to aperture sizes in your model." Then the first step when debugging a problem would be to switch on verbose logging and look at what it's doing. This logging may be worth doing whenever an INI file value is used.

Remote solving back-end

@ssl: we could abstract away the solver back-end from the user code in such a way that the solving can be handled either on the user's local machine or on a remote cluster in a way that is transparent to the user. Ideally the server would just have to have Finesse 3 installed - with no special server version, just started with a flag that tells it to run as a server and to listen for incoming connections. We'd probably have to serialise/unserialise objects to send across the network though - definitely the Solution, but probably also the Analysis (unless we support kat-script inputs only), which means these objects would have to be serialisable.