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:
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.
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.
After following through:
Things look pretty good, however,
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: