Openfast: Problème lorsque j'exécute le modèle simulink qui dépend de openfast S-Function mex

Je suis un peu confus par la pile de traceback. Il semble que le problème se produise dans la routine FAST_OpFM_Init mais je ne sais pas pourquoi l'interface OpenFAST-Simulink serait dans cette routine. Autant que je sache, cette routine ne doit être appelée qu'avec l'interface d'OpenFAST avec un code CFD (pas Simulink).

1. Quelle version d'OpenFAST utilisez-vous?
2. Avez-vous construit la bibliothèque mex et la DLL OpenFAST-Simulink (si oui, comment?), Ou utilisez-vous des binaires précompilés?
3. Avez-vous modifié le code source ou créé des scripts avant de créer?
4. Les exemples de modèles OpenFAST Simulink s'exécutent-ils sans planter?

1 - Je ne sais pas comment je peux voir ça mais je pense que j'utilise 1.0.0
2- Oui, j'ai construit la bibliothèque mex. J'utilise d'abord Visual Studio 2015 et compile le fichier Simulink-Openfast avec les options Release_Matlab et l'option x64. Le nom du fichier résultant est OpenFAST-Simulink_x64 (je joins une image), et je peux le trouver dans build / bin.
Pour obtenir une solution rapide, j'utilise également le même programme.

3- Je ne touche pas au fichier mex, je ne modifie que le .m pour charger dans l'espace de travail les variables et après avoir exécuté le modèle simulink (les deux sont au même emplacement que les modèles prédéterminés [C: UsersCASADocumentscodeopenfastglue-codessimulinkexamples, and. m qui génère la fonction S dans build / bin, vous pouvez le trouver dans ..... openfastglue-codessimulinksrc])
4- Non, ce n'est pas le cas

1. Si vous êtes réellement sur v1.0.0, vous devez absolument mettre à niveau vers la dernière version d'OpenFAST (branche principale). Cependant, je serais surpris si la v1.0.0 avait l'option Release_Matlab, donc je suppose que c'est une version différente. Vous devriez pouvoir voir le numéro de version dans un fichier appelé <openfast>\vs-build\gitVersionInfo.h . Ou, vous pouvez le voir imprimé à l'écran lorsque vous exécutez OpenFAST.

2. Ce que vous décrivez est la construction du fichier OpenFAST_Simulink_x64.DLL . Le fichier mex est généralement construit en utilisant openfast\glue-codes\simulink\src\create_FAST_SFunc.m . Avez-vous également construit cela? Sur votre système, il devrait créer FAST_SFunc.mex64 . Compte tenu de la date de modification de FAST_SFunc sur votre capture d'écran, je suppose que vous l'avez également construit, mais je vérifie simplement qu'il ne provient pas d'une autre version d'OpenFAST.

Je travaillerais pour faire fonctionner l'exemple de modèle OpenLoop avec l'un des cas de test r OpenFAST avant d'essayer de déboguer ce qui se passe avec votre modèle Simulink particulier. De cette façon, vous pouvez partager tous les détails de ce que vous faites.

Assurez-vous que vous avez construit le FAST_SFunc avec le même compilateur que vous avez utilisé lors de la construction de OpenFAST-Simulink_x64.DLL (c'est-à-dire, exécutez mex -setup dans Matlab et utilisez Visual Studio C / C ++ et Intel Fortran).

Bonjour @bjonkman ,

1. Désolé pour les informations de version, je vérifie ça et c'est V2.3.0 ---> #define GIT_VERSION_INFO 'v2.3.0-548-g43191a90'

2 - Oui, j'exécute create_FAST_SFunc.m et j'obtiens FAST_SFunc.mex64 dans build / bin.

Pour vous montrer toutes les étapes que j'ai effectuées, je vais joindre quelques captures d'écran:

Tout d'abord, j'exécute mex -setup pour confirmer que j'utilise le même compilateur --- Visual Studio 2015. C'est correct.
L'étape suivante consiste à générer la fonction S en exécutant create_FAST_SFunc.m et j'obtiens FAST_SFunc.mex64.

L'étape suivante consiste à exécuter Run_OpenLoop.m:

Vous pouvez voir que Matlab a un problème à cette étape et qu'il doit se fermer à ce moment-là.

Meilleures salutations,

Joaquín

Je pense que cela indique probablement un problème dans le fichier OpenFAST-Simulink_x64.DLL . Le code a-t-il imprimé autre chose dans la fenêtre de commande Matlab avant qu'il ne plante? (Je ne peux pas voir s'il y a quelque chose imprimé sous le temps d'exécution.) Comme je l'ai mentionné, le retraçage que vous montrez indique que c'est dans une routine qui ne devrait pas être appelée pour cette construction. Pouvez-vous me montrer comment vous avez construit cette DLL?

Non, le code ne montrait rien d'autre à part ça.
Le processus pour obtenir le fichier .dll est:

1- J'exécute une solution rapide (release_x64 double); après avoir utilisé python pour exécuter le test et le test qui me passionne, passez ok.

2- Étape suivante, pour faire l'intégration Openfast Simulink, j'ouvre Visual Studio 2015 et j'exécute le fichier fortran appelé OpenFAST-Simulink et dans properties-input, je change pour viser correctement vers libmex.lib (le chemin par défaut n'est pas le bon )
3- Je lance OpenFAST-Simulink (release Matlab x64) et après j'ai lancé FAST (Release Matlab x64) et c'est tout ce que j'ai fait

Avez-vous besoin de captures d'écran de toutes les étapes?

Pourriez-vous ouvrir le fichier FAST.sln et construire avec Release_Matlab | x64 partir de ce fichier de solution au lieu du fichier OpenFAST-Simulink.sln que vous utilisez? Si vous n'avez pas cette option (avec le projet OpenFAST-Simulink dans le fichier de solution FAST ), je vous recommande d'utiliser la dernière branche principale d'OpenFAST afin que vous construisiez avec celle-là.

J'ai construit la solution FAST.sln avec cette configuration et j'ai obtenu ceci que je vous montre dans la capture d'écran ci-dessous:

Je ne sais pas comment faire la compilation avec la solution principale. Dois-je télécharger uniquement le nouveau fortran Openfast-Simulink?

Quelles étapes dois-je suivre pour obtenir le fichier .dll que vous recherchez? (Si tu prétends ça)

Bonjour à tous,

Je ne sais pas si je peux participer à la discussion, j'ai exactement le même problème.

J'utilise VS 2019 Community avec Intel Parallel Studio XE 2020. J'ai récemment téléchargé la version principale d'OpenFAST donc je devrais avoir la dernière.

Je compile le fichier DLL avec la solution FAST.sln avec différentes configurations:

1. En mode "Release_Double_x64": la compilation fonctionne sans erreur. Ensuite, je crée le fichier mex avec le "create_FAST_Sfunc.m" ==> cela fonctionne. Je lance le fichier "RUN_OpenLoop" et j'obtiens la capture d'écran en pièce jointe.
   

2. En mode "Release_64": même problème en accédant à la simulation Simulink

3. En mode "Release_Matlab_64" (uniquement pour les projets OpenFast-Simulink et FASTlib, non?): Je ne parviens pas à compiler la solution FAST VS (voir en pièce jointe)
   

@hbasbas : vous devez générer un OpenFAST-Simulink-x64.dll à partir du projet Visual Studio, vous n'avez donc vraiment besoin de créer la version qu'à l'étape 3 (sauf que vous devez également exécuter le fichier create_FAST_SFunc.m après avoir terminé l'étape 3). Si vous exécutez FAST_SFunc dans Matlab avant de créer la DLL, je suppose qu'il appelle une autre version de cette dll à partir d'un autre endroit sur votre chemin Matlab. Si vous tapez which OpenFAST-Simulink-x64.dll , dans la fenêtre de commande Matlab, il devrait vous donner le chemin complet de la DLL qu'il utilise.

