Биологический проект Налаштування

[Alien]

Как насчет сделать клиенты для громакса\намда с практическим применением в НИИ академии наук Украины?

[Sergyg]

тогда я не понял про что это
QUOTE(Rilian @ Feb 1 2010, 00:01)

Alien, как насчет обычного проекта на BOINC? Строить кластер на домашних компах, даже в пределах домосети, это будет очень нестабильно

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

[Sergyg]

...Для меня это интересно как минимум в том, чтоб и домашние пользователи присоединялись к расчетам и участвовали с нами в исследованиях.

ну, хоть в этом утверждении здесь все сходятся...

[Rilian]

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

теоретически, если можно "замедлить" обмен данными (то есть одна нода будет сама по себе считать как минимум несколько минут) и если данных при обмене меньше нескольких МБ, то на BOINC перенести можно. Если же ноды читают и пишут в другие ноды, то без изменений архитектуры не обойтись.

Alien, ну так никто и не говорит закрывать кластеры. Давайте сделаем доп проект и что-то посчитаем на BOINC, чисто для обкатки технологии

[Sergyg]

Если же ноды читают и пишут в другие ноды, то без изменений архитектуры не обойтись

Какой ты умный, Рильян! (только в последнее время что-то зачастил орфографическими ошибками описками )
Именно этот принцип (а что бывают и другие варианты ? ) моё имхо и подразумевало в работе упоминаемого кластера.

Имхо, на это косвенно указывает тот факт, что коннекта в 1Гбит оказывается недостаточно: инфайнибенд позволяет вторе повысить произв.кластера. Значит, там всё "летает" оттуда-сюда и потом снова туда, новая задача формируется на основании результатов предыдущей.

Тогда, если утверждение

без изменений архитектуры не обойтись

- верно, то , видимо, мы уже на 1 шаг ближе к цели

Це повідомлення відредагував Sergyg: Feb 1 2010, 01:36

[Alien]

Строить кластер на домашних компах, даже в пределах домосети, это будет очень нестабильно

потому что нельзя будет надеяться что определнный комп не выключат (на ночь) или не забьют канал (торрентами итд) пока он считает что-то важное

Отсылается сразу несколько одинаковых копий одного подзадания. Например кворум = 2 валидных результата. А отправляем 3. То есть даже если один из тройки компов не ответит в течение дедлайна, на сервер прийдут 2 результата. Ситуации когда не успевают 2 компьютера - меньше 1%, ситуации когда не успевают 3 компа - еще меньше.

БОИНК не подразумивает использование домашних компьютеров (ПК), в качестве ресурсов..? Или после каких моих слов я ограничился тем, что не есть BOINC?

В целом мы друг-друга поняли, если есть 10 компьютеров и они связаны в сеть и производят расчет одной задачи, в случае если один зависает или выключается вся задача виснет или сбивается (но есть чекпоинт у громакса).
Вопрос, что предлагает конкретно BOINC в решении таких непредвиденных ситуаций? Копии подзадач другим юзерам?
Я не уверен, но я думаю что перед запуском задачи необходимо знать точное число ядер, которое будет задано перед расчетом (не считая копий подзаданий).
К примеру есть задача и 3 ПК, поставили на расчет. Через 10 минут появляется еще 10 желающих, но расчет запущен, как они присоединятся? МЫсль одна, с каждым фреймом будет обновление информации о количестве доступных ядер и их участвии (заново разбиение на ячейки в фрейме, для параллелизации)..
Или отправляется какая-то тяжелая часть кода на расчет, а на сервере перед запуском указываем количество ядер, соответствующую доступности на узле.

преобразовать схему (настроенного вами и успешно работающего) кластера в схему Боинк-образных sarcastic.gif вычислений

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

[Rilian]

Вопрос, что предлагает конкретно БИОНИК в решении таких непредвиденных ситуаций? Копии подзадач другим юзерам?

