Понимаете, здесь все не ради крыла делается, а скорее цель в разработке общей технологии быстрой и эффективной оптимизации. В промышленности крыло отдельно уже никто не оптимизирует, а оптимизируют формы сложной трехмерной геометрии. Нужна понятная и быстрая технология, которая позволит инженеру условно выбрать параметры геометрии, которые нужно оптимизировать и нажать на большую красную кнопку (ну и чтобы оптимизация вечность не занимала).
То, что вы описываете, это как раз построение суррогатной модели (или Reduced Order Modeling) по результатам расчетов. Условный следующий этап развития этой задачи. Только для того, чтобы такие суррогатные модели стали работоспособны на 12-мерном пространстве точек там должно быть ~100-1000, что уже выбивается за бюджет инженерного применения. Как я уже написал выше, есть идея попробовать такой подход в гибридном режиме. Локальный градиентный оптимизатор условно исследует пространство в локальном минимумах, суррогатная модель используется для постановки начальной точки градиентного оптимизатора и построения общей поверхности отклика.
Спасибо! Сравнить с оптимизацией на основе ROM тоже хочу. Еще есть идея поставить ROM для глобального поиска и SLSQP для локального поиска с выдачей точек в ROM для уточнения.
Честно говоря, узнал от вас впервые! Причем когда-то давно я что-то подобное пилил самостоятельно на yaml+python-docx но потом решил все-таки разобраться в Latex и теперь на Word смотреть не могу. Круто! Может еще поразбираюсь на досуге) Может возникнуть одна задачка.
Да, исходные данные в виде xlsx или csv таблиц. Они хранятся в отдельных объектах, поэтому их могут редактировать не только расчетчики. Таблицы могут быть отправлены на расчет в фоновом режиме ( без загрузки интерфейса Jupyter), и сложиться в тимцентр в виде измененного расчета и отчета.
Предполагаю, что невалидные ходы игнорируются, а ей выдается отрицательный Reward. Доп информацию извлечь возможно и не получится, но они утверждают, что таким образом у алгоритма появляется более эффективное векторное представление среды.
Да, но в AlphaZero были заложены правила игры. Условно говоря, она не могла сделать неправильный ход. В MuZero правила игры не заложены, ей просто дали доску, и давай на ней учись. На самом деле там очень хитро устроено, моя ламерская интерпретация: MuZero обучена делать свое нейросетевое представление игры, с которым она взаимодействует с помощью метода Monte-Carlo tree search. AlphaZero взаимодействует Monte-Carlo tree search с самой игрой.
Насколько можно судить, они любой входной поток кодируют в векторное представление, а не просто в текст (как было бы, если использовалась сторонняя нейронка под обработку голоса). Соответственно эти вектора могут содержать больше информации, полезной нейронке, и ей с ними легче работать. Это предположение, свечку не держал. И еще, такой же подход помог алгоритму MuZero обучиться лучше играть в игры, чем AlphaZero. MuZero сам учился выстраивать свое векторное представление игры (например Шахмат или Го), а не использовал навязанное человеком.
Классный вопрос, спасибо! А взаимодействие есть, просто раскрыть эту тему в одном абзаце в статье не получится. Полагаю сделаю отдельную статью вообще про работу в PLM с расчетами, и в частности с Teamcenter. Но если вкратце, сейчас у заказчика реализован механизм, когда расчеты Jupyter хранятся и запускаются через Teamcenter. Расчетчик просто запускает свои расчеты через кнопку из Тимцентра, результаты расчета в виде пдф-отчетов и файлов .ipynb и .py хранятся в Тимцентре. Объект расчета может быть связан с конструкцией (по которой делается расчет), а также его можно отправлять по рабочему процессу.
Тут все от целеполагания зависит. В моем варианте пользователи работали на Word и Excel (как и на 100% предприятий, которые я видел), поэтому логично было учитывать их потребности. Что касается Линукс-дистрибутивов, у Питона и Jupyter с этим проблем явно не возникнет. Не думаю, что возникнет проблема у Питона с аналогами MS Office на Linux, поэтому переделка под новые реалии много времени не займет.
Спасибо! В статье в конце есть ссылка на код с небольшой инструкцией по запуску. Более проработанную методичку наверное сделаем, попробую свой обучающий курс по расчетам в Python реализовать с автоматизированным отчетом. Мне кажется студентам будет полезно, я в универе о такой штуке мечтал)
Не слышал про такие подходы, поизучаю. Спасибо!
Понимаете, здесь все не ради крыла делается, а скорее цель в разработке общей технологии быстрой и эффективной оптимизации. В промышленности крыло отдельно уже никто не оптимизирует, а оптимизируют формы сложной трехмерной геометрии. Нужна понятная и быстрая технология, которая позволит инженеру условно выбрать параметры геометрии, которые нужно оптимизировать и нажать на большую красную кнопку (ну и чтобы оптимизация вечность не занимала).
То, что вы описываете, это как раз построение суррогатной модели (или Reduced Order Modeling) по результатам расчетов. Условный следующий этап развития этой задачи. Только для того, чтобы такие суррогатные модели стали работоспособны на 12-мерном пространстве точек там должно быть ~100-1000, что уже выбивается за бюджет инженерного применения. Как я уже написал выше, есть идея попробовать такой подход в гибридном режиме. Локальный градиентный оптимизатор условно исследует пространство в локальном минимумах, суррогатная модель используется для постановки начальной точки градиентного оптимизатора и построения общей поверхности отклика.
Что-то я не понял, как я смогу посчитать без геометрии с помощью численных методов целевую функцию для трехмерной постановки задачи. Можете объяснить?
Спасибо! Сравнить с оптимизацией на основе ROM тоже хочу. Еще есть идея поставить ROM для глобального поиска и SLSQP для локального поиска с выдачей точек в ROM для уточнения.
Честно говоря, узнал от вас впервые! Причем когда-то давно я что-то подобное пилил самостоятельно на yaml+python-docx но потом решил все-таки разобраться в Latex и теперь на Word смотреть не могу. Круто! Может еще поразбираюсь на досуге) Может возникнуть одна задачка.
Да, исходные данные в виде xlsx или csv таблиц. Они хранятся в отдельных объектах, поэтому их могут редактировать не только расчетчики. Таблицы могут быть отправлены на расчет в фоновом режиме ( без загрузки интерфейса Jupyter), и сложиться в тимцентр в виде измененного расчета и отчета.
Предполагаю, что невалидные ходы игнорируются, а ей выдается отрицательный Reward. Доп информацию извлечь возможно и не получится, но они утверждают, что таким образом у алгоритма появляется более эффективное векторное представление среды.
Если аудио в текст, то потеряет конечно. Если аудио в вектор, то как раз может такие вещи и ловить. Трансформация в вектор обучаемая.
Да, но в AlphaZero были заложены правила игры. Условно говоря, она не могла сделать неправильный ход. В MuZero правила игры не заложены, ей просто дали доску, и давай на ней учись.
На самом деле там очень хитро устроено, моя ламерская интерпретация: MuZero обучена делать свое нейросетевое представление игры, с которым она взаимодействует с помощью метода Monte-Carlo tree search. AlphaZero взаимодействует Monte-Carlo tree search с самой игрой.
Насколько можно судить, они любой входной поток кодируют в векторное представление, а не просто в текст (как было бы, если использовалась сторонняя нейронка под обработку голоса). Соответственно эти вектора могут содержать больше информации, полезной нейронке, и ей с ними легче работать. Это предположение, свечку не держал.
И еще, такой же подход помог алгоритму MuZero обучиться лучше играть в игры, чем AlphaZero. MuZero сам учился выстраивать свое векторное представление игры (например Шахмат или Го), а не использовал навязанное человеком.
Классный вопрос, спасибо!
А взаимодействие есть, просто раскрыть эту тему в одном абзаце в статье не получится. Полагаю сделаю отдельную статью вообще про работу в PLM с расчетами, и в частности с Teamcenter.
Но если вкратце, сейчас у заказчика реализован механизм, когда расчеты Jupyter хранятся и запускаются через Teamcenter. Расчетчик просто запускает свои расчеты через кнопку из Тимцентра, результаты расчета в виде пдф-отчетов и файлов .ipynb и .py хранятся в Тимцентре. Объект расчета может быть связан с конструкцией (по которой делается расчет), а также его можно отправлять по рабочему процессу.
Как только запрос возникнет, обязательно учтем!
Тут все от целеполагания зависит. В моем варианте пользователи работали на Word и Excel (как и на 100% предприятий, которые я видел), поэтому логично было учитывать их потребности.
Что касается Линукс-дистрибутивов, у Питона и Jupyter с этим проблем явно не возникнет. Не думаю, что возникнет проблема у Питона с аналогами MS Office на Linux, поэтому переделка под новые реалии много времени не займет.
Спасибо!
В статье в конце есть ссылка на код с небольшой инструкцией по запуску.
Более проработанную методичку наверное сделаем, попробую свой обучающий курс по расчетам в Python реализовать с автоматизированным отчетом. Мне кажется студентам будет полезно, я в универе о такой штуке мечтал)