Вы задали три вопроса. Я собираюсь ответить на них отдельно (и немного перефразировать):
1) Какую архитектуру MDO вы используете, когда решаете проблему (обычным способом) в OpenMDAO?
Если вы посмотрите на статью Мартинса и Лэмба об архитектурах, вы увидите, что они делят их на монолитные c и распределенные классы. Когда вы используете OpenMDAO, вы почти всегда применяете некоторую форму монолитной c архитектуры оптимизации. На практике многие люди заканчивают тем, что применяют что-то, что очень похоже на MDF, потому что у них есть решатели в их моделях, но я также часто видел гибриды MDF / IDF, SAND и даже аспекты AAO к проблемам.
В широком смысле я бы сказал, что гибкость OpenMDAO позволяет вам пересмотреть вашу модель так, чтобы любое конкретное ограничение равенства могло быть обработано либо решателем (например, MDF), либо ограничением совместимости (например, IDF), или непосредственно как ограничение равенства оптимизатором (как SAND) означает, что пользователи могут гибко создавать гибридные формы различных монолитных c архитектур.
Можно реализовать распределенные архитектуры с OpenMDAO, используя вложенные экземпляры класса OpenMDAO Problem для подзадач в модели верхнего уровня. Это не тривиально, но возможно. Этот подход часто имеет одну серьезную проблему: проблема оптимизации верхнего уровня потребует производных по всем подзадачам, чего на самом деле не может обеспечить OpenMDAO (потому что он требует вычисления чувствительности после оптимальности, которая является нетривиальной и выходит за рамки of MAUD)
2) Каково отношение MAUD к архитектурам MDO?
Эти две концепции являются отдельными вещами, которые имеют отношение друг к другу, но никак не связаны тоже самое.
- MAUD - это определенный c способ вычисления производных по произвольной суперфункции, которая состоит из набора подфункций, соединенных вместе.
- Архитектура MDO a представляет собой преобразование формулировки задачи фундаментальной оптимизации в конкретную форму c, которая разрешима (подробности о том, что я имею в виду, см. В статье Pate et al. «формулировка задачи фундаментальной оптимизации»). В какую бы форму вы не преобразовали задачу, для этого потребуются производные функций цели / ограничения, которые можно вычислить так, как вы хотите (возможно, с использованием MAUD / OpenMDAO или, возможно, нет).
3 ) Является ли предыдущий бенчмаркинг архитектур, выполненный в OpenMDAO, все еще действительным?
По моему мнению, бенчмаркинг, выполненный в статье на основе OpenMDAO, на которую вы ссылались , подкрепляется этим другим бумага от Тедфорда и Мартинса , которая вообще не использовала OpenMDAO, но я думаю, что это также актуально. Лично я не ожидаю, что ответы значительно изменятся, если вы попытаетесь решить новые проблемы. Эти две статьи, похоже, согласны с тем, что монолитные c архитектуры (AAO, SAND, MDF, IDF) являются наиболее эффективными и наиболее согласованными среди всех.
В некоторых случаях распределенные архитектуры работают хорошо, и группа из Европы добилась определенных успехов с ними для конкретных c проблем. Посмотрите этот документ от Газе и др. в качестве примера.
Так что, если вы действительно интересуетесь архитектурами, я бы предложил вам найти способ создания определенных c классов задач, которые хорошо работают при разных архитектурах, а затем представить такую классификацию в документе. В случае успеха это может быть хорошим ресурсом для будущих исследователей / практиков, которым необходимо решить, какую архитектуру использовать. Тем не менее, я считаю, что в подавляющем большинстве случаев монолитные c архитектуры будут работать лучше всего. Я подозреваю, что вам будет трудно заставить распределенные архитектуры работать хорошо в широком диапазоне случаев. Газета Gazaix доказывает, что, безусловно, можно получить полезные результаты от распределенной архитектуры MDO, но не доказывает, что она будет быстрее, чем эквивалентная монолитная c формулировка.