finesse3 issueshttps://git.ligo.org/finesse/finesse3/-/issues2021-02-09T06:54:34Zhttps://git.ligo.org/finesse/finesse3/-/issues/237Automatic ABCD code2021-02-09T06:54:34ZDaniel BrownAutomatic ABCD codeA similar process to the Automatic Knm code could be applied to connector objects and ABCD matrices. A similar `set_abcd_info` method could be made available which sets in the ABCD info for each optical-to-optical connection. This could flag which matrix element will be changing, set up all the the cythonised expressions, etc. and do it in a way that no C code needs to be touched for new components.
This should probably be a new class between `ElementWorkspace` and `ConnectorWorkspace` (`ABCDElementWorkspace` or something) as the latter is now tied into carrier/signal matrix simulations. This symbolic ABCD code would be beneficial to other simulation codes too, like a pure beam tracing simulation or LCT.A similar process to the Automatic Knm code could be applied to connector objects and ABCD matrices. A similar `set_abcd_info` method could be made available which sets in the ABCD info for each optical-to-optical connection. This could flag which matrix element will be changing, set up all the the cythonised expressions, etc. and do it in a way that no C code needs to be touched for new components.
This should probably be a new class between `ElementWorkspace` and `ConnectorWorkspace` (`ABCDElementWorkspace` or something) as the latter is now tied into carrier/signal matrix simulations. This symbolic ABCD code would be beneficial to other simulation codes too, like a pure beam tracing simulation or LCT.Beta 1https://git.ligo.org/finesse/finesse3/-/issues/169Astigmatic surfaces - separate components?2021-02-08T15:18:47ZSamuel RowlinsonAstigmatic surfaces - separate components?Currently `Mirror` and `Beamsplitter` components have both `Rcx`, `Rcy` model parameters for the RoCs in each plane. The `Lens` just has `f` (no separation of the focal length into the two planes) for now but we'll want to have support for astigmatic lenses too (easy to do).
I was wondering recently whether we want to keep these surfaces as being generic, with the option of them being astigmatic, or do we want to have separate components for the astigmatic versions? e.g. `Mirror` would just have `Rc` as a model parameter whilst `AstigmaticMirror` would have `Rcx` and `Rcy`.
This separation could be quite neat in my opinion as it would get around some of the (essentially) user-interface problems referenced in #133. I think the majority of the time people use non-astigmatic surfaces so having specialised component versions for these could remove any confusion about planes and setting up references when scanning RoCs.
The only disadvantage I can think of here is that there would be a bit of code duplication I imagine. But this could be solved in principle by having, using mirrors as an example, a `MirrorBase` abstract class from which `Mirror` and `AstigmaticMirror` both derive.
Any thoughts?Currently `Mirror` and `Beamsplitter` components have both `Rcx`, `Rcy` model parameters for the RoCs in each plane. The `Lens` just has `f` (no separation of the focal length into the two planes) for now but we'll want to have support for astigmatic lenses too (easy to do).
I was wondering recently whether we want to keep these surfaces as being generic, with the option of them being astigmatic, or do we want to have separate components for the astigmatic versions? e.g. `Mirror` would just have `Rc` as a model parameter whilst `AstigmaticMirror` would have `Rcx` and `Rcy`.
This separation could be quite neat in my opinion as it would get around some of the (essentially) user-interface problems referenced in #133. I think the majority of the time people use non-astigmatic surfaces so having specialised component versions for these could remove any confusion about planes and setting up references when scanning RoCs.
The only disadvantage I can think of here is that there would be a bit of code duplication I imagine. But this could be solved in principle by having, using mirrors as an example, a `MirrorBase` abstract class from which `Mirror` and `AstigmaticMirror` both derive.
Any thoughts?Alpha 1https://git.ligo.org/finesse/finesse3/-/issues/238Allow optics to be directly shifted laterally2021-02-09T14:38:17ZSean LeaveyAllow optics to be directly shifted laterallyFollowing the emails with Matthew Stewart on the finesse-support mailing list, it would be good to allow optics to be shifted laterally as well as in angle (as is currently possible) directly rather than having to go the complicated route of converting a tilt into a translation via a telescope or by adding TEM modes to the laser.Following the emails with Matthew Stewart on the finesse-support mailing list, it would be good to allow optics to be shifted laterally as well as in angle (as is currently possible) directly rather than having to go the complicated route of converting a tilt into a translation via a telescope or by adding TEM modes to the laser.Futurehttps://git.ligo.org/finesse/finesse3/-/issues/223Reflection ABCD minus sign2021-02-01T05:56:00ZDaniel BrownReflection ABCD minus signAlexei recently posted a confusing result between the component ABCDs accessed in different ways: component direct access, and the tracertools
https://chat.ligo.org/ligo/pl/p69d6okfopdqpd7e6kihdiabur
This comes down to the fact that the coordinate system change that happens on reflection. Siegmann has a nice drawing of it here
![image](/uploads/fb92615595c9b0f4e894d162754058cf/image.png)
Given that Finesse nodes have a specified coordinate system associated with them I believe we should include this minus sign in the ABCD definition in components, rather than having tracertools do it in some hidden way. It makes no difference to any beam parameter calculations, i.e. waist size and position.
Users will use the Finesse ABCDs for their own calculations or extending Finesse, invariably they always forget this minus sign. This will stop any future errors.
We access this component level ABCD with code like `self.ABCD(self.p1.i, self.p1.o, "x")` which implies we are going from one node to another node which has specific coordinate systems implied. It's not like we have `mirror.ABCD_reflection('x')` or something which is coordinate system agnostic.
Users might initially be confused why the reflected ABCD has a minus sign, however it should be documented and made clear why it exists.Alexei recently posted a confusing result between the component ABCDs accessed in different ways: component direct access, and the tracertools
https://chat.ligo.org/ligo/pl/p69d6okfopdqpd7e6kihdiabur
This comes down to the fact that the coordinate system change that happens on reflection. Siegmann has a nice drawing of it here
![image](/uploads/fb92615595c9b0f4e894d162754058cf/image.png)
Given that Finesse nodes have a specified coordinate system associated with them I believe we should include this minus sign in the ABCD definition in components, rather than having tracertools do it in some hidden way. It makes no difference to any beam parameter calculations, i.e. waist size and position.
Users will use the Finesse ABCDs for their own calculations or extending Finesse, invariably they always forget this minus sign. This will stop any future errors.
We access this component level ABCD with code like `self.ABCD(self.p1.i, self.p1.o, "x")` which implies we are going from one node to another node which has specific coordinate systems implied. It's not like we have `mirror.ABCD_reflection('x')` or something which is coordinate system agnostic.
Users might initially be confused why the reflected ABCD has a minus sign, however it should be documented and made clear why it exists.Alpha 1https://git.ligo.org/finesse/finesse3/-/issues/211cymem2021-01-06T05:47:22ZDaniel BrowncymemMight be worth looking into moving stdlib memory calls over to something like cymem in the future.
https://github.com/explosion/cymemMight be worth looking into moving stdlib memory calls over to something like cymem in the future.
https://github.com/explosion/cymemFuturehttps://git.ligo.org/finesse/finesse3/-/issues/110Remove mirror/bs phase signal node2020-06-15T09:40:42ZDaniel BrownRemove mirror/bs phase signal nodeI don't really see the need to keep a `phase` signal input on components when we have mechanical motions. It's rare that we actually want a W/rad of longitudinal motion, people just want W/m.
In the case of wanting a W/rad TF you'd just use a signal generator with the appropriate scaling.I don't really see the need to keep a `phase` signal input on components when we have mechanical motions. It's rare that we actually want a W/rad of longitudinal motion, people just want W/m.
In the case of wanting a W/rad TF you'd just use a signal generator with the appropriate scaling.Alpha 1Andreas FreiseDaniel BrownAndreas Freisehttps://git.ligo.org/finesse/finesse3/-/issues/83A way to translate between finesse symbols and sympy2021-03-02T15:44:06ZAlexei CiobanuA way to translate between finesse symbols and sympyFinesse 3 seems to rely more and more on symbolic objects and operations (see #80 ). Instead of reinventing symbolic algebra there should be a way to convert between finesse symbols and sympy to achieve the same effect. I've previously written two functions to do this. I am not sure if they work anymore (or if they even covered all the cases correctly) but it seems like something like this would be useful to have around.
These functions were taken from `element.py` in the `operator` branch
```
def finesse2sympy(expr, iter_num=0):
# print(iter_num)
iter_num += 1
if isinstance(expr, NamedConstant):
if expr.__name__ == 'Pi':
return sympy.pi
else:
return expr.value
elif isinstance(expr, Constant):
return expr.value
elif isinstance(expr, ParameterRef):
return sympy.Symbol(expr.name)
elif isinstance(expr,Operation):
sympy_args = [finesse2sympy(arg,iter_num) for arg in expr.args]
if expr.op == mul:
op = sympy.Mul
elif expr.op == add:
op = sympy.Add
elif expr.op == sub:
op = lambda x,y: sympy.Add(x,-y)
elif expr.op == np.conj:
op = sympy.conjugate
elif expr.op == np.radians:
op = sympy.rad
elif expr.op == np.exp:
op = sympy.exp
elif expr.op == np.sqrt:
op = sympy.sqrt
else:
raise Exception(f"undefined Operation {expr.op} in {expr}")
return op(*sympy_args)
else:
raise Exception(f'{expr} undefined')
def sympy2finesse(expr, symbol_dict={}, iter_num=0):
# print(iter_num,expr)
iter_num += 1
print(expr,expr.is_NumberSymbol)
if isinstance(expr,sympy.Mul):
return np.product([sympy2finesse(arg, symbol_dict, iter_num=iter_num) for arg in expr.args])
elif isinstance(expr,sympy.Add):
return np.sum([sympy2finesse(arg, symbol_dict, iter_num=iter_num) for arg in expr.args])
elif isinstance(expr,sympy.conjugate):
return np.conj(sympy2finesse(*expr.args, symbol_dict))
elif isinstance(expr,sympy.exp):
return np.exp(sympy2finesse(*expr.args, symbol_dict))
elif isinstance(expr,sympy.Pow):
return np.power(sympy2finesse(expr.args[0], symbol_dict), sympy2finesse(expr.args[1], symbol_dict))
elif expr.is_NumberSymbol: # sympy class for named symbols (eg Pi, golden ratio, ...)
if str(expr) == 'pi':
return Pi
else:
return complex(expr)
elif expr.is_number:
if expr.is_integer:
return int(expr)
elif expr.is_real:
return float(expr)
else:
return complex(expr)
elif expr.is_symbol:
return symbol_dict[str(expr)]
else:
raise Exception(f'{expr} undefined')
```Finesse 3 seems to rely more and more on symbolic objects and operations (see #80 ). Instead of reinventing symbolic algebra there should be a way to convert between finesse symbols and sympy to achieve the same effect. I've previously written two functions to do this. I am not sure if they work anymore (or if they even covered all the cases correctly) but it seems like something like this would be useful to have around.
These functions were taken from `element.py` in the `operator` branch
```
def finesse2sympy(expr, iter_num=0):
# print(iter_num)
iter_num += 1
if isinstance(expr, NamedConstant):
if expr.__name__ == 'Pi':
return sympy.pi
else:
return expr.value
elif isinstance(expr, Constant):
return expr.value
elif isinstance(expr, ParameterRef):
return sympy.Symbol(expr.name)
elif isinstance(expr,Operation):
sympy_args = [finesse2sympy(arg,iter_num) for arg in expr.args]
if expr.op == mul:
op = sympy.Mul
elif expr.op == add:
op = sympy.Add
elif expr.op == sub:
op = lambda x,y: sympy.Add(x,-y)
elif expr.op == np.conj:
op = sympy.conjugate
elif expr.op == np.radians:
op = sympy.rad
elif expr.op == np.exp:
op = sympy.exp
elif expr.op == np.sqrt:
op = sympy.sqrt
else:
raise Exception(f"undefined Operation {expr.op} in {expr}")
return op(*sympy_args)
else:
raise Exception(f'{expr} undefined')
def sympy2finesse(expr, symbol_dict={}, iter_num=0):
# print(iter_num,expr)
iter_num += 1
print(expr,expr.is_NumberSymbol)
if isinstance(expr,sympy.Mul):
return np.product([sympy2finesse(arg, symbol_dict, iter_num=iter_num) for arg in expr.args])
elif isinstance(expr,sympy.Add):
return np.sum([sympy2finesse(arg, symbol_dict, iter_num=iter_num) for arg in expr.args])
elif isinstance(expr,sympy.conjugate):
return np.conj(sympy2finesse(*expr.args, symbol_dict))
elif isinstance(expr,sympy.exp):
return np.exp(sympy2finesse(*expr.args, symbol_dict))
elif isinstance(expr,sympy.Pow):
return np.power(sympy2finesse(expr.args[0], symbol_dict), sympy2finesse(expr.args[1], symbol_dict))
elif expr.is_NumberSymbol: # sympy class for named symbols (eg Pi, golden ratio, ...)
if str(expr) == 'pi':
return Pi
else:
return complex(expr)
elif expr.is_number:
if expr.is_integer:
return int(expr)
elif expr.is_real:
return float(expr)
else:
return complex(expr)
elif expr.is_symbol:
return symbol_dict[str(expr)]
else:
raise Exception(f'{expr} undefined')
```https://git.ligo.org/finesse/finesse3/-/issues/46Installation by pip fails2020-04-02T14:59:36ZArtemiy DmitrievInstallation by pip failsWhen installing Finesse 3 on Mac OS (following the procedure here https://finesse.readthedocs.io/en/latest/getting_started/installation.html), `pip` keeps getting stuck forever with 100% CPU load (when executing `$ pip install -e ./`). Running `make` in the Finesse directory produces output as attached [log.txt](/uploads/eb96aac0bac5b0b72fe8e6dcfaf8c35c/log.txt).
It looks like parallel building is the problem. Switching it off manually in `setup.py` as suggested by Sam Rowlinson removes this issue (as per attached patch [fixsetup.patch](/uploads/1a90df428b2cbfafaa96e45404523b3d/fixsetup.patch) ).When installing Finesse 3 on Mac OS (following the procedure here https://finesse.readthedocs.io/en/latest/getting_started/installation.html), `pip` keeps getting stuck forever with 100% CPU load (when executing `$ pip install -e ./`). Running `make` in the Finesse directory produces output as attached [log.txt](/uploads/eb96aac0bac5b0b72fe8e6dcfaf8c35c/log.txt).
It looks like parallel building is the problem. Switching it off manually in `setup.py` as suggested by Sam Rowlinson removes this issue (as per attached patch [fixsetup.patch](/uploads/1a90df428b2cbfafaa96e45404523b3d/fixsetup.patch) ).https://git.ligo.org/finesse/finesse3/-/issues/272Parallel build with pools is broken2021-03-07T14:40:28ZAndreas FreiseParallel build with pools is brokenThe parallel build via monkey-patching build_ext with Pools seems to fail. (It caused other issues as well, see #235).
The build now seems to compile each file several times (probably after upgrading to python >3.7)
See for example Mattermost discussion:
https://chat.ligo.org/ligo/pl/f6qhgfuhbpgs3bagi44yq8qffe
I have disabled the parallel build with pools for now, in 3daca11a. Instead I added an argument for parallel compilation to the Makefile:
```
python3 setup.py build_ext -j 4 --inplace
```
This should be tested on all platforms, and maybe someone wants to find a better way to run pools again.The parallel build via monkey-patching build_ext with Pools seems to fail. (It caused other issues as well, see #235).
The build now seems to compile each file several times (probably after upgrading to python >3.7)
See for example Mattermost discussion:
https://chat.ligo.org/ligo/pl/f6qhgfuhbpgs3bagi44yq8qffe
I have disabled the parallel build with pools for now, in 3daca11a. Instead I added an argument for parallel compilation to the Makefile:
```
python3 setup.py build_ext -j 4 --inplace
```
This should be tested on all platforms, and maybe someone wants to find a better way to run pools again.https://git.ligo.org/finesse/finesse3/-/issues/271Clean make omp.h and klu.h not found2021-03-06T10:39:24ZDaniel BrownClean make omp.h and klu.h not foundWhen doing a clean build it warns that klu.h and omp.h are not available. We should probably have setup.py do a test first to see if these exist then carry on, rather than spend ages building things then complain.
`conda install suitesparse llvm-openmp` gives what you need on anaconda.When doing a clean build it warns that klu.h and omp.h are not available. We should probably have setup.py do a test first to see if these exist then carry on, rather than spend ages building things then complain.
`conda install suitesparse llvm-openmp` gives what you need on anaconda.Alpha 1https://git.ligo.org/finesse/finesse3/-/issues/270Multi-processing EOFError HTML docs build2021-03-08T10:30:17ZSamuel RowlinsonMulti-processing EOFError HTML docs buildSeveral pipelines recently have failed with:
```
File "/usr/local/lib/python3.9/multiprocessing/connection.py", line 388, in _recv
raise EOFError
EOFError
The full traceback has been saved in /tmp/sphinx-err-5ctmkgj4.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
make: *** [Makefile:37: html_build] Error 2
Cleaning up file based variables
ERROR: Job failed: exit code 1
```
Looks this has been an issue in Sphinx before (last year): https://github.com/sphinx-doc/sphinx/issues/7802
That, and related issues, were closed but I suspect the newer version of Sphinx (coupled with the Py3.9 version getting used in pipeline) maybe causing this to show up again somehow.Several pipelines recently have failed with:
```
File "/usr/local/lib/python3.9/multiprocessing/connection.py", line 388, in _recv
raise EOFError
EOFError
The full traceback has been saved in /tmp/sphinx-err-5ctmkgj4.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
make: *** [Makefile:37: html_build] Error 2
Cleaning up file based variables
ERROR: Job failed: exit code 1
```
Looks this has been an issue in Sphinx before (last year): https://github.com/sphinx-doc/sphinx/issues/7802
That, and related issues, were closed but I suspect the newer version of Sphinx (coupled with the Py3.9 version getting used in pipeline) maybe causing this to show up again somehow.Alpha 1https://git.ligo.org/finesse/finesse3/-/issues/269Add pyproject.toml for pip install to install numpy and cython dependencies2021-03-05T12:45:52ZAndreas FreiseAdd pyproject.toml for pip install to install numpy and cython dependencies(Continuing my tries for a clean install of Finesse3 (dev) in a new conda env)
`pip install -e ".[dev]"`
Cannot easily install cython and numpy before they are imported in setup.py. The recommended solution is to add a pyproject.toml file specifying the requriements for setup.py, e.g.
```
[build-system]
requires = ["setuptools", "wheel", "Cython>=0.29", "numpy >= 1.11"]
```
`python setup.py install` will not be aware of these dependencies but `pip` will be.(Continuing my tries for a clean install of Finesse3 (dev) in a new conda env)
`pip install -e ".[dev]"`
Cannot easily install cython and numpy before they are imported in setup.py. The recommended solution is to add a pyproject.toml file specifying the requriements for setup.py, e.g.
```
[build-system]
requires = ["setuptools", "wheel", "Cython>=0.29", "numpy >= 1.11"]
```
`python setup.py install` will not be aware of these dependencies but `pip` will be.Andreas FreiseAndreas Freisehttps://git.ligo.org/finesse/finesse3/-/issues/268General problems with setting objects to element parameters2021-03-05T18:12:48ZDaniel BrownGeneral problems with setting objects to element parameters```
fp = finesse.Model()
fp.parse("""
variable f1 9099471
variable f2 45497355
variable nsilica 1.45
variable Mloss 30u
variable Larm 3994
modes(maxtem=0)
laser L0 P=125
mod mod1 f=&f1 midx=0.18 order=1 mod_type=pm
mod mod2 f=&f2 midx=0.18 order=1 mod_type=pm
link(L0, mod1, mod2, ITMXAR)
m ITMXAR R=0 L=20u xbeta=ITMX.xbeta ybeta=&ITMX.ybeta phi=&ITMX.phi
s ITMXsub ITMXAR.p2 ITMX.p1 L=0.2 nr=&nsilica
m ITMX T=0.014 L=&Mloss Rc=-1934
s LX ITMX.p2 ETMX.p1 L=&Larm
m ETMX T=5u L=&Mloss Rc=2245 phi=0
s ETMXsub ETMX.p2 ETMXAR.p1 L=0.2 nr=&nsilica
m ETMXAR 0 500u xbeta=&ETMX.xbeta ybeta=&ETMX.ybeta phi=&ETMX.phi
cav arm ETMX.p1.o
dof CARM ITMX.dofs.z +1 ETMX.dofs.z +1
dof DARM ITMX.dofs.z +1 ETMX.dofs.z -1
readout_rf REFL9 ITMXAR.p1.o f=&f1 phase=33 output=[I, Q]
pd1 REFL9_I ITMXAR.p1.o f=&f1 phase=33
lock DARM_lock REFL9. DARM.DC -0.0055 1e-5
xaxis(L0.f, lin, 10, 40k, 20)
""")
```
Gives:
```
KatDirectiveCompilationError: (use finesse.tb() to see the full traceback)
line 16: Unexpected input '0 radians'
15:
-->16: m ITMXAR R=0 L=20u xbeta=ITMX.xbeta ybeta=&ITMX.ybeta phi=&ITMX.phi
^
17: s ITMXsub ITMXAR.p2 ITMX.p1 L=0.2 nr=&nsilica
```
It seems to be taking `ITMX.xbeta` and using the string representation. I guess we don't want this, and for it to throw an error if the value isn't an expression or number?```
fp = finesse.Model()
fp.parse("""
variable f1 9099471
variable f2 45497355
variable nsilica 1.45
variable Mloss 30u
variable Larm 3994
modes(maxtem=0)
laser L0 P=125
mod mod1 f=&f1 midx=0.18 order=1 mod_type=pm
mod mod2 f=&f2 midx=0.18 order=1 mod_type=pm
link(L0, mod1, mod2, ITMXAR)
m ITMXAR R=0 L=20u xbeta=ITMX.xbeta ybeta=&ITMX.ybeta phi=&ITMX.phi
s ITMXsub ITMXAR.p2 ITMX.p1 L=0.2 nr=&nsilica
m ITMX T=0.014 L=&Mloss Rc=-1934
s LX ITMX.p2 ETMX.p1 L=&Larm
m ETMX T=5u L=&Mloss Rc=2245 phi=0
s ETMXsub ETMX.p2 ETMXAR.p1 L=0.2 nr=&nsilica
m ETMXAR 0 500u xbeta=&ETMX.xbeta ybeta=&ETMX.ybeta phi=&ETMX.phi
cav arm ETMX.p1.o
dof CARM ITMX.dofs.z +1 ETMX.dofs.z +1
dof DARM ITMX.dofs.z +1 ETMX.dofs.z -1
readout_rf REFL9 ITMXAR.p1.o f=&f1 phase=33 output=[I, Q]
pd1 REFL9_I ITMXAR.p1.o f=&f1 phase=33
lock DARM_lock REFL9. DARM.DC -0.0055 1e-5
xaxis(L0.f, lin, 10, 40k, 20)
""")
```
Gives:
```
KatDirectiveCompilationError: (use finesse.tb() to see the full traceback)
line 16: Unexpected input '0 radians'
15:
-->16: m ITMXAR R=0 L=20u xbeta=ITMX.xbeta ybeta=&ITMX.ybeta phi=&ITMX.phi
^
17: s ITMXsub ITMXAR.p2 ITMX.p1 L=0.2 nr=&nsilica
```
It seems to be taking `ITMX.xbeta` and using the string representation. I guess we don't want this, and for it to throw an error if the value isn't an expression or number?Alpha 1https://git.ligo.org/finesse/finesse3/-/issues/267Missing brackets parser error2021-03-05T08:39:59ZDaniel BrownMissing brackets parser errorParser should probably complain about missing brackets rather than missing element name.
```
KatScriptError: (use finesse.tb() to see the full traceback)
line 8: missing element name
7:
-->8: modes maxtem=0
```Parser should probably complain about missing brackets rather than missing element name.
```
KatScriptError: (use finesse.tb() to see the full traceback)
line 8: missing element name
7:
-->8: modes maxtem=0
```Alpha 1Sean LeaveySean Leaveyhttps://git.ligo.org/finesse/finesse3/-/issues/266Parser trying to get objects from Model?2021-03-05T11:11:10ZDaniel BrownParser trying to get objects from Model?```
fp = finesse.Model()
fp.parse("""
variable f1 9099471
variable f2 45497355
variable nsilica 1.45
variable Mloss 30u
variable Larm 3994
laser L0 P=125
mod mod1 f=&f1 midx=0.18 order=1 mod_type=pm
mod mod2 f=&f2 midx=0.18 order=1 mod_type=pm
link(L0, mod1, mod2, ITMXAR)
m ITMXAR R=0 L=20u xbeta=&ITMX.xbeta ybeta=&ITMX.ybeta phi=&ITMX.phi
s ITMXsub ITMXAR.p2 ITMX.p1 L=0.2 nr=&nsilica
m ITMX T=0.014 L=&Mloss Rc=-1934
s LX ITMX.p2 ETMX.p1 L=&Larm
m ETMX T=5u L=&Mloss Rc=2245 phi=0
s ETMXsub ETMX.p2 ETMXAR.p1 L=0.2 nr=&nsilica
m ETMXAR 0 500u xbeta=&ETMX.xbeta ybeta=&ETMX.ybeta phi=&ETMX.phi
dof CARM ITMX.dofs.z +1 ETMX.dofs.z +1
dof DARM ITMX.dofs.z +1 ETMX.dofs.z -1
pd1 REFL9_I ITMXAR.p1.o f=&f1 phase=33
lock DARM_lock REFL9. DARM.DC -0.0055 1e-5
xaxis(L0.f, lin, 10, 40k, 20)
readout_rf REFL9 ITMXAR.p1.o f=&f1 phase=33 output=[I, Q]
""")
```
Gives
```
ModelAttributeError: (use finesse.tb() to see the full traceback)
model has no element or space with path 'I'
```
This is from the kwarg `output=[I, Q]`, which isn't defined by the readout element yet. But I guess it should point to that being the issue in the file?```
fp = finesse.Model()
fp.parse("""
variable f1 9099471
variable f2 45497355
variable nsilica 1.45
variable Mloss 30u
variable Larm 3994
laser L0 P=125
mod mod1 f=&f1 midx=0.18 order=1 mod_type=pm
mod mod2 f=&f2 midx=0.18 order=1 mod_type=pm
link(L0, mod1, mod2, ITMXAR)
m ITMXAR R=0 L=20u xbeta=&ITMX.xbeta ybeta=&ITMX.ybeta phi=&ITMX.phi
s ITMXsub ITMXAR.p2 ITMX.p1 L=0.2 nr=&nsilica
m ITMX T=0.014 L=&Mloss Rc=-1934
s LX ITMX.p2 ETMX.p1 L=&Larm
m ETMX T=5u L=&Mloss Rc=2245 phi=0
s ETMXsub ETMX.p2 ETMXAR.p1 L=0.2 nr=&nsilica
m ETMXAR 0 500u xbeta=&ETMX.xbeta ybeta=&ETMX.ybeta phi=&ETMX.phi
dof CARM ITMX.dofs.z +1 ETMX.dofs.z +1
dof DARM ITMX.dofs.z +1 ETMX.dofs.z -1
pd1 REFL9_I ITMXAR.p1.o f=&f1 phase=33
lock DARM_lock REFL9. DARM.DC -0.0055 1e-5
xaxis(L0.f, lin, 10, 40k, 20)
readout_rf REFL9 ITMXAR.p1.o f=&f1 phase=33 output=[I, Q]
""")
```
Gives
```
ModelAttributeError: (use finesse.tb() to see the full traceback)
model has no element or space with path 'I'
```
This is from the kwarg `output=[I, Q]`, which isn't defined by the readout element yet. But I guess it should point to that being the issue in the file?Alpha 1Sean LeaveySean Leaveyhttps://git.ligo.org/finesse/finesse3/-/issues/265Unclear parser error2021-03-05T16:37:33ZDaniel BrownUnclear parser errorasterix throwing problems in xaxis line
```
fp = finesse.Model()
fp.parse("""
laser L0 P=125
xaxis(L0.f, lin, 10*, 40k, 20)
""")
```
Gives:
```
KatParsingError: (use finesse.tb() to see the full traceback)
syntax error
```asterix throwing problems in xaxis line
```
fp = finesse.Model()
fp.parse("""
laser L0 P=125
xaxis(L0.f, lin, 10*, 40k, 20)
""")
```
Gives:
```
KatParsingError: (use finesse.tb() to see the full traceback)
syntax error
```Alpha 1Sean LeaveySean Leaveyhttps://git.ligo.org/finesse/finesse3/-/issues/264Better error message for functions written as if they are elements2021-03-05T08:40:19ZSean LeaveyBetter error message for functions written as if they are elements```
KatScriptError: (use finesse.tb() to see the full traceback)
line 8: missing element name
7:
-->8: modes maxtem=0
^
```
This should match that ``modes`` is a function and tell the user they forgot parentheses.```
KatScriptError: (use finesse.tb() to see the full traceback)
line 8: missing element name
7:
-->8: modes maxtem=0
^
```
This should match that ``modes`` is a function and tell the user they forgot parentheses.Alpha 1Sean LeaveySean Leaveyhttps://git.ligo.org/finesse/finesse3/-/issues/263Automatically support new keywords for bp, cp detectors2021-03-05T08:03:51ZSamuel RowlinsonAutomatically support new keywords for bp, cp detectorsThis is related to the comment I made in !57 yesterday. I was adding a round-trip ABCD matrix property to `CavityPropertyDetector` recently, but to have support for this new `"abcd"` target on `cp` detector one would
have to manually add it to the `_SUPPORTED_KEYWORDS` set in `spec.py`.
My suggestion is to do this instead of the current hard-coding of these property names:
```python
_SUPPORTED_KEYWORDS = {
# Previous stuff...
# Beam properties (see :class:`finesse.detectors.compute.gaussian.BeamProperty`).
*detectors.BP_KEYWORDS.keys(),
# Cavity properties (see :class:`finesse.detectors.compute.gaussian.CavityProperty`).
*detectors.CP_KEYWORDS.keys(),
}
```
that way, when a new keyword corresponding to a `BeamProperty` or `CavityProperty` in the `BP_KEYWORDS` and `CP_KEYWORDS` dicts, respectively, gets added then it would be supported for use in the parser immediately.
Perhaps there's a reason this is not done currently though, so I won't go ahead and make this change now just in case.This is related to the comment I made in !57 yesterday. I was adding a round-trip ABCD matrix property to `CavityPropertyDetector` recently, but to have support for this new `"abcd"` target on `cp` detector one would
have to manually add it to the `_SUPPORTED_KEYWORDS` set in `spec.py`.
My suggestion is to do this instead of the current hard-coding of these property names:
```python
_SUPPORTED_KEYWORDS = {
# Previous stuff...
# Beam properties (see :class:`finesse.detectors.compute.gaussian.BeamProperty`).
*detectors.BP_KEYWORDS.keys(),
# Cavity properties (see :class:`finesse.detectors.compute.gaussian.CavityProperty`).
*detectors.CP_KEYWORDS.keys(),
}
```
that way, when a new keyword corresponding to a `BeamProperty` or `CavityProperty` in the `BP_KEYWORDS` and `CP_KEYWORDS` dicts, respectively, gets added then it would be supported for use in the parser immediately.
Perhaps there's a reason this is not done currently though, so I won't go ahead and make this change now just in case.Sean LeaveySean Leaveyhttps://git.ligo.org/finesse/finesse3/-/issues/262Check Cavity Axis Tilts & Shifts2021-03-04T09:24:09ZAaron JonesCheck Cavity Axis Tilts & Shifts[DCC T1900708](https://dcc.ligo.org/DocDB/0163/T1900708/002/cavity_dynamics_texnote.pdf) compares the geometrical tilt and shift equations presented in Siegman's lasers with the results in the Finesse2 modal model. Repeat this for Finessd3 and put the results in the [logbook](https://logbooks.ifosim.org/finesse/) also add some validation tests.[DCC T1900708](https://dcc.ligo.org/DocDB/0163/T1900708/002/cavity_dynamics_texnote.pdf) compares the geometrical tilt and shift equations presented in Siegman's lasers with the results in the Finesse2 modal model. Repeat this for Finessd3 and put the results in the [logbook](https://logbooks.ifosim.org/finesse/) also add some validation tests.2021-03-18Aaron JonesAaron Joneshttps://git.ligo.org/finesse/finesse3/-/issues/261Fix Issues with New Parser and Doc2021-03-04T13:24:56ZAaron JonesFix Issues with New Parser and DocSee [Mattermost discusssion](https://chat.ligo.org/ligo/pl/dgtj7mzj6pfodg8yonhw4gayhe)See [Mattermost discusssion](https://chat.ligo.org/ligo/pl/dgtj7mzj6pfodg8yonhw4gayhe)2021-03-11Aaron JonesAaron Jones