Конкретно при создании пачки ВЮ (work unit) указывается сколько копий (task) будет выслано _разным_ компьютерам, а также дедлайн тасков (время сколько сервер будет ждать результат, и если не дождется - сгенерит еще один таск на основе WU) .

К примеру есть задача и 3 ПК, поставили на расчет. Через 10 минут появляется еще 10 желающих, но расчет запущен, как они присоединятся? МЫсль одна, с каждым фреймом будет обновление информации о количестве доступных ядер и их участвии (заново разбиение на ячейки в фрейме, для параллелизации)..

В BOINC "есть задача" = есть пачка WU, например 1000 штук. Если делать двойную избыточность (для того чтобы убедиться что WU посчитана правильно), то будет создано 2000 тасков. Таски рассылаются на компьютеры юзеров в порядке очереди (компы сами периодически опрашивают сервер проекта на предмет наличия новых тасков). Например компьютеров меньше чем тасков - тогда таски которые не отправлены на рассчет так и будут висеть в очереди, пока за ними не обратятся.

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

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

[Alien]

ПРичем задания из диапазона №№1001-2000 сформированы БЕЗ УЧЁТА результатов выполнения заданий №№0000-1000.
А вот при расчете ВАШИМ методом на кластере (имхо) именно нельзя приступить к серии №№1001-2000 не дождавшись предыдущих. Как раз кластер и выполняет быстренько такой обмен, когда даже при скорости соединения 1Гбит общая производительность в 3 раза падает против коннекта Инфайнибенд.
Имхо это совсем не Боинк...

ну вот я тоже так думаю, наверное в Ф.Х отправляет индивидуальные, целостные, но маленькие задачки (малая система + короткое время). Обмен данных не производится между юзерами.
Пакет отправленный каждому из юзеров должен быть индивидуальным.
Я правильно понял?

Тогда таким критериям отвечают программы с принципом работы как у Modeller и АutoDock. Тут будут десятки тысяч одноядерных независимых пакетов, для одной задачи.
У нас есть питоновский скрипт для моделлера, который может распараллелить в пределах одного узла или пк, если нужно.
Если с чего-то начинать то пока с моделлера, вроде бы он бесплатный.

Run your AutoDock Research project on World Community Grid!
by Sargis Dallakyan — Последнее изменение: 2009-02-10 16:34
Сделали вклад: Bill Bovermann

Does your research run on AutoDock? If so, you may be eligible to benefit from World Community Grid’s free computational power to accelerate your research. AutoDock has already been ”grid-enabled” by World Community Grid’s technical team and is currently being run on World Community Grid with the FightAIDS@Home project from The Scripps Research Institute and the Discover Dengue Drugs - Together project from The University of Texas Medical Branch. Please review World Community Grid’s research project criteria and contact World Community Grid if you have an idea for a project proposal or any questions.

возможно с автодоком не нужно будет создавать 2й велосипед (как предлагал Rilian), даже не знаю пока что делать в данном случае.
Если поставить задачу через WCG, будет ли это считаться украинским проектом?

[Alien]

Распределённые вычисления для чайников (F@H)
http://nnm.ru/blogs/folding/raspredelennye..._chaynikov_f_h/

блин,

Folding@home успешно смоделировал процесс свёртывания белковых молекул на протяжении 5—10 мкс

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

[Sergyg]

вроде, 1,5мс - их наивысшее достижение http://distributed.org.ua/forum/index.php?showtopic=4261

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

мы с Рилианом несколько утрировали на счет автономности и несвязности заданий. По-видимому, они все же связаны. Но как бы в единицу времени у них заготовлено и находится на РВ-просчете ОЧЕНЬ много заданий. Они ОТНОСИТЕЛЬНО автономны. Но порции заданий, рассылаемых в течение бОльшего времени (напр. 1 мес) - всё же те, что выданы на 30-м дне, имхо, зависят от результатов, полученных в начале месяца. Просто эта взаимосвязь, из природы их РВ-метода, не может (имхо) быть очень быстрой. Т.е. авторы проекта ИМХО, постепенно получают результаты одной фазы просчета (дедлайн довольно большой), затем ихний "домашний" алгоритм сгенерирует следующую порцию заданий.
Т.к. у них одновременно запущено много проектов, то пул заданий на раздачу большой. Кажется, просто огромный.

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

