Включите в графике опцию использования ступенчатой интерполяции и будут строго вертикальные. А вообще при постоянном шаге интегрирования время когда меандр равен например 0 и время когда он стал например 1 отличается как раз на этот самый шаг интегрирования. При этом если включить метод с переменным шагом и опцию учета формы для источников в настройках то можно снизить шаг в момент переключения меандра до заданного минимума.
Интегратор является линейным звеном поэтому на входе его умножать или на выходе значения не имеет. Ограничение выполняется не просто по выходу а по переменной состояния, что есть правильно. В симулинке был косяк когда делали именно ограничение чисто выхода интегратора и получалось, что когда переменная состояния там не ограничивалась и например при постоянном входном воздействии он выходил на ограничение, но при этом накопление все равно шло. Из за этого там при смене входного воздействия на обратное возникала задержка которой быть не должно. Основное назначение блока интегратора с ограничениями это имитация приводов имеющих конечное положение (например привод клапана с концевыми выключателями) - вот собственно у нас он как положено так и работает.
В SimInTech библиотека "Конечные автоматы" сделана на основе такой штуки как субмодель с условным выполнением - это в чём-то более общая концепция (потому что выполнять одновременно можно и несколько моделей сразу). Смысл именно такой реализации был в том, чтобы обеспечить возможность задания внутренней структуры каждого состояния в виде структурной схемы (и соответственно использовать имеющийся набор вычислительных блоков) и обеспечить сортировку модели до её исполнения, чтобы: 1. исключить неявно заданные алгебраические петли. 2. минимизировать задержки на шаг расчёта. 3. совместить всё с моделью в виде сигнального графа (входо-выходной блочной диаграммой, это основной способ задания моделей для реакторного АСУТП). Т.е. по сути в данной библиотеке используется расширение понятия структурной схемы за счёт усовершенствованной сортировки и переменной структуры, которое позволяет задавать карту состояний.
Вот в этих статьях мы делали сравнение с "ручным" расчётом и с моделью в SimInTech как раз в таком виде и оно у нас совпало:
Шорников Ю. В., Тимофеев К. А. "Событийно-дискретные модели управления движением", Автометрия. Т. 60, № 2. С. 119-127. DOI: 10.15372/AUT20240214. EDN: LTWEUQ
А так вообще если операции внутри состояния не в виде структурной схемы задавать, а в виде текста во встроенном языке программирования есть оператор case.
Ну вот по этой причине сейчас динамическая модель, включая модель АСУТП делается до воплощения станции в железе. А потом после корректируется по ходу реализации проекта.
Ну тут в модели дело у тебя. Тут таймер сбросить надо при выходе по другому событию. Для этого поставь у него на входе блок И и на него сигнал cold заведи. Ну или сейчас можно поставить блок вывода флага входа в состояние и по входу сбросить. Или таймер из сумматора собери.
Мы для немцев из GRS делали работу по использованию simintech для генерации входных файлов для кода athlet и его подсистемы gcsm. У них тогда тоже импортозамещение начальство попросило и мы сделалали версию системы для open suse linux. В результате вся эта деятельность вылилась в то, что описано на Хабре в статье про портирование сложного модульного по на Линукс. Т.е. когда нас заставили поддерживать нативно наши ос мы к этому были готовы.
Ну это вы спросите у заказчиков проекта, почему в итоге оно не пошло в работу (они посчитали что экономии не будет особой на оптимизации вентиляции). А мы как исполнители сделали модель, получили результат и получили за это свою денежку. Это всё вообще в основном один человек делал, ну и я сделал прототип модели, чтобы её можно было масштабировать хорошо. Зато по итогам распараллелили свой теплогидравлический код.
У нас в 3В Сервис из разработчиков нашей системы SimInTech программистов по образованию нет: все инженеры, по ядерным энергоустановкам, баллистике, робототехнике. И людей учить в основном приходится нам лично. Интересно, приходят ли к вам люди с хоть более менее профильной подготовкой после ВУЗа?
А давайте я вам пришлю одну дискретно событийную модель транспортного потока с диаграммами Харелла и ссылку на статью иностранную одну по данным которой эта модель и строилась. Интересно было бы сравнить способ реализации.
Ректификат это хорошо. Но хочу сказать, что динамика процесса конденсации многокомпонентной спирто-водяной смеси с неконденсирующимся газом имеет весьма сложную математику. Поэтому интересно было бы привести систему уравнений и требуемые режимы. А потом сравнить модель с экспериментально полученным продуктом.
Ну вот чтобы схему не считать вместо одного два раза её и сортируют. При наличии алгебраических петель система будет считаться у вас так, как будто вы петлю развязывание блоком задержки на шаг. Да и сходимость такого способа расчета будет обеспечиваться не всегда. К слову такой механизм используется в simintech для установления размерностей при инициализации схемы, но естественно после сортировки.
Для этого не так уж много и надо - помещать выходные значения в буфер, а в начале следующего цикла вытаскивать. И сортировать при этом не надо даже.
Это не так, т.к. значения входов блоков которые являются мгновенными функциями должны быть рассчитаны на текущем временном слое. Для этого их и сортируют.
В общей части подсистемы моделирования входо-выходных моделей метода трапеций нет, но есть более точный метод Гира из неявных. Результат следует сравнивать вам или с методом Гира или с Адаптивный 1, 3 . Список методов доступен по нажатию кнопки параметров расчёта на схемном окне. Разные графики при перемешивании как раз и отображают разные задержки на шаг в разных вариантах. Дело в том что интеграторы при непрерывном моделировании должны являться приоритетными блоками. Т.е. они свой выход формируют первыми, потом от них по цепочке пересчитываются функции, потом, для всех интеграторов вычисляются производные зависящие от входов, потом эти производные поступают в метод интегрирования и с него проинтегрированные величины идут на выходы интеграторов, потом цикл повторяется.
Т.е. схема расчёта в общем такая:
X=Xo
While(1) {
Расчёт выходов блоков
Y = Fouts(X)
Расчёт производных
X' = Fderi(Y)
Интегрирование непрерывных частей
X = X + X' *h;
}
Т.е. как бы расчёт многостадийный и выход интегратора не обновляется сразу после его пересчёта, а обновляется через его внутреннюю переменную состояния.
А вы шаг у себя в модели и SimInTech сделайте побольше и разницу увидите скорее всего. Тут вот в чём дело: к примеру я могу работать с неотсортированной моделью и выполнять её в произвольном порядке имея при этом неявные задержки на шаг непонятно где. Но при этом даже если я получу устойчивое решение (а могу и не получить), то скорее всего мне придётся для как раз обеспечения устойчивости на шаге интегрирования пересчитывать схему не один а два раза. Вообще автоматный подход и непрерывное моделирование - это принципиально 2 разных способа моделирования. При этом я на классическую непрерывную схему моделирования, когда модель рассматривается как функция X' = F(X, u) могу натянуть и условное исполнение и конечные автоматы и дискретную логику (внутри самой функции). Автоматный же подход который вы продвигаете подразумевает, что схема разделена на независимые "параллельно" исполняемые компоненты, которые взаимодействуют друг с другом через передачу сигналов от входа к выходу. Соответственно в такой схеме я к примеру согласованно обеспечить контроль точности интегрирования и итерационный процесс, если у меня решение не сходится, по ВСЕЙ модели не смогу. Что внутри SimInTech, что внутри Simulink метод интегрирования дёргает вызов общей функции F(x, x') внутри которой уже по отсортированной модели идёт последовательный её пересчёт - т.е. вызов для каждого блока исполняемого кода. Поэтому способ моделирования должен выбираться соответственно решаемой задаче. Наличие сортировки модели и элиминация задержек на шаг интегрирования позволяет устранить численную неустойчивость и увеличить шаг интегрирования, и соответственно сократить время решения задачи на ЭВМ.
Ну по хорошему вы тогда должны моделировать по честному количество тактов выполнения операции в процессоре и точно симулировать собственно железо. На уровне программы внутри контроллера никакой инерционности сложения учитывать не надо. Вообще как бы все понимают, что к примеру в процессоре операция сложения занимает определённое к-во тактов, также как и про то что к примеру есть спекулятивное выполнение. На разных уровнях рассмотрения задачи подходы к моделированию различаются. Поэтому в приведённой задаче никакой неопределённости быть не должно - она рассматривается как непрерывная.
Включите в графике опцию использования ступенчатой интерполяции и будут строго вертикальные. А вообще при постоянном шаге интегрирования время когда меандр равен например 0 и время когда он стал например 1 отличается как раз на этот самый шаг интегрирования. При этом если включить метод с переменным шагом и опцию учета формы для источников в настройках то можно снизить шаг в момент переключения меандра до заданного минимума.
Интегратор является линейным звеном поэтому на входе его умножать или на выходе значения не имеет. Ограничение выполняется не просто по выходу а по переменной состояния, что есть правильно. В симулинке был косяк когда делали именно ограничение чисто выхода интегратора и получалось, что когда переменная состояния там не ограничивалась и например при постоянном входном воздействии он выходил на ограничение, но при этом накопление все равно шло. Из за этого там при смене входного воздействия на обратное возникала задержка которой быть не должно. Основное назначение блока интегратора с ограничениями это имитация приводов имеющих конечное положение (например привод клапана с концевыми выключателями) - вот собственно у нас он как положено так и работает.
В SimInTech библиотека "Конечные автоматы" сделана на основе такой штуки как субмодель с условным выполнением - это в чём-то более общая концепция (потому что выполнять одновременно можно и несколько моделей сразу). Смысл именно такой реализации был в том, чтобы обеспечить возможность задания внутренней структуры каждого состояния в виде структурной схемы (и соответственно использовать имеющийся набор вычислительных блоков) и обеспечить сортировку модели до её исполнения, чтобы: 1. исключить неявно заданные алгебраические петли. 2. минимизировать задержки на шаг расчёта. 3. совместить всё с моделью в виде сигнального графа (входо-выходной блочной диаграммой, это основной способ задания моделей для реакторного АСУТП). Т.е. по сути в данной библиотеке используется расширение понятия структурной схемы за счёт усовершенствованной сортировки и переменной структуры, которое позволяет задавать карту состояний.
Вот в этих статьях мы делали сравнение с "ручным" расчётом и с моделью в SimInTech как раз в таком виде и оно у нас совпало:
Шорников Ю. В., Тимофеев К. А. "Событийно-дискретные модели управления движением",
Автометрия. Т. 60, № 2. С. 119-127. DOI: 10.15372/AUT20240214. EDN: LTWEUQ
https://www.elibrary.ru/item.asp?id=65660464
Y.V. Shornikov, K.A. Timofeev, Event-Discrete Traffic Control Models. Optoelectron.Instrument.Proc. 60, 276–283 (2024).
https://doi.org/10.3103/S875669902470033X
А так вообще если операции внутри состояния не в виде структурной схемы задавать, а в виде текста во встроенном языке программирования есть оператор case.
Ну вот по этой причине сейчас динамическая модель, включая модель АСУТП делается до воплощения станции в железе. А потом после корректируется по ходу реализации проекта.
Немцы жмоты.
Ну тут в модели дело у тебя. Тут таймер сбросить надо при выходе по другому событию. Для этого поставь у него на входе блок И и на него сигнал cold заведи. Ну или сейчас можно поставить блок вывода флага входа в состояние и по входу сбросить. Или таймер из сумматора собери.
Мы для немцев из GRS делали работу по использованию simintech для генерации входных файлов для кода athlet и его подсистемы gcsm. У них тогда тоже импортозамещение начальство попросило и мы сделалали версию системы для open suse linux. В результате вся эта деятельность вылилась в то, что описано на Хабре в статье про портирование сложного модульного по на Линукс. Т.е. когда нас заставили поддерживать нативно наши ос мы к этому были готовы.
Я гляну уточню.
Ну это вы спросите у заказчиков проекта, почему в итоге оно не пошло в работу (они посчитали что экономии не будет особой на оптимизации вентиляции). А мы как исполнители сделали модель, получили результат и получили за это свою денежку. Это всё вообще в основном один человек делал, ну и я сделал прототип модели, чтобы её можно было масштабировать хорошо. Зато по итогам распараллелили свой теплогидравлический код.
У нас в 3В Сервис из разработчиков нашей системы SimInTech программистов по образованию нет: все инженеры, по ядерным энергоустановкам, баллистике, робототехнике. И людей учить в основном приходится нам лично. Интересно, приходят ли к вам люди с хоть более менее профильной подготовкой после ВУЗа?
Сейчас мне отдадут все последние разработки по каталогу и я всё выложу
Ну вообще да, надо бы на сайт новости класть нам почаще.
Понял, спасибо ! Завтра пришлю.
А давайте я вам пришлю одну дискретно событийную модель транспортного потока с диаграммами Харелла и ссылку на статью иностранную одну по данным которой эта модель и строилась. Интересно было бы сравнить способ реализации.
Ректификат это хорошо. Но хочу сказать, что динамика процесса конденсации многокомпонентной спирто-водяной смеси с неконденсирующимся газом имеет весьма сложную математику. Поэтому интересно было бы привести систему уравнений и требуемые режимы. А потом сравнить модель с экспериментально полученным продуктом.
Ну вот чтобы схему не считать вместо одного два раза её и сортируют. При наличии алгебраических петель система будет считаться у вас так, как будто вы петлю развязывание блоком задержки на шаг. Да и сходимость такого способа расчета будет обеспечиваться не всегда. К слову такой механизм используется в simintech для установления размерностей при инициализации схемы, но естественно после сортировки.
Для этого не так уж много и надо - помещать выходные значения в буфер, а в начале следующего цикла вытаскивать. И сортировать при этом не надо даже.
Это не так, т.к. значения входов блоков которые являются мгновенными функциями должны быть рассчитаны на текущем временном слое. Для этого их и сортируют.
В общей части подсистемы моделирования входо-выходных моделей метода трапеций нет, но есть более точный метод Гира из неявных. Результат следует сравнивать вам или с методом Гира или с Адаптивный 1, 3 . Список методов доступен по нажатию кнопки параметров расчёта на схемном окне. Разные графики при перемешивании как раз и отображают разные задержки на шаг в разных вариантах. Дело в том что интеграторы при непрерывном моделировании должны являться приоритетными блоками. Т.е. они свой выход формируют первыми, потом от них по цепочке пересчитываются функции, потом, для всех интеграторов вычисляются производные зависящие от входов, потом эти производные поступают в метод интегрирования и с него проинтегрированные величины идут на выходы интеграторов, потом цикл повторяется.
Т.е. схема расчёта в общем такая:
X=Xo
While(1) {
Расчёт выходов блоков
Y = Fouts(X)
Расчёт производных
X' = Fderi(Y)
Интегрирование непрерывных частей
X = X + X' *h;
}
Т.е. как бы расчёт многостадийный и выход интегратора не обновляется сразу после его пересчёта, а обновляется через его внутреннюю переменную состояния.
У вас судя по коду метод трапеций используется. Посмотрите какой метод стоит в simintech в настройках расчёта проекта и сделайте такой же
А вы шаг у себя в модели и SimInTech сделайте побольше и разницу увидите скорее всего. Тут вот в чём дело: к примеру я могу работать с неотсортированной моделью и выполнять её в произвольном порядке имея при этом неявные задержки на шаг непонятно где. Но при этом даже если я получу устойчивое решение (а могу и не получить), то скорее всего мне придётся для как раз обеспечения устойчивости на шаге интегрирования пересчитывать схему не один а два раза. Вообще автоматный подход и непрерывное моделирование - это принципиально 2 разных способа моделирования. При этом я на классическую непрерывную схему моделирования, когда модель рассматривается как функция X' = F(X, u) могу натянуть и условное исполнение и конечные автоматы и дискретную логику (внутри самой функции). Автоматный же подход который вы продвигаете подразумевает, что схема разделена на независимые "параллельно" исполняемые компоненты, которые взаимодействуют друг с другом через передачу сигналов от входа к выходу. Соответственно в такой схеме я к примеру согласованно обеспечить контроль точности интегрирования и итерационный процесс, если у меня решение не сходится, по ВСЕЙ модели не смогу. Что внутри SimInTech, что внутри Simulink метод интегрирования дёргает вызов общей функции F(x, x') внутри которой уже по отсортированной модели идёт последовательный её пересчёт - т.е. вызов для каждого блока исполняемого кода. Поэтому способ моделирования должен выбираться соответственно решаемой задаче. Наличие сортировки модели и элиминация задержек на шаг интегрирования позволяет устранить численную неустойчивость и увеличить шаг интегрирования, и соответственно сократить время решения задачи на ЭВМ.
Ну по хорошему вы тогда должны моделировать по честному количество тактов выполнения операции в процессоре и точно симулировать собственно железо. На уровне программы внутри контроллера никакой инерционности сложения учитывать не надо. Вообще как бы все понимают, что к примеру в процессоре операция сложения занимает определённое к-во тактов, также как и про то что к примеру есть спекулятивное выполнение. На разных уровнях рассмотрения задачи подходы к моделированию различаются. Поэтому в приведённой задаче никакой неопределённости быть не должно - она рассматривается как непрерывная.