Обсуждаем проект Rosetta@Home.
Все вопросы задавать только после прочтения
FAQ по проекту Rosetta@Home
(обновлен 05.07.2020)

официальный сайт проекта
наша команда номер 528.
скачать BOINC клиент. (Windows, OS X, Linux, Android)
"Portable" версия BOINC клиента

Новости о борьбе с COVID 19 и о проекте в целом с оф. форума за март 2020 (спасибо Lecc)
Список научных достижений за последние 5 лет от 19.01.2019 (спасибо Lecc за анализ)

Альтернативная статистика:
1) BOINCstats;
2) stats.free-dc;

Соседние темы:
[TSC!] Наши успехи в Rosetta@Home
[R@H] Догонялки
[TSC!] Разбираемся с BOINC
[TSC!] Заготовки для FAQ BOINC
[TSC!] Выбор железа для F@H и R@H

Мы в Telegram - https://t.me/TSCRussia

Не совсем. Победа весьма вероятна, но не гарантирована.
То что мы без труда держим 1е место в текущем счете, это не показатель нашей несокрушимой мощи, а больше следствие
1. Низкой популярности проекта среди основной массы BOINC кранчеров по множеству причин:
- дает мало очков относительно других проектов
- высокие требования к железу (в частности жрет очень много оперативки - по-моему по этому параметру вообще максимум из всех BOINC-проектов, любит насиловать диски кучей бессмысленных операций чтения и записи)
- высокое потребление интернет трафика (в этом плане есть и более "прожорливые" проекты, но R@H в числе лидеров)
- большое кол-во глюков в заданиях и софте (из-за его постоянного перепиливания)
- полный пофигизм программистов и админов в отношении вышеперечисленного и сбоев/глюков в серверной части
2. Концентрации нашей команды в основном на 1м этом BOINC проекте (тогда как большинство BOINC команд участвую во множестве параллельно).

А так в BOINC есть команды сильнее нашей. Просто R@H не входит в их приоритетные проекты. Но на короткий забег вполне могут и заглянуть.
Например во время предыдущего пентатлона топовые BOINC команды порядка 1 млн. очков в сутки сливали (и это без учета "бункеровки", т.к. R@H не была 1м проектом в этом составном забеге и заранее заданий насчитать не получилось бы, точнее в принципе возможно, но только в ущерб предыдущему проекту). Против наших 400-500к/сутки (если без "форсажа" и помощи временно перебрасывающих мощности из F@H).

Добавлено спустя 59 минут 2 секунды:
Ну после ведра какашек (заслуженных!) в адрес R@H и что-нибудь хорошее для контраста.
Как водится из той области, где заслуги проекта несомненных и за что его и поддерживаем активно - собственно науки.

Парочку успешных работ.
Взаимодействия белок-малая молекула.

Разработали методологию создания(разработки-моделирования) белков с целью захвата-взаимодействия не с другим белком (что уже не совсем ново - такие успешные работы были, в первую очередь тоже лабы Бейкера но парой лет раньше), а так называемыми "малыми молекулами" - относительно простыми химическими соединениями небелковой природы.
Причем речь идет о разработке "с нуля".
1 - Задается "цель" - какое-то определенное вещество, с помощью алгоритмов розетты и выч. мощности моделируется какая структура у белка должна быть, чтобы захватывать именно это вещество избирательно (т.е. активно взаимодействовать с ним, но не реагировать на любые другие).
2 - Подбирается аминокислотная последовательность - какую нужно синтезировать цепочку из аминокислот, чтобы после того как она свернется в естественных условиях она образовала белок нужной нам структуры (одна из самых сложных задач на данный момент - задача обратная фолдингу белка)
3 - Эта цепочка прогоняется через R@H, чтобы ее свернуть и смоделировать взаимодействие с целевым веществом. (это уже стандартная для розетты вещь, но этот шаг вместе с п.2 повторяется многократно, пока не будет желаемый уровень эффективности и избирательности достигнут)
4 - Найденные наиболее перспективные цепочки синтезируются в "пробирке" и проверяются в реальных условиях.

