Обсуждаем проект 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

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

Может машина свопится начинает, когда большое задание считается? Отсюда замедление работы --> меньше очков. Так же если клиент видит что памяти свободной маловато, задание может вставать на паузу и "ждать" пока будет достаточно памяти). Так что от доп. памяти точно хуже не будет. (это тот случай когда кашу маслом не испортишь )
Но сами вычисления от объема памяти все-таки не зависят - либо ее достаточно либо нет, промежуточных вариантов нет. Этот вопрос на форуме розетты поднимался и ответ был нет, не зависит.

Так же может еще что влиять: если камень слабый, а задания короткие (маленькое Target CPU Time выставлено) то много съедают "накладные расходы": запросить и скачать новое задание, распаковать нужные данные во временной папке(slot'e) , запустить вычисления (там вначале тоже какие-то подготовительные этапы идут), после вычислений запаковать результаты и очистить временную папку, отослать результаты на сервер.
+ во все это активно вмешивает антивирус, когда идет подготовка/завершение работы там постоянно файлы перемещаются и модифицируются, а антивирус их по 10 раз проверяет.
Так что если комп работает в режиме 24ч то желательно выставить большой Target CPU (если часто выключается/перезагружается, то нежелательно, т.к. переодические проблемы с сохранением промежуточных результатов сохраняются - переодически можно терять результаты по начатому перед перезагрузкой заданию), чтобы сократить "накладные расходы".

Добавлено спустя 10 минут 45 секунд:

Зайти в свой аккаунт(http://boinc.bakerlab.org/rosetta/home.php), в раздел "Resource share and graphics Rosetta@home preferences"
Отредактировать пункт "Target CPU run time" по своему усмотрению.
Какое значение там поставите(в часах), столько примерно клиент и будет стараться одно задание считать.
(Задания те же самые, просто он меньше/больше моделей будет считать перед тем как результаты на сервер отправлять).
3 часа - это сейчас по-умолчанию всем ставится, если вручную не выбрать другое значение.
12ч - видимо когда-то ставили на 12ч, а потом настройка сбилась на дефолтные 3ч.
Так же можно настроить кэш заданий выставив в "Computer is connected to the Internet about every" нужное значение. Например 1 день, соотв. клиент будет стараться запасать заданий, чтобы можно было считать сутки не подключаясь к интернету (сколько именно заданий в штуках зависит от времени счета 1 задания, т.е. может быть 8 по 3ч или 2 по 12ч).

Добавлено спустя 33 минуты 31 секунду:

Избыточность действительно равна 1, т.к. аглогритмы розетты основаны на вероятностном подходе, а не точных вычислениях(кроме точных изначальных данных используются еще и псевднослучайно генерируемые параметры), поэтому двух 100% индентичных результатов не бывает - сверять нечего (да и не нужно при таком подходе).
Зато каждый белок (или пару белков если моделируется взаимодействие) считают ОЧЕНЬ много раз, от десятков до сотен тысяч раз каждый (каждый такой единичный расчет называют моделью или decoys в оригинале), а потом собрав все эти decoys вмете их обрабатывают с помощью статистического анализа, по его результатам при необходимости вносят какие-то коррективы и запускают следующую пачку заданий.
В одной жабе (WU) может быть от 1 до нескольких сотен decoys (в зависимости от сложности модели, мощности процессора, времени счета), так что по любому один белок (пару белков) считает множество людей, а единичные неадекватные результаты отбрасываются при стат. обработке.

да, это очень важная новость ! Значит алгоритм уже отлажен до конца ! И начался реальный счёт для пользы науке?

Ну и судя из последнего рассказа о том, как считается Rosetta@Home можно прийти к выводу, что какое время бы не ставили, оно ни на что не повлияет (я имею ввиду не на интернет-трафик, а имею ввиду на полезность/завершенность/польза проекту)

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

Да, целевое время на научную полезность не влияет. Просто нужно сгенерить допустим 100к моделей (декоев) для протеина/пары протенинов.
Можно для этого посчитать (к примеру) 1000 жаб по 100 моделей(допустим по 12ч каждая), либо 4000 жаб по 25 моделей (по 3ч каждая). С научной точки зрения результат будет один - будет набрано 100к моделей необходимых для дальнейшей обработки (уже централизованно в лаборатории).
Разница только в объеме трафика и нагрузке на сервера.
Поэтому если интернет не безлимитный и приходится платить за трафик (или переживать - а не превысишь ли установленный лимит), то можно спокойно увеличивать время счета до нужного значения.
Так же если машина работает 24ч в сутки и при этом стабильно (ошибки расчета редки), тоже можно увеличить время, чтобы сократить "накладные расходы".
В противном случае - если часто бывают ошибки в расчетах или машина каждый день выключается/перезагружается(в этом случае высока вероятность потерять данные из заданий которое считались на момент завершения работы - чекпоинты в розетте до сих пор не очень хорошо работают), имеет смысл оставить дефолтные 3ч.

понятно. Спасибо за рассказ.

Но только есть вопрос. А как может за 3 часа например, посчитаться ровно 25 моделей (я просто привожу пример)? Ведь у всех же процессоры разные есть и постарее на 1 ГГц, и современные по 3 ГГц).

И можно ещё один вопрос. А если поставить 1 час счёту например, или 6 часов, то в этих случаях с сервера задание будет скачиваться примерно одинаковое или будет скачиваться изначально рассчитанное на столько часов, сколько задали?

Народ, подскажите, стоит ли заморачиваться с установкой розетты на домашний комп(полный оффлайн) AMD x2, который работает по 2-4 часа в сутки? (Раз в неделю таскать рез-ты на онлайновый комп и на нем же получать новые задания) Толк от всего этого будет, и много ли геморроя?

13march,так поставь. почему бы и нет?

13march
bi6a
Вообще то в Rosetta не допускается перенос заданий, да и интернет должен быть.

Ответ неверный (вероятно, путаешь с Фолдингом?). В этой же теме об этом уже говорили.

На разных CPU за одно и то же время просчитается разное кол-во моделей.

Задания одни и те же. Мог бы и сам проверить - измени время расчёта с 3-х на 24 часа и посмотри, как будут считаться задания из кэша. Кстати, на этот вопрос уже неоднократно отвечали.

13march
Я так делал. Но так как дедлайн 10 суток, то приходилось не через неделю, а через 3-4 дня сливать на сервер.

Я это и дальше про алгоритмы в новый FAQ вставлю.

Понятно.

А никто не задумывался ещё и над таким вопросом. Предположим есть компьютер, считающий непрерывно без выключения. У него самый мощный на сегодняшний день процессор Core i7-980X . Поставлено время счёта максимальное - 1 день.

А может ли при таких условиях пересчитаться абсолютно все модели, заложенные в задание?

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

2. Где именно в задание записывается настройка по времени счета (на сервере при выдаче задания или прямо в клиенте на ходу) я точно не знаю (хотя это можно проверить, только зачем?). Точно могу сказать, что объем от этого не меняется - что задание на 1 час, что на 6 часов в мегабайтах весят одинаково (в отношении даунлоада). Будет различаться только аплоад (больше или меньше готовых результатов на сервер закачивать), но аплоад в розетте небольшой.

Добавлено спустя 25 минут 15 секунд:
13march
В принципе можно. Только если время работы всего 2-4 часа в сутки (а потом выключение), лично я порекомендовал бы небольшое время счета поставить (2 часа к примеру). Разумеется если объем трафика позволяет.

anwjl
OK. Только перед переносом в FAQ тогда "причесать" не помешает - ошибки подправить, сокращения развернуть.

Yura12
Модели в задании не могут "кончиться". Как я написал выше, там есть 2 набора исходных параметров - заданные точно (они присылаются с сервера вместе с иходной моделью) и псевдослучайные - их клиент сам подбирает в процессе моделирования, а в исходном задании указаны только диапазоны, в пределах которых их можно изменять. Ну а случайных чисел можно сколько угодно сгенерировать.
Единственное установлены лимиты на максимальное количество моделей, которые клиент может вернуть в одном задании, дабы защититься от ошибок, чтобы заглючивший клиент не завалил базу данных проекта сбойными моделями.
Для обычных заданий это - 100 (сто) штук.
Для моделирования взаимодействий белок-белок - 10 000 (десять тысяч) штук
Если клиент доходит до этого лимита раньше отведенного времени, значит закончит считать раньше и отправит 100 (или 10.000) результатов.

У меня кстати было 1 задание, в котом мой комп насчитал 10.000 моделей, причем всего за 1.5 часа.
Правда потом оказалось, что это глюк, для отлова которых и был выставлен этот лимит.

Спасибо за помощь и рассказ. Теперь всё понятно.

У меня очередное обновление (на основе инфы появляющейся на английском форуме RAH)
Готовы предварительные результаты тестирования первой "пачки" переспективных кандидатов, полученных после первого "боевого" прогона алгоритма взаимодействий белок-белок. Те что наши компы считали в январе и феврале 2010.
Большинство как обычно в таких случаях оказались ложными, т.е. при испытании "в пробирке" отобранные кандитаты либо вообще не подтвердили своих свойств и/или они оказались слишком слабыми (для практического применения).
Но один из них оказался "очень перспективным", т.е. и в пробирке демонстрирует сильную способность связываться со своей целью, конкретно - с вирусами гриппа. (напомню, в качестве первых целей, на которых решили "практиковаться" были выбраны несколько штаммов вируса гриппа, "палочка Коха", вызывающая туберкулез и "инсулиноподобный фактор роста", который связан с некоторыми аномалиями развития организма и некоторыми злокачественными опухолями).
Сейчас образцы переданы на более подробное исследование, чтобы убедиться что это не случайность и не ошибка, после чего будут отправлены в другой (как я понял независимый от лабораторий RAH) иститут (Scripps research institute) для тестирования в условиях "приближенных к боевым" - на живых клетках зараженных вирусом гриппа (и далее на животных, если первая стадия будет успешной) и так же для составления "кристаллографии" (составления детальной трехмерной модели, только не расчетной на компьютере, а на основе точных физических измерений образца).
А пока основная лаборатория RAH займется следующей пачкой кандидатов (то, что наши компы считали в марте)
И для нас(кранчеров) тоже есть новенькое:
- вышла новая версия клиента (Rosetta Mini 2.10), в которую внесли какие-то изменения/улучшения в основные алгоритмы на основе анализа предыдущих результатов (в отличии от нескольких версий выходивших перед этим, которые были только баг-фиксами к 2.0)
- в очередь заданий добавлена следующая пачка жаб на расчет белок-белок, т.к. предыдущая в конца марта где-то закончилась, а для новой нужны были как раз обновленные алгоритмы. С этим как раз связано недавнее увеличение очереди заданий примерно на 1 млн. жаб.

Хотелось бы узнать на какой платформе лучше считать 32битной или 64? Процессор Атлон II х4. И есть ли разница в скорости счета между вин и линукс?

розетта сама 32битная, так что от 64бит прибавки не будет. Но вообще,64битные системы мне куда больше нравится))

Так ведь у меня на убунте розетта тоже 64 битная. Вот и хотел узнать, что всё таки лучше. Встроенный бенчмарк под 64 бит убунтой показывает больше чем под виндой хп 32бит.

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