Improve coh_PTF efficiency
Description
This patch contains the following changes:
- A patch to avoid setting the name of various FrequencySeries. Given changes in lalsuite, shortening the default length, this code is now broken, and causes failures. I'll simply remove this code now. This will prevent the ability to dump these files to disk, but this is a debugging tool, not used in production, and given that this code should be replaced with a python equivalent at some point, I'm not worrying too much about losing features like this.
- An optimization improvement in how triggers are stored and clustered. Previously some of the internal loops would loop over all triggers when clustering. This quickly becomes a bottleneck when dealing with many triggers (e.g. many sky points). By storing the triggers in different arrays (one for every analysis second) we can improve the run time of these particular function by ~100 - 1000.
- One other double loop inside the "loop over all sky points" block had a number of repeated logic checks. By only doing this once we can also speed up that function.
In an example given by Tessa I find a case for no-injections, using 60 templates and 300 sky points and 5000 seconds previously took 88428 seconds:
Generated triggers for segment 42, template 58, sky point 285, short slide 0 at 7808629999
There are 174605 total triggers before cluster.
There are 25336 total triggers after cluster.
output events to LIGOLw XML file H1L1V1-INSPIRAL_COHERENT_INJECTIONS_NSNS30INJ_SPLIT37_BANK8_INJECTIONS-1243407636-5648--.xml.gz
Generated output xml file, cleaning up and exiting at 8428788435
and now takes:
Generated triggers for segment 42, template 58, sky point 285, short slide 0 at 5132778897
There are 174604 total triggers before cluster.
There are 25336 total triggers after cluster.
output events to LIGOLw XML file H1L1V1-INSPIRAL_COHERENT_INJECTIONS_NSNS30INJ_SPLIT37_BANK8_INJECTIONS-1243407636-5648--.xml.gz
Generated output xml file, cleaning up and exiting at 5135351065
API Changes and Justification
Backwards Compatible Changes
- [(./) ] This change introduces no API changes
-
This change adds new API calls
Backwards Incompatible Changes
None. This change is designed to produce identical output, other than removing a feature that is currently causing the code on master to fail outright, and was never used anyway.