Лаборатория МТП

Как писать грант РФФИ

Статья основана на публикации "ГРАНТ РОССИЙСКОГО ФОНДА ФУНДАМЕНТАЛЬНЫХ ИССЛЕДОВАНИЙ (РФФИ): ЗАЯВКИ, КОНКУРСЫ, ПРОБЛЕМЫ, ПЕРСПЕКТИВЫ"
Цель данной статьи – рассказать об особенностях различных конкурсов и экспертизы проектов (заявок) с тем, чтобы помочь сделать ваши заявки более результативными. Кроме того, рекомендую прочитать ранее изданную Фондом брошюру В.Д. Смирнова «Грант РФФИ. Требования к заявке», Москва, 1998. В данной статье основной упор будет делаться на проблемы написания заявки по физико-математическим наукам.
Основной сайт, на котором можно найти побробную информацию: http://www.rfbr.ru/
Все виды грантов присуждаются Фондом на конкурсной основе, независимо от ученого звания, ученой степени, места работы, должности и возраста ученого. Фонд ежегодно организует следующие конкурсы:

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

Каждый учёный может одновременно участвовать в нескольких видах конкурсов. Но в качестве руководителя (за исключением конкурса на организацию и проведение научных мероприятий) учёный имеет право подать только одну заявку. В конкурсах инициативных (в том числе региональных) проектов руководитель проекта может участвовать в качестве исполнителя ещё только в одном проекте.
Информация о сроках и правилах проведения конкурсов публикуется в газете “ПОИСК” ежегодно в мае – июне, а также отдельными объявлениями в течение года и содержится на сайтах http//:www.rfbr.ru. или http://grant.rfbr.ru На этих же сайтах – полная информация о структуре Фонда, включая телефоны отделов. Там же – текст этой брошюры.
Почтовый адрес РФФИ: 119991, Москва В-334 ГСП-1, Ленинский проспект, 32а.
Телефон для справок: (495) 938-5532.
Теперь основные правила:

  1. Объём гранта, не предусматривает покрытия всех расходов, связанных с реализацией заявленного проекта, и предполагает проведение работ в научном учреждении, которое обеспечивает как частичное финансирование этих работ, так и возможность использования оборудования, лабораторных помещений и т.п.РФФИ предусматривает использование до 15 % выделяемых сумм в форме накладных расходов, взимаемых с гранта организацией, в которой выполняется работа.
  2. РФФИ заключает с администрацией организации, где выполняется исследование, соглашение, строго регламентирующее финансовые взаимоотношения Фонда, института и грантодержате-ля.
  3. Грант РФФИ предоставляется на безвозмездной основе и не предусматривает вмешательства Фонда в работу над проектом. Фонд не претендует также на право интеллектуальной и матери-альной собственности исследователя на результаты его научной работы
  4. РФФИ не только допускает, но приветствует наличие у заявителя грантов других организаций по предложенной теме, так что заявка обязательно должна содержать эти сведения. Но заявка в РФФИ по каждому из видов конкурса (за исключением конкурса по организации и проведению научных мероприятий) у Вас может быть только одна.
  5. Срок выполнения инициативного научного проекта – 1, 2 или 3 года – определяется заявите-лем и не может быть увеличен в дальнейшем
  6. Финансирование проекта реализуется через указанную Вами организацию в соответствии с заключенным соглашением. В Уставе организации, через которую Вы намерены финансироваться, должна быть указана научная деятельность.
  7. Число исполнителей проекта не должно превышать 10 человек

