![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
paroh posting in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
ru_crunchingМы в SETI@home полностью провакцинированы, но все еще встречаемся в Zoom. Прогресс был хорошим. Наконец-то мы генерируем пики для большинства птичек и «находим» их мультиплеты. Мы пробуем птички с меньшим увеличением, чтобы исследовать чувствительность. Вот что мы делали/думали в последнее время.
Повторное наблюдение
Если радиопроект SETI (например, SETI@home) обнаруживает что-то похожее на сигнал ET, это также может быть радиопомехи, шум, спутниковая передача или помехи изображения, вызванные аппаратным или программным обеспечением проекта. Один из способов исключить это - повторно наблюдать это местоположение на небе, предпочтительно с использованием другого телескопа и системы анализа данных, и посмотреть, обнаружите ли вы то же самое. (Это, конечно, предполагает, что передатчик ET включен в течение длительного времени.)
SETI@home, поскольку он просматривает большинство местоположений неба по несколько раз, имеет ограниченный встроенный компонент программы для повторного наблюдения. Мы используем это (в нашей функции оценки мультиплетов), чтобы отсеивать разовые аномалии. Но чтобы быть уверенным в том, что кандидат является инопланетянином, нам все равно нужно повторно наблюдать отдельно. Мы начали строить планы на это.
Система, используемая для повторного наблюдения, должна быть по крайней мере такой же чувствительной, как и исходная. Аресибо был бы в порядке, но, увы. Другой вариант - радиотелескоп FAST в Китае, и мы подаем заявку на время наблюдения там.
Алгоритм дрейфующих радиопомех
Алгоритм дрейфующих радиопомех ошибочно удалял множество птичьих всплесков (~ 30% из них). Мы исправили это и внесли некоторые другие улучшения в алгоритм:
Наблюдая за временем
Мне стало любопытно, сколько всего времени для наблюдений за Аресибо мы (симбиотически) использовали. Оказалось, что меньше, чем я думал - около 400 дней данных (на каждый луч) за 12 календарных лет, или около 9%. Это связано с тем, что использованный нами приемник ALFA - всего лишь один из нескольких приемников Arecibo, и он устанавливался только часть времени. Подробности здесь и здесь.
Некоторое время назад я обсуждал "покрытие неба, зависящее от полосы пропускания" - тот факт, что для больших длин БПФ (например, 128K выборок или ~ 13 секунд) у нас нет достаточно длинных наблюдений в некоторых пикселях, и поэтому мы эффективно покрываем меньше неба при такой пропускной способности.
Я рассчитывал это «пессимистично»: считал пиксель только в том случае, если у него был достаточно длинный интервал. То есть: вам нужно 26-секундное наблюдение, чтобы быть уверенным, что в нем содержится 13-секундный период неизвестного времени начала. Дэн указал, что если у вас есть более короткое наблюдение - скажем, 14 секунд - в нем МОЖЕТ быть случайный 13-секундный интервал. Поэтому я рассчитал покрытие неба, зависящее от полосы пропускания, исходя из этого «оптимистического» предположения. Действительно, покрытие неба больше, но при длине БПФ 128K ненамного. Результаты здесь.
Обрезка частотного диапазона
Наши существующие алгоритмы радиопомех работают вместе для всего набора обнаружений. Мы добавили новый тип отклонения радиопомех, который выполняется позже в конвейере: а именно, во время поиска мультиплетов. Это применимо только к барицентрическим мультиплетам пик/гаусса. Он основан на том факте, что барицентрические частоты обнаружений в этих мультиплетах не должны сильно различаться, но топоцентрические частоты (то есть фактическая принимаемая частота, не скорректированная доплеровским сдвигом от движения Аресибо) ДОЛЖНЫ изменяться из-за этого движения. Для радиопомех (от наземных источников) все наоборот.
Мы называем это «сокращением частотного диапазона». Что мы делаем, так это удаляем группы обнаружений, которые находятся в интервале 0,1 дня и для которых B > 2 * max (max_bw, D), где B - среднеквадратичное изменение барицентрической частоты, D - среднеквадратичное изменение частоты обнаружения, а max_bw - максимальная полоса пропускания (разрешение частоты БПФ) обнаружений. Это делается в самом конце (т.е. после обрезки с перекрытием по времени).
Разное
Я изменил нормализацию коэффициента оценки так, чтобы 25-й процентиль перешел в -1, а 75-й - в 1. Это ставит среднее значение где-то около 0, так что легче интерпретировать оценку.
Наконец, пара вещей по программированию. Я исправил крайне редкую ошибку при удалении радиопомех. Я получал «ссылку» на первый элемент в двухсторонней очереди, затем удалял элемент, а затем использовал ссылку. Это грубейшая ошибка. Как только я увидел это в отладчике, это стало очевидным, но на то, чтобы найти это, потребовалось много часов, потому что это произошло в 1 процессе из 56, примерно через 1 час при 90-минутном вычислении. Это заставило меня на короткое время пожалеть о том, что я не использовал язык, который предотвращал бы такую ошибку (C ++ - не делает так).
Кроме того, я обнаружил, что программа, которая вычисляет зоны радиопомех, дает сбой, но я не заметил этого, потому что способ, которым я запускаю конвейер Nebula (с помощью программы «make» Unix), не проверял код выхода. Итак, мы использовали растровые изображения зон 6 месяцев назад, хотя я не думаю, что это имело какое-либо значение. В любом случае, make-файл теперь проверяет все коды выхода.
на англ.
Повторное наблюдение
Если радиопроект SETI (например, SETI@home) обнаруживает что-то похожее на сигнал ET, это также может быть радиопомехи, шум, спутниковая передача или помехи изображения, вызванные аппаратным или программным обеспечением проекта. Один из способов исключить это - повторно наблюдать это местоположение на небе, предпочтительно с использованием другого телескопа и системы анализа данных, и посмотреть, обнаружите ли вы то же самое. (Это, конечно, предполагает, что передатчик ET включен в течение длительного времени.)
SETI@home, поскольку он просматривает большинство местоположений неба по несколько раз, имеет ограниченный встроенный компонент программы для повторного наблюдения. Мы используем это (в нашей функции оценки мультиплетов), чтобы отсеивать разовые аномалии. Но чтобы быть уверенным в том, что кандидат является инопланетянином, нам все равно нужно повторно наблюдать отдельно. Мы начали строить планы на это.
Система, используемая для повторного наблюдения, должна быть по крайней мере такой же чувствительной, как и исходная. Аресибо был бы в порядке, но, увы. Другой вариант - радиотелескоп FAST в Китае, и мы подаем заявку на время наблюдения там.
Алгоритм дрейфующих радиопомех
Алгоритм дрейфующих радиопомех ошибочно удалял множество птичьих всплесков (~ 30% из них). Мы исправили это и внесли некоторые другие улучшения в алгоритм:
- Понизили пороги вероятности (т.е. удаляется меньше).
- Изменили понятие «среднего» обнаружения на ячейку, чтобы оно использовало среднее значение, если медиана равна нулю. Это улучшает работу алгоритма при небольшом количестве обнаружений.
- Изменили способ измерения «энтропии» обнаружений в корзине, чтобы он работал даже при небольшом количестве обнаружений.
Наблюдая за временем
Мне стало любопытно, сколько всего времени для наблюдений за Аресибо мы (симбиотически) использовали. Оказалось, что меньше, чем я думал - около 400 дней данных (на каждый луч) за 12 календарных лет, или около 9%. Это связано с тем, что использованный нами приемник ALFA - всего лишь один из нескольких приемников Arecibo, и он устанавливался только часть времени. Подробности здесь и здесь.
Некоторое время назад я обсуждал "покрытие неба, зависящее от полосы пропускания" - тот факт, что для больших длин БПФ (например, 128K выборок или ~ 13 секунд) у нас нет достаточно длинных наблюдений в некоторых пикселях, и поэтому мы эффективно покрываем меньше неба при такой пропускной способности.
Я рассчитывал это «пессимистично»: считал пиксель только в том случае, если у него был достаточно длинный интервал. То есть: вам нужно 26-секундное наблюдение, чтобы быть уверенным, что в нем содержится 13-секундный период неизвестного времени начала. Дэн указал, что если у вас есть более короткое наблюдение - скажем, 14 секунд - в нем МОЖЕТ быть случайный 13-секундный интервал. Поэтому я рассчитал покрытие неба, зависящее от полосы пропускания, исходя из этого «оптимистического» предположения. Действительно, покрытие неба больше, но при длине БПФ 128K ненамного. Результаты здесь.
Обрезка частотного диапазона
Наши существующие алгоритмы радиопомех работают вместе для всего набора обнаружений. Мы добавили новый тип отклонения радиопомех, который выполняется позже в конвейере: а именно, во время поиска мультиплетов. Это применимо только к барицентрическим мультиплетам пик/гаусса. Он основан на том факте, что барицентрические частоты обнаружений в этих мультиплетах не должны сильно различаться, но топоцентрические частоты (то есть фактическая принимаемая частота, не скорректированная доплеровским сдвигом от движения Аресибо) ДОЛЖНЫ изменяться из-за этого движения. Для радиопомех (от наземных источников) все наоборот.
Мы называем это «сокращением частотного диапазона». Что мы делаем, так это удаляем группы обнаружений, которые находятся в интервале 0,1 дня и для которых B > 2 * max (max_bw, D), где B - среднеквадратичное изменение барицентрической частоты, D - среднеквадратичное изменение частоты обнаружения, а max_bw - максимальная полоса пропускания (разрешение частоты БПФ) обнаружений. Это делается в самом конце (т.е. после обрезки с перекрытием по времени).
Разное
Я изменил нормализацию коэффициента оценки так, чтобы 25-й процентиль перешел в -1, а 75-й - в 1. Это ставит среднее значение где-то около 0, так что легче интерпретировать оценку.
Наконец, пара вещей по программированию. Я исправил крайне редкую ошибку при удалении радиопомех. Я получал «ссылку» на первый элемент в двухсторонней очереди, затем удалял элемент, а затем использовал ссылку. Это грубейшая ошибка. Как только я увидел это в отладчике, это стало очевидным, но на то, чтобы найти это, потребовалось много часов, потому что это произошло в 1 процессе из 56, примерно через 1 час при 90-минутном вычислении. Это заставило меня на короткое время пожалеть о том, что я не использовал язык, который предотвращал бы такую ошибку (C ++ - не делает так).
Кроме того, я обнаружил, что программа, которая вычисляет зоны радиопомех, дает сбой, но я не заметил этого, потому что способ, которым я запускаю конвейер Nebula (с помощью программы «make» Unix), не проверял код выхода. Итак, мы использовали растровые изображения зон 6 месяцев назад, хотя я не думаю, что это имело какое-либо значение. В любом случае, make-файл теперь проверяет все коды выхода.
на англ.
