There's a huge spike in seismic activity. No earthquake report from Terramon. Not sure what caused the lockloss.

The BNS range has been dropping slowly for the past three hours as the seismic noise goes up -- probably due to increasing wind speed (slightly above 20 mph at the moment). Saturation alarm complains very little. Hardly any glitches on DMT Omega. Nobody else on site. Quiet shift so far.

Stefan, Evan

We spent some time today trying to estimate the amount of carrier power (00 or otherwise) in HAM6 in full lock. Stefan had previously estimated about 270 mW of non-45-MHz light entering HAM6, based on AS_C calibration. This seemed high to us, since we should expect < 150 mW of carrier: 25 mW or so of 00 carrier (based on the DCPD sum), and 110 mW or so of other carrier (23 W input power × 0.88 input chain throughput × 37 W/W recycling gain × 150 ppm contrast defect, taken at low power).

[Does Dan have updated numbers for the contrast defect (and the 9 MHz AS port content) based on new 23 W modescans???]

According to Dan, there is a factor-of-two error in Stefan's AS_C calibration, which would bring the estimated carrier power down to 135 mW [but this is problematic; see below]. Since one can never have too many calibrations of the same diode, I'm going to use 60×10³ ct/W for the calibration [referred to watts of power entering HAM6], based on 1638.4 ct/V (ADC) × 0.78 A/W (responsivity) × 2 V/V (single/differential conversion) × 10^36/20 V/V (whitening) × 370 ppm (optical throughput to AS_C).

We did a few different measurements.

DARM offset sweep

We locked the IFO on RF at 23 W, locked the OMC (with dither on), and swept the DARM offset by a few tens of picometers (positive and negative). From these data it should be possible to compute a calibrated curve of current versus DARM offset, as Dan has done previously at lower power. But even without that, we can already infer 2700(640)×10³ ct on AS_C for 39.5(6) mA on the DCPD sum [= 68(16) ct/mA]. Assuming an AS_C calibration of 60×10³ ct/W, and noting that the amount of photocurrent at zero DARM offset is small (< 1 mA), this suggests that for 20 mA of DCPD sum we have 23 mW of carrier from the arms entering HAM6. This seems unphysically low, since we already expect 26 mW of carrier based on a DCPD responsivity of 0.75 A/W. Either way, something about the numbers in HAM6 doesn't hang together, which is a conclusion that Koji and Dan already came to based on single-bounce power budgeting.

I believe we expect at least 30 mW coming into HAM6 under normal operation, since we expect at least 14 % readout losses, not including the quantum efficiencies of the photodiodes or anything upstream of the OFI. [31 mW × (1 − 0.14) × 0.75 A/W = 20 mA.]

[For this measurement, we notched out the 332 Hz pcal line in the EX drive, so it is visible in the DCPDs. So this can be used to estimate the optical gain at each DARM offset.]

DCPDs vs AS_C vs OMC REFL

As a second test, we modulated DCPD sum at 8 Hz by driving OMC-READOUT_X0 while watching AS_C and OMC_REFL (we again opened the beam diverter for this). First, from the quiescent spectra alone we could already calibrate the PDs against each other; the calibrations are roughly 70 ct/mA for AS_C sum / DCPD sum and 2 ct/ct for AS_C sum / OMC REFL A sum. With AS_C and OMC REFL A calibrated (attachment), the strength of the line in OMC REFL A appears with a factor of 0.012 relative to the line in AS_C, suggesting that >98% of the modulated DARM light is coupled into the OMC.

J. Kissel, M. Evans

After downloading the work that Matt has done (LHO aLOG 21424)carefully fitting the nasty actuation function we'd discovered (LHO aLOG 21419), 
1) I've plotted it myself, to make sure I understand what Matt has given me
2) Inverted it, made sure I got the same residuals he did
3) Discovered the fit contained a pole at 15 [kHz], played around with the implications of moving the pole to the highest frequency foton accepts (8190 [Hz])
4) Painstakingly copied over to foton, because the fit poles and zeros did not all fit into one filter bank, and *I* wanted to control how they were divided between banks
5) Exported the foton filter, loaded it back into matlab, and fine tuned the necessary advance.

T'was a lot of work, but we have something installed and running. Now we beat the heck out of it to find the bugs, while we (in parallel) push injection through the photon calibrator forward.