Успех заявки на 50% определяется её руководителем. Руководитель проекта – основной субъект взаимодействия с Фондом. Он (руководитель) по своему усмотрению расходует средства гранта, корректирует, при необходимости, программу ис-следований, определяет и меняет состав исполнителей и даже сохраняет за собой грант (соблюдая определённые правила) при переходе на другое место работы. Необходимо чтобы у руководителя было 5-6 статей по заявленной теме в журналах ВАК. Также желательны публикации в цитируемых иностранных журналах. Рейтинг журналов можно посмотреть тут (http://www.scopus.com/).

Название работы должно отражать ее существо. В общении с серьезными учеными нужна не пустозвонная реклама, а уверенная, чёткая и обоснованная формулировка фундаментальной научной задачи, которая сразу внушит эксперту ощущение общения с грамотным и серьезным исследователем. Просмотрите последний “Бюллетень РФФИ”, в котором перечислены поддержанные проекты, это убедит Вас в возможности дать краткое, но привлекающее к себе внимание название любой сложной работе.
Краткая аннотация. Это существенная часть Вашего успеха. Она должна позволить экс-перту представить себе научную проблему, которой посвящен проект, Ваш подход и план ее ре-шения, основные направления экспериментальной работы и возможные выводы. Особенно важно, чтобы в этой части проекта была представлена авторская гипотеза. Здесь же уместно сказать о том, какие предварительные результаты Вами уже получены. В общем, убедить рецензента в том, что Вы можете не только сформулировать проблему, но и знаете путь к ее решению и уже идете по этому пути. Так как аннотация должна быть краткой, ее уместнее писать в последнюю очередь, когда составлен уже весь проект и Вы многократно продумали все формулировки.
Содержание проекта. По этому разделу вряд ли уместно давать какие-то советы. Если Вас затрудняет написание именно этого раздела, не обращайтесь в РФФИ, Ваш проект поддержки не получит. Но если Вы пишете этот раздел с удовольствием, явно представляя себе, что, как и для чего Вы можете сделать, обратите внимание на следующее:
Конкретная фундаментальная задача в рамках проблемы, на решение которой на-правлен проект. Фундаментальная задача - увидеть, какие принципы, какой механизм лежит в основе этих изменений. В описании стремитесь к максимальной точности. Из инструкции Национального института здо-ровья США (NIH): “Рецензенты во многих случаях рассматривают краткость и ясность изложения как показатели сконцентрированного подхода руководителя программы к задачам исследования и его способности достичь конкретных целей проекта”.
Предлагаемые методы и подходы. Здесь важен весь план работы. И возможные его варианты, зависящие от полученных результатов. Эксперимент - не самоцель. Цель - подтверждение Вашей гипотезы. Планирование эксперимента в фундаментальном исследовании (и это характерная черта фундаментальной работы) - это, прежде всего планирование получения од-нозначного ответа на поставленный вопрос. Поэтому методы должны соответствовать задаче, а будут эти методы ультрасовременными или давно известными - вопрос второстепенный.
Современное состояние исследований... Имеющийся у коллектива научный задел.... Не экономьте на этих пунктах. Никогда не предполагайте, что рецензент “поймет, что Вы имели в ви-ду”. Дайте развернутую картину, приведя ссылки на наиболее важные зарубежные и отечественные, в том числе и Ваши собственные, публикации по проблеме. Если у эксперта складывается впечатление, что Вы недостаточно знаете литературу по исследуемой теме, - это смерть Вашего проекта. Будьте объективны: не игнорируйте хороших работ, даже если они противоречат Вашей концепции. Рецензент-то эти работы обязательно знает и такое замалчивание не только бросит тень на Вашу объективность, но и может подтолкнуть эксперта к “разгромной” рецензии. Наобо-рот, воспользуйтесь случаем доказать неправоту Ваших оппонентов, показать, как могут быть преодолены разногласия, какие эксперименты выявят истину. В то же время умейте отобрать не-обходимый материал, не стремитесь “излить” все, что Вам известно, только для того, чтобы про-извести впечатление на эксперта. Многословие не убеждает, а раздражает. И главное - выявите тенденции развития исследований, основные направления. Тогда станет особенно ясно, насколько необходимо развитие предложенного Вами подхода, важность вклада Вашего исследования в со-поставлении с уже выполненными. По сути, эксперт принимает решение именно при чтении этих разделов. И его вывод должен быть не вялым “Можно попробовать”, но абсолютно катего-ричным “Этого нельзя не поддержать..., именно этого подхода мы ждали ..., автор нашел одно-значное решение ...”.
Список основных публикаций коллектива. Не перегружайте этот список. Странно было бы ожидать, что по этой теме у Вас уже есть десятки публикаций, но показать, что Вы уже прошли стадию первоначального вживания в проблему, обладаете высокой квалификацией и собственным мнением - очень важно. Ни в коем случае не приводите слабые работы в не рецензируемых изда-ниях (у Вас вообще нет слабых работ!), институтских сборниках, локальных конференциях и т. п., всеядность снижает Ваш авторитет в глазах эксперта.
Список основных публикаций руководителя. Это - чисто квалификационный вопрос. Эксперту важно видеть, что Вы - глубокий исследователь, даже если у Вас еще нет серьезных публикаций именно по предложенной теме.
Перечень оборудования и материалов. Как уже говорилось, Фонд не может обеспечить Вас всем необходимым для выполнения ра-боты. Поэтому чем больше оборудования и реактивов Вы уже имеете (или можете привлечь для работы с помощью коллег и администрации института), тем выше Ваши шансы на поддержку. Задача Фонда - помощь в развитии научных исследований.
Общий объем финансирования. В случае поддержки проекта мы заключаем соглашение с учреждением, через которое финансируется про-ект, и в этом документе указываем сумму, которая будет переведена грантодержателю в течение календарного года.

Статья разработана на основе: "ГРАНТ РОССИЙСКОГО ФОНДА ФУНДАМЕНТАЛЬНЫХ ИССЛЕДОВАНИЙ (РФФИ): ЗАЯВКИ, КОНКУРСЫ, ПРОБЛЕМЫ, ПЕРСПЕКТИВЫ"

Сайты с математическими алгоритмами

Современный специалист по научно-ориентированному программному обеспечению должен программировать в разных средах с использованием разных библиотек (C++, STL, IPP, OpenCV, boost, MFC, Matlab и другие), владеть современным методиками разработки ПО, хорошо представлять себе специфику разработки ПО для систем реального времени, быть фанатом написания правильного, модулярного объектно-ориентированного кода и при этом работать быстро и без ошибок, в том числе на разнопрофильных проектах и проектах с большой загрузкой. Данная статья посвящена обзору российских и иностранных сайтов, где можно найти примеры алгоритмизации и программирования различных технологических процессов.
Рассматриваются математические методы в следующих областях:

  • обработка изображений
  • сегментация видео, распознавание объектов
  • трехмерная реконструкция сцен
  • обработка аудиозаписей
  • криптография
  • лингвистический анализ
  • оптимизация алгоритмов для встроенных (embedded) систем и систем реального времени

Сергей Лукин

(статья не завершена)
Вопросы и комментарии сюда: serg@imech.anrb.ru

Виды систем контроля версий

Содержание

  1. Общие сведения
  2. Subversion
  3. Google.com
  4. Trac
  5. Redmine
  6. Mantis
  7. Mercurial
  8. XPlanner
  9. Cogito
  10. StGit
  11. Bazaar
  12. Darcs
  13. Ohloh.net
  14. Git
  15. Сводная таблица

Общие сведения

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

Subversion

(ранняя версия: CVS, другое название: SVN)
Свободно распространяемая централизованная система управления версиями. Создана в 2000 г. компанией CollabNet Inc.
Subversion разработана специально для замены устаревшей системы CVS, распространённой открытой системы управления версиями. Используется многими сообществами разработчиков открытого программного обеспечения. В их числе такие известные проекты, как Apache, KDE, GCC, Free Pascal, Python, Ruby, Mono, FreeBSD. Хостинг Subversion для проектов с открытым кодом предоставляют SourceForge.net и Tigris.org. Subversion используется в системах Google Code и BountySource. Также Subversion широко используется в корпоративной сфере. В 2007 году независимая компания Forrester Research, сравнивая преимущества и недостатки различных систем, оценила Subversion как «единоличного лидера в категории Standalone Software Configuration Management (SCM) и сильного участника в категории Software Configuration and Change Management (SCCM)».

Subversion — централизованная система (в отличие от распределённых систем, таких, как Git или Mercurial), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере. Работа в Subversion мало отличается от работы в других централизованных системах управления версиями. Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и фиксируют эти изменения в хранилище. Несколько клиентов могут одновременно обращаться к хранилищу. Для совместной работы над файлами в Subversion преимущественно используется модель Копирование-Изменение-Слияние. Кроме того, для файлов, не допускающих слияние (различные бинарные форматы файлов), можно использовать модель Блокирование-Изменение-Разблокирование.

При сохранении новых версий используется дельта-компрессия: система находит отличия новой версии от предыдущей и записывает только их, избегая дублирования данных.
При использовании доступа с помощью WebDAV также поддерживается прозрачное управление версиями — если любой клиент WebDAV открывает для записи и затем сохраняет файл, хранящийся на сетевом ресурсе, то автоматически создаётся новая версия.

Возможности

* Реализовано большинство возможностей CVS.
* Отслеживается история файлов, директорий и метаданных файлов и директорий, в том числе при переименовании и копировании.
* Атомарная фиксация изменений.
* Возможность организации доступа к хранилищу Subversion через Apache по протоколу WebDAV/DeltaV.
* Возможность установки автономного сервера Subversion с доступом по собственному протоколу.
* «Дешёвые» операции создания ветвей и меток (требуется небольшое фиксированное количество временных и дисковых ресурсов).
* Многоуровневая архитектура библиотек, изначально рассчитанная на клиент-серверную модель.
* Клиент-серверный протокол разработан для пересылки по сети только разницы между объектами, когда это возможно.
* Затраты ресурсов пропорциональны размеру изменений, а не размеру данных, которые затронуты изменениями.
* Два возможных внутренних формата хранилища (англ. repository): база данных или набор обычных файлов.
* Версионированные символьные ссылки (только в рабочих копиях под UNIX-системами).
* Одинаково эффективная работа и с текстовыми, и с двоичными файлами.
* Вывод клиента командной строки одинаково удобен и для чтения, и для разбора программами.
* Интернационализированные сообщения программы.
* Библиотеки для языков PHP, Python, Perl, Java. Позволяют встроить функциональность клиента Subversion в программы, написанные на этих языках.
* Возможность зеркалирования хранилища.

Недостатки

Subversion не всегда может правильно обработать операции переименования файлов, если одновременно с переименованием изменяется и содержимое файла. Проблемы могут также возникнуть, если файл, переименованный в локальной копии, кто-то другой изменил в хранилище. Часть этих проблем исправлена в версии 1.5, однако это решение пока не полное.
Также слабым местом Subversion считают операции слияния веток. До версии 1.5 все такие операции пользователям приходилось отслеживать вручную, с помощью подробных записей в журнале изменений. В текущей версии появилась базовая поддержка автоматического отслеживания слияний, которую разработчики планируют улучшить в последующих релизах.
Информация, однажды помещённая в хранилище Subversion, остаётся там навсегда: файл можно удалить в текущей ревизии, но всегда есть возможность получить из хранилища одну из предыдущих ревизий, в которых файл существовал. Хотя сохранность прошлых ревизий и является, собственно, целью использования систем управления версиями, иногда бывает необходимо полностью удалить из хранилища информацию, попавшую туда по ошибке. В Subversion не предусмотрено для этого никакого штатного способа; единственная возможность заключается в создании дампа хранилища, его редактировании (это текстовый файл) и последующем восстановлении хранилища из дампа. Существуют сторонние программы для автоматизации этого процесса, но, в любом случае, для выполнения этой операции требуется временное прекращение доступа к хранилищу и вмешательство администратора с привилегиями, достаточно высокими для того, чтобы полностью стереть старое хранилище и заменить его новым.

Google.com

Trac

Trac является открытым программным обеспечением, разработанным и поддерживаемым компанией Edgewall Software (не путать с TrackStudio Enterprise и Track+, другими системами аналогичного назначения).

Trac использует минималистичный веб-интерфейс, основанный на технологии wiki, и позволяет организовать перекрёстные гиперссылки между базой данных зарегистрированных ошибок, системой управления версиями и wiki-страницами. Это даёт возможность использовать Trac в том числе и как веб-интерфейс для доступа к системе контроля версий subversion, а так же, через плагины, к Mercurial, git, Bazaar и другим.

Trac написан на языке программирования python и в настоящее время распространяется по модифицированной лицензии BSD. В качестве системы HTML шаблонов веб-интерфейса Trac до версии 0.11 использовал ClearSilver. Новые версии, начиная с 0.11, используют разработанную в Edgewall систему шаблонов Genshi, при этом совместимость с плагинами, использующими ClearSilver, будет оставлена еще в течение нескольких версий.

Redmine

Открытое серверное веб-приложение для управления проектами и отслеживания ошибок. Включает в себя календарь-планировщик и диаграммы Ганта для визуального представления хода работ по проекту и сроков. Redmine написан на Ruby представляет собой приложение на основе широко известного веб-фреймворка Ruby on Rails, что подразумевает под собой легкость в развертывании системы и в доработке под конкретные требования. Для каждого проекта можно вести свою вики и форумы.

Возможности

* Ведение нескольких проектов
* Гибкая система доступа, основанная на ролях
* Система отслеживания ошибок
* Диаграммы Ганта и календарь
* Ведение новостей проекта, документов и управление файлами
* Оповещение об изменениях с помощью RSS-потоков и email
* Wiki для каждого проекта
* Форумы для каждого проекта
* Учет временных затрат
* Настраиваемые произвольные (custom)поля для инцидентов (issues), временных затрат (time-entries), проектов и пользователей
* Легкая интеграция с репозиториями (SVN, CVS, Git, Mercurial, Bazaar и Darcs)
* Создание записей об ошибках на основе полученных писем
* Поддержка множественной LDAP аутентификации
* Возможность саморегистрации новых пользователей
* Многоязычный интерфейс (русский в том числе)
* Поддерживаются СУБД: MySQL, PostgreSQL, SQLite.

Mantis

Cвободно распространяемая система отслеживания ошибок в программных продуктах (bugtracker). Обеспечивает взаимодействие разработчиков с пользователями (тестировщиками). Позволяет пользователям заводить сообщения об ошибках и отслеживать дальнейший процесс работы над ними со стороны разработчиков.

Система имеет гибкие возможности конфигурирования, что позволяет настраивать её не только для работы над программными продуктами, но и в качестве системы учёта заявок для Helpdesk. Является веб-приложением, поэтому не требует для работы специального ПО и работает через веб-браузер.

Плюсы

* Бесплатность
* Возможность работать сразу, почти без настройки
* Код на PHP свободно модифицируем
* Понятно написанный код
* Цветовая индикация по статусу бага
* Настраиваемые пользователем поля
* Удобные фильтры
* Скорость работы
* Уведомления по e-mail
* Большое количество плагинов, расширяющих функциональность

Минусы

* Через веб-интерфейс нельзя произвести существенные изменения настроек. Необходимо настраивать в конфигурации. Через интерфейс можно редактировать возможность перехода между статусами, но не список статусов. Изменить (добавить, удалить) имеющиеся поля в фильтре, окнах создания и просмотра бага можно только редактируя код. Редактирование набора полей в списке багов возможно только в коде. Но данные операции с кодом достаточно просты и не требуют глубоких знаний программирования на PHP.

Mercurial

Кроссплатформенная распределённая система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода. Mercurial первоначально был написан для Linux, позже портирован под Windows, Mac OS X и большинство Unix-систем. В первую очередь он является консольной программой. Все его операции запускаются параметрами программы hg, название которой взято от обозначения химического знака ртути (ртуть по англ. — mercury).
Система Mercurial написана на Python, хотя чувствительные к производительности части (например, своя реализация diff) выполнены в качестве Python-расширений на C. Репозитории Mercurial управляются при помощи утилиты командной строки hg.

Наряду с традиционными возможностями систем контроля версий, Mercurial поддерживает полностью децентрализованную работу (отсутствует понятие основного хранилища кода), ветвление (возможно вести несколько веток одного проекта и копировать изменения между ветками), слияние репозиториев (чем и достигается «распределённость» работы). Поддерживается обмен данными между репозиториями через HTTP/HTTPS, SSH и вручную при помощи упакованных наборов изменений.

Mercurial использует SHA1-хеши для идентификации ревизий и позволяет присваивать отдельным ревизиям индивидуальные метки. Утилита hg обладает компактным интерфейсом, и Mercurial считается простой в освоении системой. Кроме того, в марте 2009 года разработчики Python приняли решение о планируемом переходе на Mercurial. Поддерживаются Mercurial-зеркала основных репозиториев других проектов, например, GCC, GNU Emacs и Linux.

XPlanner

XPlanner is a project planning and tracking tool for eXtreme Programming (XP) teams. If you are not familiar with XP software development practices, the links page contains pointers to relevant resources. To summarize the XP planning process, the customers pick the features to be added (user stories) to each development iteration (typically, one to three weeks in duration). The developers estimate the effort to complete the stories either at the story level or by decomposing the story into tasks and estimating those. Information about team development velocity from the previous iteration is used to estimate if the team can complete the stories proposed by the customer. If the team appears to be overcommitted, the set of stories are renegotiated with the customer. The XPlanner tool was created to support this process and address issues experienced in a long-term real-life XP project.

This is very much a work in progress. We expect this tool to evolve as our and the software community's understanding of XP and other agile processes increases. If you'd like to the discuss the planning approaches supported by this tool or provide other feedback and suggestions there is a mailing list for that purpose or contribute to our wiki.

Возможности

* Simple planning model
* Virtual note cards
* Support for recording and tracking projects, iterations, user stories, and tasks.
* Smart continuation of unfinished stories (unfinished tasks copied, copied stories are crosslinked).
* Distributed integration token (with email notification)
* Online time tracking and time sheet generation at individual/team level
* Metrics generation (team velocity, individual hours, ...)
* Charts for iteration velocity, Scrum burn down, distribution of task types, dispositions, and more..
* Ability to attach notes to stories and tasks (with attachments).
* Iteration estimate accuracy view
* Page showing task and story status for individual developers and customers.
* Export of project and iteration information to XML, MPX (MS Project), PDF, and iCal formats.
* TWiki-style text formatting support with support external tool integration and extensible wiki word linking.
* Integrated, extensible authentication supports multiple projects with project-specific authorization.
* SOAP interfaces for advanced XPlanner integration and extension.
* Language support for English, Spanish, French, German, Italian, Brazilian Portuguese, Danish, Russian, Chinese, and Japanese..
Последняя версия вышла 24 мая 2006 года

  • Cogito
  • При написании статьи использовались сайты: Википедия, Habrahabr.

    Сергей Лукин

    (статья незавершена)
    Пожелания и замечания сюда: serg@imech.anrb.ru

    Lukin Sergei Vl.

    Русский

    The candidate of physical and mathematical sciences,
    the younger scientific employee of laboratory « Modelling of technological processes»
    Lukin S.V.
    With 1997 for 2002 was trained at mathematical faculty of the Bashkir state university.
    With 2002 for 2005 passed specialization in postgraduate study of Institute of mechanics UBS the Russian Academy of Science.
    Since 2007 the candidate of physical and mathematical sciences.

    Protection passed in dissertational council D 212.013.09 at the Bashkir state university on May, 25, 2007
    on a speciality 01.02.05 – «Mechanics of a liquid, gas and plasma».
    Theme of the dissertation «Dynamics of waves of pressure in the saturated porous medium».
    The leading organization: the Tyumen State university.
    The supervisor of studies: Sc.D. Urmancheev S.F. (01.02.05).
    The first opponent: Sc.D. Dontsov Vladimir Egorovich (01.02.05) Institute of Thermophysics of the Siberian Branch of the Russian Academy of Science,
    The second opponent: Ph.D Galeyeva Gulshat Jaudatovna (05.13.16) Bashkir State university.

    Contacts:

    Office number: (347)-2-921-406
    (the Room 527)
    send by e-mail: serg@imech.anrb.ru

    Scientific interests

    • Currents of compressed environments and shock waves.
    • Currents of multiphase environments (gas-liquid streams, bubble environments, aerosols, suspensions, etc.).
    • Linear and nonlinear waves in liquids and gases.
    • Analytical, assumptotic and numerical methods of research of the equations kinetic and continuum models of homogeneous and multiphase environments (spectral, methods of final volume, methods of direct modelling, etc.).
    • Development of the problem-oriented control systems, decision-making and optimization of technical, economic, biological, medical and social objects.
    • Visualization, transformation and the analysis of the information on the basis of computer methods of processing of the information.
    • Mathematical modelling of process of hydrobreak of an oil layer.

    Current

    • Studying of a degree and character of influence of heat and mass exchange on parameters of a pulse of pressure in the porous environments saturated with a liquid with gas bubbles. Carrying out of numerical experiments with the purpose of revealing laws of influence of a porous barrier on passage and reflection of a wave of pressure.
    • Modelling of behaviour of a crack of hydrobreak at various elastic and коллекторских properties of a layer, and also at various properties of the agent of hydrobreak and modes.
    • Calculation, optimization and management of operating modes of complex systems of oil pipelines.

    Шагапов Владислав Шайхуллагзамович

    Доктор физико-математических наук, профессор,
    главный научный сотрудник лаборатории «Моделирование технологических процессов»

    RSS-материал