Reports until 17:58, Thursday 12 December 2019
H1 CAL
vladimir.bossilkov@LIGO.ORG - posted 17:58, Thursday 12 December 2019 - last comment - 13:49, Tuesday 17 December 2019(53870)
UIM Dynamics propagated through tagged models and to python friendly filter files available to pyDARM

Following up from the last alog.

With the UIM dyanamics filter ready I propagated it through a set of new tagged sus models. I made a set of three to help make an informed decision on how to treat the new UIM dynamics - the complication being that there appears to be dynamics around the violin modes. I have split off a second tagsusdynamicalmodel.m so I don't interfere with livingston using the file.

I have created the following files using /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/tagsusdynamicalmodel_h1.m

/ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/
quadmodelproduction-rev9944_ssmake4pv2eMB5f_fiber-rev8442_h1etmx-rev10093_h1etmx_options-rev10093_released-2019-12-12.mat
quadmodelproduction-rev9944_ssmake4pv2eMB5f_fiber-rev8442_h1etmx-rev10090_h1etmx_options-rev10090_released-2019-12-12_noUIMdyn.mat
quadmodelproduction-rev9944_ssmake4pv2eMB5f_fiber-rev8442_h1etmx-rev10093_h1etmx_options-rev10093_released-2019-12-12_noviolins.mat

And from these I have generated the following files using /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/matlab_scripts/export_AAAI_SUS.m:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/matlab_scripts/

H1susdata_O3_new.mat
H1susdata_O3_new_noUIMdyn.mat
H1susdata_O3_new_noviolins.mat

Using these I can compare before are afters, namely:

compare_with_no_violin.png
compare_with_violin.png

In the case when I plotted against no violins, the MATLAB removes the highest most zero in the UIM dynamics, making the TF look like its going down more than it should be (an effective extra 1/f term). This is a problem in the current workflow that takes the tagged model and splits it up into low frequency terms and the violin terms, where I'd need to add a separate operation that takes the tagged model that has no violin modes to split off these dynamics. Looks like I will have to rethink.

Also the low frequency features are being changed by a bit - seems even matlab has its limits of tolerance when it comes to how many poles and zeros it can play with at a time.

I think a better approach is to have the dynamics added into the "H1susdata_O3" matrix directly by export_AAAI_SUS.m, and make no changes to the tagged susmodels as they stand. At the end of the day I am always drawing from the same file into which I have saved my dynamics... I can just do that later down the line even for the foton file.

Images attached to this report
Comments related to this report
vladimir.bossilkov@LIGO.ORG - 12:08, Friday 13 December 2019 (53884)
Link

Looks like how I've treated my raw data for the higher frequencies (near the violin modes) is incorrect. It seems the violin mode part of the TF is conflating with my data in part of the processing.

When I was doing fitting, I was dividing out a TF that had no violin modes (as was my intention), but "umodelUIM_afterLock_freqresp" was being divided out instead in a pyDARM function

I'll be dividing out more correctly, removing any data >200 Hz and refitting now.

Images attached to this comment
vladimir.bossilkov@LIGO.ORG - 10:41, Monday 16 December 2019 (53921)
Link

After following through:

Things look pretty good, however,

  • Matlab seems to skip a zero pole pair at low frequency
    • For the foton filters, this is irrelevant as the minreal function cuts that out anyway
    • Somewhat important for the pyDARM models, and they would be relying on this model.
  • there is a little dip in magnitude after the 150 Hz feature (visible in both attachments), that restores  restores after about 1kHz. (This is an artifact of fitting)
  • Phase is flipped 180 degrees after the 150 Hz feature
  • There is something at 300 Hz, which may be the first harmonic of the 150 Hz feature.
    • It is hard to tell its significance without careful measurement with fine scale sweep sine measurements in the future.
  • There is a small misfit the the magnitude gain visible in the pdf.
    • The fit gets the mganitude correct at the 150Hz feature
    • Any added poles and zeroes are <410 Hz such that the TF can be broken up into 3 constituent pieces:
      • Low frequency part <45 Hz
      • UIM dynamics: 45-410 Hz
      • Violins: >410 Hz
    • better fits would push poles into the region of violin modes
Images attached to this comment
Non-image files attached to this comment
vladimir.bossilkov@LIGO.ORG - 13:49, Tuesday 17 December 2019 (53945)
Link

Vlad, Jeff

We investigated the source of this apparent blip at around 0.5Hz, and traced it down to Matlab doing funny things when converting from SS to ZPK model. In fact, we got different results for every input for each of the latest 4 Matlab versions we have available (actually 2016b and 2017b gave identically bad results).

I have made a number of plots which I hope will convince people that we should, and importantly *can*, migrate this step to python.

I have put up a whole lot of plots which have one consistent aspect: the SS model response never changes.  The most plots worth highlighting are  are:

Old_Model_2015b.png and New_Model_2015b.png: Here you can see that my addition of the UIM dynamics (which has no features at <45 Hz)
Old_Model_Python.png and New_Model_Python.png: Here you can see that when I evaluate the SS->ZPK transition in Python, I get consistent results, which are far closer to the SS model. [Blue and Red lines just about perfectly overlap]
Old_Model_Python_Full.png and New_Model_Python_Full.png: Here you can see results are consistent up to higher frequencies. The Matlab's frequency response is degrading at some step: either at the output of Matlab, or at the import of Python.
 
I recommend that SS models are extracted from Matlab and that further conversion to ZPK is done within Python for the future. Vlad is overseeing improvements to the flow of this data through to pyDARM and foton, and can implement this.
Images attached to this comment