pygwinc issueshttps://git.ligo.org/gwinc/pygwinc/-/issues2022-03-28T02:22:41Zhttps://git.ligo.org/gwinc/pygwinc/-/issues/83Sub-budgets at run time2022-03-28T02:22:41ZChristopher WipfSub-budgets at run timeThe way pygwinc works now, all noises must be predefined in the budget before it is run. This can be unwieldy, for example when noises are very numerous (e.g. suspensions), or when the relevant noises are not definitely known until runt...The way pygwinc works now, all noises must be predefined in the budget before it is run. This can be unwieldy, for example when noises are very numerous (e.g. suspensions), or when the relevant noises are not definitely known until runtime (e.g. quantum losses). So it would be useful to have a way of defining sub-budgets at run time.1.0 releasehttps://git.ligo.org/gwinc/pygwinc/-/issues/81Expose precomp and other convenience data to user2023-11-01T14:43:53ZLee McCullerExpose precomp and other convenience data to userShould make an interface for users to index the precomp data and add some of the convenience SQZ and power calculations into this interface. The command line should be usable to dump this data via flag.Should make an interface for users to index the precomp data and add some of the convenience SQZ and power calculations into this interface. The command line should be usable to dump this data via flag.1.0 releasehttps://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/57separate all materials parameters into a global materials parameter struct2021-03-23T19:54:17ZJameson Rollinsjameson.rollins@ligo.orgseparate all materials parameters into a global materials parameter structRather than listing materials parameters under the particular object where they're used, all global materials parameters should be moved to a separate struct, and they should always be pulled from the global struct during calculation.
`...Rather than listing materials parameters under the particular object where they're used, all global materials parameters should be moved to a separate struct, and they should always be pulled from the global struct during calculation.
`ifo.Materials` seems like a good place for global materials parameters. But I wonder if the things like the test mass geometry, which are currently under that same struct should be moved elsewhere.https://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/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/54Suggestion: add higher order parameter class to generate compiled parameter f...2020-04-28T07:19:22ZSean LeaveySuggestion: add higher order parameter class to generate compiled parameter filesThis relates to the discussions about handling precomputed parameters in a generic way (#40, #49).
I suggest we add a class that acts like a higher order parameter file and can be optionally used instead of specifying a parameter file d...This relates to the discussions about handling precomputed parameters in a generic way (#40, #49).
I suggest we add a class that acts like a higher order parameter file and can be optionally used instead of specifying a parameter file directly. In this class users can define the location of one or many input parameter files to load in order (with successive files overwriting any duplicate parameters in earlier files), and any precomp routines you wish to define along with the name of the parameter(s) they should define. This class could then generate a single, "machine readable" representation of the parameter file for use in `pygwinc`. This file could be intentionally obfuscated to discourage users from modifying it directly, e.g. by pickling it or dumping to YAML without any whitespace. The class could check if such a file exists, and if not, generate it. It could also have fancier `make`-like checks for file modification times, triggering a recompilation if one of the input parameter files (or the higher order parameter class itself) changes.
We could also add the ability to define sanity checks in this class, e.g. to check precomp parameters are within certain bounds.
Here is an example of how this class could look:
```python
class HigherOrderStruct:
def __init__(self, *input_files):
self._struct = Struct()
self.input_files = input_files
@property
def struct(self):
"""Get struct including precomputed parameters."""
if self.modified():
self._compile()
self._do_checks()
return pickle.load(self.output_path)
@property
def output_path(self):
# generate hash from paths and modification times of input files and this file, in order,
# and use this as the filename. can be stored in user's cache or temp directory?
pass
def modified(self):
# check if the file named self.output_path exists
def _compile(self):
for input_file in self.input_files:
self._struct.update(Struct.from_file(input_file))
for params, precomp_method in self._PRECOMP_METHODS: # populated by decorator
values = precomp_method(self._struct)
for param, value in zip(params, values):
self._struct[param] = value
pickle.dump(self.output_path, self._struct)
def _do_checks(self):
# perform checks defined by e.g. self.set_param_tolerance.
# trigger exception on failure
pass
@defines('Materials.MirrorVolume', 'Materials.MirrorMass')
def mirror_stuff(self, ifo):
volume = pi*ifo.Materials.MassRadius**2 * Materials.MassThickness
mass = volume * ifo.Materials.Substrate.MassDensity
return volume, mass
def set_param_tolerance(self, param, value, rtol=1e-6, atol=1e-9):
# Add some internal check to run once the parameter file is compiled.
# In this case, it could use math.isclose.
self._param_tolerances.append((param, value, rtol, atol))
```
This approach would:
- Provide a clear API for users to define their own precomp routines without having to directly modify the `Struct` object created from their parameter file before passing it to `pygwinc`.
- Let users define a hierarchy of parameter files. This could be useful for instance to allow users to load some set of shared parameters like material properties, provided by gwinc, before their own custom parameter file, avoiding repetition.
- Avoid having to call precomp routines during subsequent runs of pygwinc (helps when running optimisations).
- Catch bugs created by changes to precomp routines by allowing users to define tolerances on expected values.
This stuff is exactly how I am using `pygwinc` currently.
Thoughts? Happy to make a PR if you think this is useful...https://git.ligo.org/gwinc/pygwinc/-/issues/15Git sha watermarking of plots/data2020-04-02T00:51:35ZLee McCullerGit sha watermarking of plots/dataIf we want to be really good about versioning of curves, we could add some way for the plotter/data-exporters to know the git sha of the code and whether the current checkout is dirty. I think that plots could keep a subtle text copy of ...If we want to be really good about versioning of curves, we could add some way for the plotter/data-exporters to know the git sha of the code and whether the current checkout is dirty. I think that plots could keep a subtle text copy of the sha in the bottom/corner/side or alternatively the tag (version) if the current sha sits on a tag.
Maybe this is unnecessary if we are already being more careful about adjusting code.. If so we can close this and the issue serves as a decision.
There are many ways to do this. In the past I have added git hooks which update an auto_version.py in the working copy before or after commit. This is annoying because it makes the working tree always dirty (at least the way I've done it). It's also bad since users have to explicitly set up the hook, so it would also need a receive hook on gitlab to ensure that the update is performed.
Is there a better way? Is this necessary. Even without watermarking I like having an auto_version.py for code to query and report.https://git.ligo.org/gwinc/pygwinc/-/issues/4coating parameter misnomer2021-06-16T04:55:08ZChristopher Wipfcoating parameter misnomerThe coating parameters named "ThermalDiffusivity{high,low}n" should be renamed as they are actually thermal conductivities.The coating parameters named "ThermalDiffusivity{high,low}n" should be renamed as they are actually thermal conductivities.Christopher WipfChristopher Wipfhttps://git.ligo.org/gwinc/pygwinc/-/issues/114load_hdf5 should load metadata in addition to just the traces and ifo struct2024-02-22T19:28:09ZKevin Kunsload_hdf5 should load metadata in addition to just the traces and ifo structYou can currently save any metadata along with the budget traces and ifo struct with `io.save_hdf5` like
```python
traces = budget.run()
metadata = {
"gps_time": 123,
"other_stuf": "blah blah",
}
io.save_hdf5(traces, path, ifo=bu...You can currently save any metadata along with the budget traces and ifo struct with `io.save_hdf5` like
```python
traces = budget.run()
metadata = {
"gps_time": 123,
"other_stuf": "blah blah",
}
io.save_hdf5(traces, path, ifo=budget.ifo, **extra_metadata)
```
This [does save](https://git.ligo.org/gwinc/pygwinc/-/blob/master/gwinc/io.py?ref_type=heads#L46) `extra_metadata` in `attrs`, however `load_hdf5` [only loads](https://git.ligo.org/gwinc/pygwinc/-/blob/master/gwinc/io.py?ref_type=heads#L115) the traces and ifo back (in SCHEMA_VERSION 2).
Furthermore, it adds the ifo struct to traces, which I don't like. I propose doing something like returning traces, ifo, and everything in attrs except `ifo` (and maybe not `SCHEMA` or `SCHEMA_VERSION` either). Or maybe make a SCHEMA 3 which saves any metadata to a separate metadata dict in attrs. Something like
```python
traces = io.load_hdf5(file_name) # if only the traces were saved
traces, ifo = io.load_hdf5(file_name) # if traces and ifo were saved
traces, ifo, metadata = io.load_hdf5(file_name) # if all three were saved
```
The one problem being knowing how many variables to expect, but maybe that's not so bad.
This kind of thing would be very useful for the LHO noise budget, for example. Right now I have them saving any extra metadata that they want as I did in the example above. If the conclusion is to move to some other slightly different SCHEMA where the metadata is saved in some other way in the hdf5 file, it will be trivial to manually fix the few budgets that they've saved as in the above example to work with whatever we eventually decide.https://git.ligo.org/gwinc/pygwinc/-/issues/111add unit test for accumulate2023-11-04T18:12:50ZKevin Kunsadd unit test for accumulateThe `nb.Budget` `accumulate` function is missing on some branches. It should be tested.The `nb.Budget` `accumulate` function is missing on some branches. It should be tested.Kevin KunsKevin Kunshttps://git.ligo.org/gwinc/pygwinc/-/issues/110unit tests for io2023-11-04T16:46:02ZKevin Kunsunit tests for ioWe need unit tests for `load_hdf5` and `save_hdf5`. This shouldn't hold up any merge requests, but things have broken them before and been accidentally caught (or not).We need unit tests for `load_hdf5` and `save_hdf5`. This shouldn't hold up any merge requests, but things have broken them before and been accidentally caught (or not).https://git.ligo.org/gwinc/pygwinc/-/issues/108add deepcopy to traces2023-04-04T03:30:57ZKevin Kunsadd deepcopy to tracesIt would be convenient if traces could be deepcopied.It would be convenient if traces could be deepcopied.https://git.ligo.org/gwinc/pygwinc/-/issues/107Add option of auxiliary wavelengths resonating in arm cavity and related calc...2021-12-09T21:30:31ZAnchal GuptaAdd option of auxiliary wavelengths resonating in arm cavity and related calculationsSince Arm Length Stabilization (ALS) is an important part of ifo design and requirements, it would be nice to allow adding auxiliary wavelength(s) that are assumed to be circulating in the arm cavities. The helper function [arm_cavity(if...Since Arm Length Stabilization (ALS) is an important part of ifo design and requirements, it would be nice to allow adding auxiliary wavelength(s) that are assumed to be circulating in the arm cavities. The helper function [arm_cavity(ifo)](https://git.ligo.org/gwinc/pygwinc/-/blob/master/gwinc/ifo/noises.py#L42) can be expanded to calculate cavity parameters for the auxiliary wavelengths. This could be the start of supporting the calculation of noise contributions to auxiliary wavelength loops as well.
I believe there is more potential for development once we have the wavelengths as an ifo parameter.https://git.ligo.org/gwinc/pygwinc/-/issues/106BS losses are only single passed in PRC for calculation of power recycling ga...2021-12-03T05:51:01ZSheila DwyerBS losses are only single passed in PRC for calculation of power recycling gain, shouldn't they be double passed?In ifo/noises.py line 105:
```
`prfactor = t5**2 / (1 + r5 * rarm * sqrt(1-bsloss))**2`
```
I'm thinking that the BS is double passed in the PRC, so this should be:
```
`prfactor = t5**2 / (1 + r5 * rarm * (1-bsloss))**2`
```
or
```
...In ifo/noises.py line 105:
```
`prfactor = t5**2 / (1 + r5 * rarm * sqrt(1-bsloss))**2`
```
I'm thinking that the BS is double passed in the PRC, so this should be:
```
`prfactor = t5**2 / (1 + r5 * rarm * (1-bsloss))**2`
```
or
```
`prfactor = t5**2 / (1 + r5 * rarm * sqrt(1-2*bsloss))**2`
```
Is that right? This may be inconsequential for the IFO models gwinc has because the BS losses are small, but we are thinking that we need to use larger PRC losses if we want to make a model to match H1.https://git.ligo.org/gwinc/pygwinc/-/issues/105pytest_addoption not doing its job2021-11-23T15:54:23ZKevin Kunspytest_addoption not doing its jobWhen trying to running pytest in the pygwinc/test directory as
```shell
pytest
```
all of the tests work. When running it from the gwinc directory I get the following error
<details>
<summary> Error </summary>
```shell
================...When trying to running pytest in the pygwinc/test directory as
```shell
pytest
```
all of the tests work. When running it from the gwinc directory I get the following error
<details>
<summary> Error </summary>
```shell
==================================== ERRORS ====================================
________________________ ERROR collecting test session _________________________
/home/kevin/.local/lib/python3.7/site-packages/_pytest/config/__init__.py:458: in _importconftest
return self._conftestpath2mod[key]
E KeyError: PosixPath('/home/kevin/Documents/Research/GWdetectionCode/pygwinc/gwinc/test/cache/7bda7f0598e6b78ac90f9d986e105469bbed08d0/gwinc/conftest.py')
During handling of the above exception, another exception occurred:
/home/kevin/.local/lib/python3.7/site-packages/py/_path/common.py:383: in visit
for x in Visitor(fil, rec, ignore, bf, sort).gen(self):
/home/kevin/.local/lib/python3.7/site-packages/py/_path/common.py:435: in gen
for p in self.gen(subdir):
/home/kevin/.local/lib/python3.7/site-packages/py/_path/common.py:435: in gen
for p in self.gen(subdir):
/home/kevin/.local/lib/python3.7/site-packages/py/_path/common.py:435: in gen
for p in self.gen(subdir):
/home/kevin/.local/lib/python3.7/site-packages/py/_path/common.py:435: in gen
for p in self.gen(subdir):
/home/kevin/.local/lib/python3.7/site-packages/py/_path/common.py:424: in gen
dirs = self.optsort([p for p in entries
/home/kevin/.local/lib/python3.7/site-packages/py/_path/common.py:425: in <listcomp>
if p.check(dir=1) and (rec is None or rec(p))])
/home/kevin/.local/lib/python3.7/site-packages/_pytest/main.py:622: in _recurse
ihook = self.gethookproxy(dirpath)
/home/kevin/.local/lib/python3.7/site-packages/_pytest/main.py:441: in gethookproxy
my_conftestmodules = pm._getconftestmodules(fspath)
/home/kevin/.local/lib/python3.7/site-packages/_pytest/config/__init__.py:436: in _getconftestmodules
mod = self._importconftest(conftestpath)
/home/kevin/.local/lib/python3.7/site-packages/_pytest/config/__init__.py:483: in _importconftest
self.consider_conftest(mod)
/home/kevin/.local/lib/python3.7/site-packages/_pytest/config/__init__.py:536: in consider_conftest
self.register(conftestmodule, name=conftestmodule.__file__)
/home/kevin/.local/lib/python3.7/site-packages/_pytest/config/__init__.py:342: in register
ret = super().register(plugin, name)
/home/kevin/.local/lib/python3.7/site-packages/pluggy/manager.py:127: in register
hook._maybe_apply_history(hookimpl)
/home/kevin/.local/lib/python3.7/site-packages/pluggy/hooks.py:333: in _maybe_apply_history
res = self._hookexec(self, [method], kwargs)
/home/kevin/.local/lib/python3.7/site-packages/pluggy/manager.py:93: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/home/kevin/.local/lib/python3.7/site-packages/pluggy/manager.py:87: in <lambda>
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
gwinc/test/cache/7bda7f0598e6b78ac90f9d986e105469bbed08d0/gwinc/conftest.py:26: in pytest_addoption
help = "Have tests update plots (it is slow)",
/home/kevin/.local/lib/python3.7/site-packages/_pytest/config/argparsing.py:78: in addoption
self._anonymous.addoption(*opts, **attrs)
/home/kevin/.local/lib/python3.7/site-packages/_pytest/config/argparsing.py:314: in addoption
raise ValueError("option names %s already added" % conflict)
E ValueError: option names {'--plot'} already added
!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
=============================== 1 error in 2.08s ===============================
```
</details>
I think this is a problem in the `pytest_addoption` function in conftest.py
This isn't an emergency since pytest watch still works when called in the gwinc directory and all the tests run when called in gwinc/test.Lee McCullerLee McCullerhttps://git.ligo.org/gwinc/pygwinc/-/issues/104Release 0.4.0 breaks residual gas noise calculation in existing budgets2021-11-23T00:32:12ZChristopher WipfRelease 0.4.0 breaks residual gas noise calculation in existing budgetsSince !121 they fail with error `Struct object has no attribute 'H2'`.Since !121 they fail with error `Struct object has no attribute 'H2'`.Kevin KunsKevin Kunshttps://git.ligo.org/gwinc/pygwinc/-/issues/103No easy way to remove filter cavity2021-11-23T00:15:53ZKevin KunsNo easy way to remove filter cavityThere's no easy way to remove the filter cavity from budgets right now because the filter cavity loss needs to be manually removed. This will maybe be solved if sub-budgets are defined at runtime (#83) depending on how that's implemented...There's no easy way to remove the filter cavity from budgets right now because the filter cavity loss needs to be manually removed. This will maybe be solved if sub-budgets are defined at runtime (#83) depending on how that's implemented. In particular, setting `ifo.Squeezer.Type = 'Freq Independent'` for the default A+ will calculate the quantum noise with frequency independent squeezing, but will fail because `QuantumVacuumFilterCavity` is hard-coded in the A+ init file. The proper way to do this is to define an ifo without `QuantumVacuumFilterCavity`, like aLIGO, but this is not obvious to a beginner. I'd love it if there was a way to inherit budgets instead of just ifo structs, but that's a long ways away.https://git.ligo.org/gwinc/pygwinc/-/issues/102add version specification to yaml files2021-10-04T18:38:15ZKevin Kunsadd version specification to yaml filesyaml files should have a field that specifies which version of gwinc to use.yaml files should have a field that specifies which version of gwinc to use.https://git.ligo.org/gwinc/pygwinc/-/issues/101how to setup matlab gwinc path2021-09-02T23:23:39ZRana Adhikarihow to setup matlab gwinc pathHaving trouble getting my old pygwinc code to find the correct matlab gwinc codes when load a coating config file.
How about adding a readme to the repo describing how to set that up?Having trouble getting my old pygwinc code to find the correct matlab gwinc codes when load a coating config file.
How about adding a readme to the repo describing how to set that up?