Openfast: Problema cuando ejecuto el modelo simulink que depende de openfast S-Function mex

Estoy un poco confundido por la pila de rastreo. Parece que el problema ocurre en la rutina FAST_OpFM_Init pero no estoy seguro de por qué la interfaz OpenFAST-Simulink estaría en esa rutina. Hasta donde yo sé, esa rutina solo debe llamarse con la interfaz de OpenFAST con un código CFD (no Simulink).

1. ¿Qué versión de OpenFAST estás usando?
2. ¿Creó la biblioteca mex y OpenFAST-Simulink DLL (si es así, cómo?), O está utilizando binarios precompilados?
3. ¿Modificó el código fuente o compiló scripts antes de compilar?
4. ¿Los modelos de ejemplo OpenFAST Simulink se ejecutan sin fallar?

1 - No sé cómo puedo ver eso, pero creo que estoy usando 1.0.0
2- Sí, construí la biblioteca mex. Primero uso Visual Studio 2015 y compilo el archivo Simulink-Openfast con las opciones Release_Matlab y la opción x64. El nombre del archivo resultante es OpenFAST-Simulink_x64 (adjunto una imagen) y puedo encontrarlo en build / bin.
Para obtener una solución rápida, también utilizo el mismo programa.

3- No toco el archivo mex, solo modifico el .m para cargar al espacio de trabajo las variables y luego ejecuto el modelo simulink (ambos están en la misma ubicación que los modelos predeterminados [C: UsersCASADocumentscodeopenfastglue-codessimulinkexamples, y. m que genera la función S en build / bin se puede encontrar en ..... openfastglue-codessimulinksrc])
4- No, no lo hace

1. Si realmente está en la v1.0.0, definitivamente debería actualizar a la última versión de OpenFAST (rama maestra). Sin embargo, me sorprendería que v1.0.0 tuviera la opción Release_Matlab, así que supongo que es una versión diferente. Debería poder ver el número de versión en un archivo llamado <openfast>\vs-build\gitVersionInfo.h . O puede verlo impreso en la pantalla cuando ejecuta OpenFAST.

2. Lo que describe es la construcción del archivo OpenFAST_Simulink_x64.DLL . El archivo mex generalmente se construye usando openfast\glue-codes\simulink\src\create_FAST_SFunc.m . ¿También construiste esto? En su sistema debería crear FAST_SFunc.mex64 . Dada la fecha de modificación de FAST_SFunc en su captura de pantalla, supongo que también creó esto, pero solo estoy comprobando que no provenga de otra compilación de OpenFAST.

Trabajaría para hacer que el modelo OpenLoop de ejemplo funcione con uno de los casos de prueba r de OpenFAST antes de intentar depurar lo que está sucediendo con su modelo particular de Simulink. De esa forma, puede compartir todos los detalles de lo que está haciendo.

Asegúrese de compilar FAST_SFunc con el mismo compilador que usó al compilar OpenFAST-Simulink_x64.DLL (es decir, ejecute mex -setup en Matlab y haga que use Visual Studio C / C ++ e Intel Fortran).

Hola @bjonkman ,

1. Lo siento por la información de la versión, lo verifico y es V2.3.0 ---> #define GIT_VERSION_INFO 'v2.3.0-548-g43191a90'

2 - Sí, ejecuto create_FAST_SFunc.my obtengo FAST_SFunc.mex64 en build / bin.

Para mostrarte todos los pasos que hice, adjuntaré algunas capturas de pantalla:

Primero, ejecuto mex -setup para confirmar que uso el mismo compilador --- Visual Studio 2015. Esto es correcto.
El siguiente paso es generar la función S ejecutando create_FAST_SFunc.my obtengo FAST_SFunc.mex64.

El siguiente paso es ejecutar Run_OpenLoop.m:

Puede ver que Matlab tiene un problema en este paso y necesita cerrarse en ese momento.

Atentamente,

Joaquín

Creo que esto probablemente apunta a un problema en el archivo OpenFAST-Simulink_x64.DLL . ¿El código imprimió algo más en la ventana de comandos de Matlab antes de que fallara? (No puedo ver si hay algo impreso debajo del tiempo de ejecución). Como mencioné, el rastreo que muestra dice que está en una rutina que no debería llamarse para esta compilación. ¿Puedes mostrarme cómo construiste esa DLL?

No, el código no mostró nada más aparte de eso.
El proceso para obtener el archivo .dll es:

1- Ejecuto solución rápida (release_x64 double); después de usar Python para ejecutar la prueba y la prueba en la que estoy interesado, pasa bien.

2- Siguiente paso, para hacer la integración Openfast Simulink, abro Visual Studio 2015 y ejecuto el archivo fortran llamado OpenFAST-Simulink y en propiedades-input, cambio para apuntar correctamente a libmex.lib (la ruta por defecto no es la correcta )
3- Ejecuto OpenFAST-Simulink (lanzamiento de Matlab x64) y después ejecuté FAST (lanzamiento de Matlab x64) y fue todo lo que hice

¿Necesitas capturas de pantalla de todos los pasos?

¿Podría abrir el archivo FAST.sln y compilar con Release_Matlab | x64 desde ese archivo de solución en lugar del archivo OpenFAST-Simulink.sln que está utilizando? Si no tiene esa opción (con el proyecto OpenFAST-Simulink en el archivo de solución FAST ), le recomendaría usar la última rama maestra de OpenFAST para que esté compilando con esa.

He construido la solución FAST.sln con esta configuración y obtuve esto, se lo muestro en la captura de pantalla a continuación:

No sé cómo hacer la construcción con la solución maestra. ¿Debo descargar solo el nuevo fortran Openfast-Simulink?

¿Qué pasos debo seguir para obtener el .dll que está buscando? (Si finges eso)

Hola a todos,

No sé si puedo unirme a la discusión, tengo exactamente el mismo problema.

Estoy usando VS 2019 Community con Intel Parallel Studio XE 2020. Recientemente descargué la versión maestra de OpenFAST, así que debería tener la última.

Compilo el archivo DLL con la solución FAST.sln con diferentes configuraciones:

1. En modo "Release_Double_x64": la compilación funciona sin errores. Luego, creo el archivo mex con el "create_FAST_Sfunc.m" ==> funciona. Ejecuto el archivo "RUN_OpenLoop" y obtengo la captura de pantalla adjunta.
   

2. En modo "Release_64": mismo problema al llegar a la simulación Simulink

3. En modo "Release_Matlab_64" (solo para proyectos OpenFast-Simulink y FASTlib, ¿verdad?): No puedo compilar la solución FAST VS (ver adjunto)
   

@hbasbas : debe generar un OpenFAST-Simulink-x64.dll desde el proyecto de Visual Studio, por lo que realmente solo necesita compilar la versión en el paso 3 (excepto que también necesita ejecutar el archivo create_FAST_SFunc.m después de completar el paso 3). Si está ejecutando FAST_SFunc en Matlab antes de crear la DLL, entonces supongo que está llamando a otra versión de esta dll desde algún otro lugar en su ruta de Matlab. Si escribe which OpenFAST-Simulink-x64.dll , en la ventana de comandos de Matlab, debería darle la ruta completa a la DLL que está usando.

