Мне видится в этом следующая ценность: теорфизику не преподают на многих технических специальностях, связанных с ИТ. Я уверен, что многие на хабре и слыхом не слыхивали о Лагранжиане--а так хоть заголовок увидят. А какая от этого польза? А польза от этого очень большая уже в том, что тем, кто будет рассказывать о квантовых вычислениях и гамильтониане, будет полегче. В конце концов, можно дать ссылку на эту статью. Не говоря уже о расширении кругозора и повышении культурного уровня.
Ну, формулы для Лагранжева формализма особенны тем, что из них можно вывести почти любую область современной физики (правильно задав Лагранжиан). Многие тома Ландафшица, по сути, так и начинаются--давайте посмотрим на Лагранжиан в этом разделе физики. А теорема Нетер, по моему мнению, одна из красивейших теорем математики и физики вообще.
Нет, не так. Перво-наперво, слово «частота» уже говорит нам, что без Фурье не обошлось. Если точнее, спектрограмма строится так: в звуковом сигнале через равные промежутки времени вырезаются маленькие «окна», для каждого окна строится преобразование Фурье (читай АЧХ). То есть у вас есть для каждого момента времени своя АЧХ. Вот это и есть сетка «частота-время» (для каждого момента времени дана мощность сигнала данной частоты).
Если совсем подробнее, то мощность сигнала на данной частоте (эти мощности и формируют АЧХ)--это квадрат амплитуды преобразования Фурье на данной частоте. Еще Фурье просто по окну делать нельзя, надо сглаживать сигнал у границ окна (иначе появятся паразитные частоты, которых нет в сигнале). Иногда какие-то из этих операции делают через цифровые фильтры, но они по сути являются эффективной реализацией преобразования Фурье (и изменения АЧХ: сделать прямое преобразование Фурье, изменить АЧХ, сделать обратное преобразование Фурье).
Вообще, получается, любые экспериментальные исследования, где хочется исключить влияние гравитации (сделать изотропную систему), хорошо проводить на МКС. Colloidal crystals, granular matter, всякая физическая химия, химическая физика, плазменная физика. Биологам часто интересно посмотреть на то, как организмы ведут себя в условиях микрогравитации.
Лично я знаю вот об исследованиях поведения плазмы в условиях микрогравитации. Плазма собирается в шарики, шарики липнут друг к другу и образуют «упаковки шариков», с разными интересными свойствами и сложной структурой. Такие упаковки шариков, вообще говоря, являются хорошей моделью для стекол, жидкостей, твердых тел, непосредственно используются в химической промышленности; песок, керамика, другие геологические породы являются такими упаковками--потому они интересны, важны, многи исследуются.
Вот статья для примера (именно с опытами на МКС). Вот она же на русском. Цитата: «Acknowledgments. The authors would like to thank the firm Kayser-Threde, RKK-Energia, the Mission Control Centre in Korolev and finally the Yuri Gagarin Cosmonaut Training Centre and the cosmonauts involved in the project.»
На многих суперкомпьютерах (на этом точно, номер восемь в top 500, и еще на двух поменьше, о которых я знаю) есть компиляторы только для C, C++, Fortran. Для всего остального нет. Так что пациент более чем жив, судя по всему--но в областях, отстоящих от бизнес-приложений, игр и сайтов.
Я пишу диссертацию в германии. В нашей группе в основном занимаются моделированием гидродинамики в пористых средах (и потом смотрят, как геометрия среды влияет на гидродинамические характеристики). Про гидродинамику я писал вот тут, про среды еще не писал. В качестве пористой среды мы используем упаковки твердых шариков. Лично я теперь занимаюсь свойствами таких упаковок шариков, потому что это хорошая и одновременно простая модель для жидкости, стекла, твердого тела, помимо того, что некоторые пористые среды выглядят именно так. Есть много алгоритмов создания упаковок шариков (это совсем не просто, как выяснилось), один из них проиллюстрирован в этом ролике--это моделирование молекулярной динамики упругих столкновений, притом что шарики одновременно растут. В нем-то мне и понадобился permutation.
Дело вот в чем: алгоритм лучше реализовывать как event-driven molecular dynamics, то есть не двигать шарики непрерывно, а обновлять скорости шариков после каждого столкновения. В куче как раз и хранятся все столкновения, которые нужно хранить, чтоб не пропустить столкновения. В самом простом случае можно хранить столкновения каждого шарика с каждым, но тогда вам не хватит ни памяти, ни времени вычисления. Столкновения можно выбрать специальным образом, и хранить всего N столкновений (где N--число шариков), в этом и есть основная фишка алгоритма. На каждый шарик должно приходится ближайшее для него столкновение, исключая те, что уже есть в куче (тогда мы не пропустим ни одно столкновение), то есть столкновения можно идентифицировать номером шарика.
На каждой итерации алгоритма я выбираю ближайшее столкновение (top из priority_queue). Потом пересчитываю ближайшее столкновение для данного шарика (делаю update top--можно сделать и pop-push), потом мне надо пересчитать ближайшее столкновение для второго шарика, и обновить его--и вот тут я нахожу позицию столкновения для второго шарика в очереди через permutation[topEvent.neighborID] (как я сказал, столкновения можно идентифицировать по номеру шарика), оно может быть в самом конце очереди, ведь это столкновение, ближайшее для второго шарика _без учета текущего_.
Кроме того, эти два шарика могли быть парными в столкновениях, ближайших для других шариков, а теперь перестать ими быть, или могут стать парными шариками в новых ближайших столкновениях для других шариков. Я определяю эти изменения, пока ищу ближайшие столкновения для моей столкнувшейся пары. И тогда я должен обновить события для этих измененных соседей. И индексы (в куче) событий для соседей я снова нахожу по permutation[neighborID].
Этот алгоритм (как и все алгоритмы для генерации упаковок шариков) плохо параллелится (вообще не параллелится), и может работать очень долго (если плохо реализовать--200 дней, если хорошо--2 дня, если очень хорошо--не знаю сколько, у меня работает 2 дня на конфигурации, бывшей hi-end 2 года назад). Поэтому set, пожалуй, не вариант.
Я открыл свой исходный код (правда, там не все хорошо с точки зрения C++, например, я строки передаю только by value, по аналогии с .NET, хотя часто можно как const reference, и есть некритичные баги). Вот классы для работы с модифицированной кучей: один, два, три.
Вот мне совсем недавно пришлось написать, вместо использования stl. По двум причинам:
а) Необходимо было обновлять вес элемента за логарифмическое время. В принципе, это можно реализовать поверх кучи stl, но для этого надо предполагать, что куча stl устроена как массив, представляющий дерево--а это не очень хорошо, ведь в каких-то реализациях она может быть устроена по-другому, или нумерация может быть не с начала массива, а с конца, кто знает. Мы разрушаем абстракцию, одним словом.
б) (самое важное) Мне необходимо было всегда знать permutation элементов кучи, то есть где находится элемент, бывший вначале на позиции i (в то время как обычно вы знаете только, какой элемент сейчас находится на позиции i). Кажется, я пришел к выводу, что без написания своей реализации сделать этого нельзя.
В русскоязычных странах инженеров и ученых как минимум меньше, чем во всем остальном мире + в русскоязычных странах. То, что русскоязычные инженеры не учат английский--проблемы и следствие крайней недальновидности русскоязычных инженеров. А не мои как исследователя.
По вашей логике все статьи нужно переводить на все языки мира? Чтоб бедные китайцы тоже смогли читать немецкие статьи на китайском?
Или каждая страна должна писать на своем языке? Но это очевидно очень плохо с точки зрения открытой науки и прогресса в целом. И, поверьте, русскоязычные ученые и инженеры в такой схеме только проиграют.
А разве этого мало? Ее увидят ученые и инженеры в штатах и европе, которым она может помочь (а это и есть основной смысл научной работы), они будут на нее ссылаться (и чисто формально вы улучшите свои характеристики производительности как исследователь, сможете подаваться на более крупные гранты, расширять штат, расти по должности и т.п.--больше зарабатывать и делать еще лучшие исследования).
Плюс, даже если бы заграницей понимали русский, статью бы меньше цитировали, потому что доверие к русскоязычным журналам меньше (его вообще нет, на самом деле--сейчас некоторые журналы переводятся на английский).
В Германии тоже публикуют статьи сразу на английском. Даже, вы не поверите, многие кандидатские диссертации пишутся на английском--потому что они составляются из опубликованных статей (четыре статьи--четыре главы). Делать русскоязычные научные журналы--просто вредно для и так почти мертвой российской науки.
Мне показалось, что вы кое-что переворачиваете с ног на голову. Пролезть в иностранный журнал сложнее потому, что там высокие стандарты качества, и это очень хорошо. Сроки принятия большие, потому что профильных рецензентов не так уж и много, у них много другой работы, и исправление недочетов авторами тоже занимает время.
Честно говоря, я не в курсе как профессионал, как обстоят дела с биоинформатикой в россии, но с точки зрения обывателя они обстоят плачевно, и хороших рецензентов в России совсем немного. И у вас есть два пути:
по-хорошему, вам надо бы использовать в основном западных (США, Европа и + Япония, Австралия) рецензентов. Но (а) они, скорее всего, будут часто отказываться (б) попасть в ваш журнал будет так же тяжело, а сроки публикации будут такими же большими.
либо пользоваться услугами не очень хороших рецензентов. Но тогда ценность журнала резко падает почти до нуля, и он выполняет почти чисто формальные функции быстрого способа формально публиковаться и защищаться. Что, на мой взгляд, очень плохо.
Я понимаю, что это не ваши решения, и ценности публикации на хабре не умаляет, но тем не менее.
А у меня вот какой вопрос: какая цель этого проекта? Этот журнал будет занимать какую-то особенную нишу? И, конечно, те вопросы, что выходят за рамки статьи--очень интересные :-) И еще, как вы выбирали/выбираете/ищите научного редактора (того, кто будет принимать решения о рецензентах и об окончательной публикации)?
Спасибо за статью, но вот это «Академия — это преподавание в университете» немного неправильно (в корне неправильно, мне кажется, со стороны аспиранта в германии). Академия, в первую очередь--это свои исследования. В Европе и Штатах чуть разные модели, но тем не менее.
Общее:
В обеих частях света профессор--это менеджер своей научной группы, заведует финансами, персоналам, направлением исследований. Насколько глубоко он вникает в детали, зависит от его стратегии и приоритетов: (а) он может говорить вплоть до «мне нужны вот эти и вот эти данные, померяй их, сделай вот такие картинки», писать тексты некоторых статей; (б) вычитывать статьи, направлять аспирантов; (в) иметь очень high-level overview, статьи читать только постфактум.
Отличия:
Европа (в основном я говорю о германии, где-то, наверное, по-другому):
В европе научная группа--основная структурная единица факультета. Исследования (статьи, гранты, патенты)--основной фактор карьерного роста профессора. Но, поскольку у профессоров есть экспертиза в своей предметной области, почему бы им еще и не учить студентов? Притом в Германии образование бесплатное, потому между студентами и профессорами, как я вижу, нет отношений «клиент-сервис», студенты (по крайней мере финансово)--не клиенты университета (это похоже на СССР). Мой профессор, например, всегда жалуется, когда ему надо читать лекции--ему это неинтересно и не доставляет удовольствия. Должность декана переходит между профессорами по кругу, дается на два года.
Штаты:
Не знаю насчет структурной единицы--может быть, ей тоже является научная группа. Исследования тоже являются очень важным фактором карьерного роста (и основным, пока вы аспирант и постдок). Скорее всего, у профессоров качество преподавания--еще один основной фактор. Потому что в Штатах студенты платят за обучение, там выполняется модель «клиент-сервис», и студенты--клиенты университета, клиенты профессоров. Поэтому значительные усилия необходимы для удовлетворения их требований, подготовки лекций, и т.п., и их качество влияет на ваш рост, потому что за счет преподавания университет зарабатывает деньги (впрочем, не уверен, можно ли финансировать исследования за счет этих денег). Поправьте меня, пожалуйста, если я в чем-то ошибся по поводу штатов.
P.S. Почему-то habrastorage не хотел принимать картинку, экспортированную из CorelDraw, пришлось сделать print screen и вырезать кусок экрана с картинкой. Потому без антиалиасинга, извините. Так бы она была еще красивее :-)
То, что графики часто надо перестраивать--это безусловно. Я имел в виду уже последний этап работы с ними--когда вы готовите график в статью или презентацию и точно знаете, какие данные там будут. Например, вы врядли сможете сделать сразу в матлабе
именно такую картинку.
Некоторые из сложностей: размеры разных элементов текста, размеры показателей степени (они чуть больше, чем по умолчанию, иначе плохо видно), цвет рамки легенды, подписи легенды (два столбца), расположение легенды, расположение буквы (d) и т.п. Кроме того, это часть графика из четырех таких картинок (2 по горизонтали, 2 по вертикали). В матлабе вы тоже аккуратно не настроите нужные поля между картинками, выравнивание подписей к осям (цифры и текст). Кроме того, пришлось сместить "-1" при \gamma вниз, иначе на соседнем графике с такой же подписью "-1" была слишком близка к цифре 10 выше. И т.п. Но исходная картинка с кое-какими настройками была из Матлаба, и, конечно, она перестраивалась много раз перед окончательной подготовкой.
То есть workflow такой: делаем график в Матлабе->экспортируем в eps->импортируем в Illustrator /Inkscape->наводим окончательную красоту там->экспортируем во что хотим (eps или png).
В качестве дополнения к статье (весьма полезной, между прочим) замечу, что Матлаб, в общем-то, предоставляет весьма скудные возможности по редактированию графиков. И мой коллега убедил меня использовать еще один этап подготовки--редактирование в векторном редакторе. Например, CorelDraw, Adobe Illustrator или Inkscape (последний--бесплатный, по функционалу вполне сравним с первыми двумя; что-то в нем хуже, а что-то лучше). Многие проблемы, тяжело- или вообще не-решаемые в Матлаб, можно решать уже там.
Пожалуйста!
1. про единицы измерения лучше всего почитайте ссылку из статьи, там очень хорошо написано
2. зависит от того, что у вас находится в десятках и сотнях метров. Если у вас пористая среда с микрометровым порами, то вам не хватит всей вычислительной мощности планеты Земля, нужно пользоваться другими, усредненными, моделями. А если вы моделируете ламинарный поток воздуха вокруг здания или самолета, то LBM прекрасно подойдет.
3. часто внешнюю силу, действующую на толщу жидкости, добавляют вместо того, чтоб указывать давление на входе и выходе трубы. То есть такая сила обеспечивает поток. Она может не зависеть от плотности. Формулы для добавления силы есть на википедии (после слов «The single phase discretized Boltzmann equation for mass density», формула для F чуть выше, в качестве G вы можете брать любую величину) и во многих статьях (формула 28). Второй типичный случай--добавление внешней силы, зависящей от плотности (настоящей силы тяжести). Обычно используют приближение Буссинеска. Вот тогда можно брать в статье на википедии ту G, что указана там.
4. перевод я тоже, к сожалению, не знаю, работаю на английском :-) Но relaxation time точно переводится как время релаксации.
Если совсем подробнее, то мощность сигнала на данной частоте (эти мощности и формируют АЧХ)--это квадрат амплитуды преобразования Фурье на данной частоте. Еще Фурье просто по окну делать нельзя, надо сглаживать сигнал у границ окна (иначе появятся паразитные частоты, которых нет в сигнале). Иногда какие-то из этих операции делают через цифровые фильтры, но они по сути являются эффективной реализацией преобразования Фурье (и изменения АЧХ: сделать прямое преобразование Фурье, изменить АЧХ, сделать обратное преобразование Фурье).
Вот статья для примера (именно с опытами на МКС). Вот она же на русском. Цитата: «Acknowledgments. The authors would like to thank the firm Kayser-Threde, RKK-Energia, the Mission Control Centre in Korolev and finally the Yuri Gagarin Cosmonaut Training Centre and the cosmonauts involved in the project.»
Дело вот в чем: алгоритм лучше реализовывать как event-driven molecular dynamics, то есть не двигать шарики непрерывно, а обновлять скорости шариков после каждого столкновения. В куче как раз и хранятся все столкновения, которые нужно хранить, чтоб не пропустить столкновения. В самом простом случае можно хранить столкновения каждого шарика с каждым, но тогда вам не хватит ни памяти, ни времени вычисления. Столкновения можно выбрать специальным образом, и хранить всего N столкновений (где N--число шариков), в этом и есть основная фишка алгоритма. На каждый шарик должно приходится ближайшее для него столкновение, исключая те, что уже есть в куче (тогда мы не пропустим ни одно столкновение), то есть столкновения можно идентифицировать номером шарика.
На каждой итерации алгоритма я выбираю ближайшее столкновение (top из priority_queue). Потом пересчитываю ближайшее столкновение для данного шарика (делаю update top--можно сделать и pop-push), потом мне надо пересчитать ближайшее столкновение для второго шарика, и обновить его--и вот тут я нахожу позицию столкновения для второго шарика в очереди через permutation[topEvent.neighborID] (как я сказал, столкновения можно идентифицировать по номеру шарика), оно может быть в самом конце очереди, ведь это столкновение, ближайшее для второго шарика _без учета текущего_.
Кроме того, эти два шарика могли быть парными в столкновениях, ближайших для других шариков, а теперь перестать ими быть, или могут стать парными шариками в новых ближайших столкновениях для других шариков. Я определяю эти изменения, пока ищу ближайшие столкновения для моей столкнувшейся пары. И тогда я должен обновить события для этих измененных соседей. И индексы (в куче) событий для соседей я снова нахожу по permutation[neighborID].
Этот алгоритм (как и все алгоритмы для генерации упаковок шариков) плохо параллелится (вообще не параллелится), и может работать очень долго (если плохо реализовать--200 дней, если хорошо--2 дня, если очень хорошо--не знаю сколько, у меня работает 2 дня на конфигурации, бывшей hi-end 2 года назад). Поэтому set, пожалуй, не вариант.
Я открыл свой исходный код (правда, там не все хорошо с точки зрения C++, например, я строки передаю только by value, по аналогии с .NET, хотя часто можно как const reference, и есть некритичные баги). Вот классы для работы с модифицированной кучей: один, два, три.
а) Необходимо было обновлять вес элемента за логарифмическое время. В принципе, это можно реализовать поверх кучи stl, но для этого надо предполагать, что куча stl устроена как массив, представляющий дерево--а это не очень хорошо, ведь в каких-то реализациях она может быть устроена по-другому, или нумерация может быть не с начала массива, а с конца, кто знает. Мы разрушаем абстракцию, одним словом.
б) (самое важное) Мне необходимо было всегда знать permutation элементов кучи, то есть где находится элемент, бывший вначале на позиции i (в то время как обычно вы знаете только, какой элемент сейчас находится на позиции i). Кажется, я пришел к выводу, что без написания своей реализации сделать этого нельзя.
По вашей логике все статьи нужно переводить на все языки мира? Чтоб бедные китайцы тоже смогли читать немецкие статьи на китайском?
Или каждая страна должна писать на своем языке? Но это очевидно очень плохо с точки зрения открытой науки и прогресса в целом. И, поверьте, русскоязычные ученые и инженеры в такой схеме только проиграют.
Плюс, даже если бы заграницей понимали русский, статью бы меньше цитировали, потому что доверие к русскоязычным журналам меньше (его вообще нет, на самом деле--сейчас некоторые журналы переводятся на английский).
Честно говоря, я не в курсе как профессионал, как обстоят дела с биоинформатикой в россии, но с точки зрения обывателя они обстоят плачевно, и хороших рецензентов в России совсем немного. И у вас есть два пути:
по-хорошему, вам надо бы использовать в основном западных (США, Европа и + Япония, Австралия) рецензентов. Но (а) они, скорее всего, будут часто отказываться (б) попасть в ваш журнал будет так же тяжело, а сроки публикации будут такими же большими.
либо пользоваться услугами не очень хороших рецензентов. Но тогда ценность журнала резко падает почти до нуля, и он выполняет почти чисто формальные функции быстрого способа формально публиковаться и защищаться. Что, на мой взгляд, очень плохо.
Я понимаю, что это не ваши решения, и ценности публикации на хабре не умаляет, но тем не менее.
Общее:
В обеих частях света профессор--это менеджер своей научной группы, заведует финансами, персоналам, направлением исследований. Насколько глубоко он вникает в детали, зависит от его стратегии и приоритетов: (а) он может говорить вплоть до «мне нужны вот эти и вот эти данные, померяй их, сделай вот такие картинки», писать тексты некоторых статей; (б) вычитывать статьи, направлять аспирантов; (в) иметь очень high-level overview, статьи читать только постфактум.
Отличия:
Европа (в основном я говорю о германии, где-то, наверное, по-другому):
В европе научная группа--основная структурная единица факультета. Исследования (статьи, гранты, патенты)--основной фактор карьерного роста профессора. Но, поскольку у профессоров есть экспертиза в своей предметной области, почему бы им еще и не учить студентов? Притом в Германии образование бесплатное, потому между студентами и профессорами, как я вижу, нет отношений «клиент-сервис», студенты (по крайней мере финансово)--не клиенты университета (это похоже на СССР). Мой профессор, например, всегда жалуется, когда ему надо читать лекции--ему это неинтересно и не доставляет удовольствия. Должность декана переходит между профессорами по кругу, дается на два года.
Штаты:
Не знаю насчет структурной единицы--может быть, ей тоже является научная группа. Исследования тоже являются очень важным фактором карьерного роста (и основным, пока вы аспирант и постдок). Скорее всего, у профессоров качество преподавания--еще один основной фактор. Потому что в Штатах студенты платят за обучение, там выполняется модель «клиент-сервис», и студенты--клиенты университета, клиенты профессоров. Поэтому значительные усилия необходимы для удовлетворения их требований, подготовки лекций, и т.п., и их качество влияет на ваш рост, потому что за счет преподавания университет зарабатывает деньги (впрочем, не уверен, можно ли финансировать исследования за счет этих денег). Поправьте меня, пожалуйста, если я в чем-то ошибся по поводу штатов.
1. про единицы измерения лучше всего почитайте ссылку из статьи, там очень хорошо написано
2. зависит от того, что у вас находится в десятках и сотнях метров. Если у вас пористая среда с микрометровым порами, то вам не хватит всей вычислительной мощности планеты Земля, нужно пользоваться другими, усредненными, моделями. А если вы моделируете ламинарный поток воздуха вокруг здания или самолета, то LBM прекрасно подойдет.
3. часто внешнюю силу, действующую на толщу жидкости, добавляют вместо того, чтоб указывать давление на входе и выходе трубы. То есть такая сила обеспечивает поток. Она может не зависеть от плотности. Формулы для добавления силы есть на википедии (после слов «The single phase discretized Boltzmann equation for mass density», формула для F чуть выше, в качестве G вы можете брать любую величину) и во многих статьях (формула 28). Второй типичный случай--добавление внешней силы, зависящей от плотности (настоящей силы тяжести). Обычно используют приближение Буссинеска. Вот тогда можно брать в статье на википедии ту G, что указана там.
4. перевод я тоже, к сожалению, не знаю, работаю на английском :-) Но relaxation time точно переводится как время релаксации.