Displaying report 1-1 of 1.
Reports until 14:45, Monday 31 October 2022
H1 CAL (CAL)
vladimir.bossilkov@LIGO.ORG - posted 14:45, Monday 31 October 2022 (65537)
Feasibility of driving all-the-lines-at-once for IFO Calibration

Motivational summary:

During a run, during every weekly planned engineering, the IFO is calibrated by running swept since to measure transfer functions of DARM, PCal-to-DARM, UIM-to-DARM, PUM-to-DARM and TST-to-DARM. Presently the procedure is as follows:

Simultaneous swept sine feasibilty was done similarly at LLO with basically the same results. this aLog just echo's information pertinent to LHO.

That is a lot. Such 'a lot' that it the last measurement on 2022-08-03 took a meager 1 hour 25 minutes (meager relative to LLO's 1 hour 45 minutes). Imagine committing that time for each Planned Engineering break! You can get a bonus 1 hour of detector uptime or time for hands-on engineering every week if this can be reduced. Exclamation marks above are for measuring the same thing again and again, because what you really want is to measure that at the same time as your actuation drivers. But what if you can? And moreover, what if you did the whole lot at once?

What stops you from driving each of the above swept sine measurements at the same time?

DAC limits. Some of these actuators, at certain frequencies (like UIM at 5-15 Hz) need to be driven with about half the total DAC range (so 2^18 out of 2^19). When any one actuator is being driven in arm longitudinal motion, the DARM loop will seek to keep the total arms difference to zero; therefore you will actually be forcing all of the other actuators to react you your drive, on top of the drive you are injecting. The scary question is: if you just drive everything, will you saturate your DACs, lose lock and waste time locking it IFO again?

And hence: proving the feasibility of this.

Feasible?

I noted the times when Jeff K. ran the last lot of calibration sweeps in August (time_list file attached below). I wrote a python script (attached below) to fetch the 16Hz data from Caltech, I then did some simple checks to see if the DACs would be saturated if all of these lines were being injected at once (at cleverly distributed spacing away from each other of course). The python script is commented with results, so you don't actually HAVE to run it; but you have everything you need to run it if you want (given the time intervals in time_list). For completeness I've also included the little script I used later to get my post-sweeps time series data that I use for a reference discussed at the end of this section.

I seek the times when a stage is being actively actuated, and I take the maximum DAC count (worst case quadrant) for that period (call this MAX). I then also seek the maximum DAC count for that stage (worst case quadrant) for all the times the stage is not actively being driven (call this WORST_FOREIGN_MAX). I then assume that we are driving a total of 5 lines: 3 for each ETM actuator + PCal_Y + Darm_OLG measurement. So the simple check is: is MAX + 4*WORST_FOREIGN_MAX < 2**19 ? (2**17 for the UIM as it did not have 20-bit DAC yet at the time.)

The outcome of this worse case scenario maths: is that there will be no issue for the TST stage, the PUM stage would saturate by a factor of 2, and the UIM stage would saturate by a factor of 1.3. So naively no, not feasible because PUM is such a huge issue.

Looking closer, the DAC counts for the PUM stage seem to be basically constant all-the-time. I looked closer, I compared DAC counts to a reference time 30 minutes after the Calibration sweeps occurred at all, and the PUM stage had higher 'ambient' DAC counts before the sweeps were occurring, than the counts that we see when the stage was actively being driven! I have attached a quick picture of the typical PUM actuation sweep. You can only just barely see the actuation injection in the first 60 seconds of the plot, leading me to conclude that the PUM stage is being driven strongly the whole time - by some other control loops, and that the actuation injections are relatively small.

Given this, I look at the UIM in the same way. It is very much clear that the injection is quite strong with counts at 80k out of a max of 130k (recall it was an 18bit at this date). By my worst case imaginable estimates it would be wise to tone the injection amplitudes down by 20-30% for the frequencies below 15 Hz, which correspond to the very strong injection amplitudes, and drive that stage for a longer period of time instead.

Conclusion - Yes, with adjustments.

TODO: I have a list of Jeffs injection frequencies and amplitudes, which I need to massage into something LHO can use. In one of my recent aLogs at LLO, I cover where the relevant files will live ('svn up' should refresh the relevant directory), and what I do with them. I'll aim to keep the sweep <30 minutes given the considerations above.

Images attached to this report
Displaying report 1-1 of 1.