Openfast: Compléter OpenFAST avec Simulink dans l'erreur VS #11023 et LNK2019

Visual studio ne trouve pas la bibliothèque Matlab qui contient MEXPRINTF . Vous devrez peut-être indiquer à Visual Studio où il se trouve.

Visual studio ne trouve pas la bibliothèque Matlab qui contient MEXPRINTF . Vous devrez peut-être indiquer à Visual Studio où il se trouve.

Si vous parlez du chemin MATLAB dans les propriétés, je l'ai changé en mon chemin MATLAB comme je l'ai mentionné. Sinon comment le changer ?

En regardant votre première capture d'écran de sortie, il n'a pas trouvé le MEXPRINTF lors de la compilation de openfast_x64.exe . Je ne suis pas sûr que VS devrait construire celui-ci lors de la construction Release_Matlab. @bjonkman , construisons-nous normalement openfsat_x64.exe avec ça ? J'aurais pensé que toutes les définitions du préprocesseur rendraient cet exécutable inutile.

Il semble qu'il ait trouvé la bibliothèque appropriée pour la version OpenFAST-Simulink_x64.lib . Je m'attends donc à ce que l'on travaille avec simulink.

@klitz06 , quelle branche construisez-vous ?

J'ai utilisé " git clone https://github.com/openfast/openfast.git " pour cloner le référentiel. Je ne sais pas lequel est-ce. Comment le vérifier ?

Éditer:
git branch --show-current dans git pour Windows me dit que c'est "principal".

git branch affichera les branches disponibles. Il affichera main et dev comme les deux options, et celle que vous avez construite sera mise en surbrillance (ou aura une étoile à côté). Je pense que main est celui par défaut.

Oui c'est main un.

Que se passe-t-il si vous essayez le script create_FAST_SFunc.m (après avoir défini les chemins nécessaires comme mentionné dans le script) ? Il ne devrait avoir besoin que de OpenFAST-Simulink_x64.lib pour se lier à Simulink, et non de openfast_x64.exe .

Les autres avertissements peuvent être ignorés en toute sécurité (nous suivons principalement la norme Fortran 2008, mais nous ne configurons VS que pour appliquer la norme Fortran 2003, de sorte qu'il signale des éléments qui ne sont pas réellement un problème).

Je pense qu'il est créé avec succès. Je vais essayer les exemples et je reviens.

OK, j'ai essayé d'exécuter Ren_Test01_SIG.m et voici le résultat :

J'ai changé VSContrl = 4 et pour voir si cela aide, j'ai ajouté LSSGagVxa aux sorties d'ElastoDyn. Cela n'a pas aidé.

vous devrez peut-être ajouter l'emplacement du SFunc au chemin matlab. addpath(genpath(('../../../install')) du répertoire des exemples.

Je suis désolé de ne pas avoir compris ce que vous voulez que je fasse. Dois-je simplement l'exécuter via la fenêtre de commande?

Oui. Je pensais dans la fenêtre de commande. mais l'erreur peut indiquer un problème avec le test lui-même.

Avez-vous initialisé le sous-module r-test après le clonage depuis github ? git submodule update --init --recursive comme indiqué ici : https://openfast.readthedocs.io/en/dev/source/testing/index.html

Oui, j'ai en fait exécuté git clone --recursive https://github.com/openfast/openfast.git au début du processus, cela pourrait-il être le problème ? Dois-je utiliser la commande que vous donnez?

<openfast git rootdir>/reg_tests/r-test/glue-codes/openfast/AWT_YFix_WSt/ existe-t-il ?

Oui ça existe. Je peux voir les fichiers d'entrée dans le dossier.

Je ne suis pas sûr alors. Je suis à court d'idées. Peut-être que quelqu'un d'autre peut commenter ce qu'il a rencontré avec cela.

Merci de votre aide. Peut-être de mon installation MATLAB ? Parce que je n'ai pas installé tout ce qui vient avec MATLAB.

Edit : Bien sûr, Simulink est installé.

donc après quelques tests, je peux reproduire l'erreur que vous voyez en utilisant MATLAB 2020b avec simullink sur une machine virtuelle Windows 10. Cela utilisait la branche main d'OpenFAST.

J'avais oublié de mentionner qu'il y avait un bugfix #641 pour ce problème. La description du bogue a été donnée dans #632. Ce correctif a été fusionné dans la branche dev , mais n'a pas encore été intégré à la branche principale. Mes excuses pour ne pas m'en être souvenu plus tôt.

Alors pourriez-vous essayer git checkout dev puis git submodule update , puis reconstruire et réessayer ?

Maintenant, OpenFAST passe par MATLAB mais maintenant j'ai cette erreur :

Edit: je n'ai pas recompilé via VS après être passé à la branche dev. Je vais l'essayer maintenant.

Après avoir téléchargé la branche dev à partir de zéro, la compilation s'est terminée sans erreur. Les mêmes avertissements sont présents et l'exemple MATLAB Test01 fonctionne. L'autre n'a pas fonctionné en raison de l'absence de DISCON.dll.

J'utilise NREL 5MW comme base (la tour et la nacelle sont identiques) et cela fonctionne bien avec conda en WSL. Lorsque je veux essayer d'exécuter mon propre WT conçu via MATLAB avec Run_OpenLoop.m je rencontre d'abord quelques problèmes :

Ensuite, j'ai changé TwrShadow de True à 1 , j'ai passé cette erreur bien que cela posera probablement des problèmes dans les prochaines étapes. Après cela, j'obtiens l'erreur ci-dessous:

Et je suis coincé ici. Est-ce lié à mes fichiers d'entrée ? Parce que j'ai pu exécuter AWT_YFix_WSt à Run_OpenLoop.m . La raison pour laquelle je veux utiliser MATLAB est que je vais concevoir un contrôleur de pitch, sinon j'utiliserais OpenFAST avec conda en WSL.

Oui. Il y a eu un changement de fichier d'entrée entre la v2.5.0 et la branche dev (nous avons ajouté un autre modèle d'ombre de tour). Le conda + WSL utilise la v2.5.0, mais votre version compilée est sur la branche dev . Vous pouvez faire un git checkout main; git submodule update et recompiler votre copie locale pour obtenir la version v2.5.0, mais si je me souviens bien de la conversation ci-dessus, vous n'obtiendrez pas le correctif de gestion des erreurs qui se trouve dans le dev branche. Donc, pour votre cas, vous voudrez probablement vous en tenir à la branche dev et mettre à jour les fichiers d'entrée nécessaires.

