pygwinc issueshttps://git.ligo.org/gwinc/pygwinc/-/issues2021-05-15T06:39:52Zhttps://git.ligo.org/gwinc/pygwinc/-/issues/84SEC loss sub-budget2021-05-15T06:39:52ZKevin KunsSEC loss sub-budgetI think we should add an SEC loss sub-budget. The frequency dependence may not be that interesting, but it would be very useful. This would necessitate generalizing the yaml files and would benefit greatly from #83, but does not need it ...I think we should add an SEC loss sub-budget. The frequency dependence may not be that interesting, but it would be very useful. This would necessitate generalizing the yaml files and would benefit greatly from #83, but does not need it to be implemented at first.Kevin KunsKevin Kunshttps://git.ligo.org/gwinc/pygwinc/-/issues/80Suspension bottom stage temperature gradient not budgeted accurately2021-04-20T12:55:44ZChristopher WipfSuspension bottom stage temperature gradient not budgeted accuratelyThe suspension noise sub-budget for the bottom stage is not accurate when a temperature gradient exists there. A continuum wire model is used to include the effect of violin modes, which does not allow for the temperature to vary along t...The suspension noise sub-budget for the bottom stage is not accurate when a temperature gradient exists there. A continuum wire model is used to include the effect of violin modes, which does not allow for the temperature to vary along the wire. An alternative treatment that does allow for temperature gradients can be found in [Komori et al (2018)](http://dx.doi.org/10.1103/PhysRevD.97.102001).https://git.ligo.org/gwinc/pygwinc/-/issues/76Substrate absorption is not consistently accounted for2021-12-03T05:51:11ZChristopher WipfSubstrate absorption is not consistently accounted forThere are two parameters found in IFO models that refer to substrate absorption: `ifo.Optics.SubstrateAbsorption` and `ifo.Optics.ITM.SubstrateAbsorption`. It's not well documented which one is supposed to be used for what.
A quick gre...There are two parameters found in IFO models that refer to substrate absorption: `ifo.Optics.SubstrateAbsorption` and `ifo.Optics.ITM.SubstrateAbsorption`. It's not well documented which one is supposed to be used for what.
A quick grep suggests that `ifo.Optics.ITM.SubstrateAbsorption` is not currently used anywhere in the code, except for the obsolete `gwinc` function. `ifo.Optics.SubstrateAbsorption` is used only for a BS thermal lensing power limit check in `ifo_power`.
We should track total absorption in all substrates that are inside the PRC/SRC (ITMs and BS), in order to correctly estimate the power recycling gain and SRC loss. We should track absorption in each substrate for thermal lensing limits, and for heat budgeting purposes in cryo substrates.https://git.ligo.org/gwinc/pygwinc/-/issues/36Gravitational Noise: should use frequency dependent subtraction2020-04-01T08:03:50ZRana AdhikariGravitational Noise: should use frequency dependent subtractionIts unlikely that we will be able to have a frequency independent subtraction of the local gravity noise. In particular, I doubt that we'll ever subtract much below 10 Hz (wind) and much above 25 Hz (not enough sensors). How should we re...Its unlikely that we will be able to have a frequency independent subtraction of the local gravity noise. In particular, I doubt that we'll ever subtract much below 10 Hz (wind) and much above 25 Hz (not enough sensors). How should we represent this in GWINC? The subtraction is hugely overestimated as it now stands in almost all such future interferometer plots. Maybe @donatella or @jan-harms harms knows.Evan HallEvan Hallhttps://git.ligo.org/gwinc/pygwinc/-/issues/33Check provenance of CTN finite size optic correction2019-05-28T21:55:40ZChristopher WipfCheck provenance of CTN finite size optic correctionKentaro points out that the reference to Braginsky and Vyatchanin that we have in the comments of `getCoatFiniteCorr()` is a slippery one. We cite both the published version and the arXiv. The latest version on the arXiv is subsequent to...Kentaro points out that the reference to Braginsky and Vyatchanin that we have in the comments of `getCoatFiniteCorr()` is a slippery one. We cite both the published version and the arXiv. The latest version on the arXiv is subsequent to the published version, and fixes an uncorrected error in the published version. Just to make sure nobody's confused, we should double-check that we have the right formula, and document this situation better in the comments. He suggests we compare with his independent calculation published here: https://doi.org/10.1103/PhysRevD.79.102004.https://git.ligo.org/gwinc/pygwinc/-/issues/31Coating code wrong/broken; needs upgrade2021-01-12T22:22:05ZRana AdhikariCoating code wrong/broken; needs upgradeCannot handle the case when the outer layer on the HR coating has a higher index of refraction than the second layer.
Need to copy correct code from CryogenicLIGO/Sensitivity/coatings.Cannot handle the case when the outer layer on the HR coating has a higher index of refraction than the second layer.
Need to copy correct code from CryogenicLIGO/Sensitivity/coatings.https://git.ligo.org/gwinc/pygwinc/-/issues/14Needs Optimization and MC tool2020-07-06T17:22:11ZLee McCullerNeeds Optimization and MC toolThis will require first #12
With some of the more advanced studies of filtercavity performance we need the ability to scan around in parameter space and choose the optimal cavity configuration given nominal installs of the system.
To ...This will require first #12
With some of the more advanced studies of filtercavity performance we need the ability to scan around in parameter space and choose the optimal cavity configuration given nominal installs of the system.
To scan around needs some function interfaces, to MC around requires some configuration parameters such as distributions, and to optimize requires an easily parametrizable optimizer.
Luckily the code is already structured around a hierarchical configuration. I will create a branch with a tool that takes a YAML config that
a) inherits nominal settings (first-try parameters for the optimizer)
b) replaces any numbers like for filter cavities
```YAML
Squeezer:
Inputs:
- type: 'filtercavity'
L_m: 300 # cavity length
Te: 1e-6 # end mirror trasmission
Lrt: 60e-6 # round-trip loss in the cavity
Rot: 0 # phase rotation after cavity
fdetune_Hz: -45.78 # detuning [Hz]
Ti: 1.2e-3 # input mirror trasmission [Power]
mode_matching_loss: .00
mode_matching_phase_deg: .00
#TODO
RMS_length_m: 1e-18 # Length noise RMS << bandwidth (for equiv phase noise)
```
with an overlay such as
```YAML
Squeezer:
Inputs:
- type: 'filtercavity'
fdetune_Hz:
parameter: 'optimize'
upperbound: 300
lowerbound: 0
mode_matching_phase_deg:
parameter: 'MC-uniform'
upperbound: 0
lowerbound: 180
```
and so on for squeezing parameters (like sqz-amplitude and sqz-phase, although those already have a much faster optimizer).
Now the tools will scan for parameters, generate bookkeeping lists, update the ifo struct with MC samples, and run an optimizer by updating other ifo-struct parameters. It will be a very slow way to optimize, but the MC sampler can be multiprocess'ed. The optimizer will probably be a simple one like Nelder-Mead simplex crawl if it can be made to use bounds. The FOM to optimize over should also be configurable, and should be able to take external noise plots such as existing controls noise.
The tool will just be some loops and bookkeeping, shouldn't take long to write and I'm sure others will find it useful.Lee McCullerLee McCuller2020-07-04