Вообще-то Alien - я, например, ожидал, что ты более четко сможешь описать блок-схему выполнения вашего алгоритма на кластере (вполне возможно, что это не является твоей частью работы в проекте). А то мы все только гадаем пока что и всё. Например я до сих пор не понял (вполне возможно - из-за невнимательности), на каждом узле есть винт - зачем он там нужен и каковы его характеристики. Т.е. там лежат собственно файлы исполняемого софта - это понятно. А как часто и в каком объеме туда откладываются посчитанные данные? Как долго они там хранятся? Насколько я понял - есть ещё массив дисков (отдельно), куда накопительно сливаются все данные расчетов. Или всё 100%-равномерно и равноправно распределено по узлам.
Т.е. я не перестаю удивляться, что скорость интерконнекта 1Гбит/с - была узким местом кластера. Ведь если бы работа каждого узла напоминала традиционные РВ - то каждый ЦП долго-долго считал бы задание, сохранял на винт (может, даже временные данные) и довольно небольшие по размеру данные отправлялись бы куда-то дальше. Но это ИМХО не приводило бы к росту производительности при переходе на инфайнибенд. Я думаю, здесь такое сильное распараллеливание, что "сырые данные" тоннами распределяются между нодами, т.е. даже без МЕДЛЕННОЙ записи на локальный винт. Т.е. 1Гбит/с=125Мбайт/с= скорости записи на быстрый винт (а если там можно задейстововать полный дуплекс, то вдвое больше). Но если при переходе на инфайнибенд скорость работы почти втрое выше, то это 350 Мбайт/с. Т.е. если бы данные в большей степени записывались на локальный винт (со скоростью, явно меньшей), то и не было бы так заметно влияние этого быстрого интерконнекта.

Поэтому, если товарищам всё же удается мега-задачу разрезать на мелкие куски. Наверняка у них есть план .

Це повідомлення відредагував Sergyg: Feb 5 2010, 21:47

[Death]

а как нащот http://en.wikipedia.org/wiki/CHARMM

http://en.wikipedia.org/wiki/AMBER

или ваще

http://en.wikipedia.org/wiki/List_of_softw...hanics_modeling

Major software for MD simulations