In addition to this pain-in-the-tuckus inversion process, Joe Betz -- on the phone for other reasons -- brought up another excellent point: LHO does NOT use linearization on the H1SUSETMY electrostatic drive. While we get away with doing so during a quiescent lock, any loud control signal will expose the non-linearity (quadratic) nature of the ESD. We think we've already seen some evidence of this while measuring DARM open loop gain transfer functions. Yuck. PCAL has no such problems (in fact, though it uses an inherently quadratic AOM, it has analog electronics to ensure its linearity).

Note: Contrary to all of my suggestions, Matt *has* included and fit inverses to the notches in the actuation function. This means, while we will likely have the same amplification problems around the notch frequencies (see, e.g. LHO aLOG 20904), the phase reconstruction of all regions except this frequency is within 5 [deg]. Since there seemed to be competing interests in the CBC group on whether or not to include the inverse of the notches, I've left them in. If we need to remove them, and somehow retain the phase reconstruction in the surrounding frequency regain, then it'll be another day's worth of work between Matt and I. But honestly, if it comes to that, we're switching to PCAL.

%%
Details
%%
--------
Not much to say on the design here -- Matt did almost all of the work. The only two gotchas were as mentioned above: I had to move the highest fitted pole down and I must split the filter in to two parts. For the splitting, I chose to put everything from the (inverse) beam-splitter violin mode notch at ~300 [Hz] into the first module ("O1.A" in FM3), leaving the (inverse) QUAD violin notches and 950 [Hz] elliptic low-pass for the next ("O1.B" in FM4).

After exporting the product back into matlab, I tuned the timing advance to account for the pole that I'd moved down from the "ideal" fit. 
Thus, all analysis should assume the waveforms need a timing advance of 255 [us]. 
Also, of course exactly surrounding the frequencies of the notches at ~300, 500, 1000, and 1500 [Hz] there is greater than 50% mismatch between the real SUS and the inverse actuation filter. 

The first .pdf attachment shows 
(pg 1) my reproduction of Matt's filter comparsion (over a little bit wider a frequency band), 
(pg 2) the inverse function, both of Matt's ideal fit, and of the reconstruction from foton, and 
(pg 3) a zoom in on the interesting region between 100 [Hz] and 2000 [Hz].

The second .pdf attachement shows a bode plot showing the breakdown of the filter between FM3 and FM4, and compares the filter against the ER7 filter. 

Noteably, there is *not* a sign difference between the new filter and ER7 or the H1 Mini-run filter, but the phase has rotated once around the unit circle.  For a clear demonstration of this, see the third .pdf attachment. Recall, folks have been worried about the hardware injection filter since ER7 (see LHO aLOG 19948 for complete summary). I'm not sure how this ~360 [deg] rotation could be mistaken for a sign flip -- but maybe I'm just carrying around the term that was used during the initial guess of what the problem was, even though the real problem was more subtle. I've confirmed that neither the design string nor the "alternate" (i.e. as what foton interprets your design) show a minus sign in the gain.

--------
Configuration control:
(1) Stefan and I updated the ODC state vector for the hardware injections, since flipping the FMs from 2 to 3&4 make the "HARDWARE filter stated OK" light go red. To make green, we changed the recently modified bit status check from 0x1602 to 0x160c. 
(2) I accepted the new filter bank state (and ODC bit word) into both the OBSERVE.snap and into the SAFE.snap for the CAL-CS front-end model.
I attach ascreenshot of the filter bank as I've left it.

• 9/13 @ 7:53utc Verbal_Log died on video5 (restarted on 9/14 @4:21) 
• 23:24:  NOMINAL_LOW_NOISE (first time post-big-quake)
• 1:25 LOCKLOSS
  • Restored SR3 Pitch value
  • Had issues Finding IR a few times tonight
  • During DRMI acquisition alignment/flashing looked bad
  • Locked PRMI & tweaked BS & PRM (did not do PR2)
    • When realigning SRM it tripped its Software Watchdog (Jim also mentioned having SRM saturations.  This is a new feature.)
    • Will try PRMI again, and this time try PR2 (& maybe PRE3?)
