Комментарии 88
С таким положением мириться нельзя и это, безусловно, требует своего разбирательства и поиска причин случившегося.
Кхм, симуляция хаоса в динамических системах не может быть вычислительно устойчивой. У чисел с плавающей запятой погрешности как бы есть. В другом порядке арифметические операции при решении диффуров посчитали, вот вам и несовпадающие результаты.
Другое дело, что SimInTech решил симулировать с каким-то конским шагом, и получился полный треш, а две другие программы просто не умеют antialiasing (ну бывает, научный софт не обязан выглядеть как конфетка).
А вы не проверяли результаты в MATLAB Simulink с другим solver'ом (методом реализации численного интегрирования)? Там же их полно, по умолчанию стоит ode45, основанный на методе Рунге-Кутты, потому что он дает приемлемую точность при приемлемой же производительности, но есть и куда более точные типа ode23 (метод Богацкого-Шампина) - он рисует даже для сравнительно простых моделей куда более гладкую и точную кривую. Есть там и методы с фиксированным шагом интегрирования, начиная с метода Эйлера. Я бы, прежде чем делать однозначные выводы, как минимум поигрался бы с разными солверами и шагами интегрирования, потому что практика показывает, что изменения в виде кривых могут быть разительными, особенно на сложных моделях (я, например, электронные фильтры высоких порядков и адаптивные системы моделирую исключительно на "тяжелых", но точных методах). Если что, настраивается в свойствах симуляции, там выбирается метод и размер шага (или границы шага, если используется метод с переменным шагом интегрирования).
Также, надеюсь, вы учли, что в целях экономии памяти, по умолчанию в блоке Scope есть ограничение на количество точек (по умолчанию, ЕМНИП, последние 4к шагов). Вы меняли этот параметр?
Вообще, всегда надо держать в уме, что разные численные методы вполне "законно" могут давать разные результаты на вычислениях с плавающей точкой, особенно при моделировании хаоса. Насколько разные - зависит от задачи. Но всегда нужно помнить, что любой численный метод имеет погрешности, и при его использовании накапливаются ошибки численного интегрирования.
А у моделей аттракторов Ресслера и Лоренца разве известно точное численное решение? Я всегда думал, что мы получаем только приближение, а с увеличением точности вычислений решение будет изменяться (ввиду свойств системы).
Претензия не обоснована. (существует задача, на которой бензопила скажет "р-р-р-р-хрфхщ", и это не значит, что бензопила плохая)
Точное численное решение - это масло масляное :) Для данных задач точного аналитического решения нет. Есть только численное.
формально, это полноценная система ДУ. Не исключено, что кто-нибудь изобретет способ найти точное решение (хотя бы в смысле предела, хотя бы в каком-то (нелинейном) случае).
Точное численное решение мало того, что бывает для некоторых задач (вот например дискретных), так еще может быть точным/не точным в разных смыслах, что сразу пришло в голову - точная диагонализация в смысле диагонализации полной матрицы (в противовес методу Ланцоша).
Для решения нелинейных задач по типу аттрактора необходимо в настройках указать методы интегрирования с переменным шагом (лучше адаптивный 1, Адаптивный 3).
По умолчанию для графиков фазовых траекторий выставлено ограничение выводимого к-ва точек которое неплохо бы в данном случае указать явно. Правой кнопкой по графику, галочку прореживания убрать, количество точек выставить каким нибудь большим.
А при чем вы вообще тут пишете про параллелизм если эта задача решается методом интегрирования строго последовательно и на одном ядре? Вы же вроде не считаете в пакете несколько систем в разных проектах? Если чти в настройках SimInTech есть опции для пакетного расчёта определяющие момент записи сигналов. Но этой конкретной задачи это не касается вообще. В данном конкретном случае слова автора о том что в пакете ВКПа результаты от запуска к запуску различаются говорит о том, что в рамках архитектуры данного программного пакета понятием воспроизводимости вычислительного эксперимента пожертвовали в пользу распараллеливания, причём делать такое в рамках приведённой задачи некорректно. В ПК SimInTech при помощи инструмента пакет можно разбить систему на параллельно исполняемые системы и глянуть как они влияют друг на друга.
shadow mode of variables используется при параллельном расчёте в режиме пакета в SimInTech. Настройка использовать запись сигналов на шагах синхронизации.
Сравнивать результаты численного интегрирования желательно на идентичных методах интегрирования. Задачи с этими аттракторами относятся к классу жёстких, результат их сильно зависит от используемого метода. Если что - в демо-примерах ПК SimInTech все эти задачки есть готовые.
А о чем была статья то? Вы взяли для примера классическую задачу интегрирования жёсткой системы диф уравнений, получили в ВКПа в одном из режимов невоспроизводимость результатов расчётов и делаете выводы что считать жёсткие системы диф уравнений надо сделав каждый интегратор в своём потоке? Ну ок можно это сделать, но вообще это не очень правильно в данном случае. Просто видимо принципиальная парадигма решения подобных задач в ВКПа совсем иная чем в simulink, simintech, modelica и т.д. и по всей видимости эта парадигма для чего-то иного предназначена?
Выводы лично для меня однозначные.
Если на входе одинаковая модель, одинаковое исходное состочние, и в модели не используютя функции рандомайзинга, и параметры моделирования одинаковые, то результаи должен совпадать на 100%, с заданной точностью. Если результаты разные, то это булшит, или факап и надо искать причину.
Ну а" теневые переменные" в статье очень похоже, не модель халса, а просто мусор который остался с предыдушего расчета и меняет начальное состояние системы приводя к разным результатам при повторении расчетов.
Другими словами Simulink и SimInTech считают правильно,достоверно и предсказуемл, а ВКПа - просто лажает. Правильное название статьи как я нашел ошибку в ВКП, которой нет в Simulink и SimInTech ;)))
бывает неявное использование случайных чисел ("не метод Монте-Карло"), например, при построении пространства Крылова, или в подобных методах. Произвольный единичный затравочный вектор не должен существенно менять решение, но не должен давать существенных отличий. Точного совпадения не будет.
Ничего страшного в этом нет. Даже результат вычислений иногда называют "результат численного эксперимента" и выдают в виде "значение+-неопределенность". (хотя это больше свойственно методам с явным использованием случайных чисел)
Почитав некоторые статьи автора по поводу автоматного программирования я хочу заметить, что:
Сводимость конечных автоматов к классическим структурным схемам (а приведена именно такая) ограничена. Для разрешения этой проблемы для структурных схем требуется введение операции условного исполнения части схемы по флагу и учёт этой операции при сортировке блоков. Ну или как минимум блока с запоминанием состояния (задержка на шаг интегрирования).
Большинство логических схем с логической обратной связью прекрасно моделируется описанием модели структурной схемой с введением блока задержки на шаг в обратной связи. При этом по выходу задержек не будет на шаге интегрирования относительно входа. При этом в SimInTech можно всё это и как карту состояний нарисовать если что. Про то, что некоторые вещи так не смоделировать я тоже в курсе, но их реальная встречаемость в практически используемых моделях невелика.
Недурно бы было если бы автор обосновал как он интегратор у себя в программе моделирует и как схема при этом сортируется. Потому что в данном случае конкретном случае неповторяемость результатов - это ошибка.
Недурно бы было если бы автор обосновал как он интегратор у себя в программе моделирует и как схема при этом сортируется. Потому что в данном случае конкретном случае неповторяемость результатов - это ошибка.
Исполняю пожелания ;)
Самым элементарным образом - считаю площадь. Известно текущее, предыдущее значения и длительность такта. Что еще надо?
Не сортируется. В параллельной среде сортировка не нужна.
Это не ошибка. Это особенность ядра. Это я пояснил в статье (читайте внимательнее). Длительность такта плавающая и это основная причина. Я так думаю! ;)
Да, по поводу начальных условий - 10, 0, 0 (X, Y, Z). Это как в статье про аттракторы.
Про то, что некоторые вещи так не смоделировать я тоже в курсе, но их реальная встречаемость в практически используемых моделях невелика.
Почти согласен, т.к. встречаюсь. В ПЛК не так уж и редко. Здесь же вот, похоже, случилось именно такое. С аттрактором Лоренца. Думаю и в остальных присутствует. Только проявляется не так очевидно.
Ну площадь считать это понятно, но не очень правильно так говорить, т.к. существуют разные способы аппроксимации интегрируемой функции. Я так понял, что вы применяете метод трапеций ?
Как это сортировка не нужна ? Ну если вы считаете что каждый блок должен рассчитываться изолированно в своём потоке то может и не нужна, только это тогда уже не считается структурной схемой собственно, а как-то совсем по другому должно именоваться. Я же говорю, что вы пытаетесь в данном случае используя некоторую свою нестандартную парадигму понимания структурных схем решать задачи для решения которых должна применяться несколько другая парадигма. И в SimInTech и Simulink и вообще везде по сути структурная схема представляет собой направленный граф, описывающий связь переменных между элементарными моделями блоков. Классическое понимание этого графа подразумевает его сортировку таким образом, чтобы при последовательном исполнении отсортированного списка блоков на входе каждого блока не возникало неопределённости. Если как вы говорите сортировки у вас нет, это значит что эта неопределённость присутствует и заложена в архитектуре вашего расчётного ядра. Вывод из этого, что для решения описанного в статье класса задач такая архитектура непригодна. Это не значит что она для другого будет непригодна, ну к примеру для описания передачи данных между контроллерами по сети, но и там по идее сортировка модели должна присутствовать. Но для вот этой конкретной модели - точно нет, описывать её без наличия сортировки блоков нельзя.
По поводу ПЛК: я в курсе чем их программируют и я делал свой генератор кода для ПЛК и свою исполняемую среду, которая работает на АЭС успешно. Вообще на данный момент язык LD не очень как-то любят использовать, в основном FBD и ST. Для крупных нетиповых алгоритмов - Си. Так вот в языке FBD сортировка блоков ЕСТЬ ! Т.к. его стандарт предусматривает, что исполнение блоков делается в порядке их соединения и никакой параллельщины там нет на уровне диаграмм, описывающих элементарные алгоритмы.
Поэтому я могу дать совет по поводу вашего вычислительного ядра: 1 - введите сортировку на уровне структурных схем. 2 - явным образом сделайте указание на схеме параллельно исполняемых ветвей кода.
Выводы лично для меня однозначные.
Я бы не спешил так... Мы же не в армии, где все понятно, однозначно и все ходят строем...
Если результаты разные, то это булшит, или факап и надо искать причину.
С интересом познал новые слова. Я, извините, закоренелый провинциал и не все до нас доходит быстро и вовремя. Ну, да ладно...
Так и я же об этом писал. Нужно понять почему результаты в MATLAB и SymInTech разные. Вы же сами говорите, что все должно 100% совпадать. Я могу даже выслать эти проекты, а Вы попробуйте их заставить выдать одинаковые результаты. По отдельности-то у них повторяемость идеальная. Какие параметры и в какое значение их установить, что все было тип-топ. Уж кто, если не Вы сможете это так настроить? Доказать, что это возможно (или какой пакет все же точнее посчитал), если не Ваша прямая обязанность, то хотя бы дело чести... Я так думаю.
Но выше - это полбеды. Беда - в параллелизме. Это кто бы и чтобы не говорил. Здесь выводы, действительно, однозначные. Ни MATLAB ни SymInTech не решат правильно задачи, содержащие параллелизм. Чтобы они это делали нужны или возможны какие-то "манипуляции". Но поскольку они ни где не упоминаются (возможно, ошибаюсь), то, скорее всего, все решается строго последовательно. В результате что имеем, то имеем.
Параллелизм проста штука, но почему-то сложно понимаемая :) Для ВКПа это естественная и простая в реализации вещь (речь не о ее ядре). Одним щелчком я перехожу от последовательных вычислений к параллельным и тут же вижу результат. Иногда он очевиден, как в случае аттрактора Лоренца, RS-триггера и т.п., а чаще все он почти не виден, как в случае остальных аттракторов.
А про "теневые переменные" - Вы просто не разобрались. О каком мусоре речь? Это просто еще одна переменная в которую я записал новое значение текущей переменной, а потом через какое-то время это значение присвоил исходной переменной. Где тут место мусору?
Другими словами Simulink и SimInTech считают правильно,достоверно и предсказуемл, а ВКПа - просто лажает.
Первое еще надо доказать, а со вторым Вы просто поспешили :) Если что и может лажать - это интегратор в ВКПа. Но на простых примерах все ОК. Ну, а в каком месте ему стоять - в сложном или простом примере - это, ведь, должно быть "по барабану". Ведь так? От перемены мест, как известно... его свойства не меняются. Хотя...
По поводу "поиграться". Поигрался. Неделю играюсь :) Но только сегодня обнаружил, что больше всего влияет значение шага. И это понятно. Но вот сейчас попробую еще одну "игрушку" - поменяю местами уравнения. В случае последовательных расчетов это должно сказаться на результате. Но на это могут повлиять процессы компиляции/исполнения схем. О результатах - доложу ;)
Но только сегодня обнаружил, что больше всего влияет значение шага
Для аттракторов Рёсслера и Лоренца аналитического решения не существует, а численное решение очевидным образом зависит от величины шага интегрирования (хотя, вообще-то, такие вещи моделируют методами с переменным (адаптивным) шагом, при этом решение будет зависеть и от выбранного метода тоже, т.к. уравнения нелинейные, и от погрешностей интегрирования). Странно, что вы изначально этого не учли и обнаружили постфактум. Также странно, что вы не учитываете свойства нелинейных уравнений, решение, тем более численное, которых зависит от начальных условий, которые вы не указываете, а это крайне важно. Вообще, это довольно очевидные вещи, которые понятны и без всякого моделирования любому, кто более-менее понимает, как реализуются численные методы решения ДУ, тем более, нелинейных.
А где вы там нашли проблемы с параллелизмом и какие-то программные ошибки, я, простите, не могу понять (либо вы вкладываете в термин "параллелизм" какой-то иной, не общепринятый смысл). Не могли бы вы пояснить, какую проблему вы вообще хотите решить этими исследованиями? Возможно, это было где-то в ваших предыдущих постах, но я не могу найти.
А где вы там нашли проблемы с параллелизмом и какие-то программные ошибки, я, простите, не могу понять (либо вы вкладываете в термин "параллелизм" какой-то иной, не общепринятый смысл). Не могли бы вы пояснить, какую проблему вы вообще хотите решить этими исследованиями? Возможно, это было где-то в ваших предыдущих постах, но я не могу найти.
Ну, ведь, в статье все это представлено. В ВКПа в паралльном режиме имеем один результат. Он достаточно сильно отличается от двух других пакетов. А они выдают достаточно похожие результаты. Может, если их настроить они будут даже одинаковы. Но в первом приближение пусть даже так.
Я меняю режим работы ВКПа на последовательный и ВКПа выдает похожий результат. Это о чем-то говорит? Позволяет сделать вывод? Позволяет.
Во-первых, явно они работают в последовательном режиме, как и последовательный ВКПа.
Во-вторых, если бы работали в параллельном режиме, то, скорее всего, выдавали результат, похожий на ВКПа.
В-третьих, результаты последовательного и параллельного расчетов отличаются достаточно сильно. Уравнения параллельные. Решение последовательное. Оно отличается достаточно существенно от параллельного (см. расчеты в ВКПа).
Вывод. Вариант существующего расчета содержит ошибки. И в МАТЛАБ и в SymInTech. Так что, похоже, это и есть та самая "лажа". Даже с учетом их отличий друг от друга (настройки или что-то иное - не знаю)
Не могли бы вы пояснить, какую проблему вы вообще хотите решить этими исследованиями? Возможно, это было где-то в ваших предыдущих постах, но я не могу найти.
Эта проблема называется - модель параллельных вычислений. И статья на эту тему. И еще одна. Это так сказать концептуально. Остальные поясняют те или иные детали. Как и нынешняя ;) Так что если читать, то желательно читать все ;)
Вариант существующего расчета содержит ошибки. И в МАТЛАБ и в SymInTech. Так что, похоже, это и есть та самая "лажа". аже с учетом их отличий друг от друга (настройки или что-то иное - не знаю)
Еще раз. Для того, чтобы говорить о неких ошибках и "лаже" при численном решении нелинейных(!) дифференциальных уравнений путем сравнения результатов в разных средах, вы должны хотя бы, как минимум, обеспечить одинаковые условия нахождения этих решений, т.е. должен использоваться в точности один и тот же метод интегрирования, один и тот же шаг (если выбран метод с фиксированным шагом), одни и те же начальные условия. Если вы не обеспечили эти условия, то говорить о последовательных или параллельных расчетах и их влиянии не имеет никакого смысла. Ну или тогда берите в качестве "кошек" линейные ДУ, потому что на нелинейных у вас малейшая разница в условиях вылезет в существенно разных результатах (особенно в аттракторах).
Вы можете хотя бы сказать, какие методы у вас использованы в Simulink, в SymInTech и в ВКП?
И я так и не понял, зачем это все нужно. Вы столкнулись на практике с тем, что вам какой-то пакет что-то не так промоделировал? Почему вы взялись именно за специализированные пакеты (Симулинк и прочее), а не за обычный код? И как вы пришли к весьма неочевидной, замечу, мысли, что в этих моделях дело именно в последовательных или параллельных вычислениях? Кстати, если вам уж так интересно, у Симулинка есть кросс-компилятор в Си, перегоните модель в код да поковыряйте, как там вычисления идут. Правда, опять же, неясно, зачем это нужно.
Когда вы меняет реди работы в ВПК и получаете другой результат, вы обнаруживаете ошибку в ВПК. И связана она как я понял с тем, что в "паралелном" режиме появляются "теневые переменные" куда сохраняются переменные с линий связи, в итоге в результате расчета "паралелном режиме" изменение переменных на линии связи не учитывается во время такта. И считается не совсем та схема которая изображена. А какя то другая, причем какая точно, судя по всему, вам самому неизвестно. :)))
Я меняю режим работы ВКПа на последовательный и ВКПа выдает похожий результат. Это о чем-то говорит? Позволяет сделать вывод? Позволяет.
Во-первых, явно они работают в последовательном режиме, как и последовательный ВКПа.
Я бы сказал, что вывод слишком сильный и неоправданный. Если ваша программа получает тот же результат в некотором режиме - это не значит что другие программы используют такой же режим.
Возможны другие объяснения, даже более простые. Скажем, это просто правильный результат, а в режиме теневых переменных у вас просто ошибка.
Более вероятная причина - погрешности вычислений. Параллельные и последовательные вычисления различаются погрешностью, и при малом шаге разница между ними должна уменьшаться до пренебрежимой на коротких расчетах. Недостаток малого шага - большое число шагов приводит к накоплению ошибок. Это можно оценить аналитически, для разных уравнений оказываются точнее иногда параллельные иногда последовательные вычисления. Утверждать что последовательные это лажа, мягко говоря, неверно.
Не получилось :( Но, как бы, тоже понятно. Почти сразу ;) Это в ПЛК на языке функциональных блоков (кажется SFC) можно устанавливать порядок исполнения блоков. Здесь не нашел. Похоже, что нет. Хотя понимать в какой последовательности блоки исполняются было бы важно и можно было бы проверить задуманное.
приведите более жизненный пример, где в ПЛК нужно решить такую дикую задачу.
Смотрите мои статьи. У меня почти в любом проекте на ПЛК от 10 до 40 блоков, работающих параллельно. Там любые связи между ними. Хотел было собрать даже аттракторы. Но ... не нашел готового интегратора, а самому лепить что-то не захотелось, т.к. операции с плавающей точкой там проблема :(. Проблемы появляются при работе с переменными. Например, в одной цепи я изменяю сигнал (по типу Мили), а где-то цепь ниже в этом же состоянии реагирует на его значение. Решения два. Или привязать сигнал к состоянию (по типу Мура) или переместить цепь выше.
Не надо прибеднятся провинциальностью, вся Москва это понаехавшие провинциалы. Даже мэр в москве - оленевод, своего толкового не нашлось :))). Москвичи, которые настоящие, зажратые и обленившиеся. По моему опыту поездок по стране, в регионах живых и толковых людей гораздо больше. А тем более среди тех кто сложными вещами щанимается. Поэтому провинциальность это преимущество!
Разные результаты Simulinka и SimInTech вполне обьяснимы, разными метолами интегрирования, разными шагами интегрирования, разным вычислением площади под интегралом. Что бы SimInTech и Simulink совпали междусобой у них в настройках должен быть метод Эйлера и одинаковый шаг.
А вот два прогона расчета в одной среде должны совпадать.
Что до паралельности и последовательности, так в SimInTech блоки сортируются поэтому порядок расчета определяется методом сортировки.
Что значит в паралельно среде сортировака не нужна? Если на схеме последовательность блоков с линиями связи, то определить первые для расчета и зависимые блоки по любому нужно. Например блок на схеме блоки константа -> синус -> усилитель-> график. Без вычисления константы синус чего будет считатся и что выведется на график?
А вот два прогона расчета в одной среде должны совпадать.
Ну, вот и разобрались. Спасибо. Действительно, совпадает. С этим разобрались. Но не с параллелизмом. Все же есть ВКПа, которое диссонирует с MATLAB и SimInTech. Как с этим быть. Сказать, мол, ваша ВКПа и сами с ней разбирайтесь. Но как? В последовательном режиме все примерно также, как и Вашем пакете. А в параллельном режиме - другое. Магии здесь нет. Есть только, вроде бы, разные режимы работы с данными. Хотя, конечно, есть и другие отличия. Ну, например, я выход любого блока могу замкнуть на его вход и он будет работать. И не только интегратор, но и любой другой, реализующий те же отдельные операции на схеме. У Вас - это ошибка. Но, ведь, для реальных элементов это вполне допустимо.
Что значит в паралельно среде сортировака не нужна?
Это свойство параллельных процессов. Их результат не определяется последовательностью работы процессов. И, вообще, в параллельной среде такой последовательности даже нет.
Без вычисления константы синус чего будет считатся и что выведется на график?
Ровно то, что у него на входе на текущий момент. Представьте электронную схему. У ней есть последовательность работы элементов? Нет. Они работают параллельно друг другу. Вспомним аналоговые машины. У них есть блоки и схема их соединений. Есть там порядок? Нет.
Да, есть проблема начального старта. В реальных схемах для этого часто создают схему начального запуска или установки в начальное состояние. Мне, например, пришлось создавать блок, который запускал бы интеграторы одновременно. И это нормально. Это динамическая система и там все так и должно быть. В статическом варианте, т.е. при расчете, все это контролируется и запускается так, как прописано запускать блоки в ядре. В ВКПа полная "демократия", которой приходится управлять. Иначе это будет анархия и хаос. Нам это надо? Образно говоря, если в MATLAB и SymInTech - жесткий тоталитаризм, то в ВКПа - управляемая демократия :)
Хотя... тоталитаризм тоже иногда нужен. И я подумываю, что, как вариант, его хорошо бы ввести и в ВКПа. Но под контролем. Как в случае переключателя режима работы с памятью. И чтобы вычисления в ВКПа совпадали с MATLAB и SymInTech. Это чтобы снять все вопросы. Для этого, думаю, достаточно контролируемый такт (привязанный к реальному времени) нужно заменить на жесткий - заданный.
Хотя, конечно, есть и другие отличия. Ну, например, я выход любого блока могу замкнуть на его вход и он будет работать.
Я же говорю что у вас принципиально парадигма структурных схем отличается, поэтому и не возникает у вас алгебраических петель собственно (зато возникают задержки на шаг расчёта, причём на этот счёт нет никакой диагностики). Так вот для описания непрерывных систем это не годится совсем, да и для дискретных тоже не годится (из-за неявно возникающих задержек на шаг неизвестно в каким местах модели). Поэтому я говорю - доделайте сортировку модели.
Я же говорю что у вас принципиально парадигма структурных схем отличается, поэтому и не возникает у вас алгебраических петель собственно (зато возникают задержки на шаг расчёта, причём на этот счёт нет никакой диагностики).
Правильно говорить не о парадигме, а модели вычислений. Моя модель исключает мгновенные вычисления на уровне процессов. Это кибернетика, когда модель процесса представлена дискретным преобразователем. Но в пределах дискретного такта действия можно считать мгновенными (иначе они не смогу "влезть" в него. Это согласуется с реалиями, т.к. в природе нет (!) мгновенных процессов/действий. Нет и все. Так боженька придумал и ни чего с этим не поделаешь.Из-за этого в реальном мире "алгебраические цепи" - нонсенс. Все это придумали "математики", чтобы разрулить свои проблемы. Свои, а не реальных систем.
Моя модель полностью исключает понятие "алгебраических петель" и все, что с ними связано. И это тоже факт: для обычный вычислений "алгебраические цепи" и боьба с ними актуальная тема, для "моей модели" это уже пройденный этап ;)
Так что та модель, которую я использую годится для описания любых систем без исключения. Ну, как теория автоматов. Отличие только в одном - в исключении понятия "алгебраических петель". Это кибернетика.
Поэтому я говорю - доделайте сортировку модели
В реальном мире ни какой сортировки нет. В принципе. Сортировки объектов - это опять "крутеж-вертеж" обычной модели вычислений. В автоматной ВКПа в этом надобности нет. Ну, от слова совсем. Не нужна и диагностика, о которой Вы говорите. Ну, совсем. Время контролируется на уровне создания модели процесса/объекта. И определяется строго числом переходов/тактов модели. Но один такт будет всегда и обязательно. Это факт Еще раз - нет, не было и не будет мгновенных процессов. Все функциональные выражения типа у = f(x) с точки зрения реального мира - абсурд. И работают только лишь в рамках определенных ограничений. Например, на уровне действий в рамках используемой мною модели. Не зря в теории автоматов предлается две модели - комбинационная и последовательностная. Первая грубая и годится лишь для узког класса процессов, вторая - точнее и применима для всех случаев. Но у нее есть один прокол - алгебраические цепи :) Таким образом, правильно все же писать y(t+1) = f(x(t)) и забыть про всякие "цепи".
Ну так а зачем тогда непрерывную модель приводить как пример? Алг петля это по сути мгновенная обратная связь. В модели она формирует алгебраическое уравнение. В жизни этого в аналоговой схемотехнике полно.
Что значит "непрерывная", "дискретная"? Передо мной структурная схема, состоящая из блоков (MATLAB, SimInTech). У меня тоже в ВКПа есть такие же блоки. Беру, соединяю, смотрю, сравниваю. Результаты не совпадают. Что-то не то. Пытаюсь понять в чем дело. Вот "на пальцах" мои действия.
Безусловно, в схемотехнике обратных связей полно. Но там их не разрывают и не вставляют в разрыв элементы задержки. Кроме, конечно, специальных схем - типа реализации автоматов.
Это согласуется с реалиями, т.к. в природе нет (!) мгновенных процессов/действий. Нет и все. Так боженька придумал и ни чего с этим не поделаешь.
Другими словами когда я бросаю камень в воздух, сила тяжести не складывается с силой сопротивления воздуха "мгновенно", потому что боженька так придумал. А действовать начинате с какой-то задержкой, y(t+1)=f(x(t)) сначала камень летит горизонтально без сопротивления воздуха, ибо нет мгновенных процессов, через так задержки на камень начинает действовать горизонтальная состоавляющая сопротивление воздуха, и камень летит немного назад, потом, через такт задержки камень летит вертикально вниз - на него начинает действовать сила тяжести, потом, еще через такт задерржки подключается вертикальная составляющая сопротивления воздуха и камень летит немного вверх. И таким образом мы получаем правильную картину брошенного камня. вперед, назад, вниз, вверх - только так камень упадет на землю потому что парабалическая траектория брошенного камня y=f(x) с точки зрения реального мира это абсурд!
А, вот как воспринимает дискретные системы мозг затуманенный современной математикой (шутка) :)
Уравнение y=f(x), безусловно абсурд. Без учета времени брошенный камень должен мгновенно телепортировать в конечную точку своего положения. И только уравнение y(t+1) = f(x1, x2, ...xn, t) воспринимает в текущий момент одновременно (!) все входные параметры (силу тяжести, сопротивление воздуха и т.д.) и при их изменении (любого или всех вместе) в момент t+1 изменяет положение камня. И не мгновенно, а с некоторой задержкой камень изменяет свое положение. Конечно, в дискретном времени, конечно, "рывками", но ... но летит и летит миленький, пока не попадет кому-нить в лоб, например, в глаз или куда-нить еще. И чем меньше значение дискретного такта, тем точнее модель камня и любого другого объекта. опишет поведение реального камня, снаряда, самолета, подводной лодки, демпфера и т.д. и т.п. Замечу, что дискретный такт может быть сколь угодно малым, но не равным нулю. Вот как представляет мир дискретная кибернетика. Ну, что это я...? Берем Глушкова В.М., его книгу "Введение в кибернетику" и там все описано подробненько и чудненько.
Не согласен я у него только с одним пунктиком в законах поведения автоматов: q(t+1) = ... - это хорошо, а y(t) = ... - не очень. Точнее для отдельного автомата - это не имеет значения, а для сети нужно y(t+1)=... Мелочь, но как много значит. Все остальное - просто великолепно. Все-таки это Глушков, а не какой-нибудь там Виннер или фон Нейман (шучу, конечно) .Ведь были ж люди в наше Время! А книги какие писали!? ...:)
Смешно. Впервые вижу человека для которого понятие производной прошло мимо, и он сразу погрузился в дискретное исчисление. Может стоит повторит школьную программу, так где скорости и ускорение? В этом случае вы бы занили, что правильная математическая формула пописывающая любой процесс во времени и пространстве веанстве выглядит так y' = f(x1,x2, ...,хn, t). А что касается книги Глушкова, так она посвященна алгоритмам и обработки информации и об этом прямо введении написано. Вы взяли теорию для обрработки дискретной информации и прямиком в лоб применили ее к непрерывным процессам и физике! Вау это охренительная девиация. Хотя Глушков прямо пишет что он описывет обработку информации, а вы почему то решнил что так описывается весь мир.
Вау это охренительная девиация. Хотя Глушков прямо пишет что он описывет обработку информации, а вы почему то решнил что так описывается весь мир.
Вы мне льстите ;). Но, действительно, я так думаю. Для меня [на уровне "черного ящика"] нет принципиальных отличий между камнем, демпфером или системой управления атомным реактором. Различие лишь в числе входов/выходов и их инерционности (т.е. в скорости их реакции на изменение информации на входе), ну и конечно поведения, т.е. алгоритма их работы. Все это с точки зрения дискретной кибернетики есть алфавитный оператор. Будь это объект или система управления им.
Далее. Поведение алфавитного оператора задается той или иной системой правил. MATLAB, SimInTech и ВКПа - всего лишь реализуют эту систему правил. Первые два - это фактически блок-схемная модель, третья - автоматная.
Вот так "на пальцах" кибернетикой описывается весь мир - и математический и физический. А какой на самом деле мир непрерывный или дискретный физики, кажется, не знаю до сих пор. Также как спорят что такое время и какое оно - непрерывное или дискретное :) Дискретная кибернетика этот вопрос для себя решила, постановив, что оно дискретное. И в определенном смысле время это подтвердило: мы забыли про аналоговые ЭВМ, отказавшись в пользу ЭВМ современных - дискретных. Хотя вполне вероятно, что когда-нибудь ситуация поменяется:).
Т.е. в определенном смысле и непрерывная модель и дискретная модель эквивалентны. Мы пользуемся в основном дискретным представлением. Просто так много удобнее представлять и много проще реализовать. И в подтверждение это диаграмма в ВКПа Вашей задачи - поведения демпфера.
Поведение демпфера
Для разнообразия я дополнил ситуацией, когда груз убирается и система приходит в исходное состояние. Здесь я только вижу идеальное совпадение результатов ВКПа и SimInTech. Это ли не доказательство того, что и мой взгляд (см. выше Ваше "Вау"), скажем так, имеет место быть ;). Он, как минимум, дает такие же результаты, которые представлены другим взглядом - SimInTech. А в чем-то дает и другие - как в случае аттрактора Лоренца. И, надо признать, что они не верные так и не доказано. Скорее множество фактов в их пользу. Как формальных - математических, так и реальных - результаты тестирования в двух режимах.
Но, действительно, я так думаю. Для меня [на уровне "черного ящика"] нет принципиальных отличий между камнем, демпфером или системой управления атомным реактором. Различие лишь в числе входов/выходов и их инерционности (т.е. в скорости их реакции на изменение информации на входе)
На самом деле отличие принципиальное, и его на уравнении можно показать достаточно легко. Дискретность появлятеся когда мы неперывный процесс прредставляем в виде последовательного приближения в наборе ррассматриваемых точек. Это математическая абстракция. Теория пределов и дифференциальное исчислени это описание непрерывных процессов которые происходят реальном физическмо мире. Дискретная математика это приближений к этому миру. И задержки на шаг 
это способ численного описания с упрощением, непрерывного процесса. При таком описании в изменение параметров выглядит например так:
, где 
. И тут уже очевидна разница между вашей фантазийно "инерционностью"и реальным шагом по времени. По сути дела схема в квадратиках SimInTech Simulink всегда описывает преобрразований в рамках вычисления 
производной в момент времени, и для этих преобазований никаких задержек в реальном мире не происходит, силы тяжести и сжатия пружины скалдываются мгновенно и действуют постоянно без всякой дискретности. Сложнеие из двух трех или одного блока, должны выдавать абсолютно одинаковыхй результат это математика, от перемены мест слагаемых сумма не меняется, школьная программа не отменяется и никаких сказочных "инерционных" задержек тут нет. Шаг по дискретному времени появялется уже после всех вычислений. А если вы хотите получить значение с предыдущего шага расчета, наприме когда появялется алгебраическая петля, то вы указываете задержку на шаг моделирования и одновременно указываете начальные условия. Как например указывает у начальных условиях степень сжатия пружин. Другими словам задержка на шаг кванотвания в SimInTech напрямую связана с реальным временем и отражает дикретность вычисления производной непрерывных процессов. Задержка в ВКП неимеет никакого физческого смысла, для всех математических блоков. Поскольку расчетная схема, это почти всегда отражение математики, а не физических объектов в реальном. И если он смешиваются появляется "теория всего" и расчеты совпадат с реальностю только чисто случайно.
И если он смешиваются появляется "теория всего"
Вы не верите в неограниченные возможности возможности дискретной кибернетики (фон Неймана/Глушкова)? Есть область/области, где она неприложима?
и расчеты совпадат с реальностю только чисто случайно.
А приведите пример, когда обсуждаемые здесь модели "случайно" показали разные результаты?
И еще. Рассмотрим совсем простой пример. Чем на Ваш взгляд отличается дискретный элемент И-НЕ, реализованный на ПК, от "непрерывного" живого, реализованного на транзисторной логике? И какие будут "непрерывные" математические формулы, описывающие его математическую модель и в том и другом случаях?
А приведите пример, когда обсуждаемые здесь модели "случайно" показали разные результаты?
как только сумматор можно содержит в себе "инерционную" задержку при вычислении операции сложения, он сразу перестает быть простым сумматором и выдает непонятный результат. Как только выход сумматора, можно соединить с входом, без указания начального состояния блока задержки на шаг дискретизации, вы получаете бредовый результат.
чем на Ваш взгляд отличается дискретный элемент И-НЕ, реализованный на ПК, от "непрерывного" живого, реализованного на транзисторной логике?
Я именно с этого и начал. Блоки в SimInTech и Simulink это не физические элементы, а математические выражения. И у них нет свойств "живых", "инерционных", которые есть у физических элементов. Для меня вопрос звучит так чем знак + отличается от смесителя в раковине? Не знаю это разные объекты, хотя в смесители тоже складывается поток воды. А если смеситель соединить с двумя сосудами, то он еще и сложение двух объемов выполнит. Только какое это имеет отношение к математическому знаку +? Никакого. Это разные объекты, как жопа и палец.
... вы получаете бредовый результат.
Я уже, помнится, давал ссылку на мою статью на Хабре про "живую математику". Давал? Вы ее читали? Если давал и Вы ее не прочли, то ... даже не знаю что сказать :) Прочтите все-таки. Там и про сумматор и про параллельное суммирование. Ну, все по полочкам разложено. Что-то не ясно - отвечу. Но только прочтите, чтобы больше к этому вопросу (хотя бы про операцию суммирования) не возвращаться.
...Только какое это имеет отношение к математическому знаку +?
Прямое. Есть формальная операция, и есть ее реализация - смеситель. Без реализации - ну ни как. Без этого мы бы до сих пор на бумажках или счетах считали (хотя счеты - уже реализация). В программировании - это одноименная операция языка программирования (реализованная затем процессором), В АВМ - делитель/сумматор на резисторах (так, кажется). На взрывоопасных производствах вся логика управления на "воздушке" (не видел, но читал) И т.д. и т.п. Т.е. "водяная математика" это вполне то, что нам грозит, при отсутствии своих микросхем :)
А про "палец" и "жопу" - это просто гениально! :) Только все же это разные вещи. Хотя ... иногда и связанные Бывает так, что кто-то грозится пальцем, не думая о последствиях для своей ... ну, понимаете чего ;).
А статью все же прочтите. Внимательно прочтите. Если что-то, а такое бывает, не укладывается в Ваше понимание - отвечу. Все ж ведь просто, как .... сложение ;)
У меня как раз все укладывается, достаточно просто и очевидна проблема паралельного вычисления известна давно, так де как и способы борьбы с ними. Никакого отношения к физике, реальному времени, они не имеют. Все проблемы связаны с изменением общих данных, при паралельной обработке. Никакой "живой" математики там не появляется, ее просто не существует, это продукт мозга в котором пропал целый раздел математики в виде теории пределов, и диференциального исчисления. Причем специально для таких как вы Глушков в ведении пишет, что перед знакомством с данной манографией необходимы знания общих курсов математики инженерных специальностей, поскольку этм разделы в его монографии не рассматриваются. Без теории пределов и диференциального исчисления, дискретная математика превращается в магическую "живую" математику. А очевидные косяки, когда суматор вдруг можно замкнуть сам на себя и на выходе у него в начале бует ноль, обьясняются волшебными "живыми" свойствами ВКП.
Есть формальная операция, и есть ее реализация - смеситель. Без реализации - ну ни как. Без этого мы бы до сих пор на бумажках или счетах считали (хотя счеты - уже реализация).
Вот именно, есть математика, есть физика использующая математику как аппарат. Есть средства вычисления, включая бумагу, счеты, камешки и палочки. Токи в транзисторах. И когда вы длинну счетных палочек, инерцию диревянных костяшек, скорость высыхания чернил на бумаге в матформулах, пытаетесь привязать свойствам реального мира, у вас и получается "живая математика" ВКП. Я с самог начало пытаюсь обьяснить, что 2+2=4, это математика и блок сумирования в SimInTech это знак +. И его свойства описываются абстракциями. Сделали мы сложения, палочками, камешками, водой в сосудах, тзарядом транзисторах, вообще не важно, его свойства как математической операции не поменялись. А вы пытаетесь с упорством лучшего применения обьяснить мне что это аналог физического устройства с какими то физическими свойсвами и "инерционностью" и якобы ВКП это сумматор правильный "живой" а в SimInTech и Simulink нет - мертвый, в ВКП "живая" математика, потому что выдает раз разные варианты ответа, в последовательном и паралелном. Любому А почему и в чем отличип? А ХЗ, живая потому что.
Это согласуется с реалиями, т.к. в природе нет (!) мгновенных процессов/действий. Нет и все. Так боженька придумал и ни чего с этим не поделаешь. Из-за этого в реальном мире "алгебраические цепи" - нонсенс. Все это придумали "математики", чтобы разрулить свои проблемы. Свои, а не реальных систем.
Да ну? Помыслить то Вы можете мгновенно, про всю Вселенную и даже шире...
Почитайте про опыты Николая Геннадиевича Басова (1966 г.), например, про сверхсветовые взаимодействия. Цитирую:
"Здесь целесообразно упомянуть еще об одном исследовании, связанном с инициативой Н.Г. Басова. Речь идет о нелинейном усилении световых импульсов. В этой работе наблюдалось и было теоретически интерпретировано явление, которое теперь называют сверхсветовым распространением. Оптический импульс в усиливающей среде потребляет накопленную инверсию, что сопровождается ростом энергии импульса, а также обеднением энергии среды. Поэтому фронт импульса усиливается больше, чем его срез, и «центр тяжести» импульса смещается вперед, по направлению распространения. В настоящее время из подобного рода наблюдений на различных средах (усиливающих или поглощающих) возникло целое направление, а именно исследования явлений быстрого или замедленного света. Работа оказалась пионерской в этом направлении. В ее экспериментальной части использовались лазер и усилитель на рубине. Измерялось время прохождения импульса длительностью 16 нс через усилительный стержень длиной 24 см по вершине импульса, как это требуется для определения групповой скорости света. При достаточно высокой входной плотности энергии импульса (~4 Дж/см^2 ) был зарегистрирован парадоксальный для того времени результат – скорость распространения импульса оказалась в 6–9 раз выше скорости света с в вакууме! Почти через 40 лет после этих исследований сверхсветовые явления стали наблюдать и в полупроводниковых оптических усилителях."
---
А некоторые экспериментаторы комментировали свои результаты аналогичных экспериментов так: "лазерный импульс в нелинейной ячейке движется вперёд по пространству, но вспять во времени: «импульс появляется на выходе ячейки до того, как он входит в неё»"
)))
Так что в реальном мире есть процессы, протекающие ещё и побыстрее, чем "мгновенно".
Так что в реальном мире есть процессы, протекающие ещё и побыстрее, чем "мгновенно".
Телепортация в прошлое, наверное :) Ну, типа, "назад в будущее" Однако, подобный бред лучше обсудить в другом месте...
Это бред это физика, подтвержденная эксперементами
Ква́нтовая запу́танность — квантовомеханическое явление, при котором квантовые состояния двух или большего числа объектов оказываются взаимозависимыми. Например, можно получить пару фотонов, находящихся в запутанном состоянии, и тогда если при измерении спина первой частицы её спиральностьоказывается положительной, то спиральность второй всегда оказывается отрицательной, и наоборот.
Такая взаимозависимость сохраняется, даже если эти объекты разнесены в пространстве за пределы любых известных взаимодействий. Измерение параметра одной частицы сопровождается мгновенным (быстрее скорости света) превращением запутанного состояния другой.
Но автоматная модель ВКП даже груз на пружинке посчитать корректно не может, где уж тут квантовая физика.
Но автоматная модель ВКП даже груз на пружинке посчитать корректно не может, где уж тут квантовая физика.
Про "запутанность" ни чего не скажу. Вот как распутают, так, возможно, и обсудим.
Но по поводу "пружинки" просьба уточнить - в чем некорректность?
Я совместил результаты SymInTech и ВКПа и вот, что получилось:
Что не так?
А вы шаг у себя в модели и SimInTech сделайте побольше и разницу увидите скорее всего. Тут вот в чём дело: к примеру я могу работать с неотсортированной моделью и выполнять её в произвольном порядке имея при этом неявные задержки на шаг непонятно где. Но при этом даже если я получу устойчивое решение (а могу и не получить), то скорее всего мне придётся для как раз обеспечения устойчивости на шаге интегрирования пересчитывать схему не один а два раза. Вообще автоматный подход и непрерывное моделирование - это принципиально 2 разных способа моделирования. При этом я на классическую непрерывную схему моделирования, когда модель рассматривается как функция X' = F(X, u) могу натянуть и условное исполнение и конечные автоматы и дискретную логику (внутри самой функции). Автоматный же подход который вы продвигаете подразумевает, что схема разделена на независимые "параллельно" исполняемые компоненты, которые взаимодействуют друг с другом через передачу сигналов от входа к выходу. Соответственно в такой схеме я к примеру согласованно обеспечить контроль точности интегрирования и итерационный процесс, если у меня решение не сходится, по ВСЕЙ модели не смогу. Что внутри SimInTech, что внутри Simulink метод интегрирования дёргает вызов общей функции F(x, x') внутри которой уже по отсортированной модели идёт последовательный её пересчёт - т.е. вызов для каждого блока исполняемого кода. Поэтому способ моделирования должен выбираться соответственно решаемой задаче. Наличие сортировки модели и элиминация задержек на шаг интегрирования позволяет устранить численную неустойчивость и увеличить шаг интегрирования, и соответственно сократить время решения задачи на ЭВМ.
А вы шаг у себя в модели и SimInTech сделайте побольше и разницу увидите скорее всего.
Это-то понятно. Сейчас не об этом. Я как раз показал, что совпадает. Даже с учетом того, что в модели шаг 0.00001, а ВКПа - 0.001. Да и метод Адаптивный1, а в ВКПа, кроме метода трапеций, другого нет. Речь-то шла о какой-то некорректности полученного решения в ВКПа.
Я кажется понял, где в ВКП ошибка. :))))) Вы почему то сомтрите на квадратики струкутрных схем как на элементы физического мира, а это не физика, а математика. И поэтому когда вы вставляете "теневые переменные" вы просто изменяете схему рассчта, по сути дела меняете математическую формулу, причем меняете неочевидным способом, и даже сами не очень понимает что изменили. Приходится выдумывать какие то "паралелные вычисления". Все проще у вас в схеме неявно появляется задержка на такт интегрирования.
Ну, например, я выход любого блока могу замкнуть на его вход и он будет работать.
Работать то он будет, толко что он будет считать? Тайно сие виликая есть :)) Предположим вы замкнули на вход сумматор и он заработал. Алилуя! Если бы вы соединили провода или трубы в физическом мире, то воросов нет. Но у нас тут математика и у меня сразу появляются два разных варината соединения и оба правильные.
А как это происходит в SimInTech? Здесь пользователь ставит задержку на такт и обязан указатьначальное условие. И мы получаем две разные математические модели. В одном случае мы стартуем расчет с 1 на выходе и на каждом такте увеличиваем, в другом случае у нас на стартер уже двойка, поскольку цитата:
Ровно то, что у него на входе на текущий момент.
Казалось бы подумаешь, 1 или 2 дальше то все будет нормально и практически одинаково, это стартовой единичкой можно пренебреч. Но не тут то было соберем два схемы как показано на следующем рисунке, просто добави интегратор и заберем в суматор обратную свзяь после интегратора. Для ВКП это одинаковые схемы, поскольку "демократия", "свойство параллельных процессов" все дела. Вопрос что должен давать самый правый график сравнения двух процессов?
А использую я этот сумматор не как аналог физического устройства, а как математическое выражение, ну например для рассчета изменения массы жидкой фазы в двухвазной среде при давлении насыщения в точке с учетом процесса кондесации и испарения, издесь представление о электрической цепи никак не помогут.
Решил собрать схему, чтобы посмотреть воочию :) Что за блок t внизу со стрелкой назад? Не могу никак найти на панели блоков. В каком он наборе элементов?
Докладываю:)
Вот в SymInTech
Hidden text
Вот ВКПа
Hidden text
Здесь дискретные такты 1 мсек и 100 мсек. В первом случае почти идеально. Во втором - есть вопросы: зеленый график (разность) в ВКПа сдвинут заметно правее. Какой правильнее - не знаю. Но замечу все сделано в параллельном режиме. В последовательном - зеленый в нуле.
Или вот еще с двумя задержками и 100 мсек:
Hidden text
Тоже есть над чем подумать...
Признаюсь, что мне пока не понятно почему в последовательном режиме зеленый график нуле (причина-то понятна - выходы интеграторов абсолютно одинаковы). Но это, может, потому, что "последовательная карта" так ложится. Но мне главное, что в параллельном режиме все работает. Ну, а в нюансах поведения зеленого графика нужно разобраться: возможно, тут какая-то "собака и зарыта" :) Главное, что пример простой и можно, думаю, разобраться.
А мне кажется все же очевидно с этапа инициализации. Вернитесь к схеме с суматорами без интегратора. В нулевой момент времени, при замыкании выхода суматора на вход, какая величина отображается на выходе суматора 2 или 1?
В SimInTech это определяет пользователь, когда задает началные условия для задержки на такт интегрирования. В ВКП это делается "демократически" и вы похоже сами не знаете какие начальные условия вы задаете в задаче. :).
В нулевой момент времени, при замыкании выхода суматора на вход, какая величина отображается на выходе суматора 2 или 1?
То, что заложено в модели для этого момента времени. У меня это обычно ноль. По крайней мере для сумматора. И только в следующий момент на его выходе будет сумма того, что было на входах модели в момент 0. Сумматор не может считать мгновенно. Это также ясно, как и то, что телепортации нет, не было и не будет :)
... и вы похоже сами не знаете какие начальные условия вы задаете в задаче. :).
Я все досконально знаю. Для автоматов формально можно просчитать состояние системы на любом такте системы. Для этого определена операция композиции (умножения) автоматов. А можете ли это сделать Вы?
Да, ситуация еще более запущена. Вы даже в выходе сумматора не вполне уверенны, у вас на старте расчета в момент времент t=0 на выходе суматора "обычно ноль", но это не точно:))).
В кокакой следующий момент времни? На следуюшем шаге интегрирования? Вы же ведем расчет дискретно, у нас есть шаг по времени, постоянный или переменный в зависимости от метода расчета.
Если замкнуть выход суматора на вход?
Блок сумматор как набор операций для контроллера конечно требует физического время для вычисления. Но блок суматор как математическая действие, не требует никакого времени. Например, я сумирую силу тяжести и силу упругого сжатия пружины, в динамической задаче "грузик на пружинке". что бы посчитать ускорение груза. Ваш блок сумирование выдаст 0, в итоге модель с самого начала будет содержать неверные скорости и ускорения для груза. Соответсвенно использовать такой суматтор для расчета ускорения под действием суммы сил нельзя в принципе.
Я кажется понял, где в ВКП ошибка. :)))))
Вы еще не поняли - ошибки нет :)))) Действительно, любой блок для меня процесс. Он по закону просто обязан иметь задержку. Как минимум, - единичную. Другое дело, что реальная величина этой задержки может быть разная. У "мгновенных блоков" они может быть близкой к нулю (но не равной нулю), у "тормознутых" - большая. Это как у реальных элементов: есть быстродействующие и не очень. Для меня любой блок в MATLAB и SimInTech должен иметь как минимум задержку определяемую заданным дискретным тактом. Т.е. в данном случае все блоки схемы имеют одинаковое быстродействие. В ВКПа же, например, объекты могут иметь разное быстродействие.
Если бы вы соединили провода или трубы в физическом мире, то воросов нет. Но у нас тут математика ...
У Вас математика, которая не согласуется с реальным миром. Что можно сказать о ней? Только одно - плохая математика. Такую математику обязательно надо дорабатывать до адекватности реальным системам.
Работать то он будет, толко что он будет считать? Тайно сие виликая есть :))
Ни каких тайн. Все строго формально обосновано. Для меня, например, полная тайна - где Рай и есть ли Бог ;) А то, что доказывается математички формально и подтверждается реальным поведением процессов тайны уже не представляет :).
А как это происходит в SimInTech? Здесь пользователь ставит задержку на такт и обязан указатьначальное условие. И мы получаем две разные математические модели. В одном случае мы стартуем расчет с 1 на выходе и на каждом такте увеличиваем, в другом случае у нас на стартер уже двойка,
И это не правильно. Любые вчисления требуют времени. У Вас в момент времени 0 сумматоры уже что-то суммируют, устанавливая значение на выходе. Это неправильная математика. В ВКПа это произойдет как минимум только на следующем такте (может быть и позже, но только не мгновенно). И это отражает поведение сумматора, как реального процесса. И это же найдет отражение в поведении всей схемы (об этом еще будет речь).
А использую я этот сумматор не как аналог физического устройства, а как математическое выражение,...
Любое даже самое маленькое "математическое выражение" это или маленький процесс или операция в раках другого процесса маленько или не очень. И об этом необходимо помнить обязательно.Особенно когда мы реализуем не отдельный процесс, а их параллельное множество. У Вас их тут как минимум два (по числу интеграторов). Но, если посчитать блоки, то их, безусловно, девять. И последнее число - это правильно. Я так думаю! :)
Продолжаю докладывать:)
Вот что имеем, если время такта равно 0.001
Такт 1 мсек в порядке: ВКПа, MATLAB, SimInTech
А здесь 0.1
Такт 100мсек
Да, параметры одинаковые. Вот только результаты разные :( Так кому довериться?
Любое даже самое маленькое "математическое выражение" это или маленький процесс или операция в раках другого процесса маленько или не очень. И об этом необходимо помнить обязательно.Особенно когда мы реализуем не отдельный процесс, а их параллельное множество. У Вас их тут как минимум два (по числу интеграторов). Но, если посчитать блоки, то их, безусловно, девять. И последнее число - это правильно. Я так думаю! :)
Это безусловно новое слово в науке и технике, получается Matlab SimInTech столько лето обманывали доверчивый народ. Я то друак думал, что когда уменя модель груза на пружинке в виде набора блоков, совпадает с моделью на языке программирования, или в виде передаточной функции, это хорошо. А на самом деле это все неправильно! Вы только что отменили ТАУ, как науку, а Эйлер перевернулся в гробу!
Вот у меня одна и та же математическая модель грузика на пружинке записанная разным способами в среде структурного моделирования, и она законмерно дает один и тот же результат с заданной точностью, поскольку это математическая модель! Но это ошибка!!!!
В зеленом квадрате модель, использует сумматор 4-х слагаемых. Вопрос. Если заменит один блок суматора на три блока. Должна ли модель выдавать другие результаты? В SimInTech от перемены мест слагаемых суммма не меняется! Представляете и это ошибка!!!! Без ВКПа, мы об это даже не догадались бы:
В зеленом квадрате модель, использует сумматор 4-х слагаемых. Вопрос. Если заменит один блок суматора на три блока. Должна ли модель выдавать другие результаты? В SimInTech от перемены мест слагаемых суммма не меняется! Представляете и это ошибка!!!! Без ВКПа, мы об это даже не догадались бы:
Речь не об ошибке и не об отмене ТАУ, а о том, что, действительно, один блок и три блока - это разные реализации пусть и одного и того же. В статье на примере квадратичной функции я как раз эту тему подробнее рассматриваю. Модель ВКПа учитывает временные свойства блоков. MATLAB и SimInTech нет, т.е. игнорируется важное свойство реальных объектов - их инерционность. В этом проблема. Вы же тоже решаете не абстрактные формулы, которые нарушая все законы физики мгновенно что-то вычисляют. Вы моделируете поведение реальных объектов. И не учитывать временные свойства тех модулей/блоков, из которых они затем будут состоять -это не правильно. В этом причина тех различий в результатах, которые мы имеем.
Не мне Вас учить, что скорость компонентов влияет на характеристики изделия из них. И в ВКПа так. Сейчас у меня все блоки работают на одной скорости, т.е. в одном дискретном времени. Возможно, это иногда не отражает свойств модели. Но здесь надо обсуждать модель, а не принцип. У Вас получаются блоки двух видов - "мгновенные" и работающие в дискретном времени (шаг интегрирования). В этом случае, чтобы адекватно отражать Вашт модели мне надо было бы в ВКПа "мгновенные" блоки помещать в более быстрые автоматные пространства. Я не могу, к сожалению, иметь дискретное время меньше 1 мсек. А именно в нем интеграторы дают более-менее качественную картину. Поэтому их "обвес" тоже работает на этой скорости. Часто это не имеет значения, а иногда влияет на процессы. Все определяется моделью.
Вот и в последнем примере. В нем, кажется ошибка. Я тупо изменил левый верхний сумматор на оператор умножения и только тогда получил в SimInTech похожую картинку. Собрал в ВКПа. Получил аналог, но частота и амплитуда колебаний другая. Видимо, в этом случае "обвес" имеет значение. Но, может, и я что-то накосячил.
Кстати, а как у Вас создается "многовходовой сумматор"? У меня в ВКПа только на два входа и нет коэффициентов на входах. Все пришлось реализовать блоками. Нет, конечно, проблем на С++ создать многовходовой сумматор и с коэффициентами. В этом случае свойства схемы будут другие. Ну, как в упомянутой выше статье создать блок для квадратичной функции.
Еще раз. Речь не о том, что я в каком-то негативном свете хочу выставить MATLAB или SimInTech или, тем более, отменить ТАУ. Речь о том, что эти пакеты, как и теория, не учитывают временные свойства всех (!) компонент схем. Из-за этого возникают проблемы. Может не так часто как [мне бы] хотелось, но возникают. В данном случае они вылезли на примере аттрактора Лоренца (до этого на примере RS-триггера). И, честное слово, я не специально это сделал ;) Я случайно обнаружил и просто озвучил факт. А уж Ваше дело с ним соглашаться или нет. Но формально все верно. И с этим тоже уже ни чего не поделаешь. Автоматы - "понимашь", кибернетика - "чтоб ее". И ТАУ базируется на ней, а не наоборот. И поменять этот порядок я не могу. Со всем моим к Вам уважением и уважением к ТАУ. Во всем виновата теория автоматов и только она... ;).
Мне нравится ваш интузазим и попытка переизобрести ТАУ на основе теории автоматов. Но к сожалению недостаток знаний классического ТАУ и физики очень сильно вам мешает. И даже очевидное правило из математики тертьего класса (сумма слагаемых не зависти от порядка сложения) вас ничуть не смущает. Должна зависеть и точка! Ибо теория автоматов нас этому учит!
Получил аналог, но частота и амплитуда колебаний другая. Видимо, в этом случае "обвес" имеет значение. Но, может, и я что-то накосячил.
Вот здесь вы видите, что накосячили и любому кто изучал физику понятно, что получена полная фигня. Но вам и в голову не приходит, что частота и амплитуда колебаний груза на пружине, определеяются исключительно физическим свойствам объекта, силой трениям, массой груза, силой тяжести, упругостью пружины. И частота колебаний, это такое же свойство системы как масса груза и коэффициент упругости.
Модель ВКПа учитывает временные свойства блоков. MATLAB и SimInTech нет, т.е. игнорируется важное свойство реальных объектов - их инерционность.
Как раз модель SimInTech и Матлаб для груза на пружине учитывает эти свойства объекта, согласно реальным законам физики. А именно согласно законам Ньютона, и поэтому частота колебаний в модели совпадает с реальной частотой. А ВКПа учитывает какую то неведомую "инерционность" неимеющую никакого физического смысла и не существующую в природе, это просто дикретная задержка на шаг интегррирования :))) возникающая при дискретном расчете непрерывных процессов.
Вы моделируете поведение реальных объектов. И не учитывать временные свойства тех модулей/блоков, из которых они затем будут состоять -это не правильно. В этом причина тех различий в результатах, которые мы имеем.
Другим словами, используя "неправильные" блоки, я получаю частоту колебаний груза, соотвествующую реальности. Вы получаете другую частоту колебаний. Но при этом ваша блоки "правильные", а у SimInTech неправильные.
Речь о том, что эти пакеты, как и теория, не учитывают временные свойства всех (!) компонент схем. Из-за этого возникают проблемы.
Я наверное открою вам страшную тайну, но на многих динамических блоках SimInTech, и Simulink в обозначениях есть буковка Т, вы будете удивлены возможно и даже поражены, но размерность этого параметра всегда - секуды, а самое частоназвание этого параметра, Сюрприз! постоянная времени. Собирая модель в SimInTech пользователь очень часто задает именно временные свойства систем. Поэтому когда я на схему ставлю один блок "колебательное звено", я получаю точную физическую модель груза на пружинке которая отображает физические свойства реально пружины, и массы груза и силы трения.
Посмотрите на картинку, для колебательного звена постоянная времени Т задается как корень квадратный из отношения массы груза к жескости пружины. И вы не поверите но размерность этой величины секунды! Получается, что блоки динамики уже содержат временные характеристик без всякой выдуманной вами абстрактной "инерционности".
Вот здесь на пальцах показано, как физический объект "груз на пружинке" первращается в один блок SimInTech, полностью моделюрующий временное поведение, и как его можно собрать разными способами, получая одинаковую модель https://habr.com/ru/post/468967/
Ну а вот здесь в конце описано как можно получить функцию переменной времени прроцесса, используюя только дробное вырражение передаточной функции https://habr.com/ru/post/509612/ Это вобще магия ТАУ, используюя только формулы, просто из уравнения передаточной функции получаем точную формулу зависимости величины от времени. Без всяких блоков и инерционности.
Вы как-то избирательно отвечаете... Пока ответьте все же на заданный ранее вопрос о корректности схемы, которую Вы привели. Ниже я привожу Вашу и то, что в меру своих способностей создал на базе Вашей. Ваша выдает результат отличный от опубликованного Вами, моя - по форме похожий на Вашу. Все собиралось в SimInTech. В чем косяк?
Ну и опять же - где взять-то сумматор на несколько входов? Или можно настроить двухвходовой? Если что - заранее прошу прощения за мою настойчивость и весьма вероятную тупизну ;)
в свойствах суматора указывается вектор коэффициентов на которые домножаются входные сигналы, увеличитваете количество коэффициентов - увеличиваете количество сумируемых входов.
По первому варианту системы, не указаны начальные условия в последнем интеграторе, масса груза должна уравновешиватся силой сжатия пружины, поэтому на выходе из последнего интегратора должна быть позиция соответствующая сжатию пружины, которая уравновешнивает массу поршня. Получается в начальный момент времени пружина не сжата, и начинает сжиматся под действием груза с началом расчета, дальше она начинает прыгать с частотой пружинного маятника. Положение демпфера награфике инвертировано, когда график идет вверх - пружина сжимается.
По второму варианту в начальный момент времени позиция такая же но нет силы тяжести она умножена на 0. В момент времени 10 ступенькой возникает сила тяжести появляется масса и груз начинате прыгать на пружине.
В исходной задаче скачком менялась сила приложенная к поршю, поэтому амплитуда колебаний была меньше, в ваших схемах на пружину бросается полная масса поршня, поэтому амплитуда колебаний меняется, но частота кстати, сохраняется поскольку ее велиина зависит только от жесткости пружины и массы поршня.
Кстати получился хороший пример к чему может приводить ситуация, когда у вас в ВПК "демократически, по умолчанию на выходе 0 :))))" хотя в реальном мире должна быть величина соотвествующая равновесию системы.
https://habr.com/ru/post/468967/ - там описание этой модели и ее саму можно по ссылке забрать.
Сортировку модели подпили опциональную, ковбой, а то у тебя образуются неочевидные задержки на шаг интегрирования. Сумматор - это оператор сложения с весовыми коэф-ми. Код его выполнен в dll в виде соответствующего класса. Если уж охота описать схему что она вообще совсем параллельная, то в списке блоков их порядок выполнения достаточно перемешать в случайной последовательности. Но это надо на каждом шаге проделывать. Только это неправильно для описания непрерывных систем. Т.е. на большом шаге интегрирования получатся искажения которых нет реально и считать тебе придётся с очень мелким шагом. По факту такой способ расчёта как сделано в ВКПа для реальных живых АСУТП и моделирования систем непригоден.
Сортировку модели подпили опциональную, ковбой
Вы, молодой человек, взяли несвойственные для себя функции "хамоватого шерифа". Я как-то был о Вас лучшего мнения. Ошибся, бывает.
Займитесь лучше совершенствованием SimInTech. Там есть куда приложить свои силы. Уж не знаю, кто отвечает за редактор в нем, но он явно требует доработки (задолбал, если честно, ковбоя :) Уж про автоматы - это отдельный совсем разговор. Но в сравнении с MATLAB - земля и небо. И не в лучшую сторону. Так что - на коня и вперед ;)
Ну, а для "шерифов", которым не доходит с первого раза повторяю (но последний раз):
сортировка блоков параллельной среде не нужна в принципе - это качественное свойство параллельных процессов. Тут - дерзайте, чтобы было и у вас так.
задержки шага интегрирования в ВКПа нет и в помине. Он определяется дискретным временем автоматов. Это сеть автоматов, дорогой, в едином для всех автоматов (блоков, если что) сети времени.
ВКПа я использую уже много лет во всех своих реальных проектах ("живых", как Вы говорите). И ни кто еще не жаловался. Ну, а результаты моделирования смотри, красавчик, даже здесь. Пока разницы особой нет. Кроме Лоренца, конечно.
Прошу прощения, если обидел/задел тоном ответа. Но не я первый начал :)
Юмора не понимаешь, что ли? Своё я сам и доработаю, но список пожеланий приветствуется.
Я даю хороший дельный совет по улучшению вашей программы, который бы позволил использовать её для того класса расчётов, для которого вы её исходно использовать не планировали и который позволил бы избавиться от принципиальной невоспроизводимости результатов расчёта и случайных задержек на шаг интегрирования.
сортировка блоков параллельной среде не нужна в принципе - это качественное свойство параллельных процессов.
Возникает задержка на шаг при передаче данных от блока к блоку при отсутствии правильного порядка этой передачи и исполнения. Ну что тут спорить - распишите это сами на бумаге в виде последовательности операций в виде блок-схемы.
По результатам моделирования: нас заказчики за невоспроизводимость при ПАРАЛЛЕЛЬНОМ расчёте вполне себе нагнули когда-то давно и пришлось меры применять правильные чтобы сделать режим когда её не возникает.
Невоспроизводимость тут это свойство реализации в вашей системе. Её надо убрать. Задержки на шаг надо убрать. Индикацию где эти задержки могут возникнуть сделать. Нам заказчик на букву А за задержки на шаг предъявлал когда-то, тоже принимали меры чтобы их избежать и указать путём модификации сортировки модели.
Примеры приведите, где применяли программу свою ? Мне странно что подобные вопросы не возникали.
Я извиняюсь, что не посмотрел ваш возраст в профиле. Думал что спорит студент очередной. Просто какие именно проблемы возникают при параллельном расчёте двух систем я в курсе. Везде где это возникает принимают меры по устранению невоспроизводимости, к примеру в тренажёрах или комплексных моделях делают строго последовательную запись данных в ячейки которые потом являются входами для других моделей с буферизацией. Насколько я понимаю ограничение кванта в 1 мсек у вас идёт от разбиения на потоки в ОС? Если это так, то ни о каком параллельном расчёте сразу всех блоков говорить не приходится.
Да ладно... проехали ;)
Просто какие именно проблемы возникают при параллельном расчёте двух систем я в курсе.
Если и знаете, то, похоже, только в рамках существующих подходов. Там, действительно, полный бардак. Параллелизм на автоматах - однозначен. Опять же. Все это (про параллельную модель вычислений) описано в моих предыдущих статьях здесь на Хабре. Все ж сотню раз озвучено и много раз строго доказано;) Точнее уже просто быть не может. Попробуйте найти ошибку - скажу спасибо. Сам я уже не найду, да, если честно, и не ищу уже :)
Насколько я понимаю ограничение кванта в 1 мсек у вас идёт от разбиения на потоки в ОС?
Абсолютно нет. Весь параллелизм - в одном потоке. И 1 мсек определяется только его вычислительными ресурсами и реализацией. А она может зависеть и от языка. Например. На С++ в Visual studio было 0.02 мсек. А после перехода на Qt такой же код на том же С++ - 0.2 мсек. И таймер (от библиотеки Intel TBB) там много лучше держит. Но ... пришлось уйти на Qt. Многоплатформенность и библиотека не MFC ;).
Так что для реализации параллелизма не нужно ни множества потоков, ни множества ядер. С этим, понимаю, трудно согласиться, но - это, проверьте, именно так. Главное - вычислительная модель. А сколько коней в тачанке - это не главный врос. Бывает, когда лучше один, но крепкий и выносливый. А три "дохляка" могут и с места не стронуться.
Ну так если у вас один поток и при этом нет воспроизводимости значит что то явно сделано не то (скорее всего с начальными условиями). Ну я пока вижу, что данная вычислительная модель не для всего пригодна. Как бы в структурных схемах вполне однозначно описано как их считать. Вообще при моделировании никому не интересны как правило быстрые переходные процессы в логических элементах. А когда интересны, то модели используют с учётом их физики (ёмкости затвора к примеру). Например никого не волнует внутреннее устройство rs триггера, а волнует только логика его работы, которая задаётся вполне однозначно и вполне однозначный результат даёт. Мне просто думается, что применённый вами подход как минимум неоднозначен и приведенную задачу им просто решать нельзя. А главное : а зачем вам системный таймер при моделировании? Он у вас что влияет на результат расчёта? Тогда как бы это не математическое моделирование уже несколько, а скорее имитационное, и что оно имитирует неочевидно.
Ну так если у вас один поток и при этом нет воспроизводимости значит что то явно сделано не то (скорее всего с начальными условиями).
Да нет. Воспоизводимость есть. Точнее ее можно сделать. Просто в рассматриваемых примерах используется интегратор, а есть шаг немного плавает, то это и сказывается на результате. Когда я "забил" неизменный шаг интегрирования, то воспроизводимость получилась идеальная. Но так не очень правильно с точки зрения физики работы модели. Короче, это сложнее рассказать, чем сделать. Попробую по-другому. Интегратор берет текущий шаг. Пусть он задан 1 мсек.. Реально он будет +- что-то пусть 0.001. Соответственно плавает и рассчитанная площадь. Если и при расчете беру не реальный такт, а число 1 мсек, то и площадь будет без погрешности. Ну, вот так, если понятно.
Например никого не волнует внутреннее устройство rs триггера, а волнует только логика его работы, которая задаётся вполне однозначно и вполне однозначный результат даёт.
Это не так. Подробнее в моих статьях про него. Не поленитесь перечитать.
А главное : а зачем вам системный таймер при моделировании? Он у вас что влияет на результат расчёта?
Влияет не он я величина дискретного времени, которую нужно выдерживать, что смоделировать реальную работу того же интегратора. Чем меньше такт, тем точнее результат интегрирования. Это-то Вам надеюсь не надо пояснять? ;).
что оно имитирует неочевидно.
Почему? Иммитирует работу модели в реальном времени. Что-то похожее делается в SimInTech, когда устанавливается флажок - синхронизировать со временем.
В SimInTech от флажка меняется только физическое время расчёта, но никак не результат. Он для этого и нужен. Этим модель отличается от управляющего контроллера для которого данные идут с физических устройств. Но этот уже другая схема моделирования : hardware in the loop
Я все-таки хочу добить этого Лоренца:) Тогда, может, Вы проясните, что не так.
Я резко упростил расчет, удалив все входные блоки, оставив только блок интегратора. Теперь все считается внутри него. Но результат все равно не совпадает с SimInTech/MATLAB. Вот расчет для Z (для X, Y только формулы разные). Код "вырезан" из С++
// читакем параметры интегратора
double dConst = pVarConstant->GetDataSrc(); // начальное условие
double dKx = pVarKx->GetDataSrc(); // коэффициент усиления
dT = pVarStep->GetDataSrc(); // шаг интегрирования
// считаем формулу на входе интегратора
double dY = dInX*dInY - dInB*dInZ; // расчитать формулу
// считаем площадь
double dS;
dS = (dT * (dPreviousY + dY))/2; // рассчитать площадь
dIntegrator += dS; // текущее значение интеграла
//
dY = dIntegrator*dKx; // "усилить"
dY += dConst; // добавить начальное условие
dPreviousY = pVarInX->GetDataSrc(); // сохранить значение входа
//
pVarOutY->SetDataSrc(this, dY);
Все сводится к параллельной (или последовательной) работе трех подобных функций. Да, dInX, dInY, dInZ и dInB - это входные текущие параметры. Соответственно dY - выходное значение.
любой блок для меня процесс. Он по закону просто обязан иметь задержку. Как минимум, - единичную
По чьему закону? В математике действие 2+3=5 не привязано ни ко времени, ни к пространству (физическому), и не имеет никакой задержки. Соответственно, в Симинтеке/Матлабе/... не все блоки суть одного ранга (как ваш "процесс").
Математика более абстрактна, а Физика (Ньютоновская по крайней мере) более приземлённа/материальна. И если вы будете математику поверять физикой, и вносить абсолютно в каждое математическое действие инерционность, задержку и распараллеливание... То боюсь и в школьных решебниках тоже все ответы надо будет выкидывать, или задавать для них "невязку параллелизма".
То боюсь и в школьных решебниках тоже все ответы надо будет выкидывать, или задавать для них "невязку параллелизма".
И тут Вы почти угадали. Действительно, многие проблемы начинаются именно с "консерватории" :)
Немного философии. Я будучи физиком ядерщиком по образованию, попал после института в Курчатовский Институт, и занимался программированием. Уже тогда общаясь с программистами, я вывел теоррию, о том, что программирование рушит мозг и когнитивные способности человека по осознанию внешнего мира. Чем лучше программист, тем хуже унего с осознанием внешнего реального мира. Ваш пример отличная иллюстрация, почитав академика Глушко вы уже готовы отменит школьную программу по математике, поскольку в тетрадке 2+3=5 не учитвает "инерционности" блока сложения, так как это учитвает "живая математика" ВКП.
... 2+3=5 не учитвает "инерционности" блока сложения
Для школы это простительно ;)
Чем лучше программист, тем хуже унего с осознанием внешнего реального мира.
Нельзя, думаю, Ваш субъективный опыт и взгляд на программистов обобщать на весь остальной мир. Нужна выборка побольше.
Ну по хорошему вы тогда должны моделировать по честному количество тактов выполнения операции в процессоре и точно симулировать собственно железо. На уровне программы внутри контроллера никакой инерционности сложения учитывать не надо. Вообще как бы все понимают, что к примеру в процессоре операция сложения занимает определённое к-во тактов, также как и про то что к примеру есть спекулятивное выполнение. На разных уровнях рассмотрения задачи подходы к моделированию различаются. Поэтому в приведённой задаче никакой неопределённости быть не должно - она рассматривается как непрерывная.
И все-таки. Что можно сказать про мой код на С++ выше?
Как я понял, к коду, кроме как по поводу выбора метода интегрирования, замечаний нет? И чем не устраивает в этом случае метод трапеций?
нет контроля ошибки, и код считает с постоянным шагом, поэтому когда скорость изменения в процессе большая ошибка увеличивается и накапливается. Методы с переменным шагом контролирую ошибку, и снижают шаг по времени, когда скорость изменения большая.
нет контроля ошибки, и код считает с постоянным шагом ...
Мне так и не ответили - есть ли в SimInTech метод трапеций? Мне бы хотелось все же получить такой же результат, но ... Это единственное, что осталось сделать :) Пока же я сделал следующее:
Чтобы не было вопросов по задержкам свел все вычисления для каждого уравнения соответственно в один блок (см. выше код на С++)
Перемешал блоки в последовательном режиме. Для этого сделал три конфигурации, где первым вычисляется тот или иной интеграл. Получил следующие результаты
В порядке вычисления первыми интеграла X, Y, Z Эти же конфигурации прогнал в параллельном режиме. Сравните с верхними результатами.
В общей части подсистемы моделирования входо-выходных моделей метода трапеций нет, но есть более точный метод Гира из неявных. Результат следует сравнивать вам или с методом Гира или с Адаптивный 1, 3 . Список методов доступен по нажатию кнопки параметров расчёта на схемном окне. Разные графики при перемешивании как раз и отображают разные задержки на шаг в разных вариантах. Дело в том что интеграторы при непрерывном моделировании должны являться приоритетными блоками. Т.е. они свой выход формируют первыми, потом от них по цепочке пересчитываются функции, потом, для всех интеграторов вычисляются производные зависящие от входов, потом эти производные поступают в метод интегрирования и с него проинтегрированные величины идут на выходы интеграторов, потом цикл повторяется.
Т.е. схема расчёта в общем такая:
X=Xo
While(1) {
Расчёт выходов блоков
Y = Fouts(X)
Расчёт производных
X' = Fderi(Y)
Интегрирование непрерывных частей
X = X + X' *h;
}
Т.е. как бы расчёт многостадийный и выход интегратора не обновляется сразу после его пересчёта, а обновляется через его внутреннюю переменную состояния.
нормальный код с постоянным шагом, судя по всему. Контроля погрешности нет. Поэтому когда скорость изменения большая, соотвественно растет ошибка. Поскольку система замкнутая. Если сделать переменный шаг и уменьшать его на участках процесса где производная большая можно получить более точный результат
нормальный код с постоянным шагом, судя по всему.
Это уже обнадеживает. И хотя, шаг, действительно, постоянный, но ни что не мешает сделать его переменным, поскольку он (шаг) определяется внешним "миром".
Поэтому когда скорость изменения большая, соотвественно растет ошибка.
Но у меня создается ощущение, что дело не в ошибке, а в том, что с изменением шага изменяется вид графиков. И это не похоже на какой-то алиассинг. Может это бред, конечно, но вот как-то так думается и все тут;) Поэтому изменение шага в таком случае больше повлияет на вид, чем на точность. Исходя из этого для адекватного сравнения нужно было бы применять и одинаковые алгоритмы интегрирования. Начиная с самого простого - метода трапеций...
Но опять же. Дело, как представляется, совсем не в точности или форме графиков. Алгоритм Лоренца, похоже, "истинно параллелен". Т.е. как тот же триггер: как ни сортируй, а в последовательном варианте счета истинный результат не получить. И здесь также. Последние эксперименты в этом дополнительно убеждают.
Конечно, более сложные варианты счета (как описано выше в SimInTech) могут "угадать". Хотя, как тут угадаешь? С "истинным параллелизмолм" такой вариант не пройдет. Был бы в SimInTech "параллельный вариант" расчета, это было бы выявлено "по щелчку". Для этого не так уж много и надо - помещать выходные значения в буфер, а в начале следующего цикла вытаскивать. И сортировать при этом не надо даже.
Вот как-то так представляется, если не окончательный, то хотя бы промежуточный итог наших "бесед" ;)
А код, действительно, настолько простой, что хоть на ПЛК реализуй. Была бы только у них (на тех ПЛК, что у меня в работе) нормальная плавающая арифметика. Есть, правда, вариант уже и с ней, но пока текучка не дает отвлечься и попробовать. Короче, ситуация - работа мешает докопаться до истины :)
Для этого не так уж много и надо - помещать выходные значения в буфер, а в начале следующего цикла вытаскивать. И сортировать при этом не надо даже.
Это не так, т.к. значения входов блоков которые являются мгновенными функциями должны быть рассчитаны на текущем временном слое. Для этого их и сортируют.
...Для этого их и сортируют.
Я расскажу Вам как это сделать без сортировки. И не раскрою при этом какого-то секрета, т.к. это достаточно известный алгоритм (может, Вы даже его знаете). Во-первых, нужно провести цикл расчета, помещая выходные значения блоков в буфера. Затем провести еще один такой же цикл расчета, но с входными значениями, вытащенными из буферов. Если выходные значения совпадут с предыдущими, то на этом можно закончить расчет. Если есть несовпадения - делаем еще один цикл. И так пока расчет не устаканится. Так исключаются гонки данных. При этом количество циклов расчета будет равно (или +1?) самому длинному пути в блоках от входа до выхода.
Что примечательно, этот алгоритм будет корректно работать даже при наличии алгебраических связей. Сортировка же в подобной ситуации бессильна. Опять же известно почему. Ответ - в отличиях комбинационной модели дискретных схем от их же последовательностной модели. Это, конечно, другая математика - дискретная. Но это тоже математика.
Ну вот чтобы схему не считать вместо одного два раза её и сортируют. При наличии алгебраических петель система будет считаться у вас так, как будто вы петлю развязывание блоком задержки на шаг. Да и сходимость такого способа расчета будет обеспечиваться не всегда. К слову такой механизм используется в simintech для установления размерностей при инициализации схемы, но естественно после сортировки.
О программных ошибках на примере MATLAB и SimInTech