El motivo de su Release_Matlab | La configuración x64 (que es la que necesita usar) no se está construyendo parece ser que tiene una versión diferente de Matlab para la que se configuró el proyecto. Deberá abrir las propiedades de configuración para el archivo de proyecto OpenFAST-Simulink (haga clic con el botón derecho en el proyecto, luego seleccione properties y vaya a la línea de entrada del enlazador. versión de Matlab que está utilizando:

@JoaquinPerCarr , para obtener la rama maestra con git, puede verificar la rama maestra y luego extraer el nuevo código.

Es posible que tenga otra copia de la DLL en su ruta de Matlab que también esté causando confusión. Pruebe which OpenFAST-Simulink_x64.dll en la ventana de comandos de Matlab y vea si apunta a la correcta.

Hola @bjonkman :

Hice lo que me dijiste. Primero descargué todos los archivos maestros de openfast, luego cambié el antiguo fortran OpenFAST-Simulink y copié el nuevo. Construí FAST con Release_Matlab_x64 y OpenFAST-Simulink_Release_Matlab_x64 para obtener el nuevo .dll.

Repetí todo el proceso tal como lo expliqué en el primer momento de esta discusión y obtuve los mismos resultados, Matlab se bloquea cuando ejecuto simulink. adjunto una captura de pantalla cuando uso qué OpenFAST-Simulink:

Hola,

@bjonkman : gracias por su respuesta. Gracias a tus recomendaciones, la compilación funciona. Me gustaría precisar (a otros posibles usuarios) que es importante insertar la cita entre la ruta. Debido al espacio del "Archivo de programa", VS intenta encontrar un archivo de objeto.
Sin embargo, Matlab continúa fallando al ejecutar la simulación de Simulink:

¿Es posible que las versiones de Matlab, de Visual Studio e Intel Parallel Studio XE sean responsables del fallo de Matlab?

@JoaquinPerCarr : En el comando "which", parece que especificó el archivo incorrecto: escribe "-x64" en lugar de "_x64"

De lo contrario, ¿es posible compartir el archivo compilado .mex64 de la versión openfast-master. Solo necesito cambiar el archivo de entrada (.dat) pero el código fuente debe ser el mismo para mí. Además, identificaré el problema:
Si no funciona con él, esto debería significar que tengo un problema con mi versión de Matlab u otras. Si funciona, significa que la compilación de Visual Studio no está bien configurada.

Bien, creo que veo cuál es el problema.

Si abre <openfast>\modules\openfast-library\src\FAST_Library.h , cambie la definición de CHANNEL_LENGTH de 10 a 20:

#define CHANNEL_LENGTH 20

Luego, vuelva a ejecutar el archivo create_FAST_SFunc.m y vuelva a intentarlo.

Recibiré una solicitud de extracción con esta corrección en OpenFAST.

Muchas gracias. Funciona !

Hola @bjonkman ,

Si hago esto, obtengo esto:

Puedo ver que simulink no se abre y no hace nada más.

Si lee el mensaje de error debajo de la parte que marcó con un círculo, verá que OpenFAST no puede encontrar el archivo de entrada que le pidió que se ejecutara. Run_OpenLoop.m se configuró para los antiguos casos CertTest FAST (v8), por lo que tendría que cambiar los nombres de los archivos de entrada. Ejecuté el siguiente código para probar el modelo 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])

Estoy probando el siguiente código porque estoy interesado en la prueba 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]);

Noto que el modelo de simulink no se abre automáticamente y no sé por qué, pero al principio parece que funciona bien

En resumen, ¿cree que el único problema de mi primer problema fue la línea de código #define CHANNEL_LENGTH 20 en el archivo .h?

Muchas gracias @bjonkman

No creo que Simulink necesite abrir el modelo cuando lo ejecuta con el comando sim() .

La definición incorrecta de CHANNEL_LENGTH en el archivo .h fue lo que hizo que Matlab se cerrara (y para cualquiera que lea esto en el futuro, el seguimiento de la pila no era preciso: en realidad no estaba en el FAST_OpFM_Init rutina).

En cuanto a que ese es el único problema, esperemos que sí. :)

Estoy haciendo cosas diferentes y creo que el maestro openfast-Simulink es necesario

Voy a intentar ejecutar mi primer modelo de simulink y te diré si funciona bien

Hola @bjonkman ,

Me gustaría preguntarle cómo puedo ver qué versión de OpenFAST tengo (dev / master). Si hay algún formulario para volver a la versión maestra, deseo hacerlo.

Si no es posible, ¿cómo puedo eliminar / corregir los errores (banderas) que les muestro en las siguientes capturas de pantalla? CalcSteady, Twr_Kdmp y Bld_Kdmp son el principal problema.

También veo la documentación de OpenFAST. Creo que los errores podrían deberse al uso de la versión dev de OpenFAST. No se que hacer.

Atentamente,

Joaquín.

Estimado @JoaquinPerCarr ,

No estoy seguro de entender realmente su pregunta, pero parece que está utilizando una versión de desarrollo anterior de OpenFAST (en algún lugar entre v2.3 y v2.4) y un archivo de entrada compatible con v2.3. Al igual que con cualquier error en el procesamiento del archivo de entrada, puede habilitar la opción Eco para depurar problemas en el formato del archivo de entrada.

Independientemente, a menos que tenga una razón específica para usar esta versión de desarrollo de OpenFAST, recomendaría actualizar a la rama maestra de OpenFAST, v2.4. Los archivos de entrada de ejemplo de OpenFAST compatibles con v2.4 se proporcionan en la rama maestra de la prueba r.

Atentamente,

@JoaquinPerCarr ,

Por lo general, puede ver la versión de OpenFAST impresa en la pantalla cuando ejecuta OpenFAST. De su captura de pantalla, veo que es v2.3.0-548-g43191a90 . Esto significa que está en el hash de git 43191a90 y 548 confirmaciones después de la versión etiquetada 2.3.0.

Para cambiar a una versión diferente, puede usar algunos comandos de git para verificar cualquier rama y confirmar que desee.

Podrías hacerlo

git checkout v2.4.0

que verificaría la versión 2.4.0 de openfast, pero lo pondría en un estado de encabezado separado en git, o

git checkout master
git pull

que debería darle la última versión de la rama maestra (asumiendo que su rama maestra apunta al repositorio de openfast). Tenga en cuenta que el estado actual de su repositorio de git puede significar que debe guardar algunos cambios antes de cambiar de rama, etc.

De lo contrario, asegúrese de estar usando archivos de ejemplo de la confirmación r-test asociada con la versión de OpenFAST que está usando.

Hola a todos,

Podría compilar el S-Fuction y ejecutar los ejemplos de OpenLoop y Test01_SIG. Ahora estoy tratando de extender las entradas de la función S para habilitar entradas adicionales además de las 8 originales. Pero en la función S de OpenFAST no tengo la opción de cambiar NumAdditionalInputs como en FASTv8.
Cualquier ayuda sería apreciada.

Gracias de antemano.

No tengo conocimiento de nada que haya cambiado la funcionalidad NumAdditionalInputs entre FAST v8 y el último OpenFAST. ¿Qué no está funcionando exactamente?

Hola @bjonkman ,

