Openfast: Défaut de segmentation pour la version SIMULINK sous Linux

Créé le 26 avr. 2021  ·  26Commentaires  ·  Source: OpenFAST/openfast

Description du bogue
Impossible d'exécuter la version simulink d'OpenFAST en raison d'une erreur de segmentation. La fonction s compile sans aucun problème.
Ce comportement existe à la fois dans les branches main(718d46f7) et dev(216bccbf).
Je montre les résultats du dev brach car la branche principale a un bogue où les erreurs simullink ne sont pas signalées.

Détails du système
Linux Mint 20.1, MATLAB 2020b, openblas, gcc et gfortran

Reproduire
Les options suivantes ont été utilisées ()

  1. cmake .. -DBUILD_OPENFAST_SIMULINK_API=ON -DBUILD_SHARED_LIBS=ON
  2. Fabriquer
  3. faire installer

Captures d'écran, le cas échéant
Le rapport de crash est joint

Version OpenFAST
dev (216bccbf)

matlab_crash_dump.txt

Bug

Tous les 26 commentaires

Avec quel modèle testes-tu ?

J'ai modifié le "Run_OpenLoop.m" pour faire fonctionner la turbine 5MW_Land_BD_Linear.

Le "Run_OpenLoop.m" d'origine a-t-il également rencontré un défaut de segmentation ?

Avec la turbine AOC_Wst, j'obtiens une erreur étrange ci-dessous.

% % % % % % % % % % % % % % % % % % %
Erreur signalée par la fonction S 'FAST_SFunc' dans 'OpenLoop/FAST Nonlinear Wind Turbine/S-Function' :
FAST_InitializeAll : IfW_ Init : IfW_UniformWind_Init : Impossible de lire la colonne de
le débit ascendant est 0.
FAST_Init ializeAll:SrvD_Init :SrvD_ ReadInput:ReadPrimaryFile :Entrée logique non valide pour le fichier
"/home/abhineet/Documents/MyOpenFAST/openfast/reg_tests/r-test/glue-codes/openfast/AOC_WSt/AOC_WSt_ServoDyn.dat"
s'est produit en essayant de lire CompNTMD.
% % % % % % % % % % % % % % % % % % % % %

le format du fichier d'entrée ServoDyn a changé entre la v2.5.0 et ce qui se trouve actuellement dans la branche dev. Le mot-clé CompNTMD été utilisé dans la version 2.5.0 (branche principale), mais pas dans la branche dev . Il semble donc que vous exécutiez les fichiers d'entrée de la branche dev avec la version compilée v2.5.0 d'OpenFAST.

J'ai vérifié la branche 'dev' (e0a73e19) du sous-module r-test.

J'obtiens l'erreur suivante pour AOC_Wst
%%%%%%%%%%%%%%%%%%
Erreur lors de l'utilisation de Run_OpenLoop (ligne 15)
Erreur signalée par la fonction S 'FAST_SFunc' dans 'OpenLoop/FAST Nonlinear Wind Turbine/S-Function' :
FAST_InitializeAll : IfW_ Init : IfW_UniformWind_Init : Impossible de lire la colonne de
le débit ascendant est 0.
FAST_Init ializeAll:SrvD_Init :SrvD_ ReadInput:ReadPrimaryFile :Entrée logique non valide pour le fichier
"/home/abhineet/Documents/MyOpenFAST/openfast/reg_tests/r-test/glue-codes/openfast/AOC_WSt/AOC_WSt_ServoDyn.dat"
s'est produit en essayant de lire CompNTMD.
% % % % % % % % % % % % % % % % % % %

mais j'obtiens une erreur au lieu d'une erreur de segmentation pour 5MW_Land_BD_Linear
% % % % % % % % % % % % % % % % % % % % % % %
Erreur lors de l'utilisation de Run_OpenLoop (ligne 15)
Erreur signalée par la fonction S 'FAST_SFunc' dans 'OpenLoop/FAST Nonlinear Wind Turbine/S-Function' :
FAST_Init ializeAll:FAST_Init :Validate InputData:LinOutJac ne peut être utilisé que lorsque LinInputs=LinOutputs=2.
FAST_Init ializeAll:ED_Init :ED_CalcContS tateDeriv:LAPACK_DGETRF : valeur illégale dans l'argument -4.
% % % % % % % % % % % % % % % % % % % % % % %

J'avais également essayé d'exécuter les simulations pour les branches «principales» et j'avais également des erreurs.
Je peux les réexécuter et partager les erreurs si cela aide au débogage.
(La branche principale avait un bogue qui empêchait l'affichage des erreurs de simullink (corrigé dans la branche dev), j'ai donc pensé que cela pourrait être moins utile pour les rapports de bogues.)

