Openfast: Проблема, когда я запускаю модель simulink, которая зависит от openfast S-Function mex

Меня немного смущает стек трассировки. Похоже, проблема возникает в подпрограмме FAST_OpFM_Init но я не уверен, почему интерфейс OpenFAST-Simulink вообще может быть в этой подпрограмме. Насколько мне известно, эту процедуру следует вызывать только через интерфейс OpenFAST с кодом CFD (не Simulink).

1. Какую версию OpenFAST вы используете?
2. Вы создали библиотеку mex и OpenFAST-Simulink DLL (если да, то как?), Или вы используете предварительно скомпилированные двоичные файлы?
3. Вы изменяли исходный код или скрипты сборки перед сборкой?
4. Работают ли примеры моделей OpenFAST Simulink без сбоев?

1 - Я не знаю, как мне это увидеть, но я думаю, что использую 1.0.0
2- Да, я создал библиотеку mex. Сначала я использую Visual Studio 2015 и компилирую файл Simulink-Openfast с параметрами Release_Matlab и x64. Имя полученного файла - OpenFAST-Simulink_x64 (я прилагаю изображение), и я могу найти его в build / bin.
Чтобы получить быстрое решение, я тоже использую ту же программу.

3- Я не трогаю файл mex, я только изменяю .m для загрузки в рабочую область переменных и после выполнения модели simulink (обе находятся в том же месте, что и предопределенные модели [C: UsersCASADocumentscodeopenfastglue-codessimulinkexamples, и. m, который генерирует S-функцию в build / bin, вы можете найти его в ..... openfastglue-codessimulinksrc])
4- Нет, это не так

1. Если вы на самом деле используете v1.0.0, вам обязательно нужно перейти на последнюю версию OpenFAST (основная ветка). Однако я был бы удивлен, если бы в v1.0.0 была опция Release_Matlab, поэтому я предполагаю, что это другая версия. Вы должны увидеть номер версии в файле с именем <openfast>\vs-build\gitVersionInfo.h . Или вы можете увидеть его напечатанным на экране, когда вы запустите OpenFAST.

2. Вы описываете создание файла OpenFAST_Simulink_x64.DLL . Файл mex обычно создается с использованием openfast\glue-codes\simulink\src\create_FAST_SFunc.m . Вы тоже это построили? В вашей системе он должен создать FAST_SFunc.mex64 . Учитывая дату модификации FAST_SFunc на вашем снимке экрана, я предполагаю, что вы также создали это, но я просто дважды проверяю, что это не из другой сборки OpenFAST.

Я бы поработал над тем, чтобы пример модели OpenLoop работал с одним из примеров r-теста OpenFAST, прежде чем пытаться отлаживать то, что происходит с вашей конкретной моделью Simulink. Таким образом, вы можете поделиться всеми подробностями того, что вы делаете.

Убедитесь, что вы создали FAST_SFunc с тем же компилятором, который вы использовали при сборке OpenFAST-Simulink_x64.DLL (т.е. запустите mex -setup в Matlab и заставьте его использовать Visual Studio C / C ++ и Intel Fortran).

Привет @bjonkman ,

1. Извините за информацию о версии, я проверяю, что это V2.3.0 ---> #define GIT_VERSION_INFO 'v2.3.0-548-g43191a90'

2 - Да, я выполняю create_FAST_SFunc.m и получаю FAST_SFunc.mex64 в build / bin.

Чтобы показать вам все шаги, которые я сделал, я прикреплю несколько скриншотов:

Сначала я выполняю mex -setup, чтобы убедиться, что я использую тот же компилятор - Visual Studio 2015. Это правильно.
Следующим шагом является создание S-функции, запускающей create_FAST_SFunc.m, и я получаю FAST_SFunc.mex64.

Следующим шагом запускаем Run_OpenLoop.m:

Вы можете видеть, что на этом этапе у Matlab есть проблема, и в этот момент ее нужно закрыть.

С наилучшими пожеланиями,

Хоакин

Я думаю, это, вероятно, указывает на проблему в файле OpenFAST-Simulink_x64.DLL . Печатал ли код что-нибудь еще в командном окне Matlab до его сбоя? (Я не вижу, напечатано ли что-нибудь под временем выполнения.) Как я уже упоминал, отображаемая вами трассировка говорит, что это находится в подпрограмме, которую не следует вызывать для этой сборки. Вы можете показать мне, как вы создали эту DLL?

Нет, код кроме этого ничего не показал.
Процесс получения файла .dll:

1- Выполняю быстрое решение (release_x64 double); после того, как я использую python для запуска теста и теста, который мне нравится, пройти нормально.

2- Следующим шагом, чтобы выполнить интеграцию Openfast Simulink, я открываю Visual Studio 2015 и выполняю файл fortran с именем OpenFAST-Simulink, а в свойствах-input я меняю, чтобы правильно нацелиться на libmex.lib (путь по умолчанию неправильный )
3- Я запускаю OpenFAST-Simulink (выпуск Matlab x64) и после запуска FAST (выпуск Matlab x64), и это все, что я сделал

¿Вам нужны скриншоты всех шагов?

Не могли бы вы открыть файл FAST.sln и построить с помощью Release_Matlab | x64 из этого файла решения вместо файла OpenFAST-Simulink.sln который вы используете? Если у вас нет такой возможности (с OpenFAST-Simulink проекта в FAST файл решения), я бы рекомендовал использовать последнюю мастер OpenFAST ветви , так что вы строите с тем.

Я создал решение FAST.sln с этой конфигурацией, и я получил это, которое я показываю вам на снимке экрана ниже:

Я не знаю, как сделать сборку с помощью de master. Должен ли я загружать только новую версию fortran Openfast-Simulink?

Какие шаги мне нужно выполнить, чтобы получить искомую .dll? (Если ты притворишься, что)

Привет всем,

Не знаю, смогу ли я присоединиться к обсуждению, у меня точно такая же проблема.

Я использую VS 2019 Community с Intel Parallel Studio XE 2020. Недавно я загрузил основную версию OpenFAST, поэтому у меня должна быть последняя.

Я компилирую DLL-файл с решением FAST.sln с разными конфигурациями:

1. В режиме «Release_Double_x64»: компиляция работает без ошибок. Затем я создаю файл mex с помощью create_FAST_Sfunc.m ==> он работает. Запускаю файл "RUN_OpenLoop" и получаю скриншот во вложении.
   

2. В режиме "Release_64": та же проблема при достижении моделирования Simulink

3. В режиме «Release_Matlab_64» (только для проектов OpenFast-Simulink и FASTlib, верно?): Я не могу скомпилировать решение FAST VS (см. В приложении)
   

@hbasbas : вам нужно сгенерировать OpenFAST-Simulink-x64.dll из проекта Visual Studio, поэтому вам действительно нужно создать версию только на шаге 3 (за исключением того, что вам также нужно запустить файл create_FAST_SFunc.m после выполнения шага 3). Если вы запускаете FAST_SFunc в Matlab перед созданием DLL, я бы предположил, что он вызывает другую версию этой dll из другого места на вашем пути Matlab. Если вы наберете which OpenFAST-Simulink-x64.dll в командном окне Matlab, он должен предоставить вам полный путь к используемой DLL.

Причина вашего Release_Matlab | Конфигурация x64 (которая является той, которую вам нужно использовать) не строится, похоже, что у вас другая версия Matlab, чем была настроена для проекта. Вам нужно будет открыть свойства конфигурации для файла проекта OpenFAST-Simulink (щелкните правой кнопкой мыши проект, затем выберите properties и перейдите к строке ввода компоновщика. версия Matlab, которую вы используете:

@JoaquinPerCarr , чтобы получить основную ветку с помощью git, вы можете проверить основную ветку, а затем вытащить новый код.

Возможно, у вас есть другая копия DLL на вашем пути к Matlab, что тоже вызывает путаницу. Попробуйте which OpenFAST-Simulink_x64.dll в командном окне Matlab и посмотрите, указывает ли он на правильный.

Привет @bjonkman :

Я сделал то, что ты мне сказал. Сначала я загрузил все основные файлы openfast, затем заменил старый fortran OpenFAST-Simulink и скопировал новый. Я построил FAST с Release_Matlab_x64 и OpenFAST-Simulink_Release_Matlab_x64, чтобы получить новый .dll.

Я повторил весь процесс, такой как тот, который я объяснил вам в первый момент этого обсуждения, и у меня были те же результаты, Matlab вылетает, когда я выполняю simulink. Я прилагаю снимок экрана, когда использую OpenFAST-Simulink:

Привет,

@bjonkman : спасибо за ответ. Благодаря вашим рекомендациям компиляция работает. Я хотел бы уточнить (для возможных других пользователей), что важно вставить цитату между путями. Из-за свободного места в «Program File» VS пытается найти объектный файл.
Однако Matlab продолжает аварийно завершать работу при выполнении симуляции Simulink:

Возможно ли, что версии Matlab, Visual Studio и Intel Parallel Studio XE несут ответственность за сбой Matlab?

@JoaquinPerCarr : в команде which кажется, что вы указали не тот файл: вы пишете «-x64» вместо «_x64»

В противном случае, можно ли поделиться скомпилированным файлом .mex64 версии openfast-master. Мне нужно изменить только входной файл (.dat), но исходный код для меня должен быть таким же. Более того, я выявлю проблему:
Если он не работает с ним, это должно означать, что у меня проблема с моей версией Matlab или другими. Если это работает, это означает, что компиляция Visual Studio плохо настроена.

Ладно, думаю, я понимаю, в чем проблема.

Если вы открываете <openfast>\modules\openfast-library\src\FAST_Library.h , измените определение CHANNEL_LENGTH с 10 на 20:

#define CHANNEL_LENGTH 20

Затем повторно запустите файл create_FAST_SFunc.m и повторите попытку.

Я получу запрос на перенос с этим исправлением в OpenFAST.

Большое спасибо. Оно работает !

Привет @bjonkman!

Если я сделаю это, я получу следующее:

Я вижу, что simulink не открывается и больше ничего не делает.

Если вы прочитаете сообщение об ошибке под частью, которую вы обвели, вы увидите, что OpenFAST не может найти входной файл, который вы просили запустить. Run_OpenLoop.m был настроен для старых случаев CertTest FAST (v8), поэтому вам нужно было изменить имена входных файлов. Я запустил следующий код для тестирования модели OpenLoop:

addpath('C:\openfast\build\bin')
FAST_InputFileName = 'C:\openfast\build\reg_tests\glue-codes\openfast\5MW_Land_DLL_WTurb\5MW_Land_DLL_WTurb.fst';

TMax=30;

sim('OpenLoop.mdl',[0,TMax])

Я пробую следующий код, потому что мне нравится тест 25:
Test25 = 'C: UsersCASADocumentscodeopenfastreg_testsr-testglue-codesopenfast5MW_OC4Semi_WSt_WavesWN5MW_OC4Semi_WSt_WavesWN.fst';

FAST_InputFileName = Test25;
disp (FAST_InputFileName)
TMax = 200;

sim ('openloop.mdl', [0, TMax]);

Я замечаю, что модель simulink не открывается автоматически, и я не знаю почему, но сначала кажется, что она хорошо работает

Подводя итог, как вы думаете, единственной проблемой, связанной с моей первой проблемой, была строка кода #define CHANNEL_LENGTH 20 в файле .h?

Большое спасибо @bjonkman

Я не думаю, что Simulink нужно открывать модель, когда вы запускаете ее с помощью команды sim() .

Неправильное определение CHANNEL_LENGTH в файле .h было причиной закрытия Matlab (и для всех, кто читал это в будущем, трассировка стека была неточной: на самом деле ее не было в FAST_OpFM_Init процедура).

Будем надеяться, что это единственная проблема. :)