Main article: List of software for molecular mechanics modeling
Abalone (classical, implicit water)
ABINIT (DFT)
ACEMD (running on NVIDIA GPUs: heavily optimized with CUDA)
ADUN (classical, P2P database for simulations)
AMBER (classical)
Ascalaph (classical, GPU accelerated)
CASTEP (DFT)
CPMD (DFT)
CP2K (DFT)
CHARMM (classical, the pioneer in MD simulation, extensive analysis tools)
COSMOS (classical and hybrid QM/MM, quantum-mechanical atomic charges with BPT)
Desmond (classical, parallelization with up to thousands of CPU's)
Culgi (classical, OPLS-AA, Dreiding, Nerd, and TraPPE-UA force fields)
DL_POLY (classical)
ESPResSo (classical, coarse-grained, parallel, extensible)
Fireball (tight-binding DFT)
GROMACS (classical)
GROMOS (classical)
GULP (classical)
Hippo (classical)
Kalypso MD simulation of atomic collisions in solids
LAMMPS (classical, large-scale with spatial-decomposition of simulation domain for parallelism)
LPMD Las Palmeras Molecular Dynamics: flexible an modular MD.
MacroModel (classical)
MDynaMix (classical, parallel)
MOLDY (classical, parallel) latest release
Materials Studio (Forcite MD using COMPASS, Dreiding, Universal, cvff and pcff forcefields in serial or parallel, QMERA (QM+MD), ONESTEP (DFT), etc.)
MOSCITO (classical)
NAMD (classical, parallelization with up to thousands of CPU's)
NEWTON-X (ab initio, surface-hopping dynamics)
ORAC (classical)
ProtoMol (classical, extensible, includes multigrid electrostatics)
PWscf (DFT)
RedMD (coarse-grained simulations package on GNU licence)
S/PHI/nX (DFT)
SIESTA (DFT)
VASP (DFT)
TINKER (classical)
YASARA (classical)
XMD (classical)
[edit]Related software

VMD - MD simulation trajectories can be visualized and analyzed.
PyMol - Molecular Visualization software written in python
Packmol Package for building starting configurations for MD in an automated fashion
Sirius - Molecular modeling, analysis and visualization of MD trajectories
esra - Lightweight molecular modeling and analysis library (Java/Jython/Mathematica).
Molecular Workbench - Interactive molecular dynamics simulations on your desktop
BOSS - MC in OPLS
[edit]Specialized hardware for MD simulations

Anton - A specialized, massively parallel supercomputer designed to execute MD simulations.
MDGRAPE - A special purpose system built for molecular dynamics simulations, especially protein structure prediction.

вобщам главный вопрос как распараллелить большую задачу. у фолдинга это получается. а какой софт будет у боинковских клиентов уже неважно. хоть http://en.wikipedia.org/wiki/Molecular_modeling_on_GPU

[Death]

Software

The Folding@home client consists of three separate components.
The client software acts as a download and file manager for work units and scientific cores, controls the cores, and is the software that the user interacts with. Separating the client from the core enables the scientific methods to be updated automatically (or new methods to be added) without a client update.
The Work Unit is the actual data that the client is being asked to process.
The Core performs the calculations on the work unit. Folding@homes cores are based on modified versions of seven molecular simulation programs for calculation: TINKER, GROMACS, AMBER, CPMD, SHARPEN, ProtoMol and Desmond.[10][11] Where possible, optimizations are used to speed the process of calculation. There are many variations on these base simulation programs, each of which is given an arbitrary identifier (Core xx):[12]
[edit]Active Cores
GROMACS (all variants of this core use SIMD optimizations including SSE, 3DNow+ or AltiVec, where available, unless otherwise specified)
Gromacs (Core 78)
Available for all Uniprocessor clients only.
DGromacs (Core 79)
Double precision Gromacs, uses SSE2 only.
Available for all Uniprocessor clients only.
DGromacsB (Core 7b)
Nominally an update of DGromacs, but is actually based on the SMP/GPU codebases (and is therefore a completely new core). As a result, both are still in use.
Double precision Gromacs, uses SSE2 only.
Available for all Uniprocessor clients only.
DGromacsC (Core 7c)
Double precision Gromacs, uses SSE2 only.
Available on Windows and Linux Uniprocessor clients only.
GBGromacs (Core 7a)
Gromacs with the Generalized Born implicit solvent model.
Available for all Uniprocessor clients only.
Gromacs SREM (Core 80)
Gromacs Serial Replica Exchange Method.
The Gromacs Serial Replica Exchange Method core, also known as GroST (Gromacs Serial replica exchange with Temperatures), uses the Replica Exchange method (also known as REMD or Replica Exchange Molecular Dynamics) in its simulations.
Available for Windows and Linux Uniprocessor clients only.
GroSimT (Core 81)
Gromacs with Simulated Tempering.
Available for Windows and Linux Uniprocessor clients only.
Gromacs 33 (Core a0)
Uses the Gromacs 3.3 codebase.
Available for all Uniprocessor clients only.
Gro-SMP (Core a1)
Symmetric MultiProcessing variant, locked to four threads (but can be run on dual core processors).
Runs only on multi-core x86 or x64 hardware.
Available for all SMP clients only.
GroCVS (Core a2)
Symmetric MultiProcessing variant with scalable numbers of threads.
Runs only on multi-core x86 or x64 hardware, with four or more cores.
Uses the Gromacs 4.0 codebase.
Available for Linux and Mac OS X SMP clients only.


NVIDIA GPU v2.0 r1 client for Windows.
Gro-A3 core (Core a3)
SMP version of the Gromacs A4 core.
Uses threads rather than MPI for multicore support.
Available for SMP2 client only.
In open beta testing before general release.
Released January 24th, 2010.
Gro-A4 (Core a4)
A single core version of the Gromacs SMP2 core.
Available for Windows and Linux Uniprocessor clients only.
GroGPU2 (Core 11)
Graphics Processing Unit variant for ATI CAL-enabled and nVidia CUDA-enabled GPUs.
Comes in two separate versions, one each for ATI and nVidia, but both have the same Core ID.
GPUs do not support SIMD optimizations by design, so none are used in this core.
Available for GPU2 client only.
ATI-DEV (Core 12)
Graphics Processing Unit developmental core for ATI CAL-enabled GPUS.
Does not support SIMD optimizations.
Available for GPU2 client only.
NVIDIA-DEV (Core 13)
Graphics Processing Unit developmental core for nVidia CUDA-enabled GPUs.
Does not support SIMD optimizations.
Available for GPU2 client only.
GroGPU2-MT (Core 14)[13]
Graphics Processing Unit variant for nVidia CUDA-enabled GPUs.
Contains additional debugging code compared to the standard Core 11.
Does not support SIMD optimizations.
Released March 2, 2009.
Available for GPU2 client only.
Gro-PS3 (Does not have a known ID number, but also called SCEARD core)
PlayStation 3 variant.
No SIMD optimizations, uses SPE cores for optimization.
Available for PS3 client only.
AMBER
PMD (Core 82)[12]
No optimizations.
Available for Windows and Linux Uniprocessor clients only.

[Alien]

Death,
CHARMM интересно, но пока менее актуально..
AMBER, у нас есть лицензия на 9й, думаю обновим до 10го, но привязка к одному кластеру.. Опять таки мало людей у нас на нем считает.. Мы просто используем бесплатные силовые поля амбера для громакса.

Gromacs SREM (Core 80)
Gromacs Serial Replica Exchange Method.
The Gromacs Serial Replica Exchange Method core, also known as GroST (Gromacs Serial replica exchange with Temperatures), uses the Replica Exchange method (also known as REMD or Replica Exchange Molecular Dynamics) in its simulations.

помимо классики МД, мы используем еще Replica Exchange Method.
технический принцип работы таков что, создается 50 подпроектов (реплик), с разницей лишь в температуре, с шагом 2-3 градуса. К примеру задача состоит из 50 реплик с диапазоном температур от 300 К до 400 К. Каждая из реплик в процессе динамики обменивается данными. Но не все сразу, а как правило 2 из 50, в данном случае... Целью является переход структуры в другой энергетический минимум, для получения иной стабильной конформации.
Детали, если кому интересно можно будет потом рассказать..

[Alien]

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

http://www.nmr.chem.uu.nl/~tsjerk/course/molmod/md.html
Блок схема есть, но еще раз повторю, что это не имеет большого значения ибо стоит выполнить лишь один этап, одну команду.

2.1- ПП GROMACS, запуск самой МД, программой mdrun
выглядит это так

mdrun_mpi -s tyrn_md.tpr -g tyrn_md.log -o tyrn_md.trr -x tyrn_md.xtc -e tyrn_md.edr -c tyrn_md.gro -cpo tyrn_md.cpt -v  -nice 0

где tyrn_md.tpr входяхий файл, размером в пару мб, на выходе получаются файлы траекторий tyrn_md.trr (динамика всей системы, достигает 250 Гб и более, можно от него отказаться), tyrn_md.edr (файл с инфой об энергии) и tyrn_md.xtc (динамика самого белка, урезанный trr файл, занимает ~2Гб при 100 нс), tyrn_md.cpt (файл чекпоинта, хранит последние фреймы динамики)

Делать все ~12 подготовительных этапов не имеет смысла из соображений затраченного труда и времени расчета.

А то мы все только гадаем пока что и всё. Например я до сих пор не понял (вполне возможно - из-за невнимательности), на каждом узле есть винт - зачем он там нужен и каковы его характеристики. Т.е. там лежат собственно файлы исполняемого софта - это понятно. А как часто и в каком объеме туда откладываются посчитанные данные? Как долго они там хранятся? Насколько я понял - есть ещё массив дисков (отдельно), куда накопительно сливаются все данные расчетов. Или всё 100%-равномерно и равноправно распределено по узлам.

Это тоже как бы не имеет особого значения ИМХО, у нас тоже тут разные архитектуры. Более детально тут http://grid.nas.gov.ua/ (в меню Грид--Грид сайты--Города--Кластеры, вся тех. информация есть).
Обращаю внимание что в КПИ Дисковое пространство: 6Тб на базе распределенной файловой системы LustreFS.
У нас да, на каждом узле находится ЖД с ОС, сис. копии папок юзеров, мы можем переходить между узлами, но хранилище одно. Зачем узлы и переход между ними, потому что какие-то могут быть занятыми под расчет и стоит перейти для более комфортной работы (или зависнет)..

Т.е. я не перестаю удивляться, что скорость интерконнекта 1Гбит/с - была узким местом кластера. Ведь если бы работа каждого узла напоминала традиционные РВ - то каждый ЦП долго-долго считал бы задание, сохранял на винт (может, даже временные данные) и довольно небольшие по размеру данные отправлялись бы куда-то дальше. Но это ИМХО не приводило бы к росту производительности при переходе на инфайнибенд. Я думаю, здесь такое сильное распараллеливание, что "сырые данные" тоннами распределяются между нодами, т.е. даже без МЕДЛЕННОЙ записи на локальный винт. Т.е. 1Гбит/с=125Мбайт/с= скорости записи на быстрый винт (а если там можно задейстововать полный дуплекс, то вдвое больше). Но если при переходе на инфайнибенд скорость работы почти втрое выше, то это 350 Мбайт/с. Т.е. если бы данные в большей степени записывались на локальный винт (со скоростью, явно меньшей), то и не было бы так заметно влияние этого быстрого интерконнекта.

Наши 7 узлов в загрузке, при 1 Гбит есернет, загружены до 150-200 Мбит. Дело не в ширине канала, а во времени доступа в нем.
К примеру на кластере ИСМА, скорость такая же высокая как на КПИ. Есть еще ЖД для всего кластера, который предназначен для временного хранения файлов, прежде чем пойдет все на сторедж.

[Rilian]

Run your AutoDock Research project on World Community Grid!
by Sargis Dallakyan — Последнее изменение: 2009-02-10 16:34
Сделали вклад: Bill Bovermann

Does your research run on AutoDock? If so, you may be eligible to benefit from World Community Grid’s free computational power to accelerate your research. AutoDock has already been ”grid-enabled” by World Community Grid’s technical team and is currently being run on World Community Grid with the FightAIDS@Home project from The Scripps Research Institute and the Discover Dengue Drugs - Together project from The University of Texas Medical Branch. Please review World Community Grid’s research project criteria and contact World Community Grid if you have an idea for a project proposal or any questions.

возможно с автодоком не нужно будет создавать 2й велосипед (как предлагал Rilian), даже не знаю пока что делать в данном случае.
Если поставить задачу через WCG, будет ли это считаться украинским проектом?

да, будет украинский проект

WCG не заберет себе никакие результаты, конечно

[Rilian]

судя по http://www.rechenkraft.net/wiki/index.php?title=RNA_World/en исходники RNA World открыты