Войти
ФлеймФорумНаука

Распределенные вычисления на благо науки. Boinc (34 стр)

Страницы: 131 32 33 34 35 36 Следующая »
#495
8:15, 10 окт 2021

Игры это хорошо, но сейчас целые геномы можно собрать на персональном компьютере.
14 сентября 2021 г.
Секвенирование ДНК

Исследователи из Массачусетского технологического института и Института Пастера во Франции разработали математический метод, позволяющий собирать целые геномы на персональном компьютере за считанные минуты. Это заметное достижение, поскольку стандартные методы сборки генома используют мощные и дорогие компьютеры и занимают примерно в 100 раз больше времени. «Мы можем быстро собрать целые геномы и метагеномы, включая микробные геномы, на скромном портативном компьютере», - сказала Бонни Бергер, профессор математики Саймонса в лаборатории компьютерных наук и искусственного интеллекта Массачусетского технологического института (MIT) и автор книги исследование, опубликованное в журнале Cell Systems, в заявлении для прессы.

«Эта способность важна для оценки изменений в микробиоме кишечника, связанных с болезнями и бактериальными инфекциями, такими как сепсис, чтобы мы могли быстрее вылечить их и спасти жизни». Прошло уже два десятилетия с тех пор, как был секвенирован геном человека, и с тех пор были достигнуты значительные успехи в технологии секвенирования. Однако, хотя операции секвенирования становятся длиннее и точнее, сборка целых геномов по-прежнему требует времени и требует больших ресурсов компьютера.

Графы де Брейна - один из нескольких методов, используемых биоинформатиками при сборке геномов и генетических последовательностей, особенно длинных считываний. В этом исследовании Бергер и его коллеги создали то, что они называют подходом «минимизирующего пространства де Брейна» (mdBG), который отличается от того, что используется в настоящее время, поскольку он включает короткие последовательности нуклеотидов, называемые «минимизаторы», а не отдельные нуклеотиды.

«Наши графы де Брейна в пространстве минимизатора хранят лишь небольшую часть всех нуклеотидов, сохраняя при этом общую структуру генома, что позволяет им быть на порядки более эффективными, чем классические графы де Брейна», - пояснил Бергер. Команда проверила свой метод на данных о последовательности человека и обнаружила, что он способен точно собирать геномы. Используя свой подход mdBG, они собрали геном человека менее чем за 10 минут, используя 10 ГБ оперативной памяти, что легко достижимо на обычном ноутбуке или настольном компьютере.

«Кроме того, мы построили основанное на mdBG представление 661 405 бактериальных геномов, включающее 16 миллионов узлов и 45 миллионов ребер, и успешно проверили в нем гены антимикробной устойчивости за 12 минут», - пишут авторы, показывая, насколько полезен этот метод для медицинских исследователей.

В этом исследовании использовали высокоточные чтения PacBio (коэффициент ошибок 1%), и их алгоритм в настоящее время лучше всего адаптирован для этих чтений, хотя они надеются развивать его в будущем. «Мы также можем обрабатывать данные секвенирования с коэффициентом ошибок до 4%», - добавляет Бергер. «Благодаря тому, что секвенсоры с длительным считыванием с различным уровнем ошибок быстро падают в цене, эта возможность открывает дверь к демократизации анализа данных секвенирования».

Например, сверхдлинные считывания Oxford Nanopore в настоящее время имеют уровень ошибок 5–12%, но вскоре ожидается, что он упадет до 4% или ниже. «Мы планируем обратиться к полевым ученым, чтобы помочь им разработать быстрые участки для геномного тестирования, выходящие за рамки ПЦР и наборов маркеров, которые могут упустить важные различия между геномами», - говорит Бергер.

Хотите принять участие в распределенных вычислениях, тогда, Вам сюда:
https://boinc.berkeley.edu/wiki/Simple_view
https://boinc.berkeley.edu/download_all.php
https://boinc.ru

May162013_49113423_DNASequencing_GenomicsCloserClinic_II | Распределенные вычисления на благо науки. Boinc
#496
7:09, 16 окт 2021

Расширяем "Соловья"!

