Add functionality to strain data

A set of changes to improve our handling of strain data. The ultimate aim is to handle all strain data in one unified approach.

Tasks:

• Add time domain data and automatically get the frequency domain (partial fix for #121 (closed))
• Add methods for setting data from CSV files of time-domain strain [removed as this can be done easily with gwpy]
• Add units and explanations for the normalization
• Add set_from_gwpy method
• Encapsulate all other gwpy calls
• Add a create_psd method that turns the strain data into a power spectral density.
• Check documentation

@paul-lasky @colm.talbot @moritz.huebner @nikhil.sarin

marked the checklist item Add time domain data and automatically get the frequency domain (partial fix for #121 (closed)) as completed

changed the description

added 3 commits

• aba896a3 - Clean up documentation and notation of nfft and infft and add tests
• e95b62d6 - Clean up time and frequency array setting and add checks
• b9636986 - Adds documentation to the time and frequency domain strain

Compare with previous version

added 1 commit

• 5835de2b - Add basic set from gwpy method

Compare with previous version

marked the checklist item Add set_from_gwpy method as completed

marked the checklist item Add units and explanations for the normalization as completed

marked the checklist item Add units and explanations for the normalization as incomplete

marked the checklist item Add set_from_gwpy method as incomplete

marked the checklist item Add set_from_gwpy method as completed

marked the checklist item Add units and explanations for the normalization as completed

• Fix windowing to be the proper roll off
• Remove data crop

resolved all discussions

added 7 commits

• a3986dc6 - Fix notation on units
• a4200ddc - Convert logic of get_open_strain to methods of strain_data
• f045fcdd - Further bug fixes and improvements
• 234ff4cd - Update from using alpha to a time of roll off
• 7cd604f6 - Simplify set_from_frame
• 1fe13b4c - Make roll_off an attribute and fix bug in the PSD roll off
• 33bc0398 - Move low pass and window to be called by default when generating td data

Compare with previous version

added 2 commits

• d66288d4 - Fix detector test
• dde16382 - Add minimum scipy version

Compare with previous version

marked the checklist item Add a create_psd method that turns the strain data into a power spectral density. as completed

marked the checklist item Encapsulate all other gwpy calls as completed

@colm.talbot I've noticed that there is some work that could be done on PowerSpectralDensity which mirrors what is done here.

I'd personally like to see (a) PSD be in its own file for convienience, and (b) it be settable from a bunch of methods (rather than the init take a load of different input). What is your feeling? I don't want to impose my views everywhere :P

(a) Why (I'm not trying to be difficult, I just don't know why this would be better)?

(b) I think this comes down to a question of whether we want users to change the existing PSD or make a new different one. I'd personally vote for the latter, although the former may be more in line with the implementation of the StrainData.

(a) okay I'm not to bothered either way, I'll leave it as is.

(b) I'm not sure I understand. Currently users can set the psd when they initialise the PSD object, by passing one of asd-file, psd-file, frame file, or an array.

My problem is that the init of PowerSpectralDensity has become too bloated. It includes things like applying a window and filtering. There are at least 2 ways I could see people wanting to extend it (pass in a gwpy object or a array of time domain strain data). And with all this it's difficult to follow. So at the least, we should move all the logic into methods.

Then, it's a question of how you access those methods. Personally, I think it's easier just to have the user instantiate an empty psd, then apply a 'set-from...' method. The alternative is to still have an init which takes all the things, but the. Passes them of to the right method.

My argument is that for one extra line of code to the user, we add better clarity to exactly how they set the psd. If you pass an asd file and a psd file which one is used? I know that would be stupid, but I'm sure someone (probably me) will do it eventually.

I'm mocking up the changes now and I'll show them to you tomorrow and we can discuss :)

added 4 commits

• b1622695 - Reorganise PowerSpectralDensity
• 81e52d06 - Add magic to recover previous behaviour and add documentation
• 5daed45a - Add explicit note about use of aLIGO PSD and make it the default
• 1711c726 - Update how PSDs are generated from strain data

Compare with previous version

added 1 commit

• 231b821c - Reorder and improve docs of InterferometerStrainData

Compare with previous version

marked the checklist item Check documentation as completed

unmarked as a Work In Progress

added 2 commits

• 3c14b1fd - Adds check of the maximum frequency
• 3f578976 - Reorder of methods

Compare with previous version

added 1 commit

• caac3d80 - Adds methods to set from a CSV file

Compare with previous version

merged

mentioned in commit 90d5c106