Étant donné que votre message d'erreur indique occurred while trying to read CompNTMD , la version OpenFAST que simulink exécute n'est pas la version dev. Quelle version OpenFAST rapporte-t-il dans les premières lignes de sortie ?

La sortie OpenFAST dit :

% % % % % % % % % % % % % % % % % % % % % % %
OpenFAST-v2.4.0-133-gb913c945-dirty
Informations sur la compilation :

  • Compilateur : GCC version 9.3.0
  • Architecture : 64 bits
  • Précision : double
  • Date : 5 janvier 2021
  • Heure: 21:12:45
    Informations sur l'exécution :
  • Date : 26/04/2021
  • Heure: 09:48:55-0500
    % % % % % % % % % % % % % % % % % % % % % % %

Aussi, voici une capture d'écran de mon journal git
image

commit b913c945 est sur la branche principale depuis 4 mois. Pouvez-vous recompiler votre version actuellement extraite et réexécuter le script create_FAST_SFunc.m ? Je m'attendrais à voir le hachage git se terminer par -g216bccbf dans la sortie OpenFAST si vous utilisez réellement la version dev qui est extraite.

Screen Shot 2021-04-26 at 9 04 32 AM

Juste pour être sûr, lorsque vous dites recompiler, vous voulez dire que je devrais exécuter les commandes suivantes (avec la version extraite actuelle)

1) cmake .. -DBUILD_OPENFAST_SIMULINK_API=ON -DBUILD_SHARED_LIBS=ON
2) faire
3) faire installer

Oui. Tout d'abord, supprimez tout dans le répertoire de construction ( rm -rf * à l'intérieur du répertoire de construction). Cela garantira absolument qu'il n'y a pas de modules restants d'une version précédente.

Vous pouvez également vouloir obtenir les balises récentes (git ne les récupère pas par défaut pour une raison quelconque) : get fetch --all --tags

D'accord, fera l'affaire.

L'erreur de segmentation pourrait être due à un conflit dans les bibliothèques LAPACK entre Matlab et OpenFAST. Je recommanderais de regarder https://github.com/OpenFAST/openfast/issues/482 (en particulier les derniers commentaires sur ce problème) pour voir si cela aide.

Une autre pensée que @rafmudaf a

Dans le fichier CMakeCache.txt du répertoire de construction, que montre l'entrée de la variable CMAKE_INSTALL_PREFIX ? Est-ce le même que l'emplacement spécifié dans le create_FAST_SFunc.m ? Sinon, il est possible qu'une ancienne version à l'emplacement spécifié dans le script create_FAST_SFunc.m soit liée dans la fonction mex.

Une autre pensée que @rafmudaf a

Dans le fichier CMakeCache.txt du répertoire de construction, que montre l'entrée de la variable CMAKE_INSTALL_PREFIX ? Est-ce le même que l'emplacement spécifié dans le create_FAST_SFunc.m ? Sinon, il est possible qu'une ancienne version à l'emplacement spécifié dans le script create_FAST_SFunc.m soit liée dans la fonction mex.

Le CMakeCache.txt a ce qui suit comme
CMAKE_INSTALL_ PREFIX:PATH=/home/abhineet/Documents/MyOpenFAST/openfast/install

qui est le même que ce que j'utilise dans create_FAST_SFUNC.m

if ( ispc ) % Windows PC
        installDir = '../../../install';
        outDir = fullfile(installDir, 'lib');
        % If there are shared libraries does it work for outDir to be the local directory?
    else
        installDir = '../../../install';  %%%%%%% <<<<<<<<< **Here**
        outDir = '.';
    end

Oui. Tout d'abord, supprimez tout dans le répertoire de construction ( rm -rf * à l'intérieur du répertoire de construction). Cela garantira absolument qu'il n'y a pas de modules restants d'une version précédente.

Vous pouvez également vouloir obtenir les balises récentes (git ne les récupère pas par défaut pour une raison quelconque) : get fetch --all --tags

@andrew-platt
J'ai essayé ce qui suit en fonction de vos commentaires
1) cd openfast
2) rm -rf ./construire
3) rm -rf ./installer
4) mkdir ./build
5) cd ./construire
6) cmake .. -DBUILD_OPENFAST_SIMULINK_API=ON -DBUILD_SHARED_LIBS=ON
7) faire -j12
8) faire installer
9) cd glue-codes/simulink/src/
10) rm ./FAST_SFunc.mexa64
11) rm ../examples/FAST_SFunc.mexa64
12) éditez et exécutez create_FAST_SFunc.m (pour garantir des options correctes pour linux built_with_visualStudio = false et installDir = '../../../install; )
13) cp ./FAST_SFunc.mexa64 ../examples/
14) exécuter Run_OpenLoop.m avec la turbine AOC_WSt