Gracias por tu repetición.
En realidad, cambiaría los NumAdditionalInputs para importar las masas de los elementos de la hoja en la función S, que son más de 11 para el modelo de 5 MW. Me refiero a 11, porque el número máximo de entradas permitidas para NumAdditionalInputs no debe exceder las 11 entradas, como leí en README_FAST8:

Ya cambié el tipo de datos de las masas del elemento blade en ElastoDyn y pude cambiar las masas dentro de una simulación dada. Ahora genero canales adicionales para exportar las masas de elementos blade de ElastoDyn en Simulink. Modificaría las masas en Simulink y las importaría en la función S, es decir, en ElastoDyn.

_¿Puede ElastoDyn reconocer las masas de elementos de hoja que se importan desde la función S?

_¿Puede ElastoDyn notar los cambios que se realizan en Simulink?

_¿Es posible ingresar más de 11 entradas además del origen 8 en la función S?

Si desea enviar más de 10 entradas adicionales a OpenFAST, puede cambiar el valor de MAXInitINPUTS tanto en FAST_Library.h como en FAST_Library.f90 y volver a compilar tanto la función S de Matlab como la OpenFAST dll. (Si ingresa una matriz con más de MAXInitINPUTS+1 valores en Simulink, probablemente obtendrá un error de segmentación).

MAXInitINPUTS define la matriz más grande que se puede aceptar de Simulink y pasar al código OpenFAST Fortran. OpenFAST no hace nada con esos valores de matriz adicionales a menos que usted se lo indique, por lo que si desea pasar valores a ElastoDyn, deberá realizar algunos cambios adicionales en el código.

Para empezar, tendrá que mirar InitInpAry en FAST_Library.f90 , y luego tendrá que pasar algo de información a ElastoDyn. Recomiendo buscar en el foro NWTC algunos consejos sobre lo que tendrá que cambiar:

• 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

Sin embargo, tenga en cuenta que estas entradas adicionales son valores pasados ​​_desde_ la función S en Simulink _a_ OpenFAST. El código no está configurado particularmente para pasar valores _to_ Simulink a menos que esté usando la matriz WriteOutput (es decir, los canales OutList especificados en cada módulo OpenFAST).

Hola @bjonkman ,

Gracias por su rápida repetición y por los enlaces.
Como iniciador, intenté al principio pasar solo una entrada adicional en la función S. Usé la velocidad del rotor ( RotSpeed ) como entrada adicional, que ya se usa en OutListParameters:

1. Establezca la velocidad del rotor como Entrada en la subrutina FAST_SetExternalInputs() en FAST_Library.f90
   

2. Reconstruya FASTlib desde C: .... OpenFASTvs-buildFASTlib FASTlib.sln

1. Ejecute OpenLoop con una entrada adicional
   

2. La simulación falló en Matlab / Simulink
   
   Veo en subroutine FAST_Start () en FAST_Library.f90 que solo se permiten 3 entradas adicionales. ¿Tengo que cambiar esto para habilitar solo una entrada?
   