La raison pour laquelle votre Release_Matlab | La configuration x64 (qui est celle que vous devez utiliser) ne se construit pas semble être que vous avez une version de Matlab différente de celle pour laquelle le projet a été configuré. Vous devrez ouvrir les propriétés de configuration du fichier de projet OpenFAST-Simulink (cliquez avec le bouton droit sur le projet, puis sélectionnez properties et accédez à la ligne d'entrée de l'éditeur de liens. Vous devrez la modifier pour qu'elle pointe vers le version de Matlab que vous utilisez:

@JoaquinPerCarr , pour obtenir la branche master avec git, vous pouvez extraire la branche master puis extraire le nouveau code.

Il est possible que vous ayez une autre copie de la DLL sur votre chemin Matlab qui sème également la confusion. Essayez which OpenFAST-Simulink_x64.dll dans la fenêtre de commande Matlab et voyez s'il pointe vers le bon.

Salut @bjonkman :

J'ai fait ce que tu m'as dit. J'ai d'abord téléchargé tous les fichiers maîtres openfast, puis j'ai changé l'ancien fortran OpenFAST-Simulink et j'ai copié le nouveau. J'ai construit FAST avec Release_Matlab_x64 et OpenFAST-Simulink_Release_Matlab_x64 pour obtenir le nouveau .dll.

J'ai répété tout le processus tel que je vous ai expliqué au premier moment de cette discussion et j'ai eu les mêmes résultats, Matlab plante quand j'exécute simulink. Je joins une capture d'écran lorsque j'utilise quel OpenFAST-Simulink:

Bonjour,

@bjonkman : merci pour votre réponse. Grâce à vos recommandations, la compilation fonctionne. Je voudrais préciser (aux éventuels autres utilisateurs) qu'il est important d'insérer la citation entre les chemins. En raison de l'espace de "Program File", VS essaie de trouver un fichier objet.
Cependant, Matlab continue de planter lors de l'exécution de la simulation Simulink:

Est-il possible que les versions de Matlab, de Visual Studio et d'Intel Parallel Studio XE soient responsables du crash de Matlab?

@JoaquinPerCarr : Dans la commande "which", il semble que vous ayez spécifié le mauvais fichier: vous écrivez "-x64" au lieu de "_x64"

Sinon, est-il possible de partager le fichier compilé .mex64 de la version openfast-master. Je n'ai besoin que de changer le fichier d'entrée (.dat) mais le code source doit être le même pour moi. De plus, j'identifierai le problème:
Si cela ne fonctionne pas, cela devrait signifier que j'ai un problème avec ma version Matlab ou d'autres. Si cela fonctionne, cela signifie que la compilation Visual Studio n'est pas bien configurée.

D'accord, je pense voir quel est le problème.

Si vous ouvrez <openfast>\modules\openfast-library\src\FAST_Library.h , changez la définition de CHANNEL_LENGTH de 10 à 20:

#define CHANNEL_LENGTH 20

Ensuite, réexécutez le fichier create_FAST_SFunc.m et réessayez.

Je recevrai une demande d'extraction avec ce correctif dans OpenFAST.

Merci beaucoup. Ça marche !

Salut @bjonkman ,

Si je fais cela, j'obtiens ceci:

Je peux voir que simulink ne s'ouvre pas et qu'il ne fait rien d'autre.

Si vous lisez le message d'erreur sous la partie que vous avez encerclée, vous verrez qu'OpenFAST ne trouve pas le fichier d'entrée que vous lui avez demandé d'exécuter. Run_OpenLoop.m a été configuré pour les anciens cas FAST (v8) CertTest, vous devrez donc changer les noms des fichiers d'entrée. J'ai exécuté le code suivant pour tester le modèle 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])

J'essaye le code suivant parce que je suis passionné par le test 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]);

Je remarque que le modèle simulink ne s'ouvre pas automatiquement et je ne sais pas pourquoi, mais au début, il semble que cela fonctionne bien

Pour résumer, pensez-vous que le seul problème avec mon premier problème était la ligne de code #define CHANNEL_LENGTH 20 dans le fichier .h?

Merci beaucoup @bjonkman

Je ne pense pas que Simulink ait besoin d'ouvrir le modèle lorsque vous l'exécutez avec la commande sim() .

La définition incorrecte de CHANNEL_LENGTH dans le fichier .h était ce qui a provoqué l'arrêt de Matlab (et pour quiconque lirait ceci à l'avenir, la trace de la pile n'était pas précise: elle n'était pas réellement dans le FAST_OpFM_Init routine).

Quant à cela étant le seul problème, espérons-le. :)

Je fais des choses différentes et je pense que le master openfast-Simulink est nécessaire

Je vais essayer d'exécuter mon premier modèle simulink et je vous dirai si cela fonctionne bien

Salut @bjonkman ,

Je voudrais vous demander comment puis-je voir quelle version d'OpenFAST j'ai (dev / master). S'il existe un formulaire pour revenir à la version principale, je souhaite le faire.

Si ce n'est pas possible, comment puis-je supprimer / corriger les erreurs (indicateurs) que je vous montre dans les prochaines captures d'écran? CalcSteady, Twr_Kdmp et Bld_Kdmp sont le principal problème.

Je vois aussi la documentation OpenFAST. Les erreurs que je pense que cela pourrait être pour l'utilisation de la version dev d'OpenFAST. Je ne sais pas quoi faire.

Meilleures salutations,

Joaquín.

Cher @JoaquinPerCarr ,

Je ne suis pas sûr de bien comprendre votre question, mais vous semblez utiliser une ancienne version de développement d'OpenFAST (quelque part entre la v2.3 et la v2.4) et un fichier d'entrée compatible avec la v2.3. Comme pour toute erreur dans le traitement du fichier d'entrée, vous pouvez activer l'option Echo pour déboguer les problèmes de formatage du fichier d'entrée.

Quoi qu'il en soit, à moins que vous n'ayez une raison spécifique d'utiliser cette version de développement d'OpenFAST, je recommanderais la mise à niveau vers la branche principale d'OpenFAST, v2.4. Des exemples de fichiers d'entrée OpenFAST compatibles avec la v2.4 sont fournis dans la branche master du r-test.

Meilleures salutations,

@JoaquinPerCarr ,

Vous pouvez généralement voir la version d'OpenFAST imprimée à l'écran lorsque vous exécutez OpenFAST. D'après votre capture d'écran, je vois que c'est v2.3.0-548-g43191a90 . Cela signifie qu'il est au hachage git 43191a90 et qu'il est de 548 commits après la version 2.3.0 balisée.

Pour passer à une version différente, vous pouvez simplement utiliser des commandes git pour extraire la branche et la validation de votre choix.

Vous pourriez faire

git checkout v2.4.0

qui achèterait openfast version 2.4.0, mais vous mettrait dans un état principal détaché dans git, ou

git checkout master
git pull

qui devrait vous donner la dernière version de la branche master (en supposant que votre branche master pointe vers le référentiel openfast). Gardez à l'esprit que l'état actuel de votre dépôt git peut signifier que vous devez cacher certaines modifications avant de changer de branche, etc.

Sinon, assurez-vous simplement que vous utilisez des fichiers d'exemple du commit r-test associé à la version d'OpenFAST que vous utilisez.

Bonjour à tous,

Je pourrais compiler la S-Fuction et exécuter les exemples d'OpenLoop et Test01_SIG. J'essaie maintenant d'étendre les entrées de la S-Fuction pour activer des entrées supplémentaires en plus de l'original 8. Mais dans la fonction OpenFAST S, je n'ai pas la possibilité de changer les NumAdditionalInputs comme dans FASTv8.
Toute aide serait appréciée.

Merci en avance.

Je n'ai connaissance de rien qui aurait changé la fonctionnalité NumAdditionalInputs entre FAST v8 et le dernier OpenFAST. Qu'est-ce qui ne fonctionne pas exactement?