Ранее сообщалось [ https://vk.com/wall-34590225_521 ] о том, что у нашего Shmya Cluster появился небольшой ARM-сегмент. Неделю назад, один из участников нашей команды прислал для него 4 одноплатных компьютера Raspberry Pi 3 Model B. Одна из "малинок" уже добавлена к двум работающим узлам (все три можно увидеть в составе Shmya Cluster в проекте SiDock@home: https://www.sidock.si/sidock/hosts_user.php?userid=6 ), но для того, чтобы добавить все, необходимо либо расширять число розеток, используемых для подключения (что увеличивает громоздкость сооружения), либо придумать для "Соловья" свою систему питания. Что и решено попробовать сделать.

В данный момент план такой:
1. Запитать вентиляторы от отдельного небольшого блока питания на 12V;
2. Сами Raspberry Pi запитать от отдельного блока на 5V.

Возможно, есть варианты и получше, но пока попробую так. Сегодня забежал в магазин за компонентами. Закуплены макетная плата, клеммники, клеммы, вилки со шнурами, провода, разъёмы для подключения вентиляторов, припой, паяльник с тонким жалом и, конечно, сами блоки питания. Попробую начать с вентиляторов. :)
Первая очередь "Соловья" переведена на свою систему питания!

После некоторого изучения того, что и как надо делать с приобретёнными ранее деталями и инструментами, сначала попробовал обеспечить питанием вентилятор (пока он один, но будет больше), затем - подключил одну из Raspberry Pi, посмотрел как будет работать в течение пары дней и, затем - подключил к этому питанию ещё 2 "малинки". То, как это происходило, можно посмотреть в фотографиях.
Следующий этап - наблюдение за работой и подключение остальных трёх RPi.
Все 6 узлов "Соловья" - в работе!

После опробования идеи на "первой очереди" из трёх Raspberry Pi, была припаяна и вторая часть проводов, стопка из узлов выросла ещё на 3 одноплатных компьютера и добавился ещё один вентилятор.
Узлы были добавлены и в SLURM, он их видит и позволяет запускать на них расчёты с использованием библиотеки MPI.

Сейчас добавленные RPi нарабатывают свои первые сотни Cobblestones вычислений в SiDock@home, а понаблюдать за ними, как обычно, можно, смотря за списком компьютеров участника Shmya Cluster [ https://www.sidock.si/sidock/hosts_user.php?userid=6 ] - это узлы на основе процессора ARM BCM2835.

Теперь им надо соорудить домик - то есть корпус. :)
Пока ещё не решил. Думаю, что либо какой-нибудь компьютерный, либо самому что-нибудь сделать. Проводов на фотографиях много, но это: провода к двум блокам питания, от БП к клеммникам на макетной плате и от макетной платы к RPi - 2 провода на контакты 5V и 2 провода - землю.
5Xfw1r7xQKU | Распределенные вычисления на благо науки. Boinc
uXancMfjE3g | Распределенные вычисления на благо науки. Boinc
rfhSzSbbU2k | Распределенные вычисления на благо науки. Boinc
4jV7wqwl1qg | Распределенные вычисления на благо науки. Boinc

#497
18:02, 25 окт 2021

2 Килобайта - не Бог весть какой размер, а жизнь SSD диску сократит в 10 раз!

О том, сколько нужно на самом деле RAM и как определять, в общем-то сказано было, без фактических данных смысла продолжать нет. Куда потратить деньги, дело, как говорится, хозяйское. 🙂

2 Килобайта - не Бог весть какой размер, а жизнь SSD диску сократит в 10 раз!

Это можно легко оценить.

Сначала про БД.

Возьмём 1 миллион WU. Им будет соответствовать 1 миллион записей в таблице workunit и 2 миллиона в таблице result, если есть кворум 2. Размер каждой записи ~ 2 кб. Итого - 3 миллиона записей по 2 кб. Во время своей жизни, result проходит несколько состояний - unsent, in progress, pending, validated и, наконец - он удаляется. Итого - 5 изменений. Для workunit-а, по идее, поменьше, но давайте считать, что тоже 5.

Далее. Как и любая приличная СУБД, MSSQL пишет данные не отдельными записями, а блоками или страницами. В MSSQL 1 страница = 8 кб, в неё поместится около 4 записей (скорее - 3, но пусть 4, возьмём вариант похуже).

Если считать что каждый раз записи меняются независимо (что вообще говоря, при создании и удалении workunit-ов и result-ов - не так, но, опять - возьмём более плохой вариант), то мы получим, что за время жизни всех 4 записей в блоке, они в худшем случае заставят перезаписать страницу, в которой они находятся, 20 раз. Ну и хорошо! Давайте считать, сколько получается:

3 миллионов записей / 4 (записи в странице) = 0.75 миллиона страниц.

0.75 миллиона страниц * 20 раз = 15 миллионов раз записи страниц