• Evan discovered high frequency noise for SRM
• 2:30  Went CER to power cycle (white button on back) of SRM Driver box (still high freq noise after power cycle)
• 5:28 NOMINAL_LOW_NOISE
• 5:36  Loading coefficients for hardware injection filter (jeff)
• 6:02  Lockloss
  • Had to help FIND_IR for ALS_DIFF
• 6:36  NOMINAL_LOW_NOISE & Evan/Stefan starting OMC measurements
  • Remember to Close OMC REFL Beam Diverter before going to OBSERVATION!!!

Addendum Notes

Bubba will address Chiller Yard alarm noted Sat night when he's in on Monday (change alarm setting?)

H1 Problems of the day:

• These are items Jim mentioned to me:
  • HAM5 ISI Watchdog rogue excitation watchdog was not trivial to reset
  • SRM saturating and tripping HAM5ISI:  This is a new feature
  • ALSy problems which were remedied by PR2 tweaks

SDF Diffs

• optical align offsets changed to not monitored for:  etmx, itmx
• PR3 was clicked to NOt Monitored, but sheila and I decided we should keep monitoring this channel
  • Idea is to Monitor SUS biases for optics we rarely touch (so that if they are touch, we get an SDF notification)
• SUSIM:  Cheryl changed alignment and then Jim changed back.  So I will go back to ACCEPTING their alignment in SDF(since these aren't changed much and we can monitor when they are changed)

SR3 Cage Servo

Locked H1 without this servo engaged (SR3 was saturating).  Sheila was able to slowly engage this while in lock.  The H1:SUS-SR3_M1_OPTICALALIGN_P_OFFSET SDF setpointpoint is 563.7, but to get this servo to go, it was moved to 562.2 (Sheila called this a "hot" state for SR3).  For future locks we want to go back to the "cold" value of 56.7.  This was done after the 1:27 Lockloss.  

I've made the GDS correction filters for the remaining of ER8 and O1.  These filters include only the corrections discussed in alog #21386 with the addition of the inverse DAQ downsampling filter which must be applied to the actuation chain (downsampled from 16kHz to 4kHz when written to frames).  They are meant to be applied as corrections to the output of the front-end CALCS channels {IFO}:DELTAL_CTRL_DQ (or {IFO}:DELTAL_CTRL_TST_DQ+{IFO}:DELTAL_CTRL_PUM_DQ+{IFO}:DELTAL_CTRL_UIM_DQ) and {IFO}:DELTAL_RESIDUAL_DQ.  In addition to the correction filters, the CALCS channels must also be dewhitened with dewhitening filters.  Plots comparing the frequency response of the FIR correction and dewhitening filters to the freuqency models they are based on are attached.  These filters are made using the following code checked into the calibraiton SVN:

aligocalibration/trunk/Runs/ER8/Common/MatlabTools/create_partial_td_filters_ER8.m

I've done a comparison of the spectrum of calibrated h(t) data from GPS times 1126003500-1126003700 from both the GDS pipeline and CALCS front-end calibration. Plots of the two spectra on top of each other and of the relative difference between the spectra are attached.  The differences between the spectra are consistent with the addition of the high-frequency corrections and accurate time delays in the GDS pipeline.  Note: For this comparision, the calibration factors have not been applied to h(t).

Evan, Jeff, Stefan

Attached is a plot of H1:OMC-READOUT_PREF_OFFSET, H1:OMC-READOUT_ERR_GAIN and H1:OMC-READOUT_X0_OFFSET over the last 10 days.
Notice the significant lock-to-lock fluctuations - they were recalculated every time the interferometer locks.

To avoid having these fake 'optical gain' changes we decided to hard-code
 H1:OMC-READOUT_PREF_OFFSET = 1.3689
 H1:OMC-READOUT_ERR_GAIN    = -8.7614e-7
which are their values during the calibration DARM UGF measurement on 2015/08/30 12:08:43 UTC (GPS 1124971740).
The values are now set in DC_READOUT in the ISC_LOCK guardian. The actual values are in the lscparams file: lscparams.omc_readout_pref and lscparams.omc_readout_err_gain.


Just before NOMINAL_LOW_NOISE we added a new state with code to average the IMC input power for 5 sec and the set
 H1:PSL-POWER_SCALE_OFFSET to the measured power, and 
 H1:OMC-READOUT_X0_OFFSET such that the DCPD values are servoed to lscparams.omc_dcpd_sum_target which currently is 20mA.
(This had been done before, but just based on one ezca read of the IMC input power.)

To avoid being affected by the DC coupled ISS 2nd loop engagement, we moved the ENGAGE_ISS_2nd_LOOP slightly earlier, between COIL_DRIVER and LOWNOISE_ESD_ETMY.

Cregg Yancey ran the hardware injection cross-checking code he has been developing, and noticed a curious discrepancy in the periods marked by the burst injection ODC bits at H1 versus L1 for the hardware injection at GPS 1125390500.  I investigated more closely, reading ODC bitmask time series from the recorded raw frame file along with the hardware injection excitation record, H1:CAL-INJ_HARDWARE_OUT_DQ.  I focused in on the bits which indicate burst hardware injections: bit 25 of H1:ODC-MASTER_CHANNEL_OUT_DQ (sampled at 16384 Hz) and bit 11 of H1:CAL-INJ_ODC_CHANNEL_OUT (sampled at 256 Hz).  What I found is rather startling: these ODC bits "flicker" between 0 and 1 around the time of the injection in a way that they definitely should not.  Each bit is supposed to equal 1 when there is no injection (meaning two or more consecutive samples with excitation amplitude less than 10^-200, according to LLO alog 18913) and 0 when there IS an injection.  The bit flickering pattern shows no obvious connection with the excitation time series.

The first three attached plots show what I found for the injection around GPS 1125390500, at three different time scales.  This is the "too-loud burst" injection which has been studied (see https://wiki.ligo.org/LSC/JRPComm/G181472) and seems to have been anomalous due to saturating the actuation chain.  However, the ODC bit setting should only be based on H1:CAL-INJ_HARDWARE_OUT_DQ, unrelated to saturation occurring anywhere later in the chain, so I believe this is a different problem.  Also, another injection at GPS 1125400500 seemed fine as an injected burst (it was a 69 Hz sine-gaussian) but still has the crazy ODC bit behavior, as shown in the last three plots.  There are even alternating "stripes" which are very odd.

Although I'm only showing plots here for H1, the problem occurs in a similar (though not identical) way in L1 data.  Therefore it is NOT restricted to one site.

Also, this bit problem did NOT occur for the ER7 injections; we checked the bitmask transitions and they all made sense.  It seems to have been introduced since then.  Perhaps the model code update described at LLO alog 18913 is not working as expected?

H1 had a lockloss after a 2hr lock.  

During acquisition noticed a rough alignment, and so locked PRMI to check alignment.  When bringing SRM back, it would saturate and its watchdog would trip.  SRM appears to be in an odd state now (see Evan's alog).  We toggled power on the SRM driver box in the CER (not sure if this did anything though).  Evan & Stefan then took control and carefully checked alignment & ASC.

Oh, and another issue is we've had to "FIND_IR" by hand for last few lock attempts.

This is where we are now.  Looks like L1 is up to Observation Mode.

2:29UTC there was a GRB.  We were out of lock.  Talked to Joe at LLO and they were locked.  They did receive the alarm.  They were in the middle of PEM injections however.

Environmentally:  the winds have picked up to around 20mph.  Most other seismc channels look fairly quiet.

From the attached spectra (taken with the suspension in safe mode), it looks like the same signature as the PRM/PR3 problem.

We thought this might be the cause today's repeated SRM trips. But Andy Lundgren has already looked through all the OSEMs, and it seems even three weeks ago these OSEMs (among many others) had some kind of problem. It is difficult to tell whether it's exactly the same problem, since the channels are only recorded at 256 Hz.

These four OSEMs all share the same driver and satellite box. We power cycled the driver, but the noise remains.

Summary:

By introducing a fudge factor of 3.6 degrees in phase to one of the values from the model (EP1), we now get the time varying calibration parameters close to their nominal values. This basically sets the values of these parameters to their nominal value at the time of calibration.

Details:

Last week, I reported that some of our  time varying parameters ( described in DCC T1500377) were off from their nominal values  and in particular kappa_tst  was off  by a factor of 2 and had a wrong sign as well (alog 21326). 

Darkhan found this discrepancy was due to the  phase of actuation coefficient of x_tst (ESD calibration line) being off by 137 degrees, which was reported in alog 21391. He also corrected for this phase by introducing a fudge factor in  H1:CAL-CS_TDEP_REF_INVA_CLGRATIO_TST_(REAL|IMAG) referred as EP1.  This variable is basically the value  of ESD actuation at time t = t0  (time of calibration) . After correcting for this phase , we got our kappa_tst very close to 1 but real part of kappa_pu was still off by about  7% and imaginary part of kappa_tst was about 0.05 (nominal value 0).

On further investigation today, I found if we change the phase of EP1 by about 3.6 degrees  (EP1 = oldEP1*exp(-1i*pi/180*3.6), the real part of kappa_pu, kappa_tst  and kappa_A will be close to 1 and their imaginary part close to zero, which is what we expect. This shows that there is discrepancy between the values produced by the model to the values obtained from this calculation. We still need to understand why this is different.

Plots:

Attached plots shows different parameters, after applying the correction. The green stretch in each plot is 5 hours of data right after the measurement (DARM sweep and Pcal sweep) used towards calibartion was taken. The values at this point should be nominal for all the parameters. Plot 1 is the real part of kappa_tst, kappa_pu and kappa_A. All these values are close to 1 at the time of calibration. Similarly, in plot 2 the imaginary parts of kappa_tst, kappa_pu and kappa_A are only few percent off from their nominal values of 0. Plot 3 shows the change in optical gain (kappa_C) and the Cavity pole. Kappa_C is close to 1 at the time of calibration and varies from one lock stretch to the other. Cavity pole is close (may be)  to its reported value of 331 Hz (alog 21221) at the time of calibration and has evolved over time.

The script used for this calculation is committed to the svn:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Projects/PhotonCalibrator/drafts_tests/ER8_Data_Analysis/Scripts/plotCalparameterFromSLMData.m

TITLE:  9/13 EVE Shift:  23:00-7:00UTC (16:00-0:00PDT), all times posted in UTC

STATE OF H1:   Continues to be down since earthquakes from just after midnight.  

OUTGOING OPERATOR:  Jim

SUPPORT:  Arrived to a fairly full Control Room on a Sunday (Jenne, Sheila, Evan, Stefan, Jeff K, Greg, Sudarshan).

QUICK SUMMARY:   Ops Overview & O1 CDS Overview look nominal.  (SDF has lots of RED, but since they'be been getting past DRMI a few times, assume we are OK according to SDF [had thought of going back to safe.snaps, but held off on that]).  Will continue troubleshooting.

UPDATE:  H1 BACK!  Jim was still here on-site, so he gets a cookie for his work (along with Jenne [who was here all DAY shift], Sheila, et.al]).

Sounds like they restored IMs to pre-Earthquake/Cheryl alignment values & then did a careful Initial Alignment with Sheila watching them as they went.

Right now we are on our way to recovery:  Addressing SR3 cage servo, SDF diffs, etc.  Currently hovering at about 70Mpc for the last 45mins.  We are listed as "NOT OK" due to current SDF Diffs.

• Title: 9/13 Day Shift: 17:00-23:00UTC

• State of H1: Trying to lock

• Support: Jenne came in early, Sheila later

• Shift Summary: Bad shift. Spent most of it changing alignments, resetting alignments, watching futile atttempts to catch DRMI.

•  

• Activity Log:

• I came in and helped Cheryl reset HAM5 ISI, which is difficult, you have to reset the watchdog and the rogue excitation watchdog. Reisolating will probably require putting GS13s in low gain as well.

•  

• Otherwise I spent it redoing alignments, and didn't get around to keeping a log, but Jenne and I were the only ones doing anything on the IFO, mostly.

Since I set up a schedule of burst hardware injections last night, three of the scheduled injection times have passed.

The first one, at GPS 1126160499 (injection start at 1126160499, actual burst signal centered at 1126160500), should have been executed at H1 (not at L1 since it was down at the time), but didn't work.  The tinjburst.log file says: "1126160499.000000 hwinj_1126160499_2_ 1.00e+00 Compromised".  (It says that five times, because tinj retries a few times if it initially fails.)  The more verbose tinj.log says:
Injection imminent in ~297s...
  1126160499 2 1 hwinj_1126160499_2_
GRB alert at 1126151534: injection allowed.
Detector locked.
Intent bit is on.
calling awgstream...
  awgstream H1:CAL-INJ_TRANSIENT_EXC 16384.000000 ../config/Burst/Waveform/hwinj_1126160499_2_H1.txt 1.000000 1126160499.000000
awgstream failure: injection compromised!

That's strange... Maybe it has to do with environment variables.  I seem to be able to run awgstream fine from the command line in an interactive session, with this zero-amplitude test while H1 was down:
[hinj@h1hwinj1 tinj]$ awgstream H1:CAL-INJ_TRANSIENT_EXC 16384.000000 ../config/Burst/Waveform/hwinj_1126160499_2_H1.txt 0.0 1126187950.000000
Channel = H1:CAL-INJ_TRANSIENT_EXC
File    = ../config/Burst/Waveform/hwinj_1126160499_2_H1.txt
Scale   =          0.000000
Start   = 1126187950.000000
The fact that a zero-amplitude injection succeeded rules out a problem with awg.

I tried to do another test by adding a zero-amplitude injection to the schedule at GPS 1126191200, but since the detector was not locked, tinj did not even call awgstream, so I didn't learn anything from that.

The second and third scheduled injections, at GPS 1126180499 (injection start at 1126180499, actual burst signal centered at 1126180500) and 1126190499, did not occur because the detector was not in observing mode at either time; that's the correct behavior. 

Attached are plots of the time-dependent calibration correction factors as computed by the GDS calibration pipeline for GPS times 1126003432-1126011584 (Fri Sep 11 03:43:35 PDT 2015 - Fri Sep 11 05:59:27 PDT 2015).  The derivation of these factors and their meaning is described in DCC-T1500377.  

The channel names correspond to the factors as such:

GDS-CALIB_F_CC: frequency of coupled cavity pole
  - average value ~ 350 Hz
GDS-CALIB_KAPPA_C: time-dependent scale factor for the sensing 
  - average value ~ 1.07
  - expected average value = 1
GDS-CALIB_KAPPA_A_IMAGINARY: imaginary part of time-dependent scale factor for the total actuation
  - average value ~ -0.01
  - expected average value = 0
GDS-CALIB_KAPPA_A_REAL: real part of time-dependent scale factor for the total actuation
  - average value ~ 1.01
  - expected average value = 1
GDS-CALIB_KAPPA_PU_IMAGINARY: imaginary part of time-dependent scale factor for the PUM/UIM stages of actuation
  - average value ~ 0.03
  - expected average value = 0
GDS-CALIB_KAPPA_PU_REAL: real part of time-dependent scale factor for the PUM/UIM stages of actuation
  - average value ~ 1.07
  - expected average value = 1
GDS-CALIB_KAPPA_TST_IMAGINARY: imaginary part of time-dependent scale factor for the TST stage of actuation
  - average value ~ 0.05
  - expected average value = 0
GDS-CALIB_KAPPA_TST_REAL: real part of time-dependent scale factor for the TST stage of actuation
  - average value ~ 1.0
  - expected average value = 1.0

These values indicate some (O(5%)) differences in gain between the current calibration models and the IFO.  We expect this level of difference for kappa_tst and kappa_c.  However, we anticipated kappa_pu to be closer to the expected average values.  This discrepancy is still being investigated.

C. Cahillane

I have tracked down the differences between my Two Signal ( h = 1/C * DARM_ERR + A * DARM_CTRL ) and Response function ( h = (1 + G)/C * DARM_ERR ) calibration uncertainties.

The trick lay in my weighting factors being slightly different with and without data included.  The Two Signal calibration method requires DARM_ERR and DARM_CTRL from the beginning, whereas the Response function does not.  This means that you must divide out DARM_ERR from the Two Signal method, or multiply it into your Response Function to get comparable results.  I did it both ways, and got identical plots (Shown in Plot 1). 
I found a bug in my Response function method since I was not including the hard-coded minus sign on the x_pcal line I use to calculate kappa_tst and kappa_pu.

Plot 1 and 2 are the same plot, but Plot 2 is zoomed in to show the data noise in the Two Signal method of calibration vs the smooth Response Function.
I have also included the updated components plots for Magnitude (Plot 3) and Phase (Plot 4).  Note that the uncertainty is inflated now compared to aLog 21390.

The next step is to fix the kappa_C and f_c calculations, they still yield ~0.75 and >1000 Hz respectively.  Sudarshan ought to be able to help me here relatively quickly.
Then I must inform my sigma_(param) values more intelligently.