#openmdao
#openmdao
Вопрос:
У меня есть ODE, заданный в форме, где x, u и d являются векторами (например
). Я сформулировал эту систему в OpenMDAO / Dymos, используя размерные входы и выходы
self.add_input('x',shape(num_nodes,Nx))
для состояний Nx. Смотрите: https://openmdao.github.io/dymos/getting_started/defining_odes.html ?выделить = размерные #размерные-входы-и-выходы
Мои ODE и траектория работают хорошо, однако мне интересно уточнить некоторую информацию:
(1) Я вижу, что при добавлении состояний, входных данных и параметров я могу указать уникальные ограничения поля через upper и lower (https://openmdao.github.io/dymos/features/phases/constraints.html ?выделить = размерность #ограничения пути). Например, состояние 1 может иметь границы [0,1], в то время как состояние 2 имеет границы [-1,5]. Мой вопрос в том, работает ли suppling ref и ref0 information таким же образом? Я протестировал это (например ref0 = [0,-1] ), но я не могу сказать, действительно ли это что-то делает?
(2) Можете ли вы указать единицы измерения для конкретных элементов задач с размерностью? Например, состояние 1 — это температура, а состояние 2 — напряжение. Не похоже, что я могу просто сделать:
self.add_input('x',shape=(num_nodes,2),units=['K','V'])
потому что это возвращает ошибку.
(3) Можете ли вы указать различные свойства оптимизации для отдельных элементов в векторах состояния, ввода и измерения? Например, скажем, я хочу оптимизировать ввод 1 ( opt=True ), но не ввод 2 ( opt=False ). В идеале я ожидал бы
phase.add_parameter('u',opt=[True,False])
но это возвращает ошибку.
Если эта функциональность возможна, не могли бы вы направить меня туда, где я мог бы найти дополнительную информацию. Я просмотрел документацию Dymos, но не смог найти много по этой теме.
Комментарии:
1. Первоначально мы решили не поддерживать масштабирование на основе массива, в значительной степени потому, что Майкл Росс и др. приводят убедительный аргумент, что это неверно с математической точки зрения. Смотрите Раздел, озаглавленный «Ошибка дискретного масштабирования» в их статье «Масштабирование и балансировка для высокопроизводительных вычислений оптимальных элементов управления» здесь: arxiv.org/pdf/1810.11073.pdf Если вы чувствуете, что это было бы действительно важно, и хотите проигнорировать совет Росса, я бы не был полностью против добавления этой возможности. Масштабирование для каждого индекса состояния или элемента управления со значением массива уже должно работать, будет протестировано.
2. Я думаю, что масштабирование, против которого выступал Майк Росс, было немного другим. Это было переменное масштабирование вдоль
num_nodesоси, которое он приводит в качестве убедительного аргумента, плохо. Я полагаю, что в этом случае масштабирование переменной будет происходить вдоль «первичной» оси векторного состояния (т. Е. Вдоль оси, по которой вы бы разделили векторное состояние на несколько скалярных состояний). В этом нет ничего математически неправильного, что я вижу, и, похоже, он частично работает с версии V1.3 для ref / ref0. однако это не работает для верхнего / нижнего. Это может быть устранено в ошибке, указанной в ответе ниже
Ответ №1:
- В общем OpenMDAO вы можете иметь векторное значение ref / ref0 для проектных переменных. Теоретически Dymos также должен поддерживать это. Вы можете указать ref / ref0 того же размера, что и ваше состояние, а затем Dymos расширит его до полного
num_nodesразмера для вас. К сожалению, начиная с версии Dymos 1.30, похоже, что это не совсем работает. Мы зарегистрировали эту ошибку здесь, и она должна быть исправлена в версии V1.4. - OpenMDAO не допускает смешанных блоков в массивах. Это был преднамеренный выбор дизайна, связанный с подробностями о том, как обрабатываются преобразования единиц измерения и как поддерживать их эффективность (как с точки зрения использования памяти, так и вычислений). Поскольку OpenMDAO этого не позволяет, Dymos не может.
Итак, вам нужно либо разделить состояние на несколько переменных, либо работать с безразмерными величинами.
- Для параметров и элементов управления это довольно просто сделать через API OpenMDAO. Если вы хотите более мелкозернистый контроль индекса, просто установите opt=False для всех из них. Dymos предоставит их вам в качестве входных данных в верхней части фазы / траектории (вы можете использовать N2, чтобы найти их). Затем вы можете вызвать собственный API
add_design_varOpenMDAO для этих входных данных уровня фазы / траектории с любыми индексами, которые вы хотите.
Делать это для состояний — не лучшая идея. Не вдаваясь в математику… Dymos очень усердно работает, чтобы сохранить для вас четко определенную (в математическом смысле) задачу оптимизации. Для состояний это означает тщательное сопоставление ограничений дефектов с проектными переменными. Вы не можете просто отключить часть массива состояний, не обратившись также к соответствующим ограничениям дефектов. Конечно, если вы нарушаете ограничения дефектов, вы больше не получаете действительную физику. Это такая огромная банка с червями, что вы действительно просто не хотите к ней прикасаться.
Комментарии:
1. Потрясающе. Это очень полезно, и спасибо за открытие этого сообщения об ошибке. Чтобы уточнить, для (3) я бы не хотел удалять состояния из списка проектных переменных. Однако мне могут понадобиться некоторые состояния с фиксированным начальным условием, в то время как другие свободны. Похоже, что это все еще может быть «хорошо». Но, основываясь на том, что вы оба упомянули, кажется, что лучшим подходом было бы избежать размерной проблемы и приложить некоторые усилия для переформулировки моей системы как безразмерной.
2. Если у вас есть векторное состояние, то вы можете управлять
fix_intialfix_finalнастройкой или только для ВСЕХ вложенных состояний в этом массиве в виде блока. Если вам нужен более точный контроль, тогда вам следует разбить вектор на более мелкие переменные. По крайней мере, так это работает с версии V1.3. Хотя мы бы приветствовали запрос на извлечение, который мог бы обновить функциональность, я думаю, нам нужно было бы убедить, что это не создаст много потенциальных проблем для пользователей. Достаточно сложно правильно настроить BCs при работе с целыми переменными. Логические массивы просто усложнили бы задачу.3. Ох. Хорошо, это помогает урегулировать наш подход. Нам придется разбить каждое из состояний и др. на их собственную переменную. Я избавлю вас от головной боли, связанной с необходимостью выполнения этого обновления. Спасибо за разъяснение!