15 миллионов записей страниц * 8 кб = 120 Гбайт.

Параллельно, конечно, данные будут записываться в лог базы. Но в него будет записываться не вся страница, а только запись. Т.е. это будет 1/20 от 120 Гбайт или + 6 Гбайт. Итого: 126 Гбайт. По факту, же, т.к. генерация и удаление workunit-ов и result-ов происходит массово, то эти два процесса будут приводить к однократной, а не 20-кратной записи страницы на диск. Т.е. на самом деле не 120, а на 2/5 меньше - 72 Гбайта. Но пусть 120 и 126 в сумме.

Это, насколько я вижу, за месяц. Тогда в год будет 1512 Гб или 1.5 Тб. Сколько там ресурс самых дешёвых SSD за 4000 р (на 250 Гб)? Около 150 Tb. (Фактический, как говорят тесты, будет в разы больше). 150 Тб/1.5 Тб/год - это 100 лет. А уже через 4 года будут совсем другие диски за совсем другие цены.

Теперь вернёмся к файлам.

Файлы у нас хранятся в файловой системе. А файловая система у нас записывается кластерами (или тоже страницами, но другими). В NTFS, обычно - 4 кб. И разница между 200 байтами и 2 кбайтами будет только в том, что файл размером в 200 байт будет целиком записан прямо в заголовке в NTFS, а ради 2-х килобайтного будет осуществлена запись в таблицу файлов и в виде страницы на диск. То есть, не 1, а 2 раза по 4 кб. Посчитаем более тяжёлый вариант для того же миллиона workunit-ов:

2 записи * 4 кб * 2 миллиона результатов = 16 Гбайт.

Смотрим на упоминавшиеся 126 Гбайт и понимаем, что пока размеры результатов не выросли до мегабайт, особо печалиться не о чем. Да, есть ещё файлы XML-запросов которые сервер принимает и отправляет. Они также порядка 1 - 2 кбайт на результат. В итоге, по видимому, всё должно в самом плохом случае уложиться в 150 .. 200 Гбайт на 1 миллион workunit-ов. (Запись внутри SSD, по идее, также должна идти страницам где-то по 4 кб, кажется, поэтому этот внутренний механизм, думаю, что можно тут пропустить). Ну а если размеры файлов будут массово подрастать до мегабайта, ну, тогда складывать именно их уже на HDD. IOPS-ность SSD тут им уже не поможет.

Время надёжного хранения данных на SSD в обесточенном состоянии - порядка полугода и выше, особенно если вы не подогреваете его постоянно градусов до 60. Если есть какие-то данные, которые хотелось бы сохранить, но их можно было бы вот так вынести из системы, физически вынув диск, - то их надо просто записать на болванку Blue-Ray. 10 штук по 25 Gb стоят ~ 700 р., 25 штук по 50 Gb (двуслойные) ~ 6700 р. А SSD должен не лежать, а работать, его для этого обычно покупают. 🙂

P.S. И, да, есть у нас давно хорошая ветка про HDD и SSD.

https://boinc.ru/forum/topic/interesnoe-o-hdd-i-ssd/

P.P.S. Можно, конечно, вспомнить, что у MSSQL есть такая база как tempdb. Но... зачем OLTP-системе, коей должен быть сервер BOINC, что-то туда писать? "Обязательная отчётность", по идее, у нас только в виде XML-ов с микроскопическими user, host и team, которые должны выгружаться раз в сутки.

P.P.P.S. Когда результат засчитывается, то обновляются также и таблицы team, user, host и host_app_version.

Но: 1) Эти изменения делаются только когда результат засчитывается, а не при изменении любого состояния на любое (т.е. уже в 5 раз реже); 2) Все эти таблицы очень небольшие (team - там считанное число блоков!), должны сидеть в кэше, в каждой странице - по значительно большему набору записей и, между записью обновлённых страниц из кэша на диск, они должны обновляться по несколько раз (тут уже важно правильно настроить checkpoint-ы). И получающийся объём записываемых данных - снова не велик

#498
9:57, 31 окт 2021

Появился новый и интересный математический проект, который занимается поиском математических формул. Присоединяйтесь!

+ Показать
unnamed | Распределенные вычисления на благо науки. Boinc
#499
11:35, 31 окт 2021

SETI25
> занимается поиском математических формул
кто то формулы потерял, да?

#500
15:27, 31 окт 2021

моя формула аш два о

#501
18:06, 26 ноя 2021