La función FAST S original está configurada de modo que si dice que hay 3 entradas adicionales, asumirá que está simulando la funcionalidad Lidar. No creo que se use el código que muestra (no creo que #ifdef sea ​​cierto), pero hay una lógica similar en la subrutina FAST_Update .

Simplemente cambiaría la línea para que no produzca un error si el número de entradas adicionales es 1:

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

Este manejo de errores está ahí porque sería muy fácil obtener una falla de segmentación al pasar matrices de diferentes tamaños entre Simulink y el código de Fortran.

Hola @bjonkman ,
Gracias por señalar eso.
Cambié la lógica como mencionaste en el comentario anterior en subroutine FAST-Update , y luego volví a compilar la DLL FAST de OpenFASTvs-buildFASTlib FASTlib.sln con una configuración diferente:

1. Relase como Configuración de Soultion, x64 como Plataforma de Soultion y Construya la solución usando Build->Build Soultion .

1. Relase como Configuración de Soultion, x64 como Plataforma de Soultion, y Construya la solución usando Build->Rebuild FASTlib .

1. Relase_Matlab como Configuración de Soultion, x64 como Plataforma de Soultion, y Construya la solución usando Build->Rebuild FASTlib .
   Después de cada compilación ejecuto OpenLoop_Test con la entrada adicional y recibí el mismo error anterior

Luego recompillé FAST de OpenFASTvs-buildFAST FASTlib.sln con Relase_Matlab , x64 , y Build->Build Soultion la compilación falló:

La línea 341 en FAST_Library.f90 es la línea donde agregué la lógica para la entrada adicional

¿Parece que la estructura de subroutine FAST_SetExtrenalInputs debería extenderse para permitir esa lógica adicional?

¿Agregó el nuevo campo %RotSpeed a la estructura de datos en la que lo está usando?

Si está agregando campos a una estructura de datos, debe definirlos en el archivo de entrada de OpenFAST Registry correspondiente. En su caso, debería haber una línea adicional en la definición de FAST_ExternInputType . Entonces, en algún lugar cerca de la línea 626 en FAST_Registry.txt , debe agregar una línea para el nuevo campo RotSpeed :

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

Además, la única configuración que necesita usar es la configuración Release_Matlab | x64 . Las otras configuraciones no se utilizan en absoluto en el proceso de Simulink, por lo que solo estaba ejecutando el código antiguo con sus primeras 2 compilaciones.

Hola @bjonkman ,
En primer lugar muchas gracias por su ayuda.
Podría agregar una entrada adicional más a la función S de la siguiente manera:

1. ocupa el noveno elemento en InputAry en FAST_Library.f90\ subroutine FAST_SetExternalInputs

1. definir la entrada adicional en FAST_Rgistery.txt\ FAST_ExternalInput data

1. vincular la entrada externa adicional a ElastoDyn en FAST_Solver.f90\ SUBROUTINE ED_SetExternalInput (escribí esta rutina)

1. definir la entrada externa adicional en ElastoDyn_Registry.txt

1. generar un nuevo parámetro en EladoDyn para sobrescribir y exportar en OutListParameter usando el script Write_ChckOutLst.m

1. sobrescribiendo el nuevo parámetro definido en ElastoDyn con la entrada adicional de Siimulink en ElastoDyn.f90\ SUBROUTINE ED_CalcOutput

1. establezca RotMass en Simulink como una constante para sobrescribir el parámetro definido en ElastoDyn.f90 RMSimulink

1. Trace la salida sobrescrita RMSimulink durante el tiempo (1 s)

Como puede ver, RMSimulink es cero constante a lo largo del tiempo y la sobrescritura no funcionó. Creo que lo que falta es un interruptor en el archivo de entrada de ElastoDyn que habilita las entradas externas de Simulink como está en el archivo de entrada de ServoDyn con PCMode . ¿Puede ver algún error en la implantación anterior? ¿Hay algo que me perdí al sobrescribir?

Debería solicitar el nuevo canal de salida RMSimulink en el OutList del archivo de entrada ElastoDyn para que el valor en la matriz m%AllOuts se coloque en el y%WriteOutput array (que es lo que se imprime en los archivos de salida y se envía a Simulink). Sin embargo, para obtener eso en la matriz WriteOutput , necesitaría modificar la subrutina SetOutParam() en ElastoDyn.f90 para que reconozca la nueva salida que está agregando.

Alternativamente, si no desea actualizar el código en SetOutParam() , puede simplemente sobrescribir un canal existente en ElastoDyn y solicitar ese canal en su lugar.

Hola @bjonkman ,
Gracias por la repetición.
Ya actualizo el código en Subroutine SetOutParam() en ElastoDyn.f90 y el código en ElastoDyn_IO.f90 , para agregar el nuevo canal de salida RMSimulink .
Todavía me pregunto por qué el valor de la entrada externa adicional u%ExternalRotMass de Simulink es igual a cero durante la simulación, aunque establezco este valor en 1000 en Simulink.
Como sugirió, utilicé un canal existente "SpnMxlb" para sobrescribir, pero el resultado sigue siendo el mismo. u%ExternalRotMass siempre es cero!

Hola @bjonkman ,
Encontré dónde estaba el problema. No llamé SUBROUTINE ED_SetExternalInputs en SUBROUTINE ED_InputSolve en el FAST_Solver.f90 . Por lo tanto, tuve que modificar el argumento de SUBROUTINE ED_InputSolve para agregar el tipo de datos m_FAST .

Hola @bjonkman ,
Como mencionaste en un comentario anterior, cambié MAXInitINPUTS de la función S para permitir 100 entradas adicionales. Mi objetivo es sobrescribir las masas de los elementos de la hoja en ElastoDyn.f90\ p%BElmntMass . Podría sobrescribir una masa de un elemento de hoja a través de la función S. Ahora estoy tratando de sobrescribir todas las masas de elementos de la hoja, que son el elemento 51 para las tres hojas. Podría compilar RÁPIDO con la nueva modificación, pero cuando compilo MATLAB me convierto en este error:

Aquí está la línea de error en FAST_Library.f90

El elemento blade masse m_FAST%ExternInput%SpnMB se define en FAST_Registery.txt :

¿Puedes ver si me pierdo algo según la definición de SPNMB?

Ha definido SPNMB como una matriz asignable bidimensional. No sé qué tamaño le asignó, con suerte lo hizo antes de llamar a FAST_SetExternalInputs pero lo está configurando igual a una matriz unidimensional de tamaño 52 (nota: es posible que desee compruebe que 51 está usando o vea si los índices InputAry deberían ir de 9:59 en su lugar). El error es decir que las matrices que está tratando de igualar entre sí no tienen la misma forma (1-d vs 2-d), por lo que no pueden ser iguales.

Además, tenga cuidado al sobrescribir los parámetros (cualquier cosa en la estructura de datos p% ). Se supone que estos valores no cambian después de la inicialización, por lo que (1) es probable que obtenga errores que indiquen que no puede cambiarlos en ciertas subrutinas, (2) otros parámetros también pueden depender de sus valores iniciales, por lo que necesitaría para que sea coherente si cambia el código para que pueda modificar los parámetros durante la simulación.

Hola @bjonkman ,
Gracias por señalar eso.
Cambié la dimensión de la matriz SpnMb de 2-d a 1-d matriz de 51 elementos en FAST_Register.txt y ElastoDyn_Registery.txt . Luego definí una matriz de 3x17 en la subrutina ED_CalcOutput()\ElastoDyn.f90

Usé esta matriz para remodelar la matriz 1-d, que se importa de Simulink, a una matriz de 3x17

Después de remodelar, sobrescribí las masas de los elementos de la hoja con los valores que se importaron de Simulink

Para actualizar los valores que dependen de p%BElmntMass llamé Subrutina UpdateCoeff(p, ErrStat, ErrMsg)

La subrutina UpdateCoeff (p, ErrStat, ErrMsg)\ElastoDyn.f90 , que yo mismo genero, es una rutina muy similar a Subroutine Coeff(p,InputFileData, ErrStat, ErrMsg) con la ventaja de la independencia de los datos del archivo de entrada. Esto permite llamar a la subrutina UpdateCoeff() en el dominio del tiempo, es decir, en ED_CalcOutput() .
Además, cambié la intención de la estructura de datos del parámetro de solo IN a INOUT . Esto es como mencionó anteriormente para permitir que se sobrescriba la estructura de datos p% .
Con las modificaciones de código anteriores, pude compilar FAST y Matlab sin errores. Pero cuando ejecuto OpenLoop con las 51 entradas adicionales, la simulación se bloqueó después de dos pasos de simulación.

No pude identificar la razón de tal error. ¿Ves algo incorrecto en mi implementación que pueda producir este error?
La sobrescritura de una sola masa de elemento de hoja se realiza correctamente. Pero para todos los elementos de la hoja no fue así.
Estaría muy agradecido por cualquier ayuda.
Y gracias de nuevo por tu rápida repetición.

Según cómo se asignan sus matrices, parece que debería tener

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

Sin embargo, no estoy seguro de que ese sea el único problema. Una forma de depurar esto sin tener Matlab en el proceso es simplemente escribir un código de controlador c simple (copie las llamadas principales de FAST_SFunc.c ) y luego compile y ejecute a través del depurador de Visual Studio. Tenía algo como esto para FAST v8: es una herramienta muy útil para ayudar a encontrar este tipo de errores.

Hola @bjonkman ,
Gracias por señalar el error con Element (K, J). Desafortunadamente, obviamente no fue el único problema.
Como sugieres, escribí un controlador c simple:

Pero no pude conocer las llamadas principales de FAST_Sfunction.c que pretendía copiar y pegar en el controlador anterior.
En realidad, solía escribir mensajes emergentes en ciertos lugares del código FORTRAN para rastrear los errores, así es como estoy depurando cuando usé el .exe

Como puede ver, este método no funcionará para la función S.
¿Puedes ayudar con la depuración con VS?

Si usa CALL WrScr( string ) , puede imprimir cosas en la consola de Matlab para su depuración. Supongo que usar print * crearía un archivo de texto fort.7 en el directorio actual de Matlab (cuando está ejecutando el modelo de Simulink). De lo contrario, podría escribir en otro archivo usando WRITE(Unit,Fmt) data para su información de depuración.

Si desea utilizar el depurador de Visual Studio, debe crear un código C para llamar a las partes apropiadas de la DLL, algo similar a este que se escribió para la interfaz OpenFOAM: https://github.com/old-NWTC/ FAST / blob / master / Source / FAST_Prog.c

Al revisar el archivo FAST_SFunc.c, supongo que necesitaría estas rutinas para la inicialización:

       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);

Luego, para cada paso de tiempo (es decir, en un bucle),

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

Y al final, necesitarías

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

Hola @bjonkman ,

Gracias por tu ayuda. CALL WrScr(string) es una función brillante, ayudó mucho. La única desventaja de esta función es que solo pude imprimir cadenas pero no valores en la ventana de comandos de Matlab. También intentaré depurar FAST_Sfunction.c con VS.
Muchas gracias

También hay una función Num2LStr() (cadena de número a la izquierda justificada) que puede usar junto con WrScr , que puede ayudar a imprimir valores numéricos: CALL WrScr( trim( Num2Lstr( number ) ) )

Tengo el mismo problema con openFAST 2.4.0-master y dev.
Compilación con Visual studio y mex generada por compilador C instalado mediante Matlab Add-on (Matlab 2018b).

La función S generada usando archivos fuente v 2.4.0 funciona bien con openFAST 2.3.0 que también compilé con Visual Studio. Entonces creo que el problema no está en la función S.

