Рубрика «моделирование» - 3

Моделирование работы реальной ТЭЦ для оптимизации режимов: пар и математика - 1

Есть большая ТЭЦ. Работает как обычно: жжёт газ, вырабатывает тепло для отопления домов и электричество для общей сети. Первая задача — отопление. Вторая — продать всё выработанное электричество на оптовом рынке. Иногда ещё в мороз при ясном небе появляется снег, но это побочный эффект работы градирен.

Средняя ТЭЦ состоит из пары десятков турбин и котлов. Если точно известны необходимые объёмы выработки электроэнергии и тепла, то задача сводится к минимизации затрат на топливо. В этом случае расчёт сводится к выбору состава и процента загрузки турбин и котлов для достижения максимально высокого КПД работы оборудования. КПД турбин и котлов сильно зависит от типа оборудования, времени работы без ремонта, режима работы и много чего ещё. Есть и другая задача, когда при известных ценах на электричество и объёмах тепла нужно решить, сколько выработать и продать электроэнергии для того, чтобы получить максимальную прибыль от работы на оптовом рынке. Тогда фактор оптимизации — прибыль и КПД оборудования — имеет гораздо меньшее значение. Результатом может быть режим, когда оборудование работает абсолютно неэффективно, но весь выработанный объём электроэнергии можно продать с максимальной маржой.

В теории всё это давно понятно и красиво звучит. Проблема — как это сделать на практике. Мы начали имитационное моделирование работы каждой единицы оборудования и всей станции в целом. Пришли на ТЭЦ и начали собирать параметры всех узлов, замеряя их реальные характеристики и оценивая работу в разных режимах. На их основе мы создавали точные модели для имитации работы каждой единицы оборудования и использовали их для оптимизационных расчётов. Забегая вперёд, скажу, что мы выиграли порядка 4 % реальной эффективности просто за счёт математики.Читать полностью »

Здравствуй!

В 2012 году я написал пост о своем увлечении — Космики: моделирование эволюции многоклеточных организмов

С того момента прошло без малого 7 лет, в течение которых я работал над развитием этого проекта. Сегодня я хочу рассказать немного о том, что научился делать, и как планирую развивать проект дальше.
Читать полностью »

С того самого момента, когда я приобрел свой первый смартфон, работающий под ОС Android, я искал приложения под эту ОС, которые бы помогли мне делать несложные рабочие расчеты «на ладошке». Об одном из таких приложений и пойдет речь.

Android для радиоинженера (и не только) - 1

Читать полностью »

Привет!

Тут мы опишем работу некоторого поля а затем сделаем пару красивых фичей (тут все ОЧЕНЬ просто).

Элементарная симуляция кастомного физического взаимодействия на python + matplotlib - 1

Что будет в этой статье.

Общий случай:

  1. Опишем базу, а именно работу с векторами (велосипед для тех, у кого нет под рукой numpy)
  2. Опишем материальную точку и поле взаимодействия

Частный случай (на основе общего):

  1. Сделаем визуализацию векторного поля напряженности электромагнитного поля (первая и третья картинки)
  2. Сделаем визуализацию движения частиц в электромагнитном поле

Встретимся под катом!
Читать полностью »

Привет!

На днях мне в очередной раз на глаза попал код вида

if(someParameter.Volatilities.IsEmpty())
{
    // We have to report about the broken channels, however we could not differ it from just not started cold system.
    // Therefore write this case into the logs and then in case of emergency IT Ops will able to gather the target line
    Log.Info("Channel {0} is broken or was not started yet", someParameter.Key)
}

В коде есть одна довольно важная особенность: получателю крайне хотелось бы знать, что произошло на самом деле. Ведь в одном случае у нас проблемы с работой системой, а в другом — мы просто прогреваемся. Однако модель не дает нам этого (в угоду отправителю, который зачастую является автором модели).
Более того, даже факт "возможно, что-то не так" происходит из того, что коллекция Volatilities пуста. Что в некоторых случаях может быть и корректно.

Я уверен, что большинство опытных разработчиков встречало в коде строки, в которых заключалось тайное знание в стиле "если выставлена эта комбинация флажков, то от нас просят сделать A, B и C" (хотя по самой модели этого не видно).

С моей точки зрения, подобная экономия на структуре классов сказывается крайне негативно на проекте в будущем, превращая его в набор хаков и костылей, постепенно трансформируя более-менее удобный код в legacy.

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

Однако если же вы занимаетесь долгоиграющим — добро пожаловать под кат.

Читать полностью »

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

К сожалению, не все так прекрасно в Trello. На нем нельзя сделать кастомный workflow. То есть нам нужно занять одного сотрудника, который будет в различных досках перетаскивать карточки руками. Как же сделать так, чтобы этого сотрудника можно было перевести на другую, более интересную и творческую работу?

Конечно, скажете вы, можно написать скрипт, который будет делать все это за нас. Но тут возникает проблема. Скрипт может написать только программист или человек, который понимает, как это делать. Поддерживать скрипт придется ему же. Мы нашли более простое и логичное решение — это семантическое моделирование.

Семантическое моделирование позволяет всю логику работы доски в Trello записать на естественном языке.
Читать полностью »

Golang DevDay: 31 мая, Новосибирск + трансляция - 1

Обычно с приходом тепла DevDay уходит на каникулы. На этот раз решили, что ждать осени — непозволительно. В последний день весны приглашаем вас присоединиться к Golang DevDay. Будет и мягкий переход «из не-Go в Go» для тех, кто только присматривается к языку, и выступления похардкорнее.

Под катом подробности, расписание и ссылка на регистрацию.
Читать полностью »

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

В какой-то момент я понял, что передача данных в такой схеме описывается с помощью обыкновенного дифференциального уравнения. Описание модели и выводы, которые удалось получить с её помощью, под катом.
Читать полностью »

UML&Enterprise Architect: проектируем целевой процесс при создании автоматизированной системы - 1
Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р. Сурьянинов, 1972

«Рассказ о моделировании именно сложных систем»

Предыстория

К одной из моих статей по моделированию «сказочной» предметной области (часть 1, часть 2) был оставлен комментарий, цитирую:

«Было бы здорово увидеть рассказ о моделировании именно сложных систем».

И я пообещала подобрать что-то из реальной жизни.

Читать полностью »

Некоторое время назад между мной и моим хорошим другом состоялся разговор, в котором прозвучали такие фразы:

— Количество программистов будет постоянно расти — ведь количество кода растет, и для его поддержки постоянно требуется все больше разработчиков.
— Но код стареет, часть его уходит из поддержки. Не исключено даже наличие какого-то равновесия.

Вспомнив их через несколько дней, я задумался, действительно ли поддержка кода, требуя с течением времени все больше и больше ресурсов, может в конечном счете парализовать разработку нового функционала, либо потребует неограниченного увеличения количества программистов? Качественно оценить зависимость объёма поддержки от разработки и найти ответы на вопросы помогли математический анализ и дифференциальные уравнения.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js