Волонтеры и борьба с различными типами рака.

Волонтеры протестировали 15 триллионов подписей для проекта Mapping Cancer Markers
В этом обновлении, приуроченном к 17-й годовщине WCG, исследовательская группа суммирует вклад всех добровольцев в каждый тип опухоли и размер сигнатуры, которые были изучены картированием маркеров рака.

Проект: Картирование онкологических маркеров
https://www.worldcommunitygrid.org/research/mcm1/overview.do
Опубликовано: 16 ноя 2021

Фон

Картирование маркеров рака (MCM) направлено на выявление маркеров (иногда называемых сигнатурами), связанных с различными типами рака. Проект анализирует миллионы точек данных, собранных из тысяч образцов тканей здоровых и злокачественных пациентов. До сих пор это были ткани с раком легких, раком яичников и саркомой.

Глядя на огромный вклад волонтеров

Каждая рабочая единица Mapping Cancer Markers тестирует несколько групп биомаркеров в сравнении с набором данных рака для использования в качестве диагностических или прогностических сигнатур. В настоящее время этот набор данных является нашим набором данных о саркоме. На данный момент MCM изучил три набора данных: рак легких, рак яичников и саркома. Для рака легких и яичников MCM исследовал различную длину сигнатуры . То есть, различное количество генов, включенных в сигнатуру), в то время как для саркомы сигнатуры имеют одинаковую длину, но разный состав (т. Е. Они включают маркеры, измеренные разными методами, в различных проценты). На момент написания этого отчета волонтеры проанализировали около 800 миллионов рабочих единиц.

Рисунок 1. Количество выполненных рабочих единиц по типу рака и размеру подписи.
Рабочий блок будет проверять сигнатуры определенного размера (количество биомаркеров) по своему набору данных. В сумме участники World Community Grid протестировали около 15 триллионов подписей, число, которое было бы невозможно протестировать без вашей поддержки.
Рисунок 2. Оцененные сигнатуры по набору данных (и размеру) для всех опухолей (A) и только для рака яичников (B).

Время вычисления, необходимое для каждой подписи в любой заданной единице работы, зависит от размера подписи и набора данных. Поскольку мы стараемся поддерживать постоянный общий объем вычислений на единицу работы, количество подписей на единицу работы также будет зависеть от размера подписи и набора данных.

В большинстве наборов данных более крупные подписи требуют больше времени вычислений, чем более короткие подписи. Наш набор данных о легких обычно следует этой схеме, в то время как для нашего набора данных о яичниках верно обратное. Для набора данных о раке яичников MCM проверила прогностические признаки, которые предсказывали короткое или долгое время выживания. Эта задача была по своей сути более сложной, чем задачи диагностики легкого (рак / отсутствие рака) или саркомы (различение подтипов саркомы). Из-за этой трудности MCM не мог вычислить почти столько же сигнатур на единицу работы яичников, сколько для других наборов данных, независимо от размера сигнатуры.

Рисунок 3. Сигнатуры, оцененные на единицу работы, по набору данных (и размеру) для всех опухолей (A) и (B), особенно для рака яичников.

Нашим следующим шагом будет оценка того, как различный состав сигнатур саркомы влияет на их прогностическую способность.

Мы благодарны всем, кто поддерживает Mapping Cancer Markers, и всем важным проектам World Community Grid.

Если мы празднуем 17-ю годовщину WCG, то это только благодаря вашей преданности делу.
Спасибо!

Хотите принять участие в борьбе с Раком, тогда, Вам сюда:
https://boinc.berkeley.edu/wiki/Simple_view
https://boinc.berkeley.edu/download_all.php
https://boinc.ru
2021_11_mcm1_figure1 | Распределенные вычисления на благо науки. Boinc
2021_11_mcm1_figure2 | Распределенные вычисления на благо науки. Boinc
2021_11_mcm1_figure3 | Распределенные вычисления на благо науки. Boinc

#502
9:45, 12 дек 2021

Программное обеспечение с открытым исходным кодом от OpenPandemics - COVID-19 помогает исследователям.

Команда OPN разрабатывает инструменты с открытым исходным кодом, которые помогают улучшить прогнозы, выполняемые в WCG, и приносят пользу исследователям во всем мире.

Проект: ОпенПандемика - COVID-19
Опубликовано: 9 Дек 2021
Фон