Ni mi proyecto ni los ejemplos funcionan, todos dan como resultado el bloqueo de Matlab.

Intenté generar la función S cambiando el parámetro #define CHANNEL_LENGTH 20 en el archivo FAST_library.h y tuve el mismo problema. Aquí está mi salida de Matlab:

abortar () detectado en el sexo 27 de noviembre 09:49:16 2020-0300

Configuración:
Decodificación por bloqueo: deshabilitado: no hay zona de pruebas ni ruta de área de construcción
Modo de bloqueo: continuar (predeterminado)
Codificación predeterminada: windows-1252
Implementado: falso
Controlador de gráficos: hardware desconocido
Tarjeta gráfica 1: Intel Corporation (0x8086) Intel (R) UHD Graphics 630 Versión 27.20.100.8681 (2020-9-5)
Versión de Java: Java 1.8.0_152-b16 con modo mixto de VM de servidor de 64 bits Java HotSpot (TM) de Oracle Corporation
Arquitectura de MATLAB: win64
ID de autorización de MATLAB: 6257193
MATLAB Root: C: Archivos de programa
Versión de MATLAB: 9.5.0.944444 (R2018b)
OpenGL: hardware
Sistema operativo: Microsoft Windows 10 Pro
ID de proceso: 9896
ID del procesador: x86 Familia 6 Modelo 158 Paso 10, GenuineIntel
Clave de sesión: 2e3cb4b1-3a3b-46b0-bf51-135d94257c8d
Sistema de ventanas: versión 10.0 (compilación 18363)

Recuento de fallas: 1

Terminación anormal

Estado de registro (capturado):
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

