Если у вас есть модель только с экземплярами ExplicitComponent, то ситуация немного сложнее и становится намного сложнее обеспечить практическое правило.
TL; DR: реальность такова, что при использовании числовых приближений для производных «лучшее» решение сильно зависит от модели. Вообще говоря, если есть какие-либо ImplicitComponents с истинно нелинейными решениями, то вам лучше использовать полуаналитический метод. Если у вас есть модель только подачи с явными компонентами (без мошенничества, хотя обернутые инженерные коды часто бывают неявными) без использования решателей OpenMDAO для объединения междисциплинарной связи, то вы могли бы получить быстрее быстрее с монолитным FD (хотя полуаналитический подход, как правило, будет здесь более точным)
Вычислительные компромиссы становятся намного более понятными, когда в вашей модели есть экземпляры ImplicitComponent. Итак, давайте сначала рассмотрим это. Чтобы упростить задачу, давайте рассмотрим модель только с одним экземпляром ImplicitComponent, который предоставляет собственный внутренний метод solve_nonlinear. Здесь у вас есть два варианта:
1) традиционный метод FD, который вычисляет d_outputs / d_inputs путем выполнения шагов по методу solve_nonlinear. Это будет включать в себя повторное сближение модели для каждого приближения FD (один раз для каждого входа).
2) полуаналитический FD, который вычисляет частичное_входы / частичное_входы, выполняя шаги по методу apply_nonlinear, а затем полагаясь на возможности аналитических производных OpenMDAO для вычисления итогов для вас.
Для варианта 1 существует несколько проблем, таких как шум сходимости решателя (зависит от допуска решателя), вычитаемое аннулирование и вычислительные затраты на повторное схождение для каждого шага. Если у вас было очень дорогое нелинейное решение (т. Е. Стоило позвонить solve_nonlinear), тогда этот подход может быть очень дорогим, особенно если у вас много входов. Кроме того, вы должны быть в состоянии гарантировать, что решатель будет сходиться для каждого вашего шага, в противном случае вы не получите никаких производных. На практике эту гарантию трудно изготовить, поэтому существуют проблемы с числовой стабильностью.
Для варианта 2, даже если у вас есть МНОГИЕ более неявные переменные, с которыми вы имеете дело, вы вызываете только apply_nonlinear, что, как правило, на несколько порядков быстрее, чем полное нелинейное решение. Это также не будет страдать так много числовых вопросов. Гораздо проще гарантировать, что вы получите действительную остаточную оценку, чем полностью сходящееся нелинейное решение, так что проблема стабильности практически устранена. Кроме того, вам не нужно беспокоиться о шуме, возникающем из-за слабых допусков решателя. Если вы используете FD, вы все равно будете страдать от вычитания мелких шагов, но это единственная реальная слабость (и это можно устранить с помощью CS).
Это правда, что для варианта 2 у вас может быть гораздо больше шагов FD, поскольку вы теперь принимаете частные производные по многим дополнительным переменным. Однако, поскольку apply_nonlinear намного дешевле в балансе, это работает в вашу пользу.
Теперь вернемся к вашему первоначальному вопросу, касающемуся больших моделей всех явных компонентов. Здесь у вас есть более сложный набор компромиссов. Сначала давайте предположим, что все ваши явные компоненты являются простыми аналитическими функциями (то есть ни одна из них на самом деле не вызывает какой-либо нелинейный решатель или внешний технический код).
Здесь вы не столкнетесь с проблемой численного шума из-за допустимого отклонения. и если у вас мало проектных переменных, вполне вероятно, что при вызове FD в верхней части вашей модели произойдет наименьшее количество вызовов функций. Это может дать вам самую низкую стоимость FD, но зависит от точности FD это также может привести к увеличению числа итераций оптимизации и повышению общей вычислительной стоимости.
Но, монолитный FD также затрудняет выбор подходящего размера шага, потому что разные компоненты будут выполнять разные вычисления и в идеале иметь разные оптимальные размеры шага. Поскольку вы можете выбрать только шаг в самой переменной проекта, вы застряли на том, что распространяется через вашу модель. Таким образом, вы можете получить менее точные итоговые (или полу-итоговые, если вы делаете это в середине модели) производные, которые требуют от вас больше оптимизационных итераций.
Теперь, если мы немного ослабим наши предположения о природе явных компонентов и скажем, что действительно существует инженерный код с его собственным внутренним решателем, обернутым где-то в модели ... то, что у вас действительно есть, есть неявный компонент о чем вы не сказали OpenMDAO. Итак, еще раз, здесь было бы лучше обернуть это как неявный компонент (выставляя остаточный расчет). В этом случае вы не можете монолитно FD модели, все еще используя полуаналитический метод. Так что здесь, вы обычно предпочитаете FD каждый компонент в отдельности. В статье 2014 года под названием «Автоматическая оценка междисциплинарных производных с использованием формулировки задачи на основе графиков в OpenMDAO» мы показали именно это. Даже если вы используете FD для самого дорогого анализа (решатель FEA) с тоннами входных данных, полуаналитический метод все еще намного быстрее по сравнению с монолитным FD.
Еще одно преимущество полуаналитического метода, который я еще не затрагивал, заключается в том, что он позволяет смешивать FD, CS и аналитические производные. Вы можете начать с полного fd, перейти к CS для некоторых ваших более нелинейных вычислений, а затем, когда ваше развитие замедляется, начать добавлять аналитические производные. Каждый раз, когда вы обновляете свои производные, вы будете видеть увеличение производительности.
Таким образом, даже если вначале полуаналитический метод работает медленнее, он предоставляет вам путь к обновлению, которого никогда не сможет обеспечить монолитный подход FD.