The frequency of LIGO detectors is 10 Hz to 10 kHz.
\nSince the data given to us is sampled at 2048 Hz or a max frequency of 1024 Hz, a BH chirp of frequency higher than 1Khz would be an alias of a smaller frequency.
\nThe above plot shows the corresponding alias of higher frequencies within the given sample rate.
\nFor example, The chirp of 3500Hz, 4500Hz, 5500Hz, 6500Hz, etc would be 500Hz in our data.
I highly doubt the \"astrophysically motivated\" chirps or BH masses are restricted to make the chirp not more than 1 Khz. Technically using a bandpass filter (20-500Hz) would be wrong as we will miss out on chirps not only from 500Hz to 1023Hz but any aliases that fall in that frequency too.
\nHow do we account for this? Why is 20-500Hz filtering working for most of us?
\nMy Stats:
\nfiltering: 30-900Hz
\nmodel: resnet50
\naugmentation: none
\nCV: 0.8592
\nLB: Disappointed with CV
The frequency of LIGO detectors is 10 Hz to 10 kHz.
\nSince the data given to us is sampled at 2048 Hz or a max frequency of 1024 Hz, a BH chirp of frequency higher than 1Khz would be an alias of a smaller frequency.
\nThe above plot shows the corresponding alias of higher frequencies within the given sample rate.
\nFor example, The chirp of 3500Hz, 4500Hz, 5500Hz, 6500Hz, etc would be 500Hz in our data.
I highly doubt the \"astrophysically motivated\" chirps or BH masses are restricted to make the chirp not more than 1 Khz. Technically using a bandpass filter (20-500Hz) would be wrong as we will miss out on chirps not only from 500Hz to 1023Hz but any aliases that fall in that frequency too.
\nHow do we account for this? Why is 20-500Hz filtering working for most of us?
\nMy Stats:
\nfiltering: 30-900Hz
\nmodel: resnet50
\naugmentation: none
\nCV: 0.8592
\nLB: Disappointed with CV
x.highpass(30)?
Anything that 'aliases' in that bucket will still get nixed.
", "rawMarkdown": "`x.highpass(30)`?\n\nAnything that 'aliases' in that bucket will still get nixed.", "votes": null }, { "id": "1501872", "postDate": "09/03/2021 15:55:26", "content": "Technically we shouldn't use a filter but filtering works. my question is why considering the above explanation.
\nIf the original LIGO data is filtered, it makes sense as the max frequency is 10Khz and the data is sampled at 16Khz
\nI'm getting the best score with highpass 30Hz.
", "rawMarkdown": "Technically we shouldn't use a filter but filtering works. my question is why considering the above explanation.\n\nIf the original LIGO data is filtered, it makes sense as the max frequency is 10Khz and the data is sampled at 16Khz\n\nI'm getting the best score with highpass 30Hz.", "votes": null }, { "id": "1501899", "postDate": "09/03/2021 16:15:48", "content": "¯\\_(ツ)_/¯ All we know is:
This is my conjecture for why it's hard to climb LB:
\n![\"\"](\"https://i.imgur.com/n9MnyB3.png\")
What does this mean? We have two fundamentally different types of signals present in the data. The easier to classify BH mergers. And the dastardly difficult to identify NS mergers. They are lower total system mass and so less energy or gws are emitted. How can we enable our models to see these? Straight BP or HP filtering is insufficient and no one has reported whitening as working yet (though maybe some top scoring teams have made it work secretly?) :)
\nTraining separate models on the hard data doesn't help. I haven't tried explicit weighting, and already mentioned focal loss failures.
", "rawMarkdown": "` ¯\\_(ツ)_/¯` All we know is:\n\n1. The matched filtering used by LIGO does HP @ 15Hz and no bandpass filtering (no max cutoff, period). In the literature and on pycbc and those other packages, they make clear that the BP'ing is purely for illustrative / exploratory / visualization purposes; but the actual MF used @Ligo doesn't make use of it.\n2. The data provided is synthetic anyway, so anything goes. Visualizing ~300 constant-q transformed samples, we don't \"see\" any GW events that jumps out when doing BP vs HP only. At the end of the day, experimentation is king anyway. Whatever works is correct in the context of this competition.\n\nThis is my conjecture for why it's hard to climb LB:\n\n- We have perfectly even split of TPs and TNs provided\n- 50% of TP's are classified correctly with +99.98% CI across 5-fold models\n- 50% of \"FNs\" are spread out over the distribution from 0-99, congregating ~20%\n\n\n\nWhat does this mean? We have two fundamentally different types of signals present in the data. The easier to classify BH mergers. And the dastardly difficult to identify NS mergers. They are lower total system mass and so less energy or gws are emitted. How can we enable our models to see these? Straight BP or HP filtering is insufficient and no one has reported whitening as working yet (though maybe some top scoring teams have [made it work](https://www.kaggle.com/c/g2net-gravitational-wave-detection/discussion/269977#1501726) secretly?) :)\n\nTraining separate models on the hard data doesn't help. I haven't tried explicit weighting, and already mentioned focal loss failures.", "votes": null }, { "id": "1501930", "postDate": "09/03/2021 16:47:31", "content": "\n\nthey make clear that the BP'ing is purely for illustrative / exploratory / visualization purposes; but the actual MF used @Ligo doesn't make use of it.
\n
This makes sense.
\nI thought we only had BH mergers and no NS. Gotta revisit some literature.
\nFocal loss and ArcFace didn't help me in improving the score either. ArcFace struggles to explicitly separate two classes.
\n😤
", "rawMarkdown": "> they make clear that the BP'ing is purely for illustrative / exploratory / visualization purposes; but the actual MF used @Ligo doesn't make use of it.\n\nThis makes sense.\n\nI thought we only had BH mergers and no NS. Gotta revisit some literature.\n\nFocal loss and ArcFace didn't help me in improving the score either. ArcFace struggles to explicitly separate two classes.\n\n😤", "votes": null }, { "id": "1501944", "postDate": "09/03/2021 16:55:04", "content": "Actually, before you do that: the Overview and Data Description sections only make mention of GW's, but say nothing about BBH/BNS. However, the Welcome to the G2Net Gravitational Wave detection challenge post says:
\n\n\nWe would really appreciate your help in exploring new ways to detect signals and we hope you enjoy the binary black hole challenge that we’ve set for you.
\n
@bayeswolf Would it be possible to clarify if we're dealing with GWs originating strictly from BBHs? Otherwise, will just continue marching with that assumption, per the above.
\nSo they're either really faint, or really faint and hidden in the 1-25Hz band (is that possible), or really faint and hidden in the first ~0.2s of the sample.
", "rawMarkdown": "Actually, before you do that: the Overview and Data Description sections only make mention of GW's, but say nothing about BBH/BNS. However, the [Welcome to the G2Net Gravitational Wave detection challenge](https://www.kaggle.com/c/g2net-gravitational-wave-detection/discussion/249978) post says:\n\n> We would really appreciate your help in exploring new ways to detect signals and we hope you enjoy the binary black hole challenge that we’ve set for you.\n\n@bayeswolf Would it be possible to clarify if we're dealing with GWs originating strictly from BBHs? Otherwise, will just continue marching with that assumption, per the above.\n\nSo they're either really faint, or really faint and hidden in the 1-25Hz band (is that possible), or really faint and hidden in the first ~0.2s of the sample.", "votes": null }, { "id": "1502121", "postDate": "09/03/2021 21:29:49", "content": "Hi @authman thanks a lot for your nice figures!
\nAs far as I remember, the host stated that the events are all BBH in one of the discussion threads. That said, those difficult cases are indeed all over there, but they are low SNRs BBH signals.
", "rawMarkdown": "Hi @authman thanks a lot for your nice figures! \n\nAs far as I remember, the host stated that the events are all BBH in one of the discussion threads. That said, those difficult cases are indeed all over there, but they are low SNRs BBH signals.", "votes": null }, { "id": "1502237", "postDate": "09/04/2021 03:49:24", "content": "In my case bandpass(30, 500) is always slightly worse than bandpass(30,1000), I'm wondering why bandpass(30, 500) is working for many public notebooks.
", "rawMarkdown": "In my case bandpass(30, 500) is always slightly worse than bandpass(30,1000), I'm wondering why bandpass(30, 500) is working for many public notebooks.", "votes": null }, { "id": "1503065", "postDate": "09/04/2021 23:40:08", "content": "@authman Thanks for sharing your thoughts. A little improvement maybe would be to use log scale when you plot histograms. It will let you look at low frequency regions more accurately.
", "rawMarkdown": "authman Thanks for sharing your thoughts. A little improvement maybe would be to use log scale when you plot histograms. It will let you look at low frequency regions more accurately.", "votes": null }, { "id": "1503108", "postDate": "09/05/2021 02:15:48", "content": "i wonder is there any +ve samples that actually contains GW lasting more than 2 sec given here?
\nmaybe that is why the banana shape cannot be observed?
https://www.youtube.com/watch?v=WoDCPTLgxh4&t=16s
\ne.g GW170817 lasts up to 30 sec
\nhttps://www.ligo.caltech.edu/system/avm_image_sqls/binaries/99/original/GW170817_Factsheet.jpg?1508114118
@hengck23 I was calmly waiting and that chirp at the end blasting through my headphones scared the crap out of me. Lol
\n\n\nGW lasting more than 2 sec given here? e.g GW170817 lasts up to 30 sec
\n
I doubt that is the case. No chirp or increasing frequency in a short duration would be considered as a stationary signal and even the matched filtering technique would reject it.
\nI think such scenarios are squashed within 2 secs by resampling. If that's the case, the chirp would be represented by maybe 20 data points at the very end in our data.
\nThis can easily fall under 1 bin of CQT - just a dot. and that's how we miss it?
\n\nI highly doubt the \"astrophysically motivated\" chirps or BH masses are restricted to make the chirp not more than 1 Khz. Technically using a bandpass filter (20-500Hz) would be wrong as we will miss out on chirps not only from 500Hz to 1023Hz but any aliases that fall in that frequency too.
\n
Data simulating the existing detectors won't really have much detectable signal above 500 Hz. That's not because the sources aren't emitting at those frequencies, but the detector noise is rising with increasing frequency by that point. The vast majority of the theoretically optimal signal-to-noise is accumulated below 500 Hz, so it isn't surprising that applying a bandpass would have little effect, barring issues of actually applying the filters sensibly to short data stretches (and avoiding boundary effects).
", "rawMarkdown": "> I highly doubt the \"astrophysically motivated\" chirps or BH masses are restricted to make the chirp not more than 1 Khz. Technically using a bandpass filter (20-500Hz) would be wrong as we will miss out on chirps not only from 500Hz to 1023Hz but any aliases that fall in that frequency too.\n\nData simulating the existing detectors won't really have much detectable signal above 500 Hz. That's not because the sources aren't emitting at those frequencies, but the detector noise is rising with increasing frequency by that point. The vast majority of the theoretically optimal signal-to-noise is accumulated below 500 Hz, so it isn't surprising that applying a bandpass would have little effect, barring issues of actually applying the filters sensibly to short data stretches (and avoiding boundary effects).", "votes": null }, { "id": "1507708", "postDate": "09/09/2021 13:04:24", "content": "Data from LIGO (and Virgo) are sampled at 16k and then resampled to lower sampling rate if needed. There are no aliases just because data is filtered prior to actual resampling in order to remove as much aliases as possible - in real life aliasing do not work as neatly as in your picture.
\nAs you correctly stated, LIGOs are not rated under 10Hz. It means that under 10Hz there may be anything (including dragons) and any detection there should be discarded. Almost any LIGO paper notes that noise level under 20Hz is overwhelming and for most applications band should be discarded. Sad but true.
\nFiltering works just because it makes SNR just good enough to let network latch on signal.
Hey All,
\nThank you all for taking part in our competition. The participation has been overwhelmingly positive. We are currently conducting a survey to gauge the demographic and outreach achieved. Kindly spare 2min and fill in this survey https://forms.gle/QP9L16niPexozyhu5.
\nThank you all,
\nRegards,
\nChris
Hey All,
\nThank you all for taking part in our competition. The participation has been overwhelmingly positive. We are currently conducting a survey to gauge the demographic and outreach achieved. Kindly spare 2min and fill in this survey https://forms.gle/QP9L16niPexozyhu5.
\nThank you all,
\nRegards,
\nChris
x.highpass(30)?
Anything that 'aliases' in that bucket will still get nixed.
", "votes": null, "replies": [ { "id": 1501872, "author_name": "harshpatel1692", "author_url": "", "post_date": "09/03/2021 15:55:26", "content": "Technically we shouldn't use a filter but filtering works. my question is why considering the above explanation.
\nIf the original LIGO data is filtered, it makes sense as the max frequency is 10Khz and the data is sampled at 16Khz
\nI'm getting the best score with highpass 30Hz.
", "votes": null, "replies": [] }, { "id": 1501899, "author_name": "authman", "author_url": "", "post_date": "09/03/2021 16:15:48", "content": "¯\\_(ツ)_/¯ All we know is:
This is my conjecture for why it's hard to climb LB:
\n
What does this mean? We have two fundamentally different types of signals present in the data. The easier to classify BH mergers. And the dastardly difficult to identify NS mergers. They are lower total system mass and so less energy or gws are emitted. How can we enable our models to see these? Straight BP or HP filtering is insufficient and no one has reported whitening as working yet (though maybe some top scoring teams have made it work secretly?) :)
\nTraining separate models on the hard data doesn't help. I haven't tried explicit weighting, and already mentioned focal loss failures.
", "votes": null, "replies": [] }, { "id": 1501930, "author_name": "harshpatel1692", "author_url": "", "post_date": "09/03/2021 16:47:31", "content": "\n\nthey make clear that the BP'ing is purely for illustrative / exploratory / visualization purposes; but the actual MF used @Ligo doesn't make use of it.
\n
This makes sense.
\nI thought we only had BH mergers and no NS. Gotta revisit some literature.
\nFocal loss and ArcFace didn't help me in improving the score either. ArcFace struggles to explicitly separate two classes.
\n😤
", "votes": null, "replies": [] }, { "id": 1501944, "author_name": "authman", "author_url": "", "post_date": "09/03/2021 16:55:04", "content": "Actually, before you do that: the Overview and Data Description sections only make mention of GW's, but say nothing about BBH/BNS. However, the Welcome to the G2Net Gravitational Wave detection challenge post says:
\n\n\nWe would really appreciate your help in exploring new ways to detect signals and we hope you enjoy the binary black hole challenge that we’ve set for you.
\n
@bayeswolf Would it be possible to clarify if we're dealing with GWs originating strictly from BBHs? Otherwise, will just continue marching with that assumption, per the above.
\nSo they're either really faint, or really faint and hidden in the 1-25Hz band (is that possible), or really faint and hidden in the first ~0.2s of the sample.
", "votes": null, "replies": [] }, { "id": 1502121, "author_name": "richx86", "author_url": "", "post_date": "09/03/2021 21:29:49", "content": "Hi @authman thanks a lot for your nice figures!
\nAs far as I remember, the host stated that the events are all BBH in one of the discussion threads. That said, those difficult cases are indeed all over there, but they are low SNRs BBH signals.
", "votes": null, "replies": [] }, { "id": 1503065, "author_name": "cpmpml", "author_url": "", "post_date": "09/04/2021 23:40:08", "content": "@authman Thanks for sharing your thoughts. A little improvement maybe would be to use log scale when you plot histograms. It will let you look at low frequency regions more accurately.
", "votes": null, "replies": [] }, { "id": 1503108, "author_name": "hengck23", "author_url": "", "post_date": "09/05/2021 02:15:48", "content": "i wonder is there any +ve samples that actually contains GW lasting more than 2 sec given here?
\nmaybe that is why the banana shape cannot be observed?
https://www.youtube.com/watch?v=WoDCPTLgxh4&t=16s
\ne.g GW170817 lasts up to 30 sec
\nhttps://www.ligo.caltech.edu/system/avm_image_sqls/binaries/99/original/GW170817_Factsheet.jpg?1508114118
@hengck23 I was calmly waiting and that chirp at the end blasting through my headphones scared the crap out of me. Lol
\n\n\nGW lasting more than 2 sec given here? e.g GW170817 lasts up to 30 sec
\n
I doubt that is the case. No chirp or increasing frequency in a short duration would be considered as a stationary signal and even the matched filtering technique would reject it.
\nI think such scenarios are squashed within 2 secs by resampling. If that's the case, the chirp would be represented by maybe 20 data points at the very end in our data.
\nThis can easily fall under 1 bin of CQT - just a dot. and that's how we miss it?
In my case bandpass(30, 500) is always slightly worse than bandpass(30,1000), I'm wondering why bandpass(30, 500) is working for many public notebooks.
", "votes": null, "replies": [] }, { "id": 1507191, "author_name": "alexnitz", "author_url": "", "post_date": "09/09/2021 00:18:36", "content": "\n\nI highly doubt the \"astrophysically motivated\" chirps or BH masses are restricted to make the chirp not more than 1 Khz. Technically using a bandpass filter (20-500Hz) would be wrong as we will miss out on chirps not only from 500Hz to 1023Hz but any aliases that fall in that frequency too.
\n
Data simulating the existing detectors won't really have much detectable signal above 500 Hz. That's not because the sources aren't emitting at those frequencies, but the detector noise is rising with increasing frequency by that point. The vast majority of the theoretically optimal signal-to-noise is accumulated below 500 Hz, so it isn't surprising that applying a bandpass would have little effect, barring issues of actually applying the filters sensibly to short data stretches (and avoiding boundary effects).
", "votes": null, "replies": [] }, { "id": 1507708, "author_name": "denisbsu", "author_url": "", "post_date": "09/09/2021 13:04:24", "content": "Data from LIGO (and Virgo) are sampled at 16k and then resampled to lower sampling rate if needed. There are no aliases just because data is filtered prior to actual resampling in order to remove as much aliases as possible - in real life aliasing do not work as neatly as in your picture.
\nAs you correctly stated, LIGOs are not rated under 10Hz. It means that under 10Hz there may be anything (including dragons) and any detection there should be discarded. Almost any LIGO paper notes that noise level under 20Hz is overwhelming and for most applications band should be discarded. Sad but true.
\nFiltering works just because it makes SNR just good enough to let network latch on signal.
Hey All,
\nThank you all for taking part in our competition. The participation has been overwhelmingly positive. We are currently conducting a survey to gauge the demographic and outreach achieved. Kindly spare 2min and fill in this survey https://forms.gle/QP9L16niPexozyhu5.
\nThank you all,
\nRegards,
\nChris
Hey All,
\nThank you all for taking part in our competition. The participation has been overwhelmingly positive. We are currently conducting a survey to gauge the demographic and outreach achieved. Kindly spare 2min and fill in this survey https://forms.gle/QP9L16niPexozyhu5.
\nThank you all,
\nRegards,
\nChris