Seguimiento de pila (capturado):
[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 :: símbolos :: 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 aumento + 00000477
[9] 0x00007ffc5307dab1 C: WINDOWSSystem32ucrtbase.dll + 00449201 abortar + 00000049
[10] 0x00007ffc5307d20f C: WINDOWSSystem32ucrtbase.dll + 00446991 terminar + 00000031
[11] 0x00007ffc4a142388 C: Archivos de programaMATLABR2018bbinwin64VCRUNTIME140.dll + 00009096 is_exception_typeof + 00002312
[12] 0x00007ffc4a141ec2 C: Archivos de programaMATLABR2018bbinwin64VCRUNTIME140.dll + 00007874 is_exception_typeof + 00001090
[13] 0x00007ffc4a14b950 C: Archivos de programaMATLABR2018bbinwin64VCRUNTIME140.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: Archivos de programaMATLABR2018bbinwin64VCRUNTIME140.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 :: enviar + 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 prueba :: 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 prueba :: sl_startup + 00020938
[41] 0x000000000b6ba838 binwin64libmwsimulink.dll + 20686904 prueba :: 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 RtlSalirUserProcess + 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

Este error se detectó mientras se estaba ejecutando un archivo MEX. Si el archivo MEX
no es una función oficial de MathWorks, examine su código fuente
por errores. Consulte la Guía de interfaces externas para obtener información.
sobre la depuración de archivos MEX.

Hola @bjonkman , Hola @jjonkman ,
Como mencioné anteriormente, podría variar las masas de los elementos de la cuchilla dentro de una simulación dada. El cambio de las masas del elemento de pala genera un par adicional a partir del cambio en el momento angular. Este par. T_cor , también se puede expresar en términos de fuerza de Coriolis, F_cor , actuando sobre el radio variable de las masas movidas, R_var , como se describe en la siguiente ecuación.

T_cor = 3 ∙ F_cor ∙ R_var

Como @jjonkman mencionó en el comentario anterior:

No pude encontrar esos términos en el código fuente de ElastoDyn que explican la fuerza de Coriolis. Veo que en ElastoDyn.f90\FUNCTION SignLSSTrq( p, m ) MomLPRot se calcula el momento en el eje de baja velocidad

Donde u% ExternalRvar y u% ExternalFcor son el radio variable y la fuerza de Coriolis de Simulink, respectivamente.
¿Me pueden ayudar a agregar el par Coriolis al par del eje de baja velocidad?

Estimado @LaurenceWETI ,

No cambiaría FUNCTION SignLSSTrq () como propones. El Coriolis y otras fuerzas se calculan intrínsecamente dentro de ElastoDyn. Si está cambiando las masas de los elementos de la pala en cada paso de tiempo antes de que se realicen los cálculos dinámicos principales, el impacto de estas masas en las fuerzas de inercia debe incluirse intrínsecamente.

Atentamente,

Estimado @jjonkman ,

Gracias por tu repetición.
Exactamente por la misma razón por la que el cambio de masas de elementos de hoja debe tener lugar en cada paso de tiempo y antes de que tengan lugar los cálculos dinámicos principales, llamé a las subrutinas de cambio de masa al comienzo de SUBROUTINE ED_CalcOutput\ElastoDyn.f90 . ¿Puedo resumir brevemente el flujo de las órdenes de llamada en la siguiente figura

Donde Subroutine Flywheel_Ini(p) llama solo en t = 0 para la inicialización, se llama a Subroutine Flywheel(p, u) en cada paso de tiempo para sobrescribir las masas de los elementos de la hoja, y se llama a Subroutine UpdateCoeff(p, ErrStat, ErrMsg) después de que se cambian las masas de la hoja para actualizar los parámetros de Subroutine Coeff(p,InputFileData, ErrStat, ErrMsg) . Para habilitar la sobrescritura del tipo de datos del parámetro p% cambié la intención de la estructura de datos del parámetro de solo IN a INOUT

¿Cambié las masas en el punto antes de que se realicen los cálculos dinámicos principales?

¿Puede arbitrar al favor en el código ElastoDyn donde se calcula la fuerza de Coriolis?

¿La fuerza de Coriolis que mencionaste se calcula debido al cambio en la masa de la hoja o debido al movimiento de la torre de lado a lado?

Estimado @LaurenceWETI ,

Los dos cálculos dinámicos principales en ElastoDyn son:

• ED_UpdateStates: integra (avanza) los estados en el tiempo, de un paso de tiempo al siguiente.
• ED_CalcOutput: calcula las salidas en el momento actual.

En la rutina principal de FAST_Solution, se llama a ED_UpdateStates antes de ED_CalcOutput, por lo que creo que necesitaría hacer estos cálculos al comienzo de ED_UpdateStates.

La fuerza de Coriolis proviene del movimiento de la hoja (debido a la deflexión de la hoja y la torre) en un marco de referencia giratorio. La fuerza de Coriolis se basa en la aceleración del cuerpo y, por tanto, es intrínseca a la cinemática y la cinética. ElastoDyn usa la dinámica de Kane, por lo que las velocidades y aceleraciones se expresan como parciales. Las principales rutinas de cinemática y cinética en ElastoDyn (CalculatePositions, CalculateAngularPosVelPAcc, CalculateLinearVelPAcc y CalculateForcesMoments) jugarán un papel.

Atentamente,

Estimado @jjonkman ,

Muchas gracias por tu repetición.
Como sugieres en el último comentario, cambié mi cálculo al comienzo de ED_UpdateStates :

Pero no estoy seguro de si la fuerza de Coriolis se calcula para las masas variables de los elementos de la hoja, o al menos para mi implementación de cambiar las masas. Permítanme ilustrar con un ejemplo donde esperaría que se viera el impacto de la fuerza de Coriolis.
En el siguiente ejemplo, cada pala se inicializa con una masa de fluido adicional de 4.000,00 kg en los dos primeros elementos de pala. Después de 40 s, cambié 2.000,00 kg de la masa de fluido del primer elemento de hoja a los elementos de hoja 11, 12 y 13. El resto del fluido en el segundo elemento de pala se mueve a los 80 sa los elementos de pala 11º, 12º y 13º. De modo que a los 100 s toda la masa de fluido de 4.000,00 kg se mueve desde los elementos de raíz de la pala hasta los elementos del cuerpo de la pala. Repetí este procedimiento en la dirección opuesta (desde el cuerpo hasta la raíz) entre 130 sy 190 s (ver figura a continuación).

Según la masa de fluido movida, el impacto de la fuerza de Coriolis debe notarse en el par de torsión del eje de baja velocidad durante el movimiento del fluido, es decir, entre 40-60 s, 80-100 s, 130-150 sy 170-190 s. Sin embargo, el par del eje de baja velocidad es casi constante en los períodos mencionados (ver figura a continuación).

Puedo ver el impacto de la masa agregada en la desviación de la punta en la dirección del borde (vea la siguiente figura TipDyb1 ), pero todavía no puedo reconocer el impacto de la fuerza de Coriolis.

Agradecería cualquier ayuda, consejo o discusión.

Estimado @LaurenceWETI ,

Realmente no entiendo lo que esperas ver de la fuerza de Coriolis.

Según tengo entendido, está cambiando la masa del interior al exterior de la pala. Esto tendrá un gran efecto en el aumento de la inercia del rotor alrededor del eje. Puede verificar que está sucediendo a través de una prueba simplificada. De la conservación del momento angular, uno esperaría en ausencia de torque aerodinámico o generador, el rotor se ralentizaría al desplazar la masa hacia fuera de borda debido al aumento de la inercia. ¿Funciona esta prueba? Es decir, deshabilite AeroDyn y ServoDyn y habilite GenDOF y dé al rotor una velocidad inicial del rotor en ElastoDyn. ¿Desplazar la masa hacia fuera de borda ralentiza el rotor?

Atentamente,

Estimado @jjonkman ,

Gracias por tu rápida respuesta.

Esperaría que la fuerza de Coriolis desacelere el rotor cuando la masa se desplace hacia fuera de borda y acelere el rotor cuando la masa se desplace hacia adentro. Creo que esta es la razón por la que sugiere deshabilitar AeroDyn y Servoyn y habilitar GenDOF. Desactive AeroDyn y ServoDyn estableciendo CompAero y CompServo en cero en el archivo de entrada FAST y GenDOF en True y RotSpeed ​​en 12.1 en el archivo de entrada ElastoDyn.

El resultado de la simulación anterior muestra obviamente que la velocidad del rotor no se ralentiza cuando la masa se desplaza hacia fuera de borda.
Como mencionó anteriormente, la fuerza de Coriolis que es intrínseca a la cinemática y la cinética se basa en la aceleración del cuerpo, pero no en el cambio de masas entre dos pasos de tiempo de simulación. La fuerza de Coriolis en mi simulación se basa en el cambio de masas. Por lo tanto, me gustaría agregar esta parte de la fuerza de Coriolis al par del rotor en el código fuente de ElastoDyn. Ya calculé el par de Coriolis en MATLAB / Simulink, y usaría este par como entrada externa en ElastoDyn. ¿Me pueden ayudar a agregar esta parte?

Atentamente

Estimado @LaurenceWETI ,

No he pensado en todos los cambios que tendrías que hacer para cambiar la masa a lo largo de la hoja. Pero está claro que los cambios que ha realizado están incompletos. ¿Qué forma toman sus nuevas cargas? A menos que estas cargas se calculen y apliquen localmente a lo largo de la hoja, no esperaría que brinden la respuesta dinámica que desea. Y deberá asegurarse de que las cargas que está agregando no cuenten dos veces los términos que ya agregó y que no falten otros términos importantes.

¿Ya revisó la base teórica de ElastoDyn e identificó cómo se debe cambiar esta base para adaptarse al desplazamiento de masa a lo largo de la hoja? Si no es así, este sería el primer paso que te propondría. Si bien no se ha publicado oficialmente, la base de la teoría de ElastoDyn está documentada en lo que se llama el "Manual teórico no oficial de FAST en nuestro foro - ver: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t= 1532. ¿Ya ha revisado esto e identificado qué cambios serían necesarios para adaptarse al desplazamiento de masa a lo largo de la hoja?

Atentamente,

Estimado @jjonkman ,

Gracias por tu rápida repetición.

Implementaría las nuevas cargas en forma de un momento adicional, que actúa directamente sobre el eje de baja velocidad. Este momento ya está calculado en Simulink y lo importaría a ElastoDyn a través de S-Function. Soy consciente de que la forma en que agrego las nuevas cargas es muy simplificada y no puedo garantizar que las cargas agregadas no cuenten dos veces los términos que ya agregué. Pero para mí ahora es muy importante comenzar con una implantación simple, que muestra al menos el efecto dinámico de la masa desplazada a lo largo de la hoja. Sobre la base de esta implementación simple, avanzaría hacia una implementación más precisa utilizando la base teórica de ElastoDyn.
En un comentario anterior no me recomendó agregar este momento en la FUNCIÓN SignLSSTrq (). ¿Puede darme una idea de dónde y cómo agregar este momento en el código fuente de ELastoDyn? Estaría muy agradecido por tu ayuda.

Atentamente,

Estimado @LaurenceWETI ,

Bueno, ElastoDyn tiene una malla de puntos de entrada a nivel de módulo para cargas externas aplicadas en el concentrador (HubPtLoad). Añadiría tu carga a eso. Pero la interfaz de Simulink no está configurada actualmente para recibir HubPtLoad como una entrada de Simulink, por lo que deberá modificar tanto el código de pegamento OpenFAST como la interfaz de Simulink para eso.

Atentamente,

Estimado @jjonkman

Gracias por señalar eso
Como sugirió en su comentario anterior, busqué las cargas externas aplicadas en el concentrador ( HubPtLoad ). Pensé que podría agregar el momento Coriolis externo a u%HubPtLoad%Moment() en SUBROUTINE ED_Perturb_u(). Pero el problema es que cuando configuro el análisis de linealización en TRUE en el archivo de entrada, para habilitar las rutinas jacobianas para las capacidades de linealización, tengo este error:

¿Este error se debe a que la interfaz de Simulink no está configurada para recibir una entrada de Simulink? ¿Es correcto mi entendimiento de lo que sugirió? ¿Podría darme más detalles sobre dónde modificar el código de pegamento OpenFAST y la interfaz Simulink?
¿Hay alguna otra forma de agregar esta carga adicional desde Simulink? En realidad, traté de agregar este momento al momento en el plano en la raíz de la hoja MomH0B en SUBROUTINE ED_CalcOutput . Pero incluso cuando se cambia el momento en el plano, la velocidad del rotor sigue sin cambios (consulte la figura siguiente).

¿La velocidad del rotor sigue sin cambios porque desactivo AeroDyn y ServoDyn?

Atentamente,

Estimado @LaurenceWETI ,

No debería necesitar cambiar ElastoDyn y parece que está enfocado en la simulación en el dominio del tiempo, no en la linealización. Por lo tanto, no debe cambiar SUBROUTINE ED_Perturb_u() .

En cambio, como dije antes, deberá cambiar la interfaz de Simulink y el código de pegamento OpenFAST. Buscaría cómo se pasan otras variables a través de la interfaz de Simulink (como GenTrq) y cómo se utilizan en el código de pegamento OpenFAST (FAST_Registry.txt, FAST_Solver.f90). Probablemente establecería la entrada HubPtLoad en el código de pegamento OpenFAST cerca de donde está configurada actualmente la entrada NacelleLoads.

Atentamente,

Estimado @jjonkman

Gracias por su rápida respuesta incluso en días festivos.

Con la ayuda de Bonnie, pude saber cómo pasar variables a través de la interfaz de Simulink y cómo usar estas variables en el código adhesivo OpenFAST e incluso en ElastoDyn. Lo que me gustaría saber dónde usar / agregar la carga externa de Simulink en el código fuente de OpenFAST o en ElastoDyn.

Quieres decir que no debería necesitar cambiar ElastoDyn. ¿Significa eso que las cargas externas (el momento de Coriolis de Simulink) debido a la masa desplazada a lo largo de la hoja no deben agregarse / usarse en ElastoDyn? ¿Eso significa que esta carga externa solo debe agregarse en el código de pegamento OpenFAST (FAST_Solver.f90)?

No pude encontrar dónde se establece la entrada NacelleLoads en el código de pegamento OpenFAST (FAST_Solver.f90) para establecer mis cargas externas cerca de. ¿Espera que cambie la velocidad del rotor cuando se agregue el momento de Coriolis externo a las Nacelleloades?

Atentamente

Estimado @LaurenceWETI ,

La entrada de nivel de módulo HubPtLoad a ElastoDyn ya se aplica dentro de ElastoDyn como una carga externa agregada al concentrador. Normalmente, esta carga se pone a cero. Se utiliza cuando BeamDyn está habilitado para aplicar cargas al concentrador ElastoDyn desde la raíz de cada blade de BeamDyn. Lo que estoy sugiriendo es que, dado que ya está calculando esta carga adicional dentro de Simulink, simplemente tome el valor de Simulink y lo use para establecer el valor de HubPtLoad en el código de pegamento OpenFAST. Por lo tanto, no se necesita ningún cambio en ElastoDyn.

La entrada de NacelleLoads a ElastoDyn se establece mediante el código de glude OpenFAST en SUBROUTINE ED_InputSolve() de _FAST_Solver.f90_ (según las cargas de un TMD basado en góndola calculado dentro de ServoDyn). También puede establecer la entrada HubPtLoad en ElastoDyn en esta SUBRUTINA.

No ha explicado cómo se calcula la "fuerza de Coriolis" en Simulink. Normalmente pienso en la fuerza de Coriolis como la fuerza de inercia causada por el movimiento en un marco de referencia giratorio. Presumiblemente, la velocidad de rotación que está usando es la del rotor y la velocidad de traslación que está usando es axial a lo largo de la pala (de la traslación de masa a lo largo de la pala). La fuerza de Coriolis estaría entonces en el plano del rotor, lo que creo que afectaría la rotación, si el brazo de momento relativo al eje es distinto de cero.

Atentamente,

Estimado @jjonkman;

Gracias por tu ayuda,
Como sugirió, establecí el valor de HubPtLoad en SUBROUTINE ED_InputSolve de FAST_Solver.f90 a la carga adicional de Simulink de la siguiente manera:

Donde u_ED%ExternalCoriolis1 es la carga adicional calculada en Simulink. Dado que HubPtLoad es la única entrada que no se resuelve en SUBROUTINE ED_InputSolve , y MeshMapData%u_ED_HubPtLoad%Moment se establece en cero en SUBROUTINE FullOpt1_InputOutputSolve () , cambié el valor de HubPtLoad en SUBROUTINE FullOpt1_InputOutputSolve () a la carga adicional de Simulink, también:

Para calcular el momento de Coriolis utilicé estas dos ecuaciones:
T_cor = 3 * F_cor * R_var
F_cor = 2 * m_fluid * w_rot * v_fluid
Donde R_var es el radio variable del centro de gravedad de la masa desplazada en los elementos de la punta de la pala [m]; m_fluid es la masa del fluido desplazado [kg]; w_rot es la velocidad de rotación del rotor [rps]; y v_fluid es la velocidad de traslación del fluido a lo largo de la pala [m / s]. La siguiente figura muestra un ejemplo extremo de momento de Coriolis, donde es obvio que el momento adicional no tiene impacto en la velocidad del rotor.

para este ejemplo desactivé ServoDyn y AeroDyn y activé GenDOF y le di a la velocidad del rotor un valor inicial de 12,1 [rpm]

¿Configuré el valor de HubPtLoad correctamente?

¿Puede explicar por qué no puedo ver el impacto de la carga adicional en la velocidad del rotor?

Atentamente

Estimado @jjonkman ,

Entiendo el impacto de la carga adicional de Coriolis debido a la masa desplazada a lo largo de la pala como una carga en el plano del rotor, que debería ser positiva (en la dirección de rotación) cuando la masa se desplaza de fuera de borda a interior, y negativa (contra la dirección de rotación) cuando la masa se desplaza del interior al exterior. ¿Estás de acuerdo con eso? ¿La velocidad del rotor permanece sin cambios en mi última simulación del comentario anterior porque el 12.1 [rpm] que se establece en el archivo de entrada ElastoDyn no es solo el valor inicial, sino también el valor fijo de la velocidad del rotor durante toda la simulación?

Cualquier ayuda será muy apreciada.

Atentamente,

Estimado @LaurenceWETI ,

Estoy de acuerdo con las líneas de código que cambió en SUBROUTINE FullOpt1_InputOutputSolve() , pero este código solo se usa cuando BeamDyn está habilitado. En SUBROUTINE ED_InputSolve() , lo que tienes no es correcto. En cambio, debería serlo;

u_ED%HubPtLoad%Moment = u_ED%ExternalCoriolis1

Sus ecuaciones para el momento de Coriolis se ven bien, pero este momento debe ser un vector de 3 elementos, que contiene las componentes globales X, Y y Z del momento. ¿Está configurando cada componente de este vector de 3 elementos? El primer componente (X) solo estaría directamente alrededor del eje si el eje está alineado con el eje X global, es decir, si la rotación de la plataforma, la deflexión de la torre, la inclinación del eje y el ángulo de guiñada son cero.

Atentamente,

Estimado @jjonkman ,

Gracias por señalar eso
Cambié la definición del momento de Coriolis a un vector de 3 elementos para incluir los componentes X, Y y Z del momento. Corregí el código en SUBROUTINE ED_InputSolve\FAST_Solver.f90 a:
u_ED%HubPtLoad%Moment = u_ED%ExternalCoriolis1
Sin embargo, la forma de la expresión de matriz del Momento en u_ED%HubPtLoad%Moment no se ajusta en este punto:

Busqué en FAST_Solver.f90 cómo se usa u_ED%HubPtLoad%Moment , y encontré que esta variable se usa en SUBROUTINE Add_FullOpt1_u_delta() en esta forma:
u_ED%HubPtLoad%Moment(fieldIndx,node)
¿Falta algo en u_ED%HubPtLoad%Moment en SUBROUTINE ED_InputSolve ?

Atentamente

Estimado @LaurenceWETI ,

Buen punto. Olvidé que u_ED%HubPtLoad%Moment es una matriz bidimensional. Por supuesto, solo hay un nodo en la segunda dimensión. Entonces, la asignación correcta debería ser:

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

Atentamente,

La malla HubPtLoad se usa actualmente en el código de pegamento solo para proporcionar el acoplamiento de BeamDyn con ElastoDyn. Dado que eso se aplica en las rutinas SolveOption1, actualmente se establece solo en los cálculos residuales de FullOpt1_InputOutputSolve .

Si desea agregar una carga adicional a la malla HubPtLoad , deberá estar en FullOpt1_InputOutputSolve para el acoplamiento BeamDyn, y en ED_InputSolve() si no está usando BeamDyn. La rutina Add_FullOpt1_u_delta no debe cambiarse.

Estimado @jjonkman , Estimado @bjonkman ,

Gracias por su respuesta. Ahora se ve mucho mejor y pude ver el impacto de la carga adicional en la velocidad del rotor.

Atentamente

Estimado @jjonkman ,

Tengo una pregunta sobre los pares de torsión que actúan en el concentrador cuando AeroDyn y ServoDyn están desactivados. Como esperaba antes, mover la masa hacia el exterior ralentiza el rotor, pero desplazar la misma masa hacia el interior no acelera el rotor con el mismo valor, consulte la figura siguiente.

En realidad, ahora estoy calculando el par de Coriolis dependiendo del cambio en la inercia de la masa desplazada de la siguiente manera:

J_Mass_bl = R_var ^ 2 * m_Mass
T_Coriolis = 3 * d / dt (J_Mass_bl) * rotor_speed

Donde R_var es el centro de gravedad variable de la masa desplazada y m_Mass es la masa desplazada a lo largo de la hoja.

¡No pude entender por qué el par de Coriolis adicional no condujo a la aceleración esperada del rotor cuando la masa se desplaza hacia adentro!

Atentamente.

Estimado @LaurenceWETI ,

No estoy seguro de entender la diferencia entre sus dos cálculos. Si está utilizando d / dt (J_Blade_bl) = 2 R_var m_Mass * v_fluid, ¿la implementación no es idéntica a la que tenía antes?

No ha mostrado el par del generador (vinculado al controlador de par) o el par aerodinámico (vinculado al controlador de tono), pero ¿podría el controlador estar jugando un papel en el motivo por el cual la velocidad del rotor no se acelera tanto como usted lo espera? ¿a?

Atentamente,

Estimado @jjonkman ,

Muchas gracias por tu pronta respuesta. Me preguntaba, ya que me pediste que mostrara el par del generador (vinculado al controlador de tono), aunque desactivé ServoDyn en el archivo de entrada de OpenFAST estableciendo CompServo en cero, y no hay salidas de este modelo para trazar la electricidad. par del generador (GenTq). Sin embargo, habilité ServoDyn en el archivo de entrada FAST y deshabilité todos los controladores en el archivo de entrada de ServoDyn, para obtener GenTq en las señales de salida sin el impacto de los controladores. De repente, la velocidad del rotor se acelera como se esperaba:

No pude encontrar una razón razonable por la que el generador y el controlador de par no se deshabilitan cuando CompServo se establece en cero en el archivo de entrada FAST, y debe deshabilitarse en el archivo de entrada ServoDyn para desactivar sus efectos en ElastoDyn. ¿Quizás puedas explicar este fenómeno?

Atentamente

Estimado @LaurenceWETI ,

Las entradas de Simulink a OpenFAST S-Function (par, cabeceo, guiñada, etc.) se habilitan configurando los modelos de control asociados de manera apropiada (por ejemplo, VSContrl = 5 para aceptar el par de Simlulink). Por lo tanto, no esperaría que se usen las entradas de Simulink si ServoDyn no está habilitado. Por supuesto, ha modificado la interfaz de Simulink para que sus nuevas cargas de Coriolis se apliquen directamente a ElastoDyn, en lugar de pasar por ServoDyn, por lo que supongo que capturó parte del efecto.

Atentamente,

Estoy trabajando para establecer una ruta para distribuir la biblioteca OpenFAST compilada para la integración de Simulink junto con los otros ejecutables que compartimos regularmente para cada versión. Agregué un archivo incluido en la última versión llamado openfastlib_simulink.dll . ¿Alguien puede probar la biblioteca adjunta? Esta es la biblioteca OpenFAST que debe estar vinculada en la función mex.

Estoy trabajando para establecer una ruta para distribuir la biblioteca OpenFAST compilada para la integración de Simulink junto con los otros ejecutables que compartimos regularmente para cada versión. Agregué un archivo incluido en la última versión llamado openfastlib_simulink.dll . ¿Alguien puede probar la biblioteca adjunta? Esta es la biblioteca OpenFAST que debe estar vinculada en la función mex.

No pude encontrar este archivo en el último Realease ...

@hbasbas Está al final del comunicado con los otros Activos. Escribí mal la URL de la última versión anterior (ahora está arreglada), así que aquí está la URL correcta: https://github.com/openfast/openfast/releases/tag/v2.5.0

¡Hola a todos!
Tengo algunos problemas al ejecutar "Run_Test01_SIG.m".
Utilicé la última versión de openfast v2.5.0 y compilé con éxito "FAST_SFunc.mexw64" con matlab2020a y visual studio 2019, pero cuando ejecuto "Run_Test01_SIG.m", matlab se bloquea. Lo he intentado muchas veces y todavía no puedo resolver este problema.
Se adjunta el informe de fallos de matlab2020a y los resultados de Create_FAST_SFunc.

¡Los mejores deseos!
ChenPeng
problema.txt

Traducción: cl: advertencia de línea de comando D9025: reescritura de "/ MD" (con "/ MT")

Estimado @rafmudaf

¿Cómo podríamos usar el comando mex con el archivo dll que proporcionaste? ¿Deberíamos necesitar un archivo .lib en su lugar?

Tengo entendido que create_FAST_SFunc usa una biblioteca vinculada dinámicamente para compilar con el comando mex. @bjonkman probablemente podría proporcionar mejor información en # 654.

@Domotopeng su seguimiento de pila muestra que SIMULINK está ingresando a la biblioteca OpenFAST, así que eso es bueno. Pero está fallando en OpFM_Init, así que eso no es bueno. ¿Compilar OpenFAST en modo de depuración cambia la información de seguimiento de la pila? Un número de línea en OpFM_Init sería genial.

Tengo entendido que create_FAST_SFunc usa la biblioteca de enlaces dinámicos y el comando mex para compilar. @bjonkman podría proporcionar mejor información en # 654 .

Tengo entendido que create_FAST_SFunc usa una biblioteca vinculada dinámicamente para compilar con el comando mex. @Bjonkman probablemente podría proporcionar mejor información en # 654.

¡Gracias por su consejo!