Перспективы применения широкие, например
- наборы экспресс-диагностики (ака тест-полоски) - можно создавать белки например меняющие цвет в случае наличия в крови/моче определенных веществ-маркеров свидетельствующих о том или ином заболевании. Причем в данном случае эти вещества могут быть практически любыми, а не только гормоны или ферменты(это тоже разновидности специализированных белков) как например в известных "тестах на беременность".
- контроль концентраций лекарственных средств в крови
- создание "белков-чистильщиков" - в случае отравления человека каким-либо ядом/просто вредным веществом можно создавать белки, которые будут "находить" его в организме и избирательно нейтрализовывать проводя ускоренную детоксикацию. Так же они могут быть пригодны как дополнительная терапия при вирусных/бактериальных болезнях (во многих инфекциях, человек умирает или просто мучается не от самого наличия в организме вирусов/бактерий, а от одного или нескольких веществ-токсинов выделяемых ими как побочный продукт жизнедеятельности. Тогда такой белок может помогать орагнизму, на время пока не подействуют антибиотики/противовирусное средство.

В принципе 1й разработанный по методике белок (на котором проверялась методика и описанный в статье) может уже практическое применение найти - он избирательно связывается с дигоксигенином - вещество растительного происхождения, один из сердечных гликозидов. Применяется в лечении некоторых заболеваний сердца. Проблема в том, что у него узкий диапазон эффективных доз - немного меньше, и лечение неэффективно, немного больше - получаем серьезные побочные эффекты и осложнения. Еще хуже то, что этот диапазон оптимальных доз еще и индивидуален для разных людей. В результате довольно часты случаи передозировки.
А этот белок можно использовать как антидот при таких передозировках. Но главное конечно не этот конкретный белок, а методика создания других белков данного класса с заранее заданными свойствами.

Подбробнее и с картинками (в частности 3d модель белка с захваченной молекулой есть) в блоге:
http://depts.washington.edu/ipd/one-sma ... in-design/
Ну или непосредственно научной статье (для "экстремалов" по дисциплинам "многа букав на английском" и "чтоб мне вывихнуть мозги от вашего матана". Хотя можно и просто картинки полистать ):
http://depts.washington.edu/bakerpg/dru ... tivity-pub (ссылка на PDF в конце)

Добавлено спустя 1 час 28 минут 25 секунд:
----------------------------------------------------------

И более интересное (в практическом плане) новостей.
Один из разработанных при помощи Розетты белков (правда не в самой лаборатории Бейкера, а их коллег по коллаборации Rosetta) используется как важная составная часть в новой методике лечения рака мозга!
Конкретно - http://ru.wikipedia.org/wiki/Глиобластома - не слишком распространенный вид рака (как и вообще рак мозга в целом - на 1м месте идут рак груди, легких, кишечника, желудка, костного мозга), но почти не поддающийся лечению на данный момент в отличии от многих других видов рыка (которые смертельны только при выявлении на поздних стадиях, а при обнаружении на ранних вполне излечимы): среднее время жизни (от момента обнаружения опухоли) - совсем без лечения около 4.5 месяцев, при активном лечении(химио и лучевая терапии) ~ 15 месяцев.

Сам белок был создан еще 8 (восемь!) лет назад. И вот только сейчас, спустя 8 лет, он завершает свой пусть - от расчетных моделей и научной статьи, через стадии успешных экспериментов "в пробирке", потом исследований на животных (которым пересаживают кусочки раковых опухолей человека и дают развиться, а потом пробую лечить) сейчас проходят клинические испытания на людях (50 человек на данный момент).

Причем методика весьма интересная и необычная:
1. Создается(уже создан) вирус-генной терапии(про это направление я как-то писал уже с полгода назад). Вводится направленно - уколом прямо в область опухоли. Который далее прицельно обнаруживает и инфицирует раковые клетки избирательно от здоровых. "полезная нагрузка" у этого вируса - ген, кодирующий специальное вещество разновидность цитозин-демиазы. Собственно вклад Rosetta состоял в создании этого вещества, просчета формулы соответствующего гена, необходимого для его синтеза и моделирование его взаимодействия с веществом-прекурсором . При инфицировании он внедряется в ДНК клетки.
2. Инфицированная раковая клетка начинает синтез этого вещества (сама! из вне оно не вводится, вирус переносит только инструкцию и формулу для его синтеза)
3. После значительного накопления этого вещества в раковых клетках пациенту дают другой препарат-прекурсор. Сам по себе довольно безвредный и который можно давать в больших дозах.
4. Но попадая в инфицированные клетки этот прекурсор взаимодействует с цитозин-демиазой накопленной в них, что конвертирует его в сильный препарат химиотерапии(давно известный и широко применяемый) образующийся только в "помеченных" клетках в высоких дозах и убивающий раковые клетки (дозы нужны такие, которые нельзя использовать без "наведения" прицельно на раковые клетки - иначе это убъет и большую часть здоровых и скорее всего приведет к смерти пациента). Упрощенная схема:

#77

Оригинал с доп. ссылками по теме:
http://depts.washington.edu/ipd/rosetta ... -patients/

Mad'Max Макс, спасибо за такие посты!
Здорово когда понимаешь что все не напрасно. Что мы тут не только ради очков, а помогаем хорошему делу. Хорошо стимулирует продолжать кранчить.

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

Спасибо за научные рассказы!

Я за участие, розетту довно не считал а тут появился повод.

Кстати насчет пожирания оперативки. На компах, на которых с ней не густо и по этой причине не ставите(не хотите ставить) R@H из опасений запуска ее счета во все имеющиеся потоки и съедания всей ОЗУ и последующими глюками (или как минимум жестким свопингом и неудобствами для пользователя) в новых версиях BOINC (в этом плане рекомендую v. 7.2.5) можно ограничить кол-во потоков именно для конкретного приложения (например R@H) отдельно, а не всему BOINC. Больше заданного кол-ва не будет запускаться, даже если проект перескочит в режим "приоритетной обработки".

Делается это так:
создаем файл с именем app_config.xml
такого вот содержания:
<app_config>
<app>
<name>minirosetta</name>
<max_concurrent>4</max_concurrent>
</app>
</app_config>
кладем его в папку проекта (в случае R@H это data\projects\boinc.bakerlab.org_rosetta\)
Перезапускам BOINC

Где 4 в данном примере - максимальное кол-во потоков выделяемых для счета R@H(любое целое число). Остальные будут отданы другим проектам подключенным в BOINC либо простаивать, если других проектов(или заданий для них) нет.
Это гораздо более надежный способ ограничить аппетиты R@H чем задание макс. объема используемой памяти в настройках BOINC - т.к. там мониториг работает постфактум - все-равно, сначала запускается макс. кол-во потоков (потому как при запуске в начале R@H довольно мало памяти кушает), потом когда лимит будет привышен BOINC оставливает один или несколько потоков, пытается вместо них другие задания на счет запустить (т.к. потребление ОЗУ от задания к заданию меняется, то другое вполне может в лимит вписаться), если они тоже не уложили запускает еще следующее и т.д. В т.ч. это одна из причин того, что бывает образуется множество "надкусанных" заданий - признак что выделенного объема памяти не хватает для полноценной работы выделенного кол-ва потоков.
В этом плане довольно удачная комбинация R@H+SIMAP. R@H очень много ОЗУ жрет, тогда как SIMAP наоборот самый минимум (в районе 10-15 Мб на 1 поток). В результате варьируя распределение кол-ва потоков между R@H и SIMAP можно добиться оптимального использования CPU и ОЗУ.

Mad'Max а сами доктора не поясняют, почему их приложение так любит память? Может в консерватории чего подправить?

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

Меня больше закачка таких задач добивает. Закачиваю обычно на неделю, а клиент качать быстрее, чем в 2 потока по 200 кб/с на поток не хочет почему-то, так что процесс растягивается. А учитывая, что сразу столько не выдают, приходится либо на ночь оставлять клиент, либо руками жать "обновить" раз в 10-20 минут...

правка cc_config.xml не помогает? параметры <max_file_xfers> и <max_file_xfers_per_project>

economist2000
Сервера у R@H справляются, а закачка медленная потому как расположены они в США. Так что это больше претензия к нашим интернет провайдерам и их дохлым внешним каналам через атлантику. Многопоточная закачка в данном случае должна частично помочь.

TSC!_Anti дело говорит. Правки cc_config.xml для этого хватит. Нужные опции (создать файл или добавить теги в уже существующий):
<cc_config>
<options>
<max_file_xfers>N</max_file_xfers>
<max_file_xfers_per_project>N</max_file_xfers_per_project>
</options>
</cc_config>

Где
max_file_xfers - максимальное кол-во потоков для Boinc в целом (по умолчанию = 8)
max_file_xfers_per_project - кол-во потоков на 1 проект (по умолчанию = 2)

TSC!_Anti Mad'Max
Спасибо, помогло! Поставил 8 потоков загрузки - стало веселее. Поставил 20 потоков - стало значительно веселее!

Mad'Max, может стоит файл конфигурации полностью перевести и разместить в теме Разбираемся с Boinc? Я бы взялся да у меня туго с английским Полных переводов на русский не встречал, все либо устаревшие либо неполные

Завтра с работы гляну - мож накидаю перевод и выложу. Останется оформить красиво.

Mad'Max
Спасибо за то, что постоянно подогреваешь интерес подробными выкладками и разъяснениями, ну и за общее руководство тоже спасибо.

Камрады!

Какой софтиной можно посмотреть объем записываемой в папку информации за единицу времени? Насколько это насилие велико? Может папку с BOINC на SSD кинуть, чтобы основные харды из года в год не трепал; поскольку ценность HDD исчисляется только ценой записанной на него информации, юзать Розетту на дисках со всякими мультимедийными архивами не очень хочется, тормозить работу системного харда - тоже не торт. Может, и впрямь на мелкий SSD переместить, чтобы никому не мешал и не шуршал?
Всеми любимый ProcessMonitor Руссиновича позволяет выставить любые мыслимые и немыслимые фильтры для ловли нужных процессов, но как посчитать общий объем инфы, я там не нашёл. Плохо смотрел?

Если именно запись интересует (с прицелом оценки живучести SSD) я могу просто готовые данные дать:
объем записи где-то порядка 150 Мб на 1 посчитанную жабу в среднем (диапазон где-то 135-180 Мб в зависимости от конкретного задания и выставленного времени счета). Ну а дальше уже помножить на "маштабы геноцида земноводных" (на кол-во жаб давимых за день/неделю/месяц)
При этом ускорение от SSD (или рам-диска) ОЧЕНЬ значительное. Т.к. задалбывает она диск не столько объемом данных, сколько количеством мелких файлов и операций (порядка 2500 рабочих файлов на одну жабу) от чего классическим HDD приходится плохо (особенно когда несколько жаб параллельно запускаются и головкам приходится носится туда-сюда между несколькими пампками в каждую из которых по 2500 файлов пишется)
Но и ресурс SSD довольно быстро выбирать будет...

Да, это объем записи именно самой R@H в рабочих временных папках(/slots/). Еще немного пишет BOINC (5-60 Мб на задание - при его получении и отправке результата) + возможная запись в своп если памяти немного маловато и он тоже на SSD.

Mad'Max Спасибо
Получается в районе 10GB ежедневно, причем из-за постоянного обращения к харду и отсутствия его простоя TRIM включаться не будет и скорость записи на ССД через неделю упадёт раза в два.
Ресурс-то свой при таком объеме записи он точно не выработает.

SSD - по цене получается то же самое, что докупить ещё 8 гигов оперативки для РАМ-диска, только не представляю, как быть в случае непредвиденного завершения работы? Все считающиеся жабы пропадут и все закачанные прозапас тоже; после рестарта и восстановления РАМдиска обсчёт начнётся с прошлого бэкапа

Ну простои по-идее должны быть, это при запуске жабы диск по полной долбает (в основном бесмысленной распаковкой полной рабочей базы данных в каждую рабочую папку), после запуска всех жаб на доступных потоках там буквально несколько операций раз в 5-30 минут. Да и при запуске нормальных SSD (в отличии от HDD) всего за несколько секунд активной работы (на каждую запускающуюся жабу) справится. Так что очистка "мусора" должна работать - хотя зависит от конкретного ее алгоритма (через сколько секунд/минут неактивности запускается).

Насчет RAM диска - если поизгалятся (внешними утилитами/средствами ОС, штатной возможности в самом боинк такой нет), то на РАМ-диск лучше переносить не весь BOINC и даже не его папку данных, а только папку \data\slots\ в которую кладутся текущие рабочие файлы запускающихся жаб - тогда в случае сбоев/перезагрузок компа пропадут только жабы находившиеся в процессе счета(+запущенные, а потом приостановленные). Закаченные про запас и уже полностью посчитанные(но еще не сданные на сервер) не пропадут. В этом случае для 8 потоков R@H наверное даже 2 Гб хватит, хотя желательно 3-4 Гб отдать (т.к. у BOINC бывает шиза и иногда бросает недосчитанные задания и начинает новые, а потом возвращается к недосчитанным)
У нас кто-то так уже делал. Вроде economist2000 если не путаю...

Но проще все же SSD и поставить весь BOINC туда - заморочек меньше, если помимо BOINC его никто особо записью мучать не будет то должно надолго хватить: по ~10 Гб/день = ~3.5 Тб в год (если 24х7). А у приличных SSD обычно гарантийный "пробег" порядка нескольких десятков Тб.

spider66
Бери ССД. Я тоже когда-то использовал РАМ-диски, фигня это все

Нашёл в барахле парочку бесхозных Crucial'овских v4, перекинул на один Розетту, разница ППД не более 5%, т.е. никакой.

А никакой разницы в ППД и не будет. Разница только в комфорте
Я вот думаю, может эконом вариант рассмотреть: 8Гб флешка, воткнутая сзади ПК и на нее перекинутая рабочая папка boinc...