Я занимаюсь разными делами и считаю, что нужен мастер openfast-Simulink

Я собираюсь попробовать запустить свою первую модель simulink и скажу вам, хорошо ли она работает

Привет @bjonkman!

Я хотел бы спросить, как мне узнать, какая у меня версия OpenFAST (dev / master). Если есть форма для возврата к основной версии, я хочу это сделать.

Если это невозможно, как мне удалить / исправить ошибки (флаги), которые я покажу вам на следующих скриншотах? CalcSteady, Twr_Kdmp и Bld_Kdmp являются основной проблемой.

Я тоже вижу документацию OpenFAST. Ошибки, я думаю, могут быть связаны с использованием версии OpenFAST для разработчиков. Я не знаю, что мне делать.

С наилучшими пожеланиями,

Хоакин.

Уважаемый @JoaquinPerCarr ,

Я не уверен, что правильно понимаю ваш вопрос, но похоже, что вы используете более старую версию OpenFAST для разработчиков (где-то между v2.3 и v2.4) и входной файл, совместимый с v2.3. Как и в случае с любой ошибкой при обработке входного файла, вы можете включить опцию Echo для отладки проблем в форматировании входного файла.

В любом случае, если у вас нет особой причины использовать эту версию OpenFAST для разработчиков, я бы рекомендовал выполнить обновление до основной ветки OpenFAST, v2.4. Примеры входных файлов OpenFAST, совместимых с v2.4, представлены в главной ветви r-теста.

С наилучшими пожеланиями,

@JoaquinPerCarr ,

Обычно вы можете увидеть версию OpenFAST, распечатанную на экране, когда вы запустите OpenFAST. Из вашего снимка экрана я вижу, что это v2.3.0-548-g43191a90 . Это означает, что он находится в git hash 43191a90 и 548 коммитов после помеченной версии 2.3.0.

Чтобы переключиться на другую версию, вы можете просто использовать некоторые команды git для проверки любой ветки и фиксации, которую вы хотите.

Ты мог бы сделать

git checkout v2.4.0

который проверяет версию openfast 2.4.0, но помещает вас в состояние отдельной головы в git, или

git checkout master
git pull

который должен предоставить вам последнюю версию основной ветки (при условии, что ваша основная ветка указывает на репозиторий openfast). Имейте в виду, что текущее состояние вашего репозитория git может означать, что вам нужно спрятать некоторые изменения перед переключением ветвей и т. Д.

В противном случае просто убедитесь, что вы используете файлы примеров из коммита r-test, связанного с версией OpenFAST, которую вы используете.

Привет всем,

Я мог бы скомпилировать S-Fuction и запустить примеры OpenLoop и Test01_SIG. Теперь я пытаюсь расширить входы S-Fuction, чтобы включить дополнительные входы в дополнение к исходной 8. Но в S-функции OpenFAST у меня нет возможности изменить NumAdditionalInputs, как в FASTv8.
Любая помощь будет оценена по достоинству.

Заранее спасибо.

Я не знаю ничего, что могло бы изменить функциональность NumAdditionalInputs между FAST v8 и последней версией OpenFAST. Что именно не работает?

Привет @bjonkman ,

Спасибо за ваш повтор.
Фактически, я бы изменил NumAdditionalInputs, чтобы импортировать массы лопастных элементов в S-функцию, которые больше 11 для модели мощностью 5 МВт. Я имею в виду 11, потому что максимальное количество записей, разрешенных для NumAdditionalInputs, не должно превышать 11 записей, как я прочитал в README_FAST8:

Я уже изменил тип данных масс элементов лезвия в ElastoDyn, и я мог изменить массы в рамках данной симуляции. Теперь я создаю дополнительные каналы для экспорта масс элементов лезвия из ElastoDyn в Simulink. Я бы изменил массы в Simulink и импортировал их в S-функцию, то есть в ElastoDyn.

_Может ли ElastoDyn распознавать массы лопастных элементов, импортированные из S-функции?

_Может ли ElastoDyn заметить изменения, сделанные в Simulink?

_Можно ли ввести более 11 входов в дополнение к исходной точке 8 в S-функции?

Если вы хотите отправить в OpenFAST более 10 дополнительных входных данных, вы можете изменить значение MAXInitINPUTS как в FAST_Library.h и в FAST_Library.f90 и перекомпилировать как S-функцию Matlab, так и OpenFAST dll. (Если вы введете массив с более чем MAXInitINPUTS+1 значениями в Simulink, вы, вероятно, получите ошибку сегментации).

MAXInitINPUTS определяет самый большой массив, который может быть принят от Simulink и передан в код OpenFAST Fortran. OpenFAST ничего не делает с этими дополнительными значениями массива, если вы не сообщите об этом, поэтому, если вы хотите передать значения в ElastoDyn, вам придется внести некоторые дополнительные изменения в код.

Для начала вам нужно будет посмотреть на InitInpAry в FAST_Library.f90 , а затем вам нужно будет передать некоторую информацию в ElastoDyn. Я бы рекомендовал заглянуть на форум NWTC, чтобы узнать, что вам нужно изменить:

• https://wind.nrel.gov/forum/wind/search.php?keywords=NumAdditionalInputs
• https://wind.nrel.gov/forum/wind/search.php?keywords=InitInpAry
• https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1171&hilit=InitInpAry

Обратите внимание, однако, что эти дополнительные входные данные являются значениями, переданными _из_ S-функции в Simulink _to_ OpenFAST. Код специально не настроен для передачи значений _to_ Simulink, если вы не используете массив WriteOutput (т.е. каналы OutList указанные в каждом модуле OpenFAST).

Привет @bjonkman ,

Спасибо за быстрый повтор и за ссылки.
Вначале я пытался передать только один дополнительный вход в S-функцию. Я использовал скорость ротора ( RotSpeed ) как дополнительный вход, который уже используется в OutListParameters:

1. Установите скорость ротора в качестве ввода в подпрограмме FAST_SetExternalInputs() в FAST_Library.f90
   

2. Восстановите FASTlib из C: .... OpenFASTvs-buildFASTlib FASTlib.sln

1. Запустите OpenLoop с одним дополнительным входом
   

2. Сбой моделирования в Matlab / Simulink
   
   Я вижу в subroutine FAST_Start () в FAST_Library.f90 что разрешены только 3 дополнительных ввода. Должен ли я изменить это, чтобы включить только один вход?
   

