Summary: We will need one of: move FC1 back to nominal, move ZM3 8mm to shorten FC1-ZM2 path by the 16mm, increase preload on the ZM2 PSAMs by ~30mD. Since ZM2 is so sensitive and needs little dynamic range, we might be able to leave it as is, but we will have to operate it >~ 150V in-air to get data that we consider sufficient. Otherwise, the newest data shows agreement with the model that we have something to converge on.
Once we can tune the system up a bit to get ~95% matching at nominal 100V ZM2, ZM4, ZM5 PSAMS settings, then it then is worth scanning ZM4 and ZM5 to fully explore the space.
Relevant alogs:
- LHO61060 first post reporting FC1 retro with profiles. I haven't used this one since the data was after ZM5 and has a lot of PSAMS variations that are difficult to plot
- LHO61080 data to check beam profile from ZM1->ZM2 in with ZM2-referred distances. In principle great data to have, but looks inconsistent with expectations and later data. Also has some ZM2 PSAMS scans that I haven't added in since later measurements supercede.
- LHO61300 Post-ZM5 data that I plotted with "nominal" psams.
- LHO61604 newest data with post ZM2 measurements, pre ZM4 and longer baseline of post ZM5. Good stuff.
- LHO61485 - Jason's log on the 16mm +Y shift of the FC that changes the path length from nominal. All the past logs have this shift in them, but maybe didn't know until 61604. That's why "nominal" 100V ZM2 is off.
- LHO60411 - my last look at mode matching around ZM4/ZM5 before the ZM1-3 path was installed. It has good "nominal" references for with the FC1 retro can aim for.
My approach to use all of this profiling data is to use the data where ZM2,ZM4 and ZM5 are at their nominal 100V operating point. That data is plotted as scatter points in the following profile plots. The OPO mode and past measurements of the post A:L2 beam are then plotted in the nominal configuration. Additionaly, I show the as-built LHO FC1 path length with ZM2 at 0mD (nominal 100V), -50mD and +50mD. Note, my mD are relative to the nominal curvature, not the PSAMS-PZT-0V curvature. This way we can best compare the data points to hypothetical as-built beam propagation profiles. It is more difficult to interpret plots with multiple beam projections as the ZM2 PSAMS moves and more data points are taken. Some data like that exists, but I have omitted it to not make too many plot variations.
ZM12.pdf - this is the view of the beam leaving the OPOS. The ZM2 is at the nominal curvature in the projections. The two magenta points suggest that as-build it is showing close to that nominal curvature. The OPO/cav beam is the nominal mode of the OPO. The MM_L1L2 is from an optics lab profile measurement (I forgot to comment it in the code and haven't dug back for the alog ref). Those two are >98% matched. The ZM2_61080 is from that log post along with its scatter points as + and x. It is inconsistent with the previous two modes I mentioned and the magenta data from 61604, so I'm not reading into it. If either ZM2 were 4" closer to ZM1 or the data locations were 4" closer to ZM4 than indicated (missing pickoff distance?), then these data would be pretty consistent with the others. FC/cav is the mode of the nominal FC back-propagated to show its overlap with the nominal OPO profile. FC/cav@LHO includes the 16mm path length increase.
ZM21retro.pdf this shows the model beams from the previous plot after having reflected from the FC1. The blue is the nominal. The others include the 16mm FC shift, as well has modelled changes to the ZM2 PSAMS curvature. They show that nominally we need 50mD to make up the 16mm. Later data suggest we need a little less than that.
ZM123.pdf - this only makes the point that I can model whatever I want. Here is the full foward and retro reflection through the system. The dynamic range of the scale is too much to be very useful. Look at the way I set up the waypoints for this in the code.
ZM14.pdf - this shows the modelled curves of ZM21retro but zoomed for the OPOS A: and B: paths. This shows how clipping can occur.
ZM456retro.pdf - this one has new and old data. The model curves at the sames as ZM21retro/ZM14 with the addtion of the IFO mode from T1200410 back-propagated. Additionally, the measurement from 60411 is included as MM_ZM4. The early data from 61300 are the magenta. They were taken at an unfortunate spot where it is difficult to resolve between the models, prompting the newer data of 61604. The 61300 data do suggest the beam astigmatism is as expected and that the ZM2 needs more mD than it can get. The next points is the cluster near ZM4, which indicate that the nominal ZM2 isn't the red, but something with effectively a few more mD. This is as likely from the path being only ~10mm too long rather than 16mm as ZM2 not having its expected nominal curvature. In any case, ZM2 needs more mD to drop the beam size down at ZM4. The pink data are the long-baseline post-ZM5 data, which confirm that things aren't quite as bad as the magenta 61300 data suggest. They also indicate we can make very good measurements to confirm everything once we get the beam more in the ballpark using ZM4 measurements.
Running the code,
So, in the spirit of the "teaching a person to fish parable" and Jeff's request of LHO60411. Here is the code for that and this alog. This alog, LLO's alog models, and all of the models in the optical layout T1900649 are in the code shared here. Since it is yet more,new complex code for mode-matching, this may be more like the "make a man a fire" joke than the parable.
The code is up at https://git.ligo.org/wavestate/wavestate-LIGO-IFO and its dependencies are now up on PyPI (and github, if you search for mccullerlp). There is some infrastructure for documentation, but it is not mature enough to link it now. The examples of this log show a lot of cookbook ways of using it though. The modeling code used currently is a just the lurid combitation of bookkeeping services and graph algorithms needed to simulate beam propagation with astigmatism and a lot of annotations.
A) if using conda: optionally create a new conda env either from scratch or by copying your existing one. This is optional but prevents the following from modifying your existing environment
A2) conda install pip numpy scipy matplotlib PyYAML tabulate pytest pytest-watch
B) if not using conda, that's fine, it should install into your linux/homebrew/... python environment like other development packages.
Get your copy at
git clone git@git.ligo.org:wavestate/wavestate-LIGO-IFO.git (or download/unzip a tar from the site)
then enter the folder 'cd wavestate-LIGO-IFO'
and you'll "install" it in develop mode. This puts it into your environment's paths and also installs several dependencies that are on PyPI but not on conda. If you just use the 'python setup.py develop' it will install everything but the dependencies. Instead, use pip
'pip install -e .' (or 'pip install --user -e .' if not using conda and not installing as root)
then if it looks like it was successful, you can run
'pytest' and it will run all the past logs and the models from the optical design doc. If they pass you know it is working. There will then be a "test_results" folder keeping the plots and logs.
'pytest -s' shows you the console output live to watch its progress. If you want just the models from this post, you can do
'pytest src/wavestate/LIGO/IFO/as_built/FC_LHO/post_ZM123/T_LHO_MM_SQZ_ZM123.py -s' or
'pytest src/wavestate/LIGO/IFO/as_built/FC_LHO/post_ZM123/T_LHO_MM_SQZ_ZM123.py -s -k ZM2_check'
and all of the design models you can look at in the folder 'src/wavestate/LIGO/IFO/Apl/design/telescopes'
if you install the pytest-watch package you can change all of the instances of the 'pytest' command to 'ptw --' and then the tests/plots will run and update as you edit and save the model code. It's a whole system I have. I hope it is a system that can keep other large repositories in more 'alive' state to ease mainainance. I favor using these "code units" with a test discover system greatly over using notebooks, which are hard to share and store in repositories. I'll comment or edit in more details to add a bit more documentation. All the code needs more comments, I know.
