Для решения нелинейных задач по типу аттрактора необходимо в настройках указать методы интегрирования с переменным шагом (лучше адаптивный 1, Адаптивный 3).
По умолчанию для графиков фазовых траекторий выставлено ограничение выводимого к-ва точек которое неплохо бы в данном случае указать явно. Правой кнопкой по графику, галочку прореживания убрать, количество точек выставить каким нибудь большим.
А при чем вы вообще тут пишете про параллелизм если эта задача решается методом интегрирования строго последовательно и на одном ядре? Вы же вроде не считаете в пакете несколько систем в разных проектах? Если чти в настройках SimInTech есть опции для пакетного расчёта определяющие момент записи сигналов. Но этой конкретной задачи это не касается вообще. В данном конкретном случае слова автора о том что в пакете ВКПа результаты от запуска к запуску различаются говорит о том, что в рамках архитектуры данного программного пакета понятием воспроизводимости вычислительного эксперимента пожертвовали в пользу распараллеливания, причём делать такое в рамках приведённой задачи некорректно. В ПК SimInTech при помощи инструмента пакет можно разбить систему на параллельно исполняемые системы и глянуть как они влияют друг на друга.
shadow mode of variables используется при параллельном расчёте в режиме пакета в SimInTech. Настройка использовать запись сигналов на шагах синхронизации.
Сравнивать результаты численного интегрирования желательно на идентичных методах интегрирования. Задачи с этими аттракторами относятся к классу жёстких, результат их сильно зависит от используемого метода. Если что - в демо-примерах ПК SimInTech все эти задачки есть готовые.
А о чем была статья то? Вы взяли для примера классическую задачу интегрирования жёсткой системы диф уравнений, получили в ВКПа в одном из режимов невоспроизводимость результатов расчётов и делаете выводы что считать жёсткие системы диф уравнений надо сделав каждый интегратор в своём потоке? Ну ок можно это сделать, но вообще это не очень правильно в данном случае. Просто видимо принципиальная парадигма решения подобных задач в ВКПа совсем иная чем в simulink, simintech, modelica и т.д. и по всей видимости эта парадигма для чего-то иного предназначена?
Не обязательно. Можно использовать и структуры обычные. Можно интерфейсы без всякого COM. Для стыковки с сишными частями я делал интерфейсную структуру, как оказалось был прав в отношении переносимости.
Может в качестве примера лучше привести обучение более менее полноценной одномерной теплогидравлической модели на базе данных CFD расчёта? Там не так много подгоночных параметров.
Ну хз у кого на чем, а у меня для windows - Delphi VCL и с того же кода для Linux - FPC+Lazarus для GTK2. Альтернатив не сильно много: QT, Java FX, Flutter больше для мобилок, Delphi/Lazarus как ни странно. А вообще выскажу такую мысль, что возможно в нынешнее время в качестве десктопного GUI имело бы смысл затачивать игровые движки, ну типа Unity.
Ну мы у себя в simintech тоже давно встроили меню вызова git клиента, но так что бы не сказал что это супервостребованная фича, но некоторые пользуются. Чаще git используют отдельно от рабочего софта. Но так дело полезное.
Интересная статья, я нашу программу ПК simintech на линукс затащил и даже тут статью написал по этому поводу. Но у меня система на Delphi исходно и там код в принципе оказался хорошо совместим с Lazarus под Linux. Сейчас кодовую базу для windows и Linux единую сделали. Проблемы были там с исключениями в многопоточном режиме. Завязка на винапи то примерно одинаковая, но вот одно дело если из своего кода его напрямую дергать, другое если вызовы абстрагированы библиотекой.
Я согласен с тем, что ООП вообще скорее это абстрактный стиль написания программы и что его можно реализовывать и на языках не имеющих встроенной его поддержки. Описанную автором методику я применял при разработке некоторых модулей к своей системе, например ядра расчета электрических цепей, которое делалось на годом Си. Зачем так было сделано: чтобы обеспечить кросс языковую структурную совместимость, то есть чтобы без проблем вызывать сишный код из Delphi/fpc и из c/c++, но при этом чтобы код был объектно ориентированный по сути. В принципе это работает и можно делать код несколькими способами, подход даёт повышенную гибкость. Из минусов хочу отметить, что оптимизатор компилятора Си может сделать код при таком подходе менее оптимальным чем если например делать его именно как объекты на плюсах или. Delphi. Проблема только потом что объектная модель компиляторов различается и с совместимостью придется извращаться если в проекте их несколько разных. Если же везде только одни плюсы и один компилятор, всё решается наследованием от абстрактного класса, который описывается в общем интерфейсном заголовочном файле.
Точное численное решение - это масло масляное :) Для данных задач точного аналитического решения нет. Есть только численное.
Для решения нелинейных задач по типу аттрактора необходимо в настройках указать методы интегрирования с переменным шагом (лучше адаптивный 1, Адаптивный 3).
По умолчанию для графиков фазовых траекторий выставлено ограничение выводимого к-ва точек которое неплохо бы в данном случае указать явно. Правой кнопкой по графику, галочку прореживания убрать, количество точек выставить каким нибудь большим.
А при чем вы вообще тут пишете про параллелизм если эта задача решается методом интегрирования строго последовательно и на одном ядре? Вы же вроде не считаете в пакете несколько систем в разных проектах? Если чти в настройках SimInTech есть опции для пакетного расчёта определяющие момент записи сигналов. Но этой конкретной задачи это не касается вообще. В данном конкретном случае слова автора о том что в пакете ВКПа результаты от запуска к запуску различаются говорит о том, что в рамках архитектуры данного программного пакета понятием воспроизводимости вычислительного эксперимента пожертвовали в пользу распараллеливания, причём делать такое в рамках приведённой задачи некорректно. В ПК SimInTech при помощи инструмента пакет можно разбить систему на параллельно исполняемые системы и глянуть как они влияют друг на друга.
shadow mode of variables используется при параллельном расчёте в режиме пакета в SimInTech. Настройка использовать запись сигналов на шагах синхронизации.
Сравнивать результаты численного интегрирования желательно на идентичных методах интегрирования. Задачи с этими аттракторами относятся к классу жёстких, результат их сильно зависит от используемого метода. Если что - в демо-примерах ПК SimInTech все эти задачки есть готовые.
А о чем была статья то? Вы взяли для примера классическую задачу интегрирования жёсткой системы диф уравнений, получили в ВКПа в одном из режимов невоспроизводимость результатов расчётов и делаете выводы что считать жёсткие системы диф уравнений надо сделав каждый интегратор в своём потоке? Ну ок можно это сделать, но вообще это не очень правильно в данном случае. Просто видимо принципиальная парадигма решения подобных задач в ВКПа совсем иная чем в simulink, simintech, modelica и т.д. и по всей видимости эта парадигма для чего-то иного предназначена?
Да! А на нашем софте считали динамику ядерной энергоустановки проекта 22220 !
CAD, CAE, спец софт всякий, PDM ы, офисные пакеты и т.п.
Не обязательно. Можно использовать и структуры обычные. Можно интерфейсы без всякого COM. Для стыковки с сишными частями я делал интерфейсную структуру, как оказалось был прав в отношении переносимости.
Это точно
Может в качестве примера лучше привести обучение более менее полноценной одномерной теплогидравлической модели на базе данных CFD расчёта? Там не так много подгоночных параметров.
Ты тоже решил писателем стать? ) Я тут одну статью написал, даже было много отзывов положительных.
Серёга привет !
Я советую сейчас на матлаб не ориентироваться в серьёзных проектах.
Добавьте в список: Simulink -> SimInTech
Ну хз у кого на чем, а у меня для windows - Delphi VCL и с того же кода для Linux - FPC+Lazarus для GTK2. Альтернатив не сильно много: QT, Java FX, Flutter больше для мобилок, Delphi/Lazarus как ни странно. А вообще выскажу такую мысль, что возможно в нынешнее время в качестве десктопного GUI имело бы смысл затачивать игровые движки, ну типа Unity.
А экспорт электрический схемы в программы для моделирования электроцепей есть интересно?
Да, есть такое. Самая популярная нынче система версионирования.
Ну мы у себя в simintech тоже давно встроили меню вызова git клиента, но так что бы не сказал что это супервостребованная фича, но некоторые пользуются. Чаще git используют отдельно от рабочего софта. Но так дело полезное.
Это отлично если сделаете статью. Актуально будет для многих.
На чем нативное то делать будете? Вообще интересно было бы услышать про проблемы написания кроссплатформенного нативного софта на C++.
Интересная статья, я нашу программу ПК simintech на линукс затащил и даже тут статью написал по этому поводу. Но у меня система на Delphi исходно и там код в принципе оказался хорошо совместим с Lazarus под Linux. Сейчас кодовую базу для windows и Linux единую сделали. Проблемы были там с исключениями в многопоточном режиме. Завязка на винапи то примерно одинаковая, но вот одно дело если из своего кода его напрямую дергать, другое если вызовы абстрагированы библиотекой.
Да приходится вообще иногда и такое делать. Могу пример скинуть реализации этого подхода на Delphi и C для конкретной расчетной библиотеки.
Я согласен с тем, что ООП вообще скорее это абстрактный стиль написания программы и что его можно реализовывать и на языках не имеющих встроенной его поддержки. Описанную автором методику я применял при разработке некоторых модулей к своей системе, например ядра расчета электрических цепей, которое делалось на годом Си. Зачем так было сделано: чтобы обеспечить кросс языковую структурную совместимость, то есть чтобы без проблем вызывать сишный код из Delphi/fpc и из c/c++, но при этом чтобы код был объектно ориентированный по сути. В принципе это работает и можно делать код несколькими способами, подход даёт повышенную гибкость. Из минусов хочу отметить, что оптимизатор компилятора Си может сделать код при таком подходе менее оптимальным чем если например делать его именно как объекты на плюсах или. Delphi. Проблема только потом что объектная модель компиляторов различается и с совместимостью придется извращаться если в проекте их несколько разных. Если же везде только одни плюсы и один компилятор, всё решается наследованием от абстрактного класса, который описывается в общем интерфейсном заголовочном файле.