Bonjour @bjonkman ,

Merci pour votre rediffusion.
En fait, je changerais les NumAdditionalInputs pour importer les masses des éléments de lame dans la fonction S, qui sont plus de 11 pour le modèle 5 MW. Je veux dire 11, car le nombre maximum d'entrées autorisées pour NumAdditionalInputs ne doit pas dépasser les 11 entrées, comme je l'ai lu dans README_FAST8:

J'ai déjà changé le type de données des masses des éléments de lame dans ElastoDyn, et je pouvais changer les masses dans une simulation donnée. Maintenant, je génère des canaux supplémentaires pour exporter les masses des éléments de lame d'ElastoDyn dans Simulink. Je modifierais les masses dans Simulink et les importerais dans la fonction S, c'est-à-dire dans ElastoDyn.

_ElastoDyn peut-il reconnaître les masses des éléments de lame importées depuis la fonction S?

_ElastoDyn peut-il remarquer les modifications effectuées dans Simulink?

_Est-il possible de saisir plus de 11 entrées en plus de l'origine 8 dans la fonction S?

Si vous souhaitez envoyer plus de 10 entrées supplémentaires à OpenFAST, vous pouvez modifier la valeur de MAXInitINPUTS à la fois dans FAST_Library.h et FAST_Library.f90 et recompiler à la MAXInitINPUTS+1 valeurs dans Simulink, vous obtiendrez probablement une erreur de segmentation).

MAXInitINPUTS définit le plus grand tableau qui peut être accepté depuis Simulink et transmis au code OpenFAST Fortran. OpenFAST ne fait rien avec ces valeurs de tableau supplémentaires à moins que vous ne le lui disiez, donc si vous voulez passer des valeurs à ElastoDyn, vous devrez apporter des modifications supplémentaires au code.

Pour commencer, vous devrez regarder InitInpAry dans FAST_Library.f90 , puis vous devrez transmettre des informations à ElastoDyn. Je vous recommande de consulter le forum NWTC pour quelques conseils sur ce que vous devrez changer:

• 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