Исходная функция FAST S настроена таким образом, что если вы скажете, что есть 3 дополнительных входа, она будет предполагать, что вы имитируете функциональность лидара. Я не думаю, что код, который вы показываете, используется (я не думаю, что #ifdef - это правда), но в подпрограмме FAST_Update есть аналогичная логика.

Я бы просто изменил строку, чтобы она не выдавала ошибки, если количество дополнительных входов равно 1:

   ELSEIF(  NumInputs_c /= NumFixedInputs .AND. NumInputs_c /= NumFixedInputs+3 .AND. NumInputs_c /= NumFixedInputs+1 ) THEN

Эта обработка ошибок существует потому, что было бы очень легко получить ошибку сегментации при передаче массивов разного размера между Simulink и кодом Fortran.

Привет @bjonkman ,
Спасибо, что указали на это.
Я изменил логику, как вы упомянули в предыдущем комментарии в subroutine FAST-Update , а затем перекомпилировал FAST DLL из OpenFASTvs-buildFASTlib FASTlib.sln с другой конфигурацией:

1. Relase как конфигурация души, x64 как платформа души и построение решения с помощью Build->Build Soultion .

1. Relase как конфигурация души, x64 как платформа души и построение решения с помощью Build->Rebuild FASTlib .

1. Relase_Matlab как конфигурация души, x64 как платформа души и построение решения с помощью Build->Rebuild FASTlib .
   После каждой компиляции я запускаю OpenLoop_Test с дополнительным вводом и получаю ту же старую ошибку

Затем я перекомпилировал FAST из OpenFASTvs-buildFAST FASTlib.sln с Relase_Matlab , x64 и Build->Build Soultion компиляция завершилась с

Строка 341 в FAST_Library.f90 - это строка, в которой я добавил логику для дополнительного ввода

Кажется, что структура subroutine FAST_SetExtrenalInputs должна быть расширена, чтобы допустить такую ​​дополнительную логику?

Вы добавили новое поле %RotSpeed в структуру данных, в которой вы его используете?

Если вы добавляете поля в структуру данных, вам необходимо определить их в соответствующем входном файле реестра OpenFAST. В вашем случае в определении FAST_ExternInputType должна быть дополнительная строка. Итак, где-то рядом со строкой 626 в FAST_Registry.txt вы должны добавить строку для нового поля RotSpeed :

typedef ^   FAST_ExternInputType    ReKi    RotSpeed    -   -   -   "Rotor speed from Simulink"

Кроме того, единственная конфигурация, которую вам нужно использовать, - это конфигурация Release_Matlab | x64 . Другие конфигурации вообще не используются в процессе Simulink, поэтому вы просто запускали старый код с вашими первыми двумя сборками.

Привет @bjonkman ,
Прежде всего, большое спасибо за вашу помощь.
Я мог бы добавить еще один дополнительный вход в S-функцию следующим образом:

1. занимают 9-й элемент InputAry в FAST_Library.f90\ subroutine FAST_SetExternalInputs

1. определить дополнительный ввод в FAST_Rgistery.txt\ FAST_ExternalInput data

1. свяжите дополнительный внешний ввод с ElastoDyn в FAST_Solver.f90\ SUBROUTINE ED_SetExternalInput (я написал эту процедуру)

1. определить дополнительный внешний ввод в ElastoDyn_Registry.txt

1. создать новый параметр в EladoDyn для перезаписи и экспорта в OutListParameter с помощью скрипта Write_ChckOutLst.m

1. перезапись нового определенного параметра в ElastoDyn дополнительным вводом от Siimulink в ElastoDyn.f90\ SUBROUTINE ED_CalcOutput

1. установите RotMass в Simulink как константу, чтобы перезаписать определенный параметр в ElastoDyn.f90 RMSimulink

1. Постройте перезаписанный вывод RMSimulink за время (1 с)

Как видите, RMSimulink постоянно равен нулю, и перезапись не сработала. Я думаю, чего не хватает, так это переключателя во входном файле ElastoDyn, который включает внешние входы из Simulink, как и во входном файле ServoDyn с PCMode . Вы видите какую-нибудь ошибку в имплантации выше? Есть что-нибудь, что я пропустил при перезаписи?

Вам нужно будет запросить новый выходной канал RMSimulink в OutList входного файла ElastoDyn, чтобы значение в массиве m%AllOuts помещено в y%WriteOutput array (который печатается в выходных файлах и отправляется в Simulink). Однако, чтобы получить это в массиве WriteOutput , вам нужно изменить подпрограмму SetOutParam() в ElastoDyn.f90, чтобы она распознавала новый вывод, который вы добавляете.

В качестве альтернативы, если вы не хотите обновлять код в SetOutParam() , вы можете просто перезаписать существующий канал в ElastoDyn и вместо этого запросить этот канал.

Привет @bjonkman ,
Спасибо за повтор.
Я уже обновил код в Subroutine SetOutParam() в ElastoDyn.f90 и код в ElastoDyn_IO.f90 , чтобы добавить новый канал вывода RMSimulink .
Мне все еще интересно, почему значение дополнительного внешнего входа u%ExternalRotMass от Simulink равно нулю во время моделирования, хотя я установил это значение на 1000 в Simulink?
Как вы предложили, я использовал существующий канал «SpnMxlb» для перезаписи, но результат все тот же. u%ExternalRotMass всегда равно нулю!

Привет @bjonkman ,
Я нашел, в чем проблема. Я не называл SUBROUTINE ED_SetExternalInputs в SUBROUTINE ED_InputSolve в FAST_Solver.f90 . Таким образом, мне пришлось изменить аргумент SUBROUTINE ED_InputSolve чтобы добавить тип данных m_FAST .

Привет @bjonkman ,
Как вы упомянули в предыдущем комментарии, я изменил MAXInitINPUTS S-функции, чтобы разрешить 100 дополнительных входов. Моя цель - перезаписать массы элементов лезвия в ElastoDyn.f90\ p%BElmntMass . Я мог перезаписать массу элемента с одним лезвием через S-функцию. Теперь я пытаюсь перезаписать все массы элементов лезвия, которые составляют 51 элемент для трех лезвий. Я мог бы скомпилировать FAST с новой модификацией, но когда я компилирую MATLAB, я становлюсь этой ошибкой:

Вот строка ошибки в FAST_Library.f90

Массовый элемент лезвия m_FAST%ExternInput%SpnMB определен в FAST_Registery.txt :

Вы видите, пропущу ли я что-нибудь по определению SPNMB?

Вы определили SPNMB как двумерный размещаемый массив. Я не знаю, какой размер вы ему присвоили - надеюсь, вы сделали это до вызова FAST_SetExternalInputs но вы устанавливаете его равным 1-мерному массиву размера 52 (примечание: вы можете захотеть проверьте, что 51, который вы используете, или посмотрите, должны ли индексы InputAry идти с 9:59). Ошибка заключается в том, что массивы, которые вы пытаетесь установить равными друг другу, не имеют одинаковой формы (1-d против 2-d), поэтому они не могут быть равными.

Также будьте осторожны при перезаписи параметров (всего в структуре данных p% ). Эти значения не должны изменяться после инициализации, поэтому (1) вы, вероятно, получите ошибки о том, что вы не можете изменить их в определенных подпрограммах, (2) другие параметры также могут зависеть от своих начальных значений, поэтому вам понадобится чтобы сделать это согласованным, если вы измените код, чтобы вы могли изменять параметры во время моделирования.

Привет @bjonkman ,
Спасибо, что указали на это.
Я изменил размерность массива SpnMb с 2-го на 1-мерный массив из 51 элемента в FAST_Register.txt и ElastoDyn_Registery.txt . Затем я определил матрицу 3x17 в подпрограмме ED_CalcOutput()\ElastoDyn.f90

Я использовал эту матрицу, чтобы изменить 1-мерный массив, который импортирован из Simulink, в матрицу 3x17

После изменения формы я перезаписал массы элемента лезвия значениями, импортированными из Simulink.

Чтобы обновить значения, которые зависят от p%BElmntMass я вызвал подпрограмму UpdateCoeff(p, ErrStat, ErrMsg)

Подпрограмма UpdateCoeff (p, ErrStat, ErrMsg)\ElastoDyn.f90 , созданная мной, очень похожа на подпрограмму Subroutine Coeff(p,InputFileData, ErrStat, ErrMsg) с тем преимуществом, что она независима от данных входного файла. Это позволяет вызывать подпрограмму UpdateCoeff() во временной области, то есть в ED_CalcOutput() .
Кроме того, я изменил назначение структуры данных параметра с IN на INOUT . Это, как вы упомянули выше, позволяет перезаписать структуру данных p% .
С помощью приведенных выше модификаций кода я смог скомпилировать как FAST, так и Matlab без ошибок. Но когда я запускаю OpenLoop с дополнительным 51 входом, симуляция вылетает после двух шагов симуляции.

Я не смог определить причину такой ошибки. Вы видите что-то неправильное в моей реализации, которое могло бы вызвать эту ошибку?
Перезапись только одной массы лопаточного элемента прошла успешно. Но для всех элементов клинка этого не произошло.
Буду очень признателен за любую помощь.
И еще раз спасибо за ваш быстрый повтор

Исходя из того, как распределены ваши массивы, похоже, что у вас должно быть

p%BElmntMass(J,K) = ElemMass(K,J)

Однако я не уверен, что это единственная проблема. Один из способов отладить это без наличия Matlab в процессе - просто написать простой код драйвера c (скопировать основные вызовы из FAST_SFunc.c ), а затем собрать и запустить его через отладчик Visual Studio. У меня было что-то подобное для FAST v8 - это очень полезный инструмент, помогающий находить подобные ошибки.

Привет @bjonkman ,
Спасибо, что указали на ошибку с Element (K, J). К сожалению, очевидно, что это не единственная проблема.
Как вы предлагаете, я написал простой драйвер c:

Но я не мог знать основные вызовы из FAST_Sfunction.c, которые вы хотели скопировать и вставить в драйвер выше.
На самом деле, я писал всплывающие сообщения в определенных местах кода FORTRAN, чтобы отслеживать ошибки, вот как я отлаживаю, когда использовал .exe

Как видите, этот метод не работает для S-функции.
Можете ли вы помочь с отладкой в ​​VS?

Если вы используете CALL WrScr( string ) вы можете выводить данные в консоль Matlab для отладки. Я бы предположил, что использование print * создаст текстовый файл fort.7 в текущем каталоге Matlab (когда вы запускаете модель Simulink). В противном случае вы можете просто записать в другой файл, используя WRITE(Unit,Fmt) data в качестве отладочной информации.

Если вы хотите использовать отладчик Visual Studio, вы должны создать код C для вызова соответствующих частей DLL, что-то вроде того, что было написано для интерфейса OpenFOAM: https://github.com/old-NWTC/ БЫСТРЫЙ / blob / master / Source / FAST_Prog.c

Просматривая файл FAST_SFunc.c, я предполагаю, что вам понадобятся эти процедуры для инициализации:

       FAST_AllocateTurbines(&nTurbines, &ErrStat, ErrMsg);
       FAST_Sizes(&iTurb, &TMax, InitInputAry, InputFileName, &AbortErrLev, &NumOutputs, &dt, &ErrStat, ErrMsg, ChannelNames);
        FAST_Start(&iTurb, &NumInputs, &NumOutputs, InputAry, OutputAry, &ErrStat, ErrMsg);

Затем для каждого временного шага (т. Е. В цикле)

    FAST_Update(&iTurb, &NumInputs, &NumOutputs, InputAry, OutputAry, &ErrStat, ErrMsg);

И в конце вам понадобится

      FAST_End(&iTurb, &tr);
      FAST_DeallocateTurbines(&ErrStat, ErrMsg);

Привет @bjonkman ,

Спасибо за помощь. CALL WrScr(string) - отличная функция, она очень помогла. Единственным недостатком этой функции является то, что я мог печатать только строку, но не значения в окне команд Matlab. Я также попробую отладить FAST_Sfunction.c с помощью VS.
Большое спасибо

Существует также функция Num2LStr() (строка, выровненная по левому краю), которую вы можете использовать вместе с WrScr , которая может помочь печатать числовые значения: CALL WrScr( trim( Num2Lstr( number ) ) )

У меня такая же проблема с openFAST 2.4.0-master и dev.
Компиляция с помощью Visual studio и mex, сгенерированная компилятором C, установленным с помощью надстройки Matlab (Matlab 2018b).

S-функция, созданная с использованием исходных файлов v 2.4.0, отлично работает с openFAST 2.3.0, которую я также скомпилировал с Visual Studio. Так что, думаю, проблема не в S-функции.

Ни мой проект, ни примеры не работают - все они приводят к сбою Matlab.

Я просто пытался сгенерировать S-функцию, изменив параметр #define CHANNEL_LENGTH 20 в файле FAST_library.h, и у меня возникла та же проблема. Вот мой вывод Matlab:

abort () обнаружен при сексе 27 ноя 09:49:16 2020-0300

Конфигурация:
Crash Decoding: Disabled - Нет песочницы или пути к области сборки
Crash Mode: continue (по умолчанию)
Кодировка по умолчанию: windows-1252
Развернуто: false
Графический драйвер: неизвестное оборудование
Видеокарта 1: Intel Corporation (0x8086) Intel (R) UHD Graphics 630, версия 27.20.100.8681 (2020-9-5)
Версия Java: Java 1.8.0_152-b16 с 64-разрядной серверной виртуальной машиной Oracle Corporation Java HotSpot (TM) в смешанном режиме
Архитектура MATLAB: win64
Идентификатор прав MATLAB: 6257193
Корень MATLAB: C: Program FilesMATLABR2018b
Версия MATLAB: 9.5.0.944444 (R2018b)
OpenGL: оборудование
Операционная система: Microsoft Windows 10 Pro
ID процесса: 9896
Идентификатор процессора: x86 Family 6 Model 158 Stepping 10, GenuineIntel
Ключ сеанса: 2e3cb4b1-3a3b-46b0-bf51-135d94257c8d
Оконная система: версия 10.0 (сборка 18363)

Количество ошибок: 1

Аномальное прекращение

Состояние регистра (захвачено):
RAX = 00000000107aedd8 RBX = 00000000107aedd8
RCX = 00000000043ed920 RDX = 0000000000000000
RSP = 00000000043ed890 RBP = 00000000043f0e39
RSI = 0000000000000000 RDI = 0000000000000000

R8 = 00000000000dc430 R9 = 00007ffc4a14e930
R10 = 0000000000000014 R11 = 00000000000d5980
R12 = 00000000043ee558 R13 = 0000000000000000
R14 = 000000001079ed08 R15 = 00000000043edf90

RIP = 000000001055292a EFL = 00000206

CS = 0033 FS = 0053 GS = 002b

Трассировка стека (захвачена):
[0] 0x000000001054b2c3 binwin64libmwfl.dll + 00045763 foundation :: core :: diag :: thread_context :: unspecified_bool + 00000051
[1] 0x0000000010549288 binwin64libmwfl.dll + 00037512 foundation :: core :: diag :: stacktrace_base :: capture + 00000024
[2] 0x000000001054db80 binwin64libmwfl.dll + 00056192 foundation :: core :: diag :: symbols :: getSymbolAddress + 00009632
[3] 0x000000001055165f binwin64libmwfl.dll + 00071263 foundation :: core :: diag :: is_terminate_message_enabled + 00000575
[4] 0x0000000016dbeb3f binwin64mcr.dll + 01108799 QueryMLFcnTable_mcr + 00047535
[5] 0x0000000016dbe277 binwin64mcr.dll + 01106551 QueryMLFcnTable_mcr + 00045287
[6] 0x0000000016dba2b0 binwin64mcr.dll + 01090224 QueryMLFcnTable_mcr + 00028960
[7] 0x0000000016dbbec7 binwin64mcr.dll + 01097415 QueryMLFcnTable_mcr + 00036151
[8] 0x00007ffc5307caad C: WINDOWSSystem32ucrtbase.dll + 00445101 поднять + 00000477
[9] 0x00007ffc5307dab1 C: WINDOWSSystem32ucrtbase.dll + 00449201 abort + 00000049
[10] 0x00007ffc5307d20f C: WINDOWSSystem32ucrtbase.dll + 00446991 terminate + 00000031
[11] 0x00007ffc4a142388 C: Program FilesMATLABR2018bbinwin64VCRUNTIME140.dll + 00009096 is_exception_typeof + 00002312
[12] 0x00007ffc4a141ec2 C: программные файлыMATLABR2018bbinwin64VCRUNTIME140.dll + 00007874 is_exception_typeof + 00001090
[13] 0x00007ffc4a14b950 C: программные файлыMATLABR2018bbinwin64VCRUNTIME140.dll + 00047440 _CxxFrameHandler3 + 00000144
[14] 0x00007ffc5554184f C: WINDOWSSYSTEM32ntdll.dll + 00661583 _chkstk + 00000287
[15] 0x00007ffc5550a889 C: WINDOWSSYSTEM32ntdll.dll + 00436361 RtlRaiseException + 00000921
[16] 0x00007ffc5550a643 C: WINDOWSSYSTEM32ntdll.dll + 00435779 RtlRaiseException + 00000339
[17] 0x00007ffc532e3b29 C: WINDOWSSystem32KERNELBASE.dll + 00277289 RaiseException + 00000105
[18] 0x00007ffc4a1444f2 C: Program FilesMATLABR2018bbinwin64VCRUNTIME140.dll + 00017650 CxxThrowException + 00000194
[19] 0x000000000d89d18a binwin64libmwsl_services.dll + 00512394 slsvStringOrID :: untranslatedStr + 00073226
[20] 0x000000000d8a2746 binwin64libmwsl_services.dll + 00534342 slsvThrowIExceptionFromDiagnostic + 00000310
[21] 0x000000017406c8a2 binwin64codermapping_core.dll + 00051362 mds :: BlockMapping :: setBlock + 00000354
[22] 0x0000000174094a28 binwin64codermapping_core.dll + 00215592 sl :: MappingManager :: checkValidMappingType + 00000168
[23] 0x00000001740966df binwin64codermapping_core.dll + 00222943 sl :: MappingManager :: getActiveModelMapping + 00000031
[24] 0x0000000174095e8a binwin64codermapping_core.dll + 00220810 sl :: MappingManager :: detachBdListener + 00000762
[25] 0x000000001a8a2c08 binwin64udd.dll + 00404488 UDListener :: removeListenerContainer + 00002392
[26] 0x000000001a89ac8c binwin64udd.dll + 00371852 UDEventInfo :: send + 00000092
[27] 0x000000025e7367d0 binwin64libmwconfigset_base.dll + 01075152 mds :: postBdEvent + 00000144
[28] 0x00000000ffeb1035 binwin64simulink_configset.dll + 00069685 detachConfigSet + 00002597
[29] 0x00000000ffeb12d2 binwin64simulink_configset.dll + 00070354 restoreOrigConfigSetForBuild + 00000322
[30] 0x000000000acabbe4 binwin64libmwsimulink.dll + 10140644 sldeutils :: searchAvailableFunctions + 00190052
[31] 0x000000000aca73f2 binwin64libmwsimulink.dll + 10122226 sldeutils :: searchAvailableFunctions + 00171634
[32] 0x000000000aca8234 binwin64libmwsimulink.dll + 10125876 sldeutils :: searchAvailableFunctions + 00175284
[33] 0x000000000b572804 binwin64libmwsimulink.dll + 19343364 slstSetOutputPortRateID + 00361588
[34] 0x000000000b5365e4 binwin64libmwsimulink.dll + 19097060 slstSetOutputPortRateID + 00115284
[35] 0x000000000ae232e7 binwin64libmwsimulink.dll + 11678439 M2MIdentifySLClones + 00138423
[36] 0x000000000bae8e2a binwin64libmwsimulink.dll + 25071146 test :: sl_startup + 04405434
[37] 0x00007ffc53029d26 C: WINDOWSSystem32ucrtbase.dll + 00105766 execute_onexit_table + 00000342
[38] 0x00007ffc53029c4b C: WINDOWSSystem32ucrtbase.dll + 00105547 execute_onexit_table + 00000123
[39] 0x00007ffc53029c04 C: WINDOWSSystem32ucrtbase.dll + 00105476 execute_onexit_table + 00000052
[40] 0x000000000b6ba73a binwin64libmwsimulink.dll + 20686650 test :: sl_startup + 00020938
[41] 0x000000000b6ba838 binwin64libmwsimulink.dll + 20686904 test :: sl_startup + 00021192
[42] 0x00007ffc554c5021 C: WINDOWSSYSTEM32ntdll.dll + 00151585 RtlActivateActivationContextUnsafeFast + 00000289
[43] 0x00007ffc5550b102 C: WINDOWSSYSTEM32ntdll.dll + 00438530 LdrShutdownProcess + 00000306
[44] 0x00007ffc5550afad C: WINDOWSSYSTEM32ntdll.dll + 00438189 RtlExitUserProcess + 00000173
[45] 0x00007ffc546bcdda C: WINDOWSSystem32KERNEL32.DLL + 00118234 ExitProcess + 00000010
[46] 0x00007ffbec542541 D: ricardodocumentsPROGRAMASnrel_open_fastbinOpenFAST-Simulink_x64.dll + 44770625 FAST_OpFM_Init + 44675569
[47] 0x00007ffbec5424f7 D: ricardodocumentsPROGRAMASnrel_open_fastbinOpenFAST-Simulink_x64.dll + 44770551 FAST_OpFM_Init + 44675495
[48] ​​0x00007ffbeaeb7b5a D: ricardodocumentsPROGRAMASnrel_open_fastbinOpenFAST-Simulink_x64.dll + 21134170 FAST_OpFM_Init + 21039114
[49] 0x00007ffbe9b7bc82 D: ricardodocumentsPROGRAMASnrel_open_fastbinOpenFAST-Simulink_x64.dll + 00965762 FAST_OpFM_Init + 00870706
[50] 0x00007ffbe9afaa54 D: ricardodocumentsPROGRAMASnrel_open_fastbinOpenFAST-Simulink_x64.dll + 00436820 FAST_OpFM_Init + 00341764
[51] 0x00007ffbe9b4b42b D: ricardodocumentsPROGRAMASnrel_open_fastbinOpenFAST-Simulink_x64.dll + 00767019 FAST_OpFM_Init + 00671963
[52] 0x00007ffbe9b4c4ef D: ricardodocumentsPROGRAMASnrel_open_fastbinOpenFAST-Simulink_x64.dll + 00771311 FAST_OpFM_Init + 00676255
[53] 0x00007ffbe9aa5aba D: ricardodocumentsPROGRAMASnrel_open_fastbinOpenFAST-Simulink_x64.dll + 00088762 FAST_End + 00000074
[54] 0x00000002b2f5155c D: ricardodocumentsPROGRAMASnrel_open_fastbinFAST_SFunc.mexw64 + 00005468
[55] 0x00000002b2f520bf D: ricardodocumentsPROGRAMASnrel_open_fastbinFAST_SFunc.mexw64 + 00008383
[56] 0x00000002b2f524ac D: ricardodocumentsPROGRAMASnrel_open_fastbinFAST_SFunc.mexw64 + 00009388
[57] 0x00000002b2f541bc D: ricardodocumentsPROGRAMASnrel_open_fastbinFAST_SFunc.mexw64 + 00016828 mexFunction + 00001596
[58] 0x00000000fc635524 binwin64libmex.dll + 00349476 MexRetrieveVersion + 00003348
[59] 0x00000000fc63571c binwin64libmex.dll + 00349980 MexRetrieveVersion + 00003852
[60] 0x00000000fc635884 binwin64libmex.dll + 00350340 MexRetrieveVersion + 00004212
[61] 0x00000000fc619059 binwin64libmex.dll + 00233561 mexUnlock_800 + 00025273
[62] 0x0000000016f0e007 binwin64pgom_dispatcher.dll + 00057351 Mfh_file :: dispatch_fh_impl + 00001111
[63] 0x0000000016f0da9e binwin64pgom_dispatcher.dll + 00055966 Mfh_file :: dispatch_fh + 00000062
[64] 0x0000000016f78622 binwin64pgom_dispatcher.dll + 00493090 mdDoMatlabFcnCall + 00000122
[65] 0x000000025d08278a binwin64sl_utility.dll + 00337802 SimpleUserException :: ~ SimpleUserException + 00000282
[66] 0x000000000da124f8 binwin64libmwsl_services.dll + 02041080 CMatlabCommandNoWatermark :: execute + 00000056
[67] 0x000000025d083129 binwin64sl_utility.dll + 00340265 slDoMatlabFcnCall + 00000089
[68] 0x000000000b510fa2 binwin64libmwsimulink.dll + 18943906 slSetStateflowChartStateAccessInterface + 00252338
[69] 0x000000000b50ecb1 binwin64libmwsimulink.dll + 18934961 slSetStateflowChartStateAccessInterface + 00243393
[70] 0x000000000b511501 binwin64libmwsimulink.dll + 18945281 slSetStateflowChartStateAccessInterface + 00253713
[71] 0x000000000b4f1993 binwin64libmwsimulink.dll + 18815379 slSetStateflowChartStateAccessInterface + 00123811
[72] 0x000000000b4f1dca binwin64libmwsimulink.dll + 18816458 slSetStateflowChartStateAccessInterface + 00124890
[73] 0x000000000b4f3737 binwin64libmwsimulink.dll + 18822967 slSetStateflowChartStateAccessInterface + 00131399
[74] 0x000000000b4b503c binwin64libmwsimulink.dll + 18567228 StateflowAccessStateInterface :: ~ StateflowAccessStateInterface + 00037084
[75] 0x000000000b301ecb binwin64libmwsimulink.dll + 16785099 closeMaskEditor + 00056683
[76] 0x000000000b3021c9 binwin64libmwsimulink.dll + 16785865 closeMaskEditor + 00057449
[77] 0x000000000b30f3c4 binwin64libmwsimulink.dll + 16839620 BlockSetLocation + 00006420
[78] 0x000000000b30b424 binwin64libmwsimulink.dll + 16823332 closeMaskEditor + 00094916
[79] 0x000000000fb5a04b binwin64sl_lang_blocks.dll + 07118923 SubsystemBlock :: DrawSubsystemVariants + 00006491
[80] 0x000000000fb59631 binwin64sl_lang_blocks.dll + 07116337 SubsystemBlock :: DrawSubsystemVariants + 00003905
[81] 0x000000000fb93d53 binwin64sl_lang_blocks.dll + 07355731 SubsystemCopyContext :: srcBdIsHighlighting + 00007491
[82] 0x000000000fb4e013 binwin64sl_lang_blocks.dll + 07069715 SubsystemBlock :: CheckPrmsAndCreateDlgPrmCache + 00001139
[83] 0x000000000b301f00 binwin64libmwsimulink.dll + 16785152 closeMaskEditor + 00056736
[84] 0x000000000b3021c9 binwin64libmwsimulink.dll + 16785865 closeMaskEditor + 00057449
[85] 0x000000000b30f3c4 binwin64libmwsimulink.dll + 16839620 BlockSetLocation + 00006420
[86] 0x000000000b30b424 binwin64libmwsimulink.dll + 16823332 closeMaskEditor + 00094916
[87] 0x00000002622387c2 binwin64sl_compile.dll + 05539778 EvalAllBlockParamsAndModelArgs + 00003586
[88] 0x0000000261f544ef binwin64sl_compile.dll + 02508015 SLCompEvalAllBlockParamsAndModelArgs + 00001439
[89] 0x000000000afd3e2b binwin64libmwsimulink.dll + 13450795 ssSetBlockIsPurelyCombinatorial + 00033739
[90] 0x000000000afd4014 binwin64libmwsimulink.dll + 13451284 ssSetBlockIsPurelyCombinatorial + 00034228
[91] 0x000000000ae33fd5 binwin64libmwsimulink.dll + 11747285 M2MIdentifySLClones + 00207269
[92] 0x000000000ae26bf7 binwin64libmwsimulink.dll + 11693047 M2MIdentifySLClones + 00153031
[93] 0x000000000ae33929 binwin64libmwsimulink.dll + 11745577 M2MIdentifySLClones + 00205561
[94] 0x000000000ae2ea7c binwin64libmwsimulink.dll + 11725436 M2MIdentifySLClones + 00185420
[95] 0x000000000b538177 binwin64libmwsimulink.dll + 19104119 slstSetOutputPortRateID + 00122343
[96] 0x000000000b53d10e binwin64libmwsimulink.dll + 19124494 slstSetOutputPortRateID + 00142718
[97] 0x000000000b5439c1 binwin64libmwsimulink.dll + 19151297 slstSetOutputPortRateID + 00169521
[98] 0x000000000b5431a7 binwin64libmwsimulink.dll + 19149223 slstSetOutputPortRateID + 00167447
[99] 0x000000000b576d05 binwin64libmwsimulink.dll + 19361029 slstSetOutputPortRateID + 00379253
[100] 0x000000000ad7960a binwin64libmwsimulink.dll + 10982922 slAccPostBlock + 00178826
[101] 0x000000000abc8e73 binwin64libmwsimulink.dll + 09211507 QueryMLFcnTable_libmwsimulink + 00088563
[102] 0x0000000016f0b724 binwin64pgom_dispatcher.dll + 00046884 Mdispatcher :: getDispatcher + 00002228
[103] 0x0000000016f0cbe7 binwin64pgom_dispatcher.dll + 00052199 Mfh_MATLAB_fn_impl :: dispatch_fh + 00000343
[104] 0x0000000017de4ead binwin64pgom_lxe.dll + 00347821
[105] 0x0000000017f7e9b6 binwin64pgom_lxe.dll + 02025910 MathWorks :: lxe :: ShutdownLxeEngine + 00004034
[106] 0x0000000017edfd3c binwin64pgom_lxe.dll + 01375548 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "145"> :: load_object_data + 00493568
[107] 0x0000000017ee091c binwin64pgom_lxe.dll + 01378588 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "147"> :: load_object_data + 00496608
[108] 0x0000000017ee1c92 binwin64pgom_lxe.dll + 01383570 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "149"> :: load_object_data + 00501590
[109] 0x0000000017ee28f8 binwin64pgom_lxe.dll + 01386744 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "151"> :: load_object_data + 00504764
[110] 0x0000000017ee1ddf binwin64pgom_lxe.dll + 01383903 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "153"> :: load_object_data + 00501923
[111] 0x0000000017ee1ede binwin64pgom_lxe.dll + 01384158 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "155"> :: load_object_data + 00502178
[112] 0x0000000017de9a7d binwin64pgom_lxe.dll + 00367229
[113] 0x0000000017dfb265 binwin64pgom_lxe.dll + 00438885
[114] 0x0000000017dfa88c binwin64pgom_lxe.dll + 00436364
[115] 0x0000000017df8779 binwin64pgom_lxe.dll + 00427897
[116] 0x0000000017df90eb binwin64pgom_lxe.dll + 00430315
[117] 0x0000000017df8a49 binwin64pgom_lxe.dll + 00428617
[118] 0x0000000016f0e007 binwin64pgom_dispatcher.dll + 00057351 Mfh_file :: dispatch_fh_impl + 00001111
[119] 0x0000000016f0da9e binwin64pgom_dispatcher.dll + 00055966 Mfh_file :: dispatch_fh + 00000062
[120] 0x0000000017de4ead binwin64pgom_lxe.dll + 00347821
[121] 0x0000000017f7e9b6 binwin64pgom_lxe.dll + 02025910 MathWorks :: lxe :: ShutdownLxeEngine + 00004034
[122] 0x0000000017edfd3c binwin64pgom_lxe.dll + 01375548 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "167"> :: load_object_data + 00493568
[123] 0x0000000017ee091c binwin64pgom_lxe.dll + 01378588 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "169"> :: load_object_data + 00496608
[124] 0x0000000017ee1c92 binwin64pgom_lxe.dll + 01383570 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "171"> :: load_object_data + 00501590
[125] 0x0000000017ee28f8 binwin64pgom_lxe.dll + 01386744 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "173"> :: load_object_data + 00504764
[126] 0x0000000017ee1ddf binwin64pgom_lxe.dll + 01383903 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "175"> :: load_object_data + 00501923
[127] 0x0000000017ee1ede binwin64pgom_lxe.dll + 01384158 mwboost :: archive :: detail :: iserializer <: archive :: binaryterm_iarchive i = "177"> :: load_object_data + 00502178

Эта ошибка была обнаружена во время работы MEX-файла. Если MEX-файл
не является официальной функцией MathWorks, пожалуйста, изучите ее исходный код
на ошибки. Пожалуйста, обратитесь к Руководству по внешним интерфейсам для получения информации.
по отладке MEX-файлов.

Привет @bjonkman , Привет @jjonkman ,
Как я уже упоминал выше, я мог изменять массы лопастных элементов в рамках данной симуляции. Изменение масс лопаточного элемента создает дополнительный крутящий момент за счет изменения углового момента. Это крутящий момент. T_cor , также может быть выражено через силу Кориолиса F_cor , действующую на переменный радиус перемещаемых масс R_var , как описано в следующем уравнении.

T_cor = 3 ∙ F_cor ∙ R_var

Как упоминал @jjonkman в предыдущем комментарии:

Я не смог найти в исходном коде ElastoDyn те термины, которые учитывают силу Кориолиса. Вижу, что в ElastoDyn.f90\FUNCTION SignLSSTrq( p, m ) рассчитывается момент на тихоходном валу MomLPRot . Правильно ли добавлять Кориолис в этот момент:

Где u% ExternalRvar и u% ExternalFcor - переменный радиус и сила Кориолиса из Simulink, соответственно.
Не могли бы вы мне помочь, как добавить крутящий момент Кориолиса к крутящему моменту вала на низкой скорости?

Уважаемый @LaurenceWETI ,

Я бы не стал менять ФУНКЦИЮ SignLSSTrq (), как вы предлагаете. Силы Кориолиса и другие силы рассчитываются внутри ElastoDyn. Если вы изменяете массы лопаточного элемента на каждом временном шаге до того, как будут выполнены основные динамические расчеты, влияние этих масс на инерционные силы должно быть учтено по существу.

С наилучшими пожеланиями,

Уважаемый @jjonkman ,

Спасибо за ваш повтор.
Точно по той же причине, что изменение масс лопаточных элементов должно происходить на каждом временном шаге и до того, как будут выполнены основные динамические вычисления, я вызвал подпрограммы изменения массы в начале SUBROUTINE ED_CalcOutput\ElastoDyn.f90 . Позвольте мне кратко описать поток заказов на вызов на следующем рисунке.

Где Subroutine Flywheel_Ini(p) вызывается только при t = 0 для инициализации, Subroutine Flywheel(p, u) вызывается на каждом временном шаге для перезаписи масс элементов лезвия, а Subroutine UpdateCoeff(p, ErrStat, ErrMsg) вызывается после изменения масс лезвия для обновления параметров Subroutine Coeff(p,InputFileData, ErrStat, ErrMsg) . Чтобы включить перезапись типа данных параметра p% я изменил назначение структуры данных параметра только с IN на INOUT

Изменил ли я массы в точке до того, как начнутся основные динамические расчеты?

Не могли бы вы указать, пожалуйста, в коде ElastoDyn, где рассчитывается сила Кориолиса?

Сила Кориолиса, о которой вы упомянули, рассчитана из-за изменения массы лопасти или из-за движения башни из стороны в сторону?

Уважаемый @LaurenceWETI ,

Два основных динамических расчета в ElastoDyn:

• ED_UpdateStates - интегрирует (продвигает) состояния во времени от одного временного шага к другому.
• ED_CalcOutput - вычисляет выходы в текущее время.

В основной подпрограмме FAST_Solution ED_UpdateStates вызывается перед ED_CalcOutput, поэтому я думаю, вам нужно будет выполнить эти вычисления в начале ED_UpdateStates.

Сила Кориолиса возникает из-за движения лезвия (из-за отклонения лезвия и башни) во вращающейся системе отсчета. Сила Кориолиса основана на ускорении тела и, следовательно, является неотъемлемой частью кинематики и кинетики. ElastoDyn использует динамику Кейна, поэтому скорости и ускорения выражаются как частичные. Основные кинематические и кинетические процедуры в ElastoDyn (CalculatePositions, CalculateAngularPosVelPAcc, CalculateLinearVelPAcc и CalculateForcesMoments) будут играть роль.

С наилучшими пожеланиями,

Уважаемый @jjonkman ,

Большое спасибо за ваш повтор,
Как вы предлагаете в последнем комментарии, я перенес свой расчет в начало ED_UpdateStates :

Но я не уверен, рассчитана ли сила Кориолиса для переменных масс элемента лопасти или, по крайней мере, для моей реализации изменения масс. Позвольте мне проиллюстрировать примером, где, как я ожидал, должно быть видно влияние силы Кориолиса.
В следующем примере каждое лезвие инициализируется дополнительной жидкостью массой 4 000,00 кг в первых двух элементах лезвия. Через 40 с я переместил 2000,00 кг массы жидкости с первого элемента лопасти на 11-й, 12-й и 13-й элементы лопасти. Остальная жидкость во втором элементе лопасти перемещается за 80 с к 11-му, 12-му и 13-му элементам лопасти. Таким образом, за 100 с вся масса жидкости массой 4 000,00 кг перемещается от корневых элементов лопатки к элементам корпуса лопасти. Я повторил эту процедуру в обратном направлении (от тела к корню) между 130 и 190 с (см. Рисунок ниже).

В соответствии с перемещаемой массой текучей среды следует отметить влияние силы Кориолиса на крутящий момент вала на низкой скорости во время движения текучей среды, то есть между 40-60 с, 80-100 с, 130-150 с и 170-190 с. Однако крутящий момент на низкоскоростном валу почти постоянен в указанные периоды (см. Рисунок ниже).

Я могу видеть влияние добавленной массы на отклонение наконечника в горизонтальном направлении (см. Следующий рисунок TipDyb1 ), но я все еще не могу распознать влияние силы Кориолиса.

Буду признателен за любую помощь, советы или обсуждение.

Уважаемый @LaurenceWETI ,

Я не совсем понимаю, что вы ожидаете увидеть от силы Кориолиса.

Насколько я понимаю, вы переносите массу лопасти с внутренней на внешнюю. Большой эффект от этого будет заключаться в увеличении инерции ротора относительно вала. Вы можете проверить, что происходит, с помощью упрощенного теста. Исходя из сохранения углового момента, можно было бы ожидать, что при отсутствии аэродинамических характеристик или крутящего момента генератора ротор будет замедляться при перемещении массы за борт из-за увеличения инерции. Этот тест работает? То есть отключите AeroDyn и ServoDyn и включите GenDOF и задайте ротору начальную скорость ротора в ElastoDyn. Замедляет ли смещение массы подвесного двигателя ротор?

С наилучшими пожеланиями,

Уважаемый @jjonkman ,

Спасибо за быстрый ответ.

Я ожидал, что сила Кориолиса замедлит ротор, когда масса смещается наружу, и ускорит ротор, когда масса смещается внутрь. Думаю, именно поэтому вы предлагаете отключить AeroDyn и Servoyn и включить GenDOF. Я отключил AeroDyn и ServoDyn, установив CompAero и CompServo на ноль во входном файле FAST, а GenDOF на True и RotSpeed ​​на 12.1 во входном файле ElastoDyn.

Результат моделирования, приведенный выше, очевидно, показывает, что скорость ротора не снижается при смещении массы за борт.
Как вы упомянули выше, сила Кориолиса, присущая кинематике и кинетике, основана на ускорении тела, а не на изменении масс между двумя временными шагами моделирования. Сила Кориолиса в моей модели основана на смещении масс. Поэтому я хотел бы добавить эту часть силы Кориолиса к крутящему моменту ротора в исходном коде ElastoDyn. Я уже рассчитал крутящий момент Кориолиса в MATLAB / Simulink, и я бы использовал этот крутящий момент в качестве внешнего входа в ElastoDyn. Вы можете мне помочь, где добавить эту часть?

С наилучшими пожеланиями

Уважаемый @LaurenceWETI ,

Я не продумал все изменения, которые вам пришлось бы внести, чтобы сместить массу на длинное лезвие. Но ясно, что внесенные вами изменения неполные. Какую форму принимают ваши новые грузы? Если эти нагрузки не вычисляются и не применяются локально вдоль лезвия, я бы не ожидал, что они обеспечат желаемый динамический отклик. И вам необходимо убедиться, что добавляемые вами нагрузки не учитывают дважды уже добавленные вами термины и что другие важные термины не пропущены.

Вы уже рассмотрели теоретическую основу ElastoDyn и определили, как следует изменить эту основу, чтобы приспособиться к сдвигу массы вдоль лезвия? Если нет, то это будет первый шаг, который я вам предлагаю сделать. Хотя официально основы теории ElastoDyn не опубликованы, они задокументированы в так называемом «Неофициальном руководстве по теории FAST на нашем форуме» - см .: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t= 1532. Вы уже рассмотрели это и определили, какие изменения потребуются, чтобы приспособиться к сдвигу массы вдоль лезвия?

С наилучшими пожеланиями,

Уважаемый @jjonkman ,

Спасибо за быстрый повтор,

Новые нагрузки я бы реализовал в виде дополнительного момента, действующего непосредственно на тихоходный вал. Этот момент уже рассчитан в Simulink, и я бы импортировал его в ElastoDyn через S-функцию. Я знаю, что способ добавления новых нагрузок очень упрощен и не могу гарантировать, что добавленные нагрузки не будут дважды учитывать термины, которые я уже добавил. Но для меня сейчас очень важно начать с простой имплантации, которая показывает хотя бы динамический эффект смещенной массы вдоль лезвия. Основываясь на этой простой реализации, я бы перешел к более точной реализации с использованием теоретической основы ElastoDyn.
В предыдущем комментарии вы не рекомендовали мне добавлять этот момент в FUNCTION SignLSSTrq (). Можете ли вы дать мне представление о том, где и как добавить этот момент в исходный код ELastoDyn. Буду очень признателен за вашу помощь.

С наилучшими пожеланиями,

Уважаемый @LaurenceWETI ,

Что ж, ElastoDyn имеет сетку точек входа на уровне модуля для внешних нагрузок, приложенных к концентратору (HubPtLoad). Я бы добавил к этому вашу ношу. Но интерфейс Simulink в настоящее время не настроен для приема HubPtLoad в качестве входных данных от Simulink, поэтому для этого вам нужно будет изменить как связующий код OpenFAST, так и интерфейс Simulink.

С наилучшими пожеланиями,

Уважаемый @jjonkman

Спасибо, что указали на это,
Как вы предложили в своем предыдущем комментарии, я искал внешние нагрузки, приложенные к концентратору ( HubPtLoad ). Я думал, что могу добавить внешний момент Кориолиса к u%HubPtLoad%Moment() в SUBROUTINE ED_Perturb_u(). Но проблема в том, что когда я устанавливаю анализ линеаризации на TRUE во входном файле, чтобы включить подпрограммы Якоби для возможностей линеаризации, у меня такая ошибка:

Эта ошибка связана с тем, что интерфейс Simulink не настроен для приема ввода от Simulink? Правильно ли я понимаю то, что вы предложили? Не могли бы вы дать мне более подробную информацию о том, где изменить связующий код OpenFAST и интерфейс Simulink?
Есть ли другой способ добавить эту дополнительную нагрузку из Simulink? Собственно, я попытался добавить этот момент к моменту в плоскости у корня лезвия MomH0B в SUBROUTINE ED_CalcOutput . Но даже при изменении момента в плоскости скорость ротора остается неизменной (см. Рисунок ниже).

Не изменилась ли скорость ротора из-за того, что я отключил AeroDyn и ServoDyn?

С наилучшими пожеланиями,

Уважаемый @LaurenceWETI ,

Вам не нужно менять ElastoDyn, и похоже, что вы сосредоточены на моделировании во временной области, а не на линеаризации. Значит, менять SUBROUTINE ED_Perturb_u() не стоит.

Вместо этого, как я сказал ранее, вам нужно изменить интерфейс Simulink и связующий код OpenFAST. Я бы поискал, как другие переменные передаются через интерфейс Simulink (например, GenTrq) и используются в связующем коде OpenFAST (FAST_Registry.txt, FAST_Solver.f90). Я бы, вероятно, установил вход HubPtLoad в связующем коде OpenFAST рядом с тем местом, где сейчас установлен вход NacelleLoads.

С наилучшими пожеланиями,

Уважаемый @jjonkman

Спасибо за быстрый ответ даже в праздники,

С помощью Бонни я смог узнать, как передавать переменные через интерфейс Simulink и как использовать эти переменные в связующем коде OpenFAST и даже в ElastoDyn. Что хотелось бы знать, где использовать / добавлять внешнюю нагрузку из Simulink в исходный код OpenFAST или в ElastoDyn.

Вы имеете в виду, что мне не нужно менять ElastoDyn. Означает ли это, что внешние нагрузки (момент Кориолиса из Simulink) из-за смещения массы вдоль лопасти не должны добавляться / использоваться в ElastoDyn? Означает ли это, что эту внешнюю нагрузку следует добавлять только в связующий код OpenFAST (FAST_Solver.f90)?

Я не смог найти, где ввод NacelleLoads установлен в связующем коде OpenFAST (FAST_Solver.f90), чтобы установить мои внешние нагрузки рядом с. Ожидаете ли вы, что скорость ротора изменится, когда внешний момент Кориолиса будет добавлен к гондолам?

С наилучшими пожеланиями

Уважаемый @LaurenceWETI ,

Вход HubPtLoad в ElastoDyn на уровне модуля уже применяется в ElastoDyn как внешняя нагрузка, добавленная к концентратору. Обычно эта нагрузка равна нулю. Он используется, когда BeamDyn включен, для приложения нагрузки к концентратору ElastoDyn из корня каждого блейда от BeamDyn. Я предлагаю, чтобы, поскольку вы уже вычисляете эту дополнительную нагрузку в Simulink, вы просто берете значение из Simulink и используете его для установки значения HubPtLoad в связующем коде OpenFAST. Таким образом, никаких изменений в ElastoDyn не требуется.

Вход NacelleLoads в ElastoDyn устанавливается кодом OpenFAST glude в SUBROUTINE ED_InputSolve() файла _FAST_Solver.f90_ (на основе нагрузок от TMD на основе гондолы, рассчитанных в ServoDyn). Вы также можете установить вход HubPtLoad на ElastoDyn в этой ПОДПРОГРАММЕ.

Вы не объяснили, как вычислить «силу Кориолиса» в Simulink. Обычно я думаю о силе Кориолиса как о силе инерции, вызванной движением во вращающейся системе отсчета. Предположительно, скорость вращения, которую вы используете, - это скорость ротора, а скорость перемещения, которую вы используете, является осевой вдоль лопасти (от перемещения массы вдоль лопасти). Тогда сила Кориолиса будет в плоскости ротора, что, как я думаю, повлияет на вращение, если плечо момента относительно вала будет отличным от нуля.

С наилучшими пожеланиями,

Уважаемый @jjonkman!

Спасибо за помощь,
Как вы предложили, я установил значение HubPtLoad в SUBROUTINE ED_InputSolve из FAST_Solver.f90 для дополнительной нагрузки от Simulink следующим образом:

Где u_ED%ExternalCoriolis1 - дополнительная нагрузка, вычисленная в Simulink. Поскольку HubPtLoad - единственный вход, который не решается в SUBROUTINE ED_InputSolve , а MeshMapData%u_ED_HubPtLoad%Moment установлен в ноль в SUBROUTINE FullOpt1_InputOutputSolve () , я изменил значение HubPtLoad в SUBROUTINE FullOpt1_InputOutputSolve () к дополнительной нагрузке Simulink:

Чтобы вычислить момент Кориолиса, я использовал эти два уравнения:
T_cor = 3 * F_cor * R_var
F_cor = 2 * m_fluid * w_rot * v_fluid
Где R_var - переменный радиус центра тяжести смещенной массы в элементах вершины лопасти [м]; m_fluid - масса перемещаемой жидкости [кг]; w_rot - скорость вращения ротора [об / с]; и v_fluid - скорость поступательного движения жидкости вдоль лезвия [м / с]. На рисунке ниже показан крайний пример момента Кориолиса, где очевидно, что дополнительный момент не влияет на скорость ротора.

в этом примере я отключил ServoDyn и AeroDyn и включил GenDOF, и я даю скорости ротора начальное значение 12,1 [об / мин]

Правильно ли я установил значение HubPtLoad?

Вы можете объяснить, почему я не вижу влияния дополнительной нагрузки на скорость вращения ротора?

Наилучшие пожелания

Уважаемый @jjonkman ,

Я понимаю влияние дополнительной кориолисовой нагрузки из-за смещения массы вдоль лопасти как нагрузки в плоскости ротора, которая должна быть положительной (в направлении вращения), когда масса смещается от внешнего двигателя к двигателю, и отрицательной (против направление вращения) при смещении массы с внутреннего на внешний. Согласны ли вы с этим? Остается ли скорость ротора неизменной в моем последнем моделировании из предыдущего комментария, потому что 12,1 [об / мин], установленное во входном файле ElastoDyn, является не только начальным значением, но также фиксированным значением скорости ротора на протяжении всего моделирования?

Любая помощь приветствуется.

С наилучшими пожеланиями,

Уважаемый @LaurenceWETI ,

Я согласен со строками кода, которые вы изменили в SUBROUTINE FullOpt1_InputOutputSolve() , но этот код используется только при включенном BeamDyn. В SUBROUTINE ED_InputSolve() , что у вас есть, неверно. Вместо этого так должно быть;

u_ED%HubPtLoad%Moment = u_ED%ExternalCoriolis1

Ваши уравнения для момента Кориолиса выглядят нормально, но этот момент должен быть трехэлементным вектором, содержащим глобальные компоненты X, Y и Z момента. Вы устанавливаете каждый компонент этого трехэлементного вектора? Первый компонент (X) будет находиться непосредственно вокруг вала только в том случае, если вал выровнен с глобальной осью X, т. Е. Если вращение платформы, отклонение башни, наклон вала и угол рыскания равны нулю.

С наилучшими пожеланиями,

Уважаемый @jjonkman ,

Спасибо, что указали на это,
Я изменил определение момента Кориолиса на трехэлементный вектор, чтобы включить компоненты момента X, Y и Z. Я исправил код в SUBROUTINE ED_InputSolve\FAST_Solver.f90 на:
u_ED%HubPtLoad%Moment = u_ED%ExternalCoriolis1
Однако форма выражения массива Момента в u_ED%HubPtLoad%Moment не соответствует:

Я искал в FAST_Solver.f90 как используется u_ED%HubPtLoad%Moment , и обнаружил, что эта переменная используется в SUBROUTINE Add_FullOpt1_u_delta() в такой форме:
u_ED%HubPtLoad%Moment(fieldIndx,node)
Что-то отсутствует в u_ED%HubPtLoad%Moment в SUBROUTINE ED_InputSolve ?

С наилучшими пожеланиями

Уважаемый @LaurenceWETI ,

Хорошая точка зрения. Я забыл, что u_ED%HubPtLoad%Moment - это двумерный массив. Конечно, во втором измерении есть только один узел. Итак, правильное назначение должно быть:

u_ED%HubPtLoad%Moment(:,1) = u_ED%ExternalCoriolis1(:)

С наилучшими пожеланиями,

Сетка HubPtLoad в настоящее время используется в связующем коде только для обеспечения связи BeamDyn с ElastoDyn. Поскольку это применяется в подпрограммах SolveOption1, в настоящее время оно устанавливается только в расчетах остатка FullOpt1_InputOutputSolve .

Если вы хотите добавить дополнительную нагрузку к сетке HubPtLoad , она должна быть в FullOpt1_InputOutputSolve для связи BeamDyn и в ED_InputSolve() если вы не используете BeamDyn. Подпрограмму Add_FullOpt1_u_delta изменять нельзя.

Уважаемый @jjonkman , Уважаемый @bjonkman ,

Спасибо за ваш ответ. Теперь он выглядит намного лучше, и я мог видеть влияние дополнительной нагрузки на скорость вращения ротора.

С наилучшими пожеланиями

Уважаемый @jjonkman ,

У меня вопрос о крутящих моментах, действующих на ступицу, когда AeroDyn и ServoDyn отключены. Как вы и ожидали раньше, смещение массы наружу замедляет ротор, но смещение той же массы внутрь не приводит к ускорению ротора с тем же значением, см. Рисунок ниже.

Собственно, сейчас я вычисляю крутящий момент Кориолиса в зависимости от изменения инерции смещенной массы следующим образом:

J_Mass_bl = R_var ^ 2 * m_Mass
T_Coriolis = 3 * d / dt (J_Mass_bl) * скорость_ротора

Где R_var - это переменный центр тяжести смещенной массы, а m_Mass - смещенная масса вдоль лезвия.

Я не мог понять, почему дополнительный крутящий момент Кориолиса не привел к ожидаемому ускорению ротора при перемещении массы внутрь!

С наилучшими пожеланиями.

Уважаемый @LaurenceWETI ,

Я не уверен, что понимаю разницу между вашими двумя расчетами. Если вы используете d / dt (J_Blade_bl) = 2 R_var m_Mass * v_fluid, разве реализация не идентична той, что была у вас раньше?

Вы не показали крутящий момент генератора (связанный с контроллером крутящего момента) или аэродинамический крутящий момент (связанный с контроллером шага), но может ли контроллер играть роль в том, почему скорость ротора не увеличивается так сильно, как вы этого ожидаете к?

С наилучшими пожеланиями,

Уважаемый @jjonkman ,

Большое спасибо за быстрый ответ. Мне было интересно, поскольку вы просили меня показать крутящий момент генератора (привязанный к контроллеру высоты тона), хотя я отключил ServoDyn во входном файле OpenFAST, установив CompServo на ноль, и нет выходных данных этой модели для построения электрических диаграмм. крутящий момент генератора (GenTq). Однако я включил ServoDyn во входном файле FAST и отключил все контроллеры во входном файле ServoDyn, чтобы получить GenTq в выходных сигналах без воздействия контроллеров. Внезапно скорость ротора увеличилась, как и ожидалось:

Я не смог найти разумную причину, по которой генератор и контроллер крутящего момента не отключаются, когда CompServo установлен на ноль во входном файле FAST, и он должен быть отключен во входном файле ServoDyn, чтобы отключить эффекты в ElastoDyn. Может ты сможешь объяснить этот феномен?

С наилучшими пожеланиями

Уважаемый @LaurenceWETI ,

Входные данные от Simulink к S-функции OpenFAST (крутящий момент, тангаж, рыскание и т. Д.) Включаются путем установки связанных моделей управления соответствующим образом (например, VSContrl = 5 для принятия крутящего момента от Simlulink). Итак, я не ожидал, что входы Simulink будут использоваться, если ServoDyn не включен. Конечно, вы изменили интерфейс Simulink так, чтобы ваши новые нагрузки Кориолиса применялись непосредственно к ElastoDyn, а не проходили через ServoDyn, поэтому я предполагаю, что вы уловили часть эффекта.

С наилучшими пожеланиями,

Я работаю над установлением пути для распространения библиотеки OpenFAST, скомпилированной для интеграции Simulink, вместе с другими исполняемыми файлами, которые мы регулярно публикуем для каждого выпуска. Я добавил файл, включенный в последний выпуск, под названием openfastlib_simulink.dll . Кто-нибудь может протестировать прикрепленную библиотеку? Это библиотека OpenFAST, которую нужно связать в mex-функции.

Я работаю над установлением пути для распространения библиотеки OpenFAST, скомпилированной для интеграции Simulink, вместе с другими исполняемыми файлами, которые мы регулярно публикуем для каждого выпуска. Я добавил файл, включенный в последний выпуск, под названием openfastlib_simulink.dll . Кто-нибудь может протестировать прикрепленную библиотеку? Это библиотека OpenFAST, которую нужно связать в mex-функции.

Мне не удалось найти этот файл в последней Realease ...

@hbasbas Он находится в конце выпуска вместе с другими активами. Я неправильно ввел URL-адрес последней версии выше (теперь он исправлен), поэтому вот правильный URL-адрес: https://github.com/openfast/openfast/releases/tag/v2.5.0

Привет всем!
У меня проблемы с запуском "Run_Test01_SIG.m".
Я использовал последнюю версию openfast v2.5.0 и успешно скомпилировал «FAST_SFunc.mexw64» с помощью matlab2020a и Visual Studio 2019, но когда я запускаю «Run_Test01_SIG.m», происходит сбой matlab. Я много раз пробовал и до сих пор не могу решить эту проблему.
Прилагается отчет о сбое matlab2020a и результаты Create_FAST_SFunc.

С наилучшими пожеланиями!
ЧенПенг
issue.txt

Перевод: cl: Предупреждение командной строки D9025: переписывание «/ MD» (с «/ MT»)

Уважаемый @rafmudaf

Как мы могли использовать команду mex с файлом dll, который вы дали. Следует ли нам вместо этого использовать файл .lib?

Насколько я понимаю, create_FAST_SFunc использует динамически подключаемую библиотеку для компиляции с помощью команды mex. @bjonkman, вероятно, мог бы предоставить более подробную информацию в # 654.

@Domotopeng ваша трассировка стека показывает, что SIMULINK входит в библиотеку OpenFAST, так что это хорошо. Но он вылетает в OpFM_Init, так что это нехорошо. Изменяет ли компиляция OpenFAST в режиме отладки информацию трассировки стека? Номер строки в OpFM_Init был бы отличным.

Я понимаю, что create_FAST_SFunc использует библиотеку динамической компоновки и команду mex для компиляции. @bjonkman может предоставить более подробную информацию в # 654 .

Насколько я понимаю, create_FAST_SFunc использует динамически подключаемую библиотеку для компиляции с помощью команды mex. @Bjonkman, вероятно, может предоставить лучшую информацию в # 654.

Спасибо за ваш совет!