OpenPandemics - COVID-19 был создан, чтобы помочь ускорить поиск новых кандидатов на разработку противовирусных препаратов от COVID-19. Целью проекта является идентификация малых молекул, которые связываются с белками SARS-CoV-2 с помощью вычислительного моделирования. Наиболее перспективные молекулы выбираются для тестирования в лабораториях сотрудников исследовательской группы. Молекулы с подтвержденной экспериментальной активностью станут отправной точкой для разработки потенциальных лекарств.

В настоящее время существуют две небольшие молекулы, которые были протестированы на людях для лечения COVID-19, показывающие хорошие результаты: молупиравир и ритонавир. Рост лекарственной устойчивости к существующим противовирусным препаратам, как это происходит с ВИЧ, может быть решен с помощью многочисленных, разнообразных противовирусных препаратов. Для этого наличие нескольких альтернатив для разработки различных противовирусных препаратов будет иметь решающее значение для преодоления резистентности и решения проблем, которые могут представлять новые варианты SARS-CoV2.

Инструменты с открытым исходным кодом

Исследовательская группа активно создает программное обеспечение с открытым исходным кодом, чтобы помочь другим ученым, выполняющим вычислительное моделирование для поддержки проектов по открытию лекарств. Например, новые функции, такие как гибкие остатки, модифицируемые парные потенциалы и контактный анализ, которые были добавлены в последних двух выпусках стыковочного движка AutoDock-GPU (v1.4 и v1.5), были разработаны специально для удовлетворения потребностей, возникающих во время крупномасштабного проекта, такого как OpenPandemics - COVID-19, но принесут пользу всему сообществу исследователей, использующих эти инструменты.

Эффективное разделение работы между CPU и GPU

Сложность поиска стыковки, а вместе с ней и соответствующего количества оценок, необходимых для получения хороших режимов связывания, возрастает экспоненциально с количеством вращающихся связей в каждой молекуле.

Это увеличение числа оценок менее резко для AutoDock-GPU (AD-GPU), чем для AutoDock4 (AD4) из-за лучшего алгоритма поиска (Adadelta), реализованного в AD-GPU. Как AD-GPU, так и AD4 легко стыкуют простые молекулы с небольшим количеством вращающихся связей. Однако только AD-GPU способен эффективно стыковать сложные молекулы. Таким образом, чтобы улучшить общую производительность WCG OPN, начиная с пакетов OPNG_0087175 и OPN1_0063952, молекулы с шестью или менее вращающимися связями стыкуются AutoDock4, в то время как молекулы с семью или более вращающимися связями стыкуются AutoDock-GPU. В результате улучшается общая пропускная способность, а также качество прогнозирования.

Лабораторные испытания

На момент этого обновления было заказано почти 300 соединений, и в настоящее время проводится еще один раунд отбора с целью расширения этого числа. Тестирование этих соединений продолжается в сотрудничающих лабораториях.

Для некоторых соединений продолжается дальнейшая проверка первоначальных многообещающих результатов, и команда осторожно взволнована полученными данными и работает над включением структурной информации, собранной до сих пор, чтобы информировать анализ новых результатов стыковки, полученных от добровольцев.

Хотите принять участие в распределенных вычислениях, тогда, Вам сюда:
https://boinc.berkeley.edu/wiki/Simple_view
https://boinc.berkeley.edu/download_all.php
https://boinc.ru
Ссылка на git-хаб,  где лежат исходники программы-клиента BOINC.
https://github.com/BOINC/boinc
загружено | Распределенные вычисления на благо науки. Boinc

#503
8:13, 25 дек 2021

2 миллиона – столько лет вычислений Добровольцы пожертвовали для медицинских проектов WCG

В то время как мы усердно работаем над переходом, мы хотели бы поблагодарить всех, кто сделал это возможным.

Опубликовано: 24 Дек 2021

Уважаемые волонтеры – спасибо за постоянную поддержку WCG и текущих проектов. Мы только что прошли 2 387 361 лет вычислений.

Наша команда глубоко погружена в процесс перехода, и хотя инфраструктура почти готова, все еще есть задачи, которые должны быть завершены до технического перехода в новый университет. Работа продолжится в декабре и январе.

Мы хотели бы поблагодарить IBM – партнера-основателя – за постоянную поддержку, как с техническим переходом, так и за продолжение предоставления значительных вычислительных ресурсов.

Мы также хотели бы поблагодарить Онкологический центр за пожертвование сервера и системы хранения данных для работы WCG, а также за продолжение циклов поддержки WCG. Мы благодарим Цифровой альянс Канады для поддержки работы системы, а также ШАРКНЕТ и Университет Ватерлоо для обеспечения пространства серверной комнаты и поддержки, в дополнение к обеспечению жизненно необходимых вычислительных циклов для проектов WCG. Без этой помощи переход был бы невозможен.

