Могу ли я добавить или удалить переменные проекта из задачи после вызова setup()?
У меня есть проблема оптимизации смешанных целых чисел, которую я пытаюсь решить. Я безуспешно пытался решить проблему с помощью штрафных методов и хочу попробовать некоторые альтернативные методы. Из того, что я могу сказать, некоторые варианты — это AMIEGO, GA и решатель типа ветвей и границ (BNB). Меня особенно интересует подход BNB, но я не вижу ветки и привязанного драйвера или решателя в OpenMDAO (https://openmdao.org/newdocs/versions/latest/features/building_blocks/drivers/index. html?highlight=драйверы). Однако базовую реализацию написать относительно просто. Из того, что я тестировал, алгоритм BNB начинается с решения упрощенной задачи, к которой добавляются ограничения для последующих решений, пока проблема не сходится к целочисленному решению.
Моя проблема в том, что мне нужно вызывать setup() каждый раз, когда мне нужно добавить новое ограничение к проблеме. Обычно это было бы нормально, но процесс установки для моей проблемы довольно долгий. Можно ли добавить ограничения или проектные переменные к задаче после вызова setup(). В документации я вижу, что есть связанные функции configure() и final_setup(), которые могут быть полезны? Однако, если честно, я не совсем понимаю их полезность. Или вы бы порекомендовали мне подойти к разработке драйвера BNB каким-то другим способом?
Я надеюсь, что это имеет смысл, и заранее спасибо за любой совет, который вы предлагаете.
Трудно догадаться, почему ваша установка такая дорогая, но это не очень частое явление. Я дал очень общий ответ, но если вы можете предоставить пример кода, показывающий структуру вашей модели и почему она такая дорогая, я смогу дать более конкретный ответ.
Я добавлю код, если предложенные вами предложения не сработают. Модель довольно большая (10-15 деталей) так что не знаю что именно было бы полезно показать....
Ответы 1
Процесс setup идет сверху вниз. Процесс configure идет снизу вверх. Основной вариант использования configure — это ситуации, когда родительским группам необходимо получить некоторую информацию от своих дочерних элементов, прежде чем завершить настройку своего ввода-вывода или соединений. configure происходит после того, как вся иерархия модели завершена, и, следовательно, вы уверены, что любой слой дерева ниже вас завершен и уже полностью настроен.
final_setup — это самый последний шаг в процессе, когда OpenMDAO знает, что все операции ввода-вывода и соединения полностью выполнены. Таким образом, он может выделить память, необходимую для работы модели.
Пользователям обычно не нужно вызывать final_setup себя, так как OpenMDAO вызовет его прямо перед тем, как ему действительно нужно будет выполнить какую-либо работу. Есть несколько угловых случаев использования, когда люди сочли полезным полностью выделить память перед вызовом run_model или run_driver --- поэтому мы сделали метод общедоступным.
Однако ни один из этих методов не является решением вашей проблемы. Я немного удивлен, узнав, что ваш процесс установки стоит дорого. Работа, которую OpenMDAO выполняет во время установки, не требует больших вычислительных ресурсов, и мы обычно не видим огромных затрат на установку. Есть несколько раз, когда я видел, что это становится дорогостоящим, хотя. Это случаи с сотнями или тысячами отдельных компонентов и переменных. (Модели со многими экземплярами модели pyCycle являются одним из примеров, где это может произойти). Стоимость установки зависит от количества компонентов/групп/переменных. Поэтому, если у вас высокая стоимость установки, возможно, у вас есть такая модель.
Если это так, мы обычно обходим эту проблему, используя подзадачи. Для модели верхнего уровня, в которой было много копий термодинамической модели pyCycle, мы бы взяли группу моделей pyCycle и вставили ее в подзадачу внутри компонента. Ограничивая общую глубину модели высшего уровня, можно добиться существенной экономии. Я видел, как время установки этого сброса сократилось с минут до секунды.
Или, возможно, у вас есть какие-то другие вычисления, не связанные с openmdao, которые выполняются один раз в setup() и которые вы не хотите повторять. В этом случае я мог бы рассмотреть возможность переноса этих вычислений на какой-то предварительный шаг, который вы можете выполнить вне установки OpenMDAO и просто использовать повторно.
Последний вариант, если вы действительно не можете найти способ сделать затраты на установку более доступными, — это использовать функцию, которая позволяет вам изменять границы DV и ограничений после установки. Здесь фактические DV и сами ограничения (то есть переменные, на которые они указывают) должны быть созданы во время установки. Но вы можете создать границы, которые эффективно зафиксируют их на месте (установите верхнюю и нижнюю границы на одно и то же значение), когда вам нужно будет ограничить что-то еще. Эта функция есть в OpenMDAO поверх версии 3.23 --- она была предложена в POEM 72. Я скажу, что я думаю, что этот метод, вероятно, будет несколько сложным. Если вы просто ограничиваете переменные дизайна, то это, вероятно, будет работать нормально. Однако задачи с чрезмерными ограничениями с очень жесткими ограничениями на выходные данные немного сложнее в численном отношении. Вы фактически создаете ограничение равенства, не сообщая об этом оптимизатору. Возможно, вам повезет больше, если вы допустите небольшую разницу между верхней и нижней границами выходных ограничений.
В целом, я рекомендую вам найти способ ускорить ваш вызов установки либо с подзадачами, либо путем перемещения дорогостоящих вычислений из стека установки OpenMDAO и выполнения их только один раз (возможно, какой-то объект конфигурации верхнего уровня, который вы могли бы передать в свой модель как вариант). Если вы не можете этого сделать, возможно, вы можете заранее добавить все ограничения/dvs и управлять их активацией через изменение границ.
Спасибо за подробный ответ. Это очень полезно. На самом деле я немного знаком с подходом к подзадачам, но не рассматривал возможность его использования в данном случае. Мне придется вернуться к этому, если эти другие подходы не сработают. Моя проблема связана с dymos, поэтому я думаю, что на самом деле она может быть довольно большой, но я все равно дважды проверю свои методы настройки компонентов и время их. У меня там есть несколько одноразовых вычислений, но я думал, что они были относительно безобидными.
Эта функция в OpenMDAO v3.23 — это именно то, что я ищу (спасибо, я не смог найти эту деталь в документации!). Однако я не совсем понимаю утверждение «Вы фактически создаете ограничение равенства, не сообщая оптимизатору, что вы это делаете». Вы говорите, что решатель будет интерпретировать lower=1,upper=1 и equals=1 по-разному? В таком случае я должен сделать lower=1-epsilon,upper=1+epsilon...
Я только что заметил, что set_design_var_options и set_constraint_options не работают, если аргумент indices=[] использовался в исходном вызове add_design_var и add_constraint... Похоже, мне нужно очистить() мои функции настройки.
это похоже на ошибку. Я сообщил об этом здесь: github.com/OpenMDAO/OpenMDAO/issues/2775
Я хотел продолжить после некоторой дополнительной отладки на основе ваших предложений, и похоже, что мои setup() функции не проблема. В настоящее время мой звонок на prob.setup() в среднем составляет около 7,0 с. Из того, что я понял, ~ 0,1 с вызывает функции setup(). Подавляющее большинство времени установки (~ 6,5 с) тратится на ._configure() в group.py. В частности, проблема заключается в configure() в Phase.py, когда вызывается transcription.configure_timeseries_outputs(self). Есть еще одно небольшое замедление в вызове функции настройки траектории (оценка 0,2 с).
Также у меня dymos 1.2.0 и openmdao 3.16.0. Я пытался обновиться до более новых версий, но по какой-то причине моя проблема в более новых версиях работает значительно медленнее. Могу ли я предоставить какую-либо дополнительную информацию, которая могла бы лучше помочь вам понять, что именно здесь происходит? Кроме того, если у меня возникают проблемы с функциями настройки dymos, я не знаю, обязательно ли будет правильно работать компонент упаковки проблем? Может если завернуть всю проблему dymos?
без какого-либо рабочего примера кода трудно дать более конкретную поддержку. Я никогда раньше не видел, чтобы метод dymos configure был узким местом, но это почти наверняка означает, что у вас МНОГО различных переменных, которые вы интегрируете. Вы создали большое количество скалярных переменных? Если это так, попробуйте вместо этого объединить их в массив.
Если вы можете поделиться своей моделью, вы можете попробовать отправить вопрос непосредственно в репозиторий Dymos. Я уверен, что они хотели бы увидеть созданный вами случай, который выявляет какое-то узкое место.
У меня не так много скалярных переменных. Почти все является либо матрицей, либо вектором. Но у меня есть относительно большое количество переменных в задаче о dymos. Я думаю, что я должен иметь возможность поделиться своим кодом. Должен ли я просто поместить все в файл .zip и просто загрузить его в репозиторий Dymos?
открыть тему на dymos. Если у вас есть куча файлов, возможно, сделайте с ними общедоступный репозиторий и дайте ссылку на него в выпуске dymos.
Сможет сделать. Я постараюсь добраться до него в ближайшее время.
Если вы заинтересованы в OpenMDAO, то, возможно, проблема заключается в том, «как я могу сделать инкрементную настройку () менее дорогой?» То есть, учитывая проблему P и связанную с ней проблему P', которая имеет одно дополнительное ограничение, как мы можем минимизировать количество материала, который необходимо пересчитывать с нуля? Но вы не показали нам никакого кода, так что непонятно, что могло быть закешировано или дешево получено.