Il n'y a aucune fonction spécifique pour le 'dde_solver' générique

J'essaye d'employer le solveur de DDE pour ex4p4p1.f90 disponible de radford en utilisant le Fortran90 sourcedde_solver_m_unix.f90. Je crois que je devrais pouvoir simplement télécharger et compiler avec zéro changements mais j'obtiens l'erreur suivante:Il n'y a aucune fonction spécifique pour le 'dde_solver' générique

ex4p4p1.f90:107:8: 

    SOL = DDE_SOLVER(NVAR,DDES,DELAYS,HISTORY,TSPAN=(/ 0D0,350D0 /)) 
     1 
Error: There is no specific function for the generic ‘dde_solver’ at (1)

Pour complètement (et simplement) reproduire, je l'ai écrit un petit script qui va télécharger , extraire et compiler la source:

#!/usr/bin/env bash 

### Download and extract solver 
dde_solver_url=http://www.radford.edu/~thompson/ffddes/dde_solver_m.zip 
wget $dde_solver_url 
unzip dde_solver_m.zip 

### Download main routine 
example_code_url=http://www.radford.edu/~thompson/ffddes/ex4p4p1.f90 
wget $example_code_url 

### Compile 
gfortran dde_solver_m_unix.f90 ex4p4p1.f90

Depuis que je crois que ces fichiers sont écrits comme des exemples de « drag and drop », je crois qu'il peut être un problème avec mon environnement ou peut-être que je suis mal la compilation.

Y a-t-il des problèmes avec la façon dont je compile? Si non, quelles modifications minimes puis-je apporter au (1) code du pilote (ex4p4p1.f90) pour que cela fonctionne ou (moins souhaitable) (2) le code du solveur (dde_solver_m_unix.f90)?

Source

2017-10-15 drjrm3

Ce serait beaucoup mieux de nous montrer ce code. C'est probablement faux. Je ne pense pas que ce soit quelque chose de changeable par une autre méthode de compilation, à moins qu'il y ait un pré-traitement quelque part ou que vous changiez le type réel ou entier par défaut pour une partie seulement du code. –

Le fait qu'ils ont besoin d'une source spécifique Unix est suspect. Fortran est normalement assez portable. –

Et étant donné qu'il n'y a pas de "IMPLICIT NONE" dans le module de solveur, je ne vais pas aller plus loin. Si vous voulez en savoir plus, trouvez la fonction spécifique appropriée et vérifiez tous les arguments un par un. Il faudra peut-être «-freal-8» ou quelque chose comme ça, mais qui sait. –

Les blocs INTERFACE utilisés lors de la définition des fonctions DKL_ * spécifient que les arguments 2, 3 et 4 de DDES doivent être considérés comme des tableaux de forme. Cependant, ex4p4p1 a DDES défini a les arguments 2, 3 et 4 comme étant des tableaux qui sont fixés au moment de la compilation. Cela provoque une certaine confusion avec le compilateur Intel, et pourrait aussi être ce qui se passe avec gfortran. Essayez d'utiliser

DOUBLE PRECISION, DIMENSION(:) :: Y,DY 
DOUBLE PRECISION, DIMENSION(:,:) :: Z

au lieu de

DOUBLE PRECISION, DIMENSION(NEQN) :: Y,DY 
DOUBLE PRECISION, DIMENSION(NEQN,NLAGS) :: Z

dans le bloc d'interface pour DDES. Bonne chance.

Source

2017-10-16 12:55:23

Cela ne devrait pas être un problème en soi. Il est parfaitement légal de passer un tableau statique à un argument de forme supposé. Mais le code n'est pas écrit de manière agréable. En outre, les rapports d'arclight fonctionnent réellement avec Intel. Quel genre de problème ou de confusion voyez-vous avec Intel? –

Si je ne fais pas la modification ci-dessus, je reçois la plainte suivante d'Intel Composer XE 2017: erreur # 7062: Les caractéristiques de l'argument factice 2 de la procédure réelle associée diffèrent des caractéristiques de l'argument factice 2 de la procédure factice. [DDES] –

Et notez que vous ne pouvez pas simplement changer la définition d'un bloc d'interface! Avez-vous exécuté le code? C'est une sorte de changement qui devrait normalement conduire à un crash. –

Il n'y a aucune fonction spécifique pour le 'dde_solver' générique

Répondre

Questions connexes