Veuillez noter, cependant, que ces entrées supplémentaires sont des valeurs passées _de_ la fonction S dans Simulink _à_ OpenFAST. Le code n'est pas particulièrement configuré pour transmettre des valeurs _to_ Simulink à moins que vous n'utilisiez le tableau WriteOutput (c'est-à-dire les canaux OutList spécifiés dans chaque module OpenFAST).

Bonjour @bjonkman ,

Merci pour votre relecture rapide et pour les liens.
En guise de starter, j'ai essayé au début de ne passer qu'une seule entrée supplémentaire dans la S-Function. J'ai utilisé la vitesse du rotor ( RotSpeed ) comme entrée supplémentaire, qui est déjà utilisée dans OutListParameters:

1. Définissez la vitesse du rotor comme entrée dans le sous-programme FAST_SetExternalInputs() in FAST_Library.f90
   

2. Reconstruisez le FASTlib à partir de C: .... OpenFASTvs-buildFASTlib FASTlib.sln

1. Exécutez OpenLoop avec une entrée supplémentaire
   

2. La simulation s'est plantée dans Matlab / Simulink
   
   Je vois dans subroutine FAST_Start () dans FAST_Library.f90 que seules 3 entrées supplémentaires sont autorisées. Dois-je changer cela pour n'activer qu'une seule entrée?
   

La fonction FAST S d'origine est configurée de telle sorte que si vous dites qu'il y a 3 entrées supplémentaires, elle supposera que vous simulez la fonctionnalité Lidar. Je ne pense pas que le code que vous montrez soit utilisé (je ne pense pas que #ifdef soit vrai), mais il y a une logique similaire dans le sous-programme FAST_Update .

Je changerais simplement la ligne pour qu'elle ne produise pas d'erreur si le nombre d'entrées supplémentaires est 1:

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

Cette gestion des erreurs est là car il serait très facile d'obtenir une erreur de segmentation lors du passage de tableaux de tailles différentes entre Simulink et le code Fortran.

Bonjour @bjonkman ,
Merci d'avoir fait remarquer cela.
J'ai changé la logique comme vous l'avez mentionné dans le commentaire précédent dans subroutine FAST-Update , puis j'ai recompilé la DLL FAST à partir d' OpenFASTvs-buildFASTlib FASTlib.sln avec une configuration différente:

1. Relase tant que configuration Soultion, x64 tant que plateforme Soultion, et construisez la solution en utilisant Build->Build Soultion .

1. Relase tant que configuration Soultion, x64 tant que plateforme Soultion, et construisez la solution en utilisant Build->Rebuild FASTlib .

1. Relase_Matlab comme configuration Soultion, x64 comme plateforme Soultion, et créez la solution en utilisant Build->Rebuild FASTlib .
   Après chaque compilation, j'exécute OpenLoop_Test avec l'entrée supplémentaire et j'ai reçu la même vieille erreur

Ensuite, j'ai recompilé FAST à partir d' OpenFASTvs-buildFAST FASTlib.sln avec Relase_Matlab , x64 et Build->Build Soultion la compilation a planté:

La ligne 341 dans FAST_Library.f90 est la ligne où j'ai ajouté la logique pour l'entrée supplémentaire

Il semble que la structure de subroutine FAST_SetExtrenalInputs devrait être étendue pour permettre une telle logique supplémentaire?

Avez-vous ajouté le nouveau champ %RotSpeed à la structure de données dans laquelle vous l'utilisez?

Si vous ajoutez des champs à une structure de données, vous devez les définir dans le fichier d'entrée OpenFAST Registry approprié. Dans votre cas, il devrait y avoir une ligne supplémentaire dans la définition du FAST_ExternInputType . Donc, quelque part près de la ligne 626 dans FAST_Registry.txt , vous devriez ajouter une ligne pour le nouveau champ RotSpeed :

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

De plus, la seule configuration que vous devez utiliser est la configuration Release_Matlab | x64 . Les autres configurations ne sont pas du tout utilisées dans le processus Simulink, vous étiez donc juste en train d'exécuter l'ancien code avec vos 2 premières versions.

Bonjour @bjonkman ,
Tout d'abord merci beaucoup pour votre aide.
Je pourrais ajouter une autre entrée supplémentaire à la fonction S comme suit:

1. occupent le 9e élément de InputAry dans FAST_Library.f90\ subroutine FAST_SetExternalInputs

1. définir l'entrée supplémentaire dans FAST_Rgistery.txt\ FAST_ExternalInput data

1. liez l'entrée externe supplémentaire à ElastoDyn dans FAST_Solver.f90\ SUBROUTINE ED_SetExternalInput (j'ai écrit cette routine)

1. définir l'entrée externe supplémentaire dans ElastoDyn_Registry.txt

1. générer un nouveau paramètre dans EladoDyn à écraser et à exporter dans OutListParameter en utilisant le script Write_ChckOutLst.m

1. écraser le nouveau paramètre défini dans ElastoDyn avec l'entrée supplémentaire de Siimulink dans ElastoDyn.f90\ SUBROUTINE ED_CalcOutput

1. définir le RotMass dans Simulink comme une constante pour écraser le paramètre défini dans ElastoDyn.f90 RMSimulink

1. Tracez la sortie écrasée RMSimulink fil du temps (1 s)

Comme vous le voyez, RMSimulink est constant à zéro dans le temps et l'écrasement n'a pas fonctionné. Je pense que ce qui manque, c'est un commutateur dans le fichier d'entrée d'ElastoDyn qui active les entrées externes de Simulink tel qu'il est dans le fichier d'entrée ServoDyn avec le PCMode . Pouvez-vous voir une erreur dans l'implantation ci-dessus? Y a-t-il quelque chose que j'ai manqué par l'écrasement?

Vous devrez demander le nouveau canal de sortie RMSimulink dans le fichier d'entrée OutList du fichier d'entrée ElastoDyn afin que la valeur du tableau m%AllOuts soit placée dans le y%WriteOutput array (qui est ce qui est imprimé dans les fichiers de sortie et envoyé à Simulink). Cependant, pour obtenir cela dans le tableau WriteOutput , vous devez modifier le sous-programme SetOutParam() dans ElastoDyn.f90 afin qu'il reconnaisse la nouvelle sortie que vous ajoutez.

Sinon, si vous ne souhaitez pas mettre à jour le code dans SetOutParam() , vous pouvez simplement écraser un canal existant dans ElastoDyn et demander ce canal à la place.

Bonjour @bjonkman ,
Merci pour la relecture.
J'ai déjà mis à jour le code dans Subroutine SetOutParam() dans ElastoDyn.f90 et le code dans ElastoDyn_IO.f90 , afin d'ajouter le nouveau canal de sortie RMSimulink .
Je me demande toujours pourquoi la valeur de l'entrée externe supplémentaire u%ExternalRotMass de Simulink est égale à zéro pendant la simulation, même si j'ai défini cette valeur sur 1000 dans Simulink?
Comme vous l'avez suggéré, j'ai utilisé un canal existant «SpnMxlb» pour écraser, mais le résultat est toujours le même. u%ExternalRotMass est toujours zéro!

Bonjour @bjonkman ,
J'ai trouvé où était le problème. Je n'ai pas appelé SUBROUTINE ED_SetExternalInputs dans SUBROUTINE ED_InputSolve dans le FAST_Solver.f90 . Ainsi, j'ai dû modifier l'argument de SUBROUTINE ED_InputSolve pour ajouter le type de données m_FAST .

Bonjour @bjonkman ,
Comme vous l'avez mentionné dans un commentaire précédent, j'ai changé le MAXInitINPUTS de la fonction S pour autoriser 100 entrées supplémentaires. Mon objectif est d'écraser les masses des éléments de lame dans ElastoDyn.f90\ p%BElmntMass . Je pourrais écraser une masse d'élément de lame grâce à la fonction S. J'essaye maintenant d'écraser toutes les masses d'élément de lame, qui sont 51 éléments pour les trois lames. Je pourrais compiler FAST avec la nouvelle modification mais lorsque je compile MATLAB, je deviens cette erreur:

Voici la ligne d'erreur dans FAST_Library.f90

L'élément lame masse m_FAST%ExternInput%SpnMB est défini dans FAST_Registery.txt :

Pouvez-vous voir si je manque quelque chose par la définition de SPNMB?

Vous avez défini SPNMB comme un tableau attribuable à 2 dimensions. Je ne sais pas quelle taille vous l'avez allouée - j'espère que vous l'avez fait avant d'appeler FAST_SetExternalInputs mais vous le définissez égal à un tableau à 1 dimension de taille 52 (note: vous voudrez peut-être vérifiez que 51 que vous utilisez ou voyez si les indices InputAry doivent aller de 9:59 à la place). L'erreur dit que les tableaux que vous essayez de définir égaux les uns aux autres n'ont pas la même forme (1-d vs 2-d), donc ils ne peuvent pas être égaux.

Faites également attention à l'écrasement des paramètres (tout ce qui se trouve dans la structure de données p% ). Ces valeurs ne sont pas censées changer après l'initialisation, donc (1) vous obtiendrez probablement des erreurs indiquant que vous ne pouvez pas les changer dans certains sous-programmes, (2) d'autres paramètres peuvent également dépendre de leurs valeurs initiales, vous aurez donc besoin pour rendre cela cohérent si vous modifiez le code afin de pouvoir modifier les paramètres pendant la simulation.

Bonjour @bjonkman ,
Merci d'avoir fait remarquer cela.
J'ai changé la dimension du tableau SpnMb tableau 2-d à 1-d de 51 éléments dans FAST_Register.txt et ElastoDyn_Registery.txt . Ensuite, j'ai défini une matrice 3x17 dans le sous-programme ED_CalcOutput()\ElastoDyn.f90

J'ai utilisé cette matrice pour remodeler le tableau 1-d, qui est importé de Simulink, en une matrice 3x17

Après le remodelage, j'ai écrasé les masses des éléments de lame avec les valeurs importées de Simulink

Afin de mettre à jour les valeurs qui dépendent du p%BElmntMass j'ai appelé Subroutine UpdateCoeff(p, ErrStat, ErrMsg)

Le sous-programme UpdateCoeff (p, ErrStat, ErrMsg)\ElastoDyn.f90 , qui est généré par moi-même, est une routine très similaire à Subroutine Coeff(p,InputFileData, ErrStat, ErrMsg) avec l'avantage de l'indépendance des données du fichier d'entrée. Cela permet d'appeler le sous-programme UpdateCoeff() dans le domaine temporel, c'est-à-dire dans ED_CalcOutput() .
De plus, j'ai changé l'intention de la structure de données des paramètres de seulement IN à INOUT . C'est comme vous l'avez mentionné ci-dessus pour permettre l'écrasement de la structure de données p% .
Avec les modifications de code ci-dessus, j'ai pu compiler FAST et Matlab sans erreurs. Mais lorsque j'exécute OpenLoop avec les 51 entrées supplémentaires, la simulation s'est plantée après deux étapes de simulation.

Je n'ai pas pu identifier la raison d'une telle erreur. Voyez-vous quelque chose de mal dans mon implémentation qui pourrait produire cette erreur?
L'écrasement d'une seule masse d'élément de lame est réussi. Mais pour tous les éléments de la lame, ce n'était pas le cas.
je serais très reconnaissant pour toute aide.
Et merci encore pour votre rediffusion rapide

En fonction de la façon dont vos tableaux sont alloués, il semble que vous devriez avoir

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

Je ne suis pas sûr que ce soit le seul problème, cependant. Une façon de déboguer cela sans avoir Matlab dans le processus consiste simplement à écrire un simple code de pilote c (copiez les appels principaux à partir de FAST_SFunc.c ), puis à le construire et à l'exécuter via le débogueur Visual Studio. J'avais quelque chose comme ça pour FAST v8 - c'est un outil très utile pour aider à trouver ce genre d'erreurs.

Bonjour @bjonkman ,
Merci d'avoir signalé l'erreur avec Element (K, J). Malheureusement, ce n’était évidemment pas le seul problème.
Comme vous le suggérez, j'ai écrit un simple pilote c:

Mais je ne pouvais pas connaître les principaux appels de FAST_Sfunction.c que vous vouliez copier et coller dans le pilote ci-dessus.
En fait, j'avais l'habitude d'écrire des messages contextuels à certains endroits dans le code FORTRAN pour retracer les erreurs, c'est ainsi que je débogue lorsque j'utilise le .exe

Comme vous le voyez, cette méthode ne fonctionnera pas pour la fonction S.
Pouvez-vous aider avec le débogage avec VS?

Si vous utilisez CALL WrScr( string ) vous pouvez imprimer des éléments sur la console Matlab pour le débogage. Je suppose que l'utilisation de print * créerait un fichier texte fort.7 dans le répertoire Matlab actuel (lorsque vous exécutez le modèle Simulink). Sinon, vous pouvez simplement écrire dans un autre fichier en utilisant WRITE(Unit,Fmt) data pour vos informations de débogage.

Si vous souhaitez utiliser le débogueur Visual Studio, vous devez créer un code C pour appeler les parties appropriées de la DLL, quelque chose de similaire à celui qui a été écrit pour l'interface OpenFOAM: https://github.com/old-NWTC/ FAST / blob / master / Source / FAST_Prog.c

En parcourant le fichier FAST_SFunc.c, je suppose que vous auriez besoin de ces routines pour l'initialisation:

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

Puis pour chaque pas de temps (c'est-à-dire en boucle),

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

Et à la fin, tu aurais besoin

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

Bonjour @bjonkman ,

Merci de votre aide. CALL WrScr(string) est une fonction géniale, elle a beaucoup aidé. Le seul inconvénient de cette fonction est que je ne pouvais imprimer que de la chaîne mais pas de valeurs dans la fenêtre de commande de Matlab. J'essaierai également de déboguer le FAST_Sfunction.c avec VS.
Merci beaucoup

Il existe également une fonction Num2LStr() (chaîne de nombre à gauche justifiée) que vous pouvez utiliser en conjonction avec WrScr , qui peut aider à imprimer des valeurs numériques: CALL WrScr( trim( Num2Lstr( number ) ) )

J'ai le même problème avec openFAST 2.4.0-master et dev.
Compilation avec Visual studio et mex généré par le compilateur C installé au moyen de Matlab Add-on (Matlab 2018b).

La fonction S générée à l'aide de fichiers source v 2.4.0 fonctionne correctement avec openFAST 2.3.0 que j'ai également compilé avec Visual Studio. Je pense donc que le problème ne vient pas de la fonction S.

Ni mon projet ni les exemples ne fonctionnent - tous entraînent un crash de Matlab.

J'ai juste essayé de générer une fonction S en modifiant le paramètre #define CHANNEL_LENGTH 20 dans le fichier FAST_library.h et j'ai eu le même problème. Voici ma sortie Matlab:

avorter () détecté au sexe le 27 novembre 09:49:16 2020-0300

Configuration:
Décodage sur incident: désactivé - Pas de bac à sable ni de chemin de zone de construction
Crash Mode: continuer (par défaut)
Codage par défaut: windows-1252
Déployé: faux
Pilote graphique: matériel inconnu
Carte graphique 1: Intel Corporation (0x8086) Intel (R) UHD Graphics 630 Version 27.20.100.8681 (2020-9-5)
Version Java: Java 1.8.0_152-b16 avec Oracle Corporation Java HotSpot (TM) 64 bits Server VM en mode mixte
Architecture MATLAB: win64
ID de droit MATLAB: 6257193
Racine MATLAB: C: Fichiers de programmeMATLABR2018b
Version MATLAB: 9.5.0.944444 (R2018b)
OpenGL: matériel
Système d'exploitation: Microsoft Windows 10 Pro
ID du processus: 9896
ID de processeur: x86 Family 6 Model 158 Stepping 10, GenuineIntel
Clé de session: 2e3cb4b1-3a3b-46b0-bf51-135d94257c8d
Système de fenêtre: Version 10.0 (Build 18363)

Nombre de défauts: 1

Terminaison anormale

État du registre (capturé):
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

Trace de pile (capturée):
[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 :: symboles :: 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 relance + 00000477
[9] 0x00007ffc5307dab1 C: WINDOWSSystem32ucrtbase.dll + 00449201 abandonner + 00000049
[10] 0x00007ffc5307d20f C: WINDOWSSystem32ucrtbase.dll + 00446991 terminer + 00000031
[11] 0x00007ffc4a142388 C: Program FilesMATLABR2018bbinwin64VCRUNTIME140.dll + 00009096 is_exception_typeof + 00002312
[12] 0x00007ffc4a141ec2 C: Program FilesMATLABR2018bbinwin64VCRUNTIME140.dll + 00007874 is_exception_typeof + 00001090
[13] 0x00007ffc4a14b950 C: Program FilesMATLABR2018bbinwin64VCRUNTIME140.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 :: envoyer + 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 :: exécute + 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

Cette erreur a été détectée lors de l'exécution d'un fichier MEX. Si le fichier MEX
n'est pas une fonction MathWorks officielle, veuillez examiner son code source
pour les erreurs. Veuillez consulter le Guide des interfaces externes pour plus d'informations
sur le débogage des fichiers MEX.

Bonjour @bjonkman , Bonjour @jjonkman ,
Comme je l'ai mentionné ci-dessus, je pourrais faire varier les masses des éléments de lame dans une simulation donnée. Le changement des masses des éléments d'aube génère un couple supplémentaire à partir du changement du moment angulaire. Ce couple. T_cor , peut également être exprimé en termes de force de Coriolis, F_cor , agissant sur le rayon variable des masses déplacées, R_var , comme décrit dans l'équation suivante.

T_cor = 3 ∙ F_cor ∙ R_var

Comme @jjonkman l'a mentionné dans le commentaire précédent:

Je n'ai pas trouvé ces termes dans le code source d'ElastoDyn qui rendent compte de la force de Coriolis. Je vois que dans ElastoDyn.f90\FUNCTION SignLSSTrq( p, m ) le moment sur l'arbre à basse vitesse MomLPRot est calculé. Est-il correct d'ajouter le Coriolis à ce stade:

Où u% ExternalRvar et u% ExternalFcor sont respectivement le rayon variable et la force de Coriolis de Simulink.
Pouvez-vous m'aider à ajouter le couple Coriolis au couple de l'arbre à basse vitesse?

Cher @LaurenceWETI ,

Je ne changerais pas FUNCTION SignLSSTrq () comme vous le proposez. Le Coriolis et les autres forces sont intrinsèquement calculés dans ElastoDyn. Si vous modifiez les masses des éléments de lame à chaque pas de temps avant que les principaux calculs dynamiques aient lieu, l'impact de ces masses sur les forces d'inertie doit être intrinsèquement inclus.

Meilleures salutations,

Cher @jjonkman ,

Merci pour votre rediffusion.
Exactement pour la même raison que le changement de masse des éléments de lame doit avoir lieu à chaque pas de temps et avant que les principaux calculs dynamiques aient lieu, j'ai appelé les sous-programmes de changement de masse au début de SUBROUTINE ED_CalcOutput\ElastoDyn.f90 . Puis-je résumer brièvement le flux des ordres d'appel dans la figure suivante

Où Subroutine Flywheel_Ini(p) appelé uniquement à t = 0 pour l'initialisation, Subroutine Flywheel(p, u) est appelé à chaque pas de temps pour écraser les masses des éléments de lame, et Subroutine UpdateCoeff(p, ErrStat, ErrMsg) est appelé après le changement des masses de lame pour mettre à jour les paramètres de Subroutine Coeff(p,InputFileData, ErrStat, ErrMsg) . Afin d'activer l'écrasement du type de données de paramètre p% j'ai changé l'intention de la structure de données de paramètre de seulement IN à INOUT

Ai-je changé les masses au point précédant la place des principaux calculs dynamiques?

Pouvez-vous vous référer au code s'il vous plaît dans ElastoDyn où la force de Coriolis est-elle calculée?

La force de Coriolis que vous avez mentionnée est-elle calculée en raison du changement de masse de la lame ou du mouvement latéral de la tour?

Cher @LaurenceWETI ,

Les deux principaux calculs dynamiques d'ElastoDyn sont:

• ED_UpdateStates - Intègre (avance) les états dans le temps, d'un pas de temps à l'autre.
• ED_CalcOutput - Calcule les sorties à l'heure actuelle.

Dans la routine principale FAST_Solution, ED_UpdateStates est appelé avant ED_CalcOutput, donc je pense que vous auriez besoin de faire ces calculs au début de ED_UpdateStates.

La force de Coriolis provient du mouvement de la lame (dû à la déflexion de la lame et de la tour) dans un cadre de référence rotatif. La force de Coriolis est basée sur l'accélération du corps, elle est donc intrinsèque à la cinématique et à la cinétique. ElastoDyn utilise la dynamique de Kane, donc, les vitesses et les accélérations sont exprimées sous forme de partiels. Les principales routines cinématiques et cinétiques d'ElastoDyn (CalculatePositions, CalculateAngularPosVelPAcc, CalculateLinearVelPAcc et CalculateForcesMoments) joueront toutes un rôle.

Meilleures salutations,

Cher @jjonkman ,

Merci beaucoup pour votre rediffusion,
Comme vous le suggérez dans le dernier commentaire, j'ai déplacé mon calcul au début de ED_UpdateStates :

Mais je ne sais pas si la force de Coriolis est calculée pour les masses variables des éléments de lame, ou du moins pour ma mise en œuvre du changement des masses. Puis-je illustrer avec un exemple où je m'attendrais à ce que l'impact de la force de Coriolis soit vu.
Dans l'exemple suivant, chaque lame est initialisée avec une masse de fluide supplémentaire de 4 000,00 kg dans les deux premiers éléments de lame. Après 40 s, j'ai déplacé 2000,00 kg de la masse fluide du premier élément de lame vers les 11e, 12e et 13e éléments de lame. Le reste du fluide dans le deuxième élément de lame est déplacé à 80 s vers les 11e, 12e et 13e éléments de lame. Ainsi, à 100 s, toute la masse de fluide de 4 000,00 kg est déplacée des éléments de pied de pale vers les éléments de corps de pale. J'ai répété cette procédure dans le sens inverse (du corps à la racine) entre 130 s et 190 s (voir figure ci-dessous).

Selon la masse de fluide déplacée, l'impact de la force de Coriolis doit être remarqué sur le couple de l'arbre à basse vitesse pendant le mouvement du fluide, c'est-à-dire entre 40-60 s, 80-100 s, 130-150 s et 170-190 s. Cependant, le couple de l'arbre à basse vitesse est presque constant dans les périodes mentionnées (voir figure ci-dessous).

Je peux voir l'impact de la masse ajoutée sur la déviation de la pointe dans le sens du bord (voir la figure suivante TipDyb1 ), mais je ne peux toujours pas reconnaître l'impact de la force de Coriolis.

J'apprécierais toute aide, conseils ou discussion.

Cher @LaurenceWETI ,

Je ne comprends pas vraiment ce que vous attendez de la force de Coriolis.

D'après ce que j'ai compris, vous déplacez la masse de l'intérieur vers l'extérieur de la lame. Cela aura pour effet d'augmenter l'inertie du rotor autour de l'arbre. Vous pouvez vérifier que cela se passe grâce à un test simplifié. De la conservation du moment cinétique, on s'attendrait en l'absence de couple aérodynamique ou générateur, le rotor ralentirait lors du déplacement de la masse vers l'extérieur en raison de l'augmentation de l'inertie. Ce test fonctionne-t-il? Autrement dit, désactivez AeroDyn et ServoDyn et activez GenDOF et donnez au rotor une vitesse initiale du rotor dans ElastoDyn. Le déplacement de la masse vers l'extérieur ralentit-il le rotor?

Meilleures salutations,

Cher @jjonkman ,

Merci pour votre réponse rapide.

Je m'attendrais à ce que la force de Coriolis ralentisse le rotor lorsque la masse se déplace vers l'extérieur, et accélère le rotor lorsque la masse se déplace vers l'intérieur. Je pense que c'est pourquoi vous suggérez de désactiver AeroDyn et Servoyn et d'activer GenDOF. Je désactive AeroDyn et ServoDyn en définissant CompAero et CompServo sur zéro dans le fichier d'entrée FAST et GenDOF sur True et RotSpeed ​​sur 12.1 dans le fichier d'entrée ElastoDyn.

Le résultat de la simulation ci-dessus montre évidemment que la vitesse du rotor ne ralentit pas lorsque la masse se déplace vers l'extérieur.
Comme vous l'avez mentionné ci-dessus, la force de Coriolis intrinsèque à la cinématique et à la cinétique est basée sur l'accélération du corps, mais pas sur le changement des masses entre deux pas de temps de simulation. La force de Coriolis dans ma simulation est basée sur le déplacement des masses. Par conséquent, je voudrais ajouter cette partie de la force de Coriolis au couple du rotor dans le code source ElastoDyn. J'ai déjà calculé le couple Coriolis dans MATLAB / Simulink, et j'utiliserais ce couple comme entrée externe dans ElastoDyn. Pouvez-vous m'aider où ajouter cette partie?

Meilleures salutations

Cher @LaurenceWETI ,

Je n'ai pas réfléchi à tous les changements que vous auriez à faire pour déplacer la masse le long de la lame. Mais il est clair que les modifications que vous avez apportées sont incomplètes. Quelle forme prennent vos nouveaux chargements? À moins que ces charges ne soient calculées et appliquées localement le long de la lame, je ne m'attendrais pas à ce qu'elles fournissent la réponse dynamique souhaitée. Et vous devrez vous assurer que les charges que vous ajoutez ne comptent pas deux fois les termes que vous avez déjà ajoutés et que d'autres termes importants ne manquent pas.

Avez-vous déjà examiné la base théorique d'ElastoDyn et identifié comment cette base devrait être modifiée pour s'adapter au déplacement de masse le long de la lame? Sinon, ce serait la première étape que je vous proposerais de faire. Bien qu'elle ne soit pas officiellement publiée, la base de la théorie ElastoDyn est documentée dans ce que l'on appelle le «Manuel de théorie FAST non officiel sur notre forum - voir: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t= 1532. Avez-vous déjà examiné cela et identifié les changements nécessaires pour tenir compte du déplacement de masse le long de la lame?

Meilleures salutations,

Cher @jjonkman ,

Merci pour votre rediffusion rapide,

Je mettrais en œuvre les nouvelles charges sous la forme d'un moment supplémentaire, qui agit directement sur l'arbre à basse vitesse. Ce moment est déjà calculé dans Simulink et je l'importerais dans ElastoDyn via la S-Function. Je suis conscient que la façon dont j'ajoute les nouvelles charges est très simplifiée et ne peut garantir que les charges ajoutées ne comptent pas deux fois les termes que j'ai déjà ajoutés. Mais pour moi maintenant, il est très important de commencer par une implantation simple, qui montre au moins l'effet dynamique de la masse déplacée le long de la lame. Sur la base de cette implémentation simple, je passerais à une implémentation plus précise en utilisant la base théorique d'ElastoDyn.
Dans un commentaire précédent, vous ne m'avez pas recommandé d'ajouter ce moment dans la FUNCTION SignLSSTrq (). Pouvez-vous me donner une idée d'où et comment ajouter ce moment dans le code source d'ELastoDyn. Je serais très reconnaissant de votre aide.

Meilleures salutations,

Cher @LaurenceWETI ,

Eh bien, ElastoDyn a un maillage de points d'entrée au niveau du module pour les charges externes appliquées au hub (HubPtLoad). J'ajouterais votre charge à cela. Mais l'interface Simulink n'est actuellement pas configurée pour recevoir HubPtLoad en tant qu'entrée de Simulink, vous devrez donc modifier à la fois le code de colle OpenFAST et l'interface Simulink pour cela.

Meilleures salutations,

Cher @jjonkman

Merci d'avoir fait remarquer cela,
Comme vous l'avez suggéré dans votre commentaire précédent, j'ai recherché les charges externes appliquées au hub ( HubPtLoad ). Je pensais que je pourrais ajouter le moment Coriolis externe à u%HubPtLoad%Moment() dans SUBROUTINE ED_Perturb_u(). Mais le problème est que lorsque je règle l'analyse de linéarisation sur TRUE dans le fichier d'entrée, afin de activer les routines jacobiennes pour les capacités de linéarisation, j'ai cette erreur:

Cette erreur est-elle due au fait que l'interface Simulink n'est pas configurée pour recevoir une entrée de Simulink? Est-ce que ma compréhension de ce que vous avez suggéré est correcte? Pourriez-vous me donner s'il vous plaît quelques détails sur où modifier le code de glue OpenFAST et l'interface Simulink?
Existe-t-il un autre moyen d'ajouter cette charge supplémentaire à partir de Simulink? En fait, j'ai essayé d'ajouter ce moment au moment dans le plan à la racine MomH0B la lame SUBROUTINE ED_CalcOutput . Mais même lorsque le moment dans le plan est modifié, la vitesse du rotor reste inchangée (voir la figure ci-dessous).

La vitesse du rotor est-elle toujours inchangée parce que je désactive AeroDyn et ServoDyn?

Meilleures salutations,

Cher @LaurenceWETI ,

Vous ne devriez pas avoir besoin de changer ElastoDyn et il semble que vous vous concentrez sur la simulation temporelle, pas sur la linéarisation. Donc, vous ne devriez pas changer SUBROUTINE ED_Perturb_u() .

Au lieu de cela, comme je l'ai déjà dit, vous devrez changer l'interface Simulink et le code de glue OpenFAST. Je rechercherais comment d'autres variables sont passées via l'interface Simulink (comme GenTrq) et utilisées dans le code de colle OpenFAST (FAST_Registry.txt, FAST_Solver.f90). Je définirais probablement l'entrée HubPtLoad dans le code de colle OpenFAST près de l'endroit où l'entrée NacelleLoads est actuellement définie.

Meilleures salutations,

Cher @jjonkman

Merci pour votre réponse rapide même en vacances,

Avec l'aide de Bonnie, j'ai pu savoir comment passer des variables via l'interface Simulink et comment utiliser ces variables dans le code glue OpenFAST et même dans ElastoDyn. Ce que je voudrais savoir où utiliser / ajouter la charge externe de Simulink dans le code source d'OpenFAST ou dans ElastoDyn.

Vous voulez dire que je ne devrais pas avoir besoin de changer ElastoDyn. Cela signifie-t-il que les charges externes (le moment de Coriolis de Simulink) dues à la masse décalée le long de la lame ne doivent pas être ajoutées / utilisées dans ElastoDyn? Cela signifie-t-il que cette charge externe ne doit être ajoutée que dans le code de colle OpenFAST (FAST_Solver.f90)?

Je n'ai pas pu trouver où l'entrée NacelleLoads est définie dans le code de colle OpenFAST (FAST_Solver.f90) afin de définir mes charges externes à proximité de. Vous attendez-vous à ce que la vitesse du rotor soit modifiée lorsque le moment de Coriolis externe est ajouté aux charges Nacell?

Meilleures salutations

Cher @LaurenceWETI ,

L'entrée au niveau du module HubPtLoad vers ElastoDyn est déjà appliquée dans ElastoDyn en tant que charge externe ajoutée au concentrateur. Normalement, cette charge est mise à zéro. Il est utilisé lorsque BeamDyn est activé pour appliquer des charges au hub ElastoDyn à partir de la racine de chaque lame de BeamDyn. Ce que je suggère, c'est que puisque vous calculez déjà cette charge supplémentaire dans Simulink, vous devez simplement prendre la valeur de Simulink et l'utiliser pour définir la valeur de HubPtLoad dans le code de colle OpenFAST. Aucune modification de ElastoDyn n'est donc nécessaire.

L'entrée NacelleLoads dans ElastoDyn est définie par le code glude OpenFAST dans SUBROUTINE ED_InputSolve() de _FAST_Solver.f90_ (basé sur les charges d'un TMD basé sur une nacelle calculé dans ServoDyn). Vous pouvez également définir l'entrée HubPtLoad sur ElastoDyn dans ce SUBROUTINE.

Vous n'avez pas expliqué comment vous calculez la "force de Coriolis" dans Simulink. Normalement, je considère la force de Coriolis comme la force d'inertie causée par le mouvement dans un cadre de référence en rotation. Vraisemblablement, la vitesse de rotation que vous utilisez est celle du rotor et la vitesse de translation que vous utilisez est axiale le long de la pale (à partir de la translation de la masse le long de la pale). La force de Coriolis serait alors dans le plan du rotor, ce qui, je pense, aurait un impact sur la rotation, si le bras de moment par rapport à l'arbre est différent de zéro.

Meilleures salutations,

Cher @jjonkman;

Merci pour votre aide,
Comme vous l'avez suggéré, j'ai défini la valeur de HubPtLoad dans SUBROUTINE ED_InputSolve de FAST_Solver.f90 à la charge supplémentaire de Simulink comme suit:

Où u_ED%ExternalCoriolis1 est la charge supplémentaire calculée dans Simulink. Puisque HubPtLoad est la seule entrée qui n'est pas résolue dans SUBROUTINE ED_InputSolve , et que MeshMapData%u_ED_HubPtLoad%Moment est mis à zéro dans SUBROUTINE FullOpt1_InputOutputSolve () , j'ai changé la valeur de HubPtLoad en SUBROUTINE FullOpt1_InputOutputSolve () à la charge Simulink supplémentaire également:

Pour calculer le moment de Coriolis, j'ai utilisé ces deux équations:
T_cor = 3 * F_cor * R_var
F_cor = 2 * m_fluid * w_rot * v_fluid
Où R_var est le rayon variable du centre de gravité de la masse décalée dans les éléments d'extrémité d'aube [m]; m_fluid est la masse du fluide déplacé [kg]; w_rot est la vitesse de rotation du rotor [rps]; et v_fluid est la vitesse de translation du fluide le long de la pale [m / s]. La figure ci-dessous montre un exemple extrême du moment de Coriolis, où il est évident que le moment supplémentaire n'a aucun impact sur la vitesse du rotor.

pour cet exemple, j'ai désactivé ServoDyn et AeroDyn et activé GenDOF et je donne à la vitesse du rotor une valeur initiale de 12,1 [rpm]

Ai-je défini correctement la valeur de HubPtLoad?

Pouvez-vous expliquer pourquoi je ne vois pas l'impact de la charge supplémentaire sur la vitesse du rotor?

Meilleures salutations

Cher @jjonkman ,

Je comprends l'impact de la charge Coriolis supplémentaire due à la masse déplacée le long de la pale comme une charge dans le plan du rotor, qui devrait être positive (dans le sens de rotation) lorsque la masse est déplacée de l'extérieur vers l'intérieur, et négative (contre le sens de rotation) lorsque la masse est déplacée de l'intérieur vers l'extérieur. Êtes-vous d'accord avec cela? La vitesse du rotor reste-t-elle inchangée dans ma dernière simulation par rapport au commentaire précédent parce que le 12,1 [rpm] qui est défini dans le fichier d'entrée ElastoDyn n'est pas seulement la valeur initiale, mais aussi la valeur fixe de la vitesse du rotor tout au long de la simulation?

Toute aide serait très appréciée.

Meilleures salutations,

Cher @LaurenceWETI ,

Je suis d'accord avec les lignes de code que vous avez modifiées dans SUBROUTINE FullOpt1_InputOutputSolve() , mais ce code n'est utilisé que lorsque BeamDyn est activé. Dans SUBROUTINE ED_InputSolve() , ce que vous avez n'est pas correct. Au lieu de cela, cela devrait être;

u_ED%HubPtLoad%Moment = u_ED%ExternalCoriolis1

Vos équations pour le moment de Coriolis semblent correctes, mais ce moment doit être un vecteur à 3 éléments, contenant les composantes globales X, Y et Z du moment. Définissez-vous chaque composant de ce vecteur à 3 éléments? Le premier composant (X) ne serait directement autour de l'arbre que si l'arbre est aligné avec l'axe X global, c'est-à-dire si la rotation de la plate-forme, la déflexion de la tour, l'inclinaison de l'arbre et l'angle de lacet sont nuls.

Meilleures salutations,

Cher @jjonkman ,

Merci d'avoir fait remarquer cela,
J'ai changé la définition du moment de Coriolis en un vecteur à 3 éléments pour inclure les composantes X, Y et Z du moment. J'ai corrigé le code dans SUBROUTINE ED_InputSolve\FAST_Solver.f90 en:
u_ED%HubPtLoad%Moment = u_ED%ExternalCoriolis1
Cependant, la forme de l'expression tableau du Moment dans u_ED%HubPtLoad%Moment n'est pas conforme à ce stade:

J'ai cherché dans FAST_Solver.f90 comment u_ED%HubPtLoad%Moment est utilisé, et j'ai trouvé que cette variable est utilisée dans SUBROUTINE Add_FullOpt1_u_delta() sous cette forme:
u_ED%HubPtLoad%Moment(fieldIndx,node)
Y a-t-il quelque chose qui manque dans u_ED%HubPtLoad%Moment dans SUBROUTINE ED_InputSolve ?

Meilleures salutations

Cher @LaurenceWETI ,

Bon point. J'ai oublié que u_ED%HubPtLoad%Moment est un tableau à deux dimensions. Certes, il n'y a qu'un seul nœud dans la deuxième dimension. Ainsi, l'affectation correcte devrait être:

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

Meilleures salutations,

Le maillage HubPtLoad est actuellement utilisé dans le code glue uniquement pour fournir le couplage de BeamDyn avec ElastoDyn. Comme cela est appliqué dans les routines SolveOption1, il n'est actuellement défini que dans les calculs résiduels de FullOpt1_InputOutputSolve .

Si vous voulez ajouter une charge supplémentaire au maillage HubPtLoad , elle devra être dans FullOpt1_InputOutputSolve pour le couplage BeamDyn, et dans ED_InputSolve() si vous n'utilisez pas BeamDyn. La routine Add_FullOpt1_u_delta ne doit pas être modifiée.

Cher @jjonkman , Cher @bjonkman ,

Merci pour votre réponse. Il semble maintenant beaucoup mieux et je pouvais voir l'impact de la charge supplémentaire sur la vitesse du rotor.

Meilleures salutations

Cher @jjonkman ,

J'ai une question sur les couples qui agissent au niveau du moyeu lorsque AeroDyn et ServoDyn sont désactivés. Comme vous vous y attendiez auparavant, le déplacement de la masse vers l'extérieur ralentit le rotor, mais le déplacement de la même masse vers l'intérieur n'a pas pour effet d'accélérer le rotor avec la même valeur, voir la figure ci-dessous.

En fait, je calcule maintenant le couple de Coriolis en fonction de l'évolution de l'inertie de la masse décalée comme suit:

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

Où R_var est le centre de gravité variable de la masse déplacée, et m_Mass est la masse déplacée le long de la lame.

Je ne pouvais pas comprendre pourquoi le couple Coriolis supplémentaire n'entraînait pas l'accélération attendue du rotor lorsque la masse est déplacée vers l'intérieur!

Meilleures salutations.

Cher @LaurenceWETI ,

Je ne suis pas sûr de comprendre la différence entre vos deux calculs. Si vous utilisez d / dt (J_Blade_bl) = 2 R_var m_Mass * v_fluid, l'implémentation n'est-elle pas identique à ce que vous aviez auparavant?

Vous n'avez pas montré le couple du générateur (lié au contrôleur de couple) ou le couple aérodynamique (lié au contrôleur de pas), mais le contrôleur pourrait-il jouer un rôle dans la raison pour laquelle la vitesse du rotor ne accélère pas autant que prévu à?

Meilleures salutations,

Cher @jjonkman ,

Merci beaucoup pour votre réponse rapide. Je me demandais, comme vous m'avez demandé de montrer le couple du générateur (lié au contrôleur de pas), même si j'ai désactivé ServoDyn dans le fichier d'entrée d'OpenFAST en mettant CompServo à zéro, et il n'y a pas de sorties de ce modèle pour tracer l'électricité couple du générateur (GenTq). Cependant, j'ai activé ServoDyn dans le fichier d'entrée FAST et désactivé tous les contrôleurs dans le fichier d'entrée de ServoDyn, afin d'obtenir GenTq dans les signaux de sortie sans l'impact des contrôleurs. Soudain, la vitesse du rotor s'accélère comme prévu:

Je n'ai pas pu trouver de raison raisonnable pour laquelle le générateur et le contrôleur de couple ne se désactivent pas lorsque CompServo est mis à zéro dans le fichier d'entrée FAST, et il doit être désactivé dans le fichier d'entrée ServoDyn, afin de désactiver les effets dans ElastoDyn. Peut-être pouvez-vous expliquer ce phénomène?

Meilleures salutations

Cher @LaurenceWETI ,

Les entrées de Simulink vers la fonction OpenFAST S (couple, pas, lacet, etc.) sont activées en réglant les modèles de commande associés de manière appropriée (par exemple VSContrl = 5 pour accepter le couple de Simlulink). Donc, je ne m'attendrais pas à ce que les entrées Simulink soient utilisées si ServoDyn n'est pas activé. Certes, vous avez modifié l'interface Simulink afin que vos nouvelles charges Coriolis soient appliquées directement à ElastoDyn, plutôt que de passer par ServoDyn, donc, je suppose que vous avez capturé une partie de l'effet.

Meilleures salutations,

Je travaille sur l'établissement d'un chemin pour distribuer la bibliothèque OpenFAST compilée pour l'intégration Simulink avec les autres exécutables que nous partageons régulièrement pour chaque version. J'ai ajouté un fichier inclus dans la dernière version appelé openfastlib_simulink.dll . Quelqu'un est-il capable de tester la bibliothèque jointe? Il s'agit de la bibliothèque OpenFAST qui doit être liée dans la fonction mex.

Je travaille sur l'établissement d'un chemin pour distribuer la bibliothèque OpenFAST compilée pour l'intégration Simulink avec les autres exécutables que nous partageons régulièrement pour chaque version. J'ai ajouté un fichier inclus dans la dernière version appelé openfastlib_simulink.dll . Quelqu'un est-il capable de tester la bibliothèque jointe? Il s'agit de la bibliothèque OpenFAST qui doit être liée dans la fonction mex.

Je n'ai pas pu trouver ce fichier dans la dernière Realease ...

@hbasbas C'est au bas de la version avec les autres actifs. J'ai mal tapé l'url de la dernière version ci-dessus (elle est maintenant corrigée), voici donc l'url correcte: https://github.com/openfast/openfast/releases/tag/v2.5.0

Bonjour à tous!
J'ai quelques problèmes lors de l'exécution de "Run_Test01_SIG.m".
J'ai utilisé la dernière version d'openfast v2.5.0 et compilé avec succès "FAST_SFunc.mexw64" avec matlab2020a et visual studio 2019, mais quand je lance "Run_Test01_SIG.m", matlab plante. J'ai essayé plusieurs fois et je n'arrive toujours pas à résoudre ce problème.
Vous trouverez ci-joint le rapport de plantage de matlab2020a et les résultats de Create_FAST_SFunc.

Meilleurs vœux!
ChenPeng
issue.txt

Traduction: cl: avertissement de ligne de commande D9025: réécriture de "/ MD" (avec "/ MT")

Cher @rafmudaf

Comment pourrions-nous utiliser la commande mex avec le fichier dll que vous avez donné. Devrions-nous avoir besoin d'un fichier .lib à la place?

Je crois comprendre que create_FAST_SFunc utilise une bibliothèque liée dynamiquement pour compiler avec la commande mex. @bjonkman pourrait probablement fournir de meilleures informations dans # 654.

@Domotopeng votre trace de pile montre que SIMULINK entre dans la bibliothèque OpenFAST, donc c'est bien. Mais il plante dans OpFM_Init, donc ce n'est pas bon. La compilation d'OpenFAST en mode débogage modifie-t-elle les informations de trace de la pile? Un numéro de ligne dans OpFM_Init serait génial.

Je crois comprendre que create_FAST_SFunc utilise la bibliothèque de liens dynamiques et la commande mex pour compiler. @bjonkman pourrait fournir de meilleures informations dans # 654 .

Je crois comprendre que create_FAST_SFunc utilise une bibliothèque liée dynamiquement pour compiler avec la commande mex. @Bjonkman pourrait probablement fournir de meilleures informations dans # 654.

Merci pour vos conseils!