pygwinc issueshttps://git.ligo.org/gwinc/pygwinc/-/issues2024-02-22T19:28:09Zhttps://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/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/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/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/64Material Parameters: Temperature Dependence2020-06-27T03:46:08ZRana AdhikariMaterial Parameters: Temperature DependenceAlthough we have some temperature derivatives (like dn/dT) in the yamls, how do we implement a large temperature scan?
Should we make it possible to implement a function like Y(T) for the Young's modulus, etc.?
Or just run gwinc multip...Although we have some temperature derivatives (like dn/dT) in the yamls, how do we implement a large temperature scan?
Should we make it possible to implement a function like Y(T) for the Young's modulus, etc.?
Or just run gwinc multiple times, changing the materials properties 'by hand' with some user code to update those parameters?https://git.ligo.org/gwinc/pygwinc/-/issues/55auto docs: plots, sphinx, tags2020-04-02T00:51:34ZRana Adhikariauto docs: plots, sphinx, tagsI saw that their is some sporadic auto doxxing stuff that @lee-mcculler has put into some pygwinc areas.
A couple of thoughts on what would be nice:
1. copy the functionality of IDfig.m from matgwinc so that each plot has a tiny doc st...I saw that their is some sporadic auto doxxing stuff that @lee-mcculler has put into some pygwinc areas.
A couple of thoughts on what would be nice:
1. copy the functionality of IDfig.m from matgwinc so that each plot has a tiny doc string subtley stuck on the side that indicates which version of gwinc/magic was used, as well as what version of ifo.yaml, so that its easy to look up the params through GIT.
1. REAMDE files or web pages auto-gen by CI. Explain the physics of the noise sources, recent changes, drawings of the IFO config, etc.
1. When we make the multi page PDFs that havve the main noise + sub-buds, we could have some params data and explanastory tex in the last page.
+ other ideas people