Спасибо всем за участие в конкурсе WVG на день рождения и раздвигая границы вычислений в день, ускоряя все текущие проекты.

WCG - это удивительный открытый научный ресурс для глобальных исследований, приносящих пользу человечеству. Соответствующие каналы социальных сетей и форумы предназначены для всех, но мы хотели бы напомнить волонтерам, чтобы они следили за нашими руководствами по коммуникации, так как любые сообщения, которые не соответствуют этим основным правилам, подлежат удалению. Участники, которые демонстрируют нетерпимость к другим участникам или нарушают работу форумов, будут заблокированы.

С праздником. Команда WCG.

Хотите принять участие в распределенных вычислениях, тогда, Вам сюда:
https://boinc.berkeley.edu/wiki/Simple_view
https://boinc.berkeley.edu/download_all.php
https://boinc.ru

Ссылка на git-хаб,  где лежат исходники программы-клиента BOINC.
https://github.com/BOINC/boinc


Intel Xeon 54 hrs Crunching Temps 1 | Распределенные вычисления на благо науки. Boinc

#504
1:09, 26 дек 2021

SETI25
> Мы только что прошли 2 387 361 лет вычислений
это с каким хешрейтом ?

#505
9:09, 26 дек 2021

Misanthrope
Он просто копипасту тулит не читая

#506
9:20, 21 янв 2022

Tonal

Неправда, я всегда прочитываю что копипащу, мне же эта тема тоже интересна...

#507
11:02, 21 янв 2022

SETI25
> мне же эта тема тоже интересна...
гос-думе тоже, скоро за подобные репосты можно будет присесть

#508
18:53, 22 янв 2022

Misanthrope

а что в них такого?

#509
17:38, 19 фев 2022

https://www.astronews.ru/cgi-bin/mng.cgi?page=news&news=20220218193424

Распределенный суперкомпьютер MilkyWay@home помог воссоздать древнюю карликовую галактику

Астрофизики впервые смогли рассчитать исходную массу и размер карликовой галактики, которая была разорвана на части в результате столкновения с нашей галактикой Млечный путь миллиарды лет назад. Реконструкция исходной карликовой галактики, звезды которой сегодня выстилают сегодня «приливный поток» в нашей Галактике, поможет ученым понять формирование галактик, подобных Млечному пути, и оценить распределение темной материи в нашей Галактике.

«Мы запустили симуляции, в которых берется этот огромный звездный поток, «отматывается» его эволюция на несколько миллиардов лет назад, и в результате смогли наблюдать, как он выглядел до того, как упал на Млечный путь, - сказала Хайди Ньюберг (Heidi Newberg), профессор физики, астрофизики и астрономии Ренсселерского политехнического института, США. – Теперь у нас есть результаты измерений, основанные на данных, и это стало первым важным шагом на пути к использованию этой информации для обнаружения темной материи в составе нашей галактики Млечный путь».

Миллиарды лет назад эта карликовая галактика и другие малые галактики в окрестностях Млечного пути были затянуты гравитацией нашей более крупной галактики. Поскольку каждая карликовая галактика сливалась с нашей Галактикой, звезды этих малых галактик были растянуты «приливными силами», аналогичными гравитационным силам, вызывающим приливы и отливы на Земле. Эти приливные силы исказили форму галактики и в конечном счете разорвали ее, в результате чего звезды галактики вытянулись в длинный «приливный поток», проходящий по Млечному пути. Такие слияния между галактиками с приливным разрывом достаточно широко распространены, и Ньюберг считает, что «звезды-иммигранты» из приливных потоков составляют большую часть звезд галактического гало, сферического «облака» из звезд, окружающего спиральные рукава центрального диска.

Изучение положений и скоростей звезд приливных потоков дает ценную информацию о гравитационном поле Млечного пути и позволяет установить распределение темной материи в нашей Галактике, отмечает автор.

Реконструкция этой карликовой галактики требовала больших вычислительных мощностей и была произведена при помощи распределенного суперкомпьютера MilkyWay@Home, созданного из множества персональных компьютеров добровольцев по всему миру.
20220218193424 | Распределенные вычисления на благо науки. Boinc

Страницы: 131 32 33 34 35 36 Следующая »
ФлеймФорумНаука