J'obtiens la sortie suivante dans matlab

OpenFAST-v2.4.0-133-gb913c945-dirty
 Compile Info:
  - Compiler: GCC version 9.3.0
  - Architecture: 64 bit
  - Precision: double
  - Date: Jan  5 2021
  - Time: 21:12:45
 Execution Info:
  - Date: 04/26/2021
  - Time: 11:16:55-0500

et la même erreur
% % % % % % % % % % % % % % % % % % %
Erreur lors de l'utilisation de Run_OpenLoop (ligne 12)
Erreur signalée par la fonction S 'FAST_SFunc' dans 'OpenLoop/FAST Nonlinear Wind Turbine/S-Function' :
FAST_InitializeAll : IfW_ Init : IfW_UniformWind_Init : Impossible de lire la colonne de
le débit ascendant est 0.
FAST_Init ializeAll:SrvD_Init :SrvD_ ReadInput:ReadPrimaryFile :Entrée logique non valide pour le fichier
"../../../reg_tests/r-test/glue-codes/openfast/AOC_WSt/AOC_WSt_ServoDyn.dat" s'est produit lors de la tentative de lecture
CompNTMD.
% % % % % % % % % % % % % % % % % % %

Je suis surpris que les informations de version n'aient pas changé. Que renvoie git describe --tags ? Je m'attends à voir quelque chose comme v2.5.0-1017-g216bccbf8

Aussi, pouvez-vous faire find /usr -name *openfast* ?

Notez également que la date de compilation indique Jan 5 2021 . Il n'utilise certainement pas le fichier de bibliothèque openfast que vous venez de créer.

Aussi, pouvez-vous faire find /usr -name *openfast* ?

Ah, belle prise. La sortie est

/usr/local/include/openfast
/usr/local/lib/libopenfast_prelib.so
/usr/local/lib/libopenfast_postlib.so
/usr/local/lib/libopenfastlib.so
/usr/local/bin/openfast

Je suppose qu'il donne la priorité à l'ancienne version d'OpenFAST qui a sur mon système un chemin de priorité plus élevée.
Mon mauvais, et désolé pour l'oubli.

Existe-t-il un moyen simple de supprimer OpenFAST dans /usr/local ? ou dois-je simplement supprimer tous les fichiers OpenFAST du dossier /usr ?

Je vais essayer d'exécuter la bonne version d'OpenFAST en attendant pour m'assurer qu'aucun défaut de segmentation ne se produit.

Il n'y a pas de fourre-tout, mais vous pouvez faire ces choses :

find /usr/local -name *openfast* -delete
find /usr/local -name *dyn*
# If there's something related to OpenFAST (aerodynlib, beamdynlib, etc), delete those
ls /usr/local/include
# Remove anything here related to OpenFAST

Merci à tous pour l'aide. J'ai fait fonctionner la simulation bien que j'aie eu plus de problèmes avec les bibliothèques LAPACK.

Ma compréhension après quelques lectures sur la question est qu'OpenBLAS inclut la bibliothèque 'LAPACK' mais pas 'LAPACKE' qui est nécessaire pour OpenFAST. Cela peut être corrigé avec

sudo apt install liblapacke liblapacke-dev

puis exécutez ce qui suit (dans un nouveau terminal pour éviter toute confusion)

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<path to openfast/install/lib>
export BLAS_VERSION=libopenblas.so
export LAPACK_VERSION=liblapacke.so
matlab

J'espère que cela aide quelqu'un.

Pour notre référence, quelle est l'erreur LAPACK que vous avez trouvée et corrigée en installant LAPACKE ?

Si j'utilise les options suivantes

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<path to openfast/install/lib>
export BLAS_VERSION=libopenblas.so
export LAPACK_VERSION=libopenblas.so
matlab

J'obtiens l'erreur suivante (qui a été corrigée en utilisant LAPACKE)

% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %
Erreur lors de l'utilisation de Run_OpenLoop (ligne 12)
Erreur dans 'OpenLoop/FAST Nonlinear Wind Turbine/S-Function' lors de l'exécution de la fonction C MEX S 'FAST_SFunc', (mdlStart),
au temps 0.0.
Causé par:
Erreur lors de l'utilisation de Run_OpenLoop (ligne 12)
Erreur de chargement LAPACK :
/usr/lib/x86_64-linux-gnu/libopenblas.so.0 : symbole non défini : LAPACKE_sbdsdc
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %

Je l'ai Merci.

Cette page vous a été utile?
0 / 5 - 0 notes