Ce changement de fichier d'entrée est noté dans le deuxième tableau Modifié dans OpenFAST dev trouvé ici https://openfast.readthedocs.io/en/dev/source/user/api_change.html

J'ai deux autres questions. Existe-t-il des cas de test où l'angle de tangage est contrôlé via simulink ? Et description des cas ?

Cher @klitz06 ,

Il n'y a pas d'exemples Simulink comme celui-ci dans le référentiel OpenFAST, mais vous pouvez trouver la version Simulink du contrôleur ROSCO d'intérêt : https://github.com/NREL/ROSCO_toolbox.

Meilleures salutations,

Merci.

Bonjour à tous,

J'ai une erreur car AeroDyn essaie de lire TwrShadow, bien que le commutateur d'ombre de la tour soit réglé sur 0.

Quelqu'un connaît-il une telle erreur ?
Meilleures salutations.

Chère @LaurenceWETI ,

Comme pour tout problème de traitement de fichier d'entrée, je recommande d'activer l'option Echo pour déboguer. Voyez-vous des problèmes dans votre fichier d'entrée lorsque vous le comparez avec le fichier Echo correspondant ?

La définition de TwrShadow = FALSE résout-elle le problème ?

Meilleures salutations,

@LaurenceWETI

La version 2.5.0 que vous exécutez utilise un indicateur booléen pour l'entrée TwrShadow . Comme @jjonkman l'a suggéré, cela devrait être soit True soit False

La version dev utilise un commutateur avec des valeurs de 0,1,2 avec l'ajout d'un deuxième modèle d'ombre de tour.

Chers @jjonkman et @andrew-platt,

Merci pour votre réponse rapide.
Définir TwrShadow sur True ou Flase a résolu le problème dans AeroDyn, mais maintenant ServoDyn a un problème avec la lecture de CompNTMD . Je n'ai pas pu trouver ce paramètre dans le fichier d'entrée d'ErvoDyn.

Avez-vous une idée de comment résoudre cette erreur?
Existe-t-il des instructions pour passer à la version dev , afin d'utiliser à nouveau le commutateur d'ombre de la tour ?

Meilleures salutations,

Oui, ils ont modifié cette partie dans les fichiers servodyn de la branche dev. Jetez ici un œil à la branche principale du lien NREL 5mw dans la section TUNED MASS DAMPER du fichier.