erreur fonction write

Version imprimable

Bonjour,

je travaille sur un code qui comporte des fonctions C et fortran. A l'aide d'une fonction write (appelée à la ligne 61 de la fonction suivante), je souhaite continuer l'écriture d'un fichier. Voici la fonction:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 subroutine ecrcont(uncont,iele,ipts,icou,iptz,ncomp, & sigkir,epslag,err) ce ce Appele par : celiso, sauvnc, sauvcv ce ---------- ce Objet : ecriture des contraintes et des deformations sur fichier ce ----- ce ce .......................................................................... ce ce Entree : ce ------ ce uncont : numero d'unite du fichier des contraintes ce ncomp : numero du type de la loi de comportement (0 --> fin de fichier) ce sigkir() : contraintes de Kirchhoff ce epslag() : deformations de Green ce ce Sortie : err : indicateur d'erreur ce ------ ce ce Erreurs : ce ------- ce ce .......................................................................... ce implicit none c c --- variables globales --- c ------------------ include 'message.dec' c c --- Arguments d'entree --- c ------------------ integer uncont integer ncomp integer iele,ipts,icou,iptz real*8 sigkir(6),epslag(6) c c --- Arguments de sortie --- c ------------------- integer err c c --- variables locales --- c ----------------- integer i,ios character *10 routine character *80 fic c c --- sous-programmes appeles --- c ----------------------- external damxmess, damsvc err=0 routine='ecrcont' c c ci ce format n'est plus util en binaire ci garder pour info ci12 format(i7,12(1x,e15.8),4(1x,i7)) write(uncont,err=29,iostat=ios) ncomp, & (sigkir(i),i=1,6),(epslag(i),i=1,6), & iele,ipts,icou,iptz c return c ce *** Erreurs *** ce ------- 29 message='erreur_ecriture' call damxmess(message,'x',80,0,0) call damsvi('iostat',ios,0,0,0,0) call damsvi('unite logique du fichier',uncont,0,0,0,0) inquire(unit=uncont,name=fic) call damsvc('Nom du fichier',fic,0,0,0,0) call damsvc('routine',routine,0,0,0,0) err=2 return c end
Cette fonction est appelée ainsi, dans un fichier rédigé en C:

Code:

ecrcont(uncont,pnumelt,&n,&c__1,&c__2,&numtyp,sig,eps,&err);

MON PROBLEME: L'écriture dans le fichier se passe correctement. Malgré cela, plutôt que de sortir classiquement de ecrcont grâce au return de la ligne 65, le code parcours le paragraphe suivant "29" dédié au message d'erreur. La variable iostat est égale à 101, ce qui semble correspondre à:

Integer,Parameter :: IOERR_INTERNAL_FILE_OVERFLOW = 101
Internal file overflow

QUESTION: A quoi peut être dû un renvoi au paragraphe d'erreur alors que la fonction fait son office ?

REMARQUES:

Quelques affichages à l'écran me renseignent sur la valeur des arguments d'entrée dans la fonction ecrcont:
Code:

1 2 3 4 5 6 7 8 uncont = 100 *pnumelt = 5641 n = 1 c__1 = 1 c__2 = 2 numtyp = 200 sig[0] = 22.000000 sig[1] = 22.000000 sig[2] = 22.000000 sig[3] = 22.000000 sig[4] = 22.000000 sig[5] = 22.000000 sig[6] = 22.000000 eps[0] = 27.000000 eps[1] = 27.000000 eps[2] = 27.000000 eps[3] = 27.000000 eps[4] = 27.000000 eps[5] = 27.000000 eps[6] = 27.000000
Merci d'avance pour votre aide

Anthony

27/01/2012, 02h01
anacharsis

salut !

Citation:

L'écriture dans le fichier se passe correctement.

tu es sûr que le fichier binaire résultat est bien correct ? l'ordre des paramètres dans les lignes 62 et 63 me semble douteux et ce write en ligne 61 ressemble bien à un appel avec format et options mais il n'y a plus de format ...
mais je n'ai jamais programmé en fortran !

A+

Bonjour, merci pour cette réponse.

Le fichier de sortie finale ressemble à ça: (j'ai mis 3 lignes sur les milliers de lignes qu'il fait). Mes variables, que ce soit des entiers, des réels, stockées en tableau ou non, sont bien affichées dans l'ordre souhaité. Elles correspondent aux données d'entrée de la fonction write.

Code:

1
2
3
4
2
     200  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01     8583        1        1        2
     200  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01     8584        1        1        2
     200  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.20000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01  2.70000000E+01     8585        1        1        2

Question format et option de la fonction write, j'avoue que je perd pied aussi car je programme en C et ce code en fortran n'est pas le mien.

27/01/2012, 12h32
anacharsis

en regardant d'un peu plus près, j'ai cherché en vain un external ecrcont et un call ecrcont(...) pour déclarer et appeler la fonction C. mais je ne crois pas qu'on puisse lui donner le même nom.

A+
30/01/2012, 09h43
Anthony_CTI

J'ai appelé la fonction de cette façon car elle est déjà appelée ainsi dans une autre partie du code. La phase de déclaration de la fonction et la compatibilité fortran/C est assurée dans d'autres fichiers que je n'ai pas jugé nécessaires de présenter car ecrcont fonctionne bien dans d'autre branches similaires du code. La seule chose qui change entre ma branche qui ne fonctionne pas et les autres, ce sont les variables d'entrée qui doivent être imprimées dans le fichier de sortie.
30/01/2012, 12h07
souviron34

C'est un fichier ouvert en Fortran ?

Il est séquentiel ou à accès direct ?

En Fortran un fichier peut être à accès direct (via le RECORD=)
30/01/2012, 14h08
anacharsis
les lignes 61 à 63, qui ne sont pas commentées, correspondent à l'appel du write FORTRAN et pas à l'appel d'un fonction C externe.
Code:

1 2 3 write(uncont,err=29,iostat=ios) ncomp, & (sigkir(i),i=1,6),(epslag(i),i=1,6), & iele,ipts,icou,iptz
A+
30/01/2012, 14h18
souviron34

:ccool:

oeil de lynx
30/01/2012, 14h34
Anthony_CTI

Il est possible que l'erreur vienne de la création de ce fichier de sortie. Je code peu en fortran: je comprends que la variable ecrcont permet d'accéder à ce fichier. Je suppose qu'il à été ouvert/créé en amont mais je n'ai pas mis la main sur cette portion de code. Avant que j'apporte des modifications, ce fichier existait déja et était rempli gra^ce à plusieurs passage dans la fonction ecrcont
30/01/2012, 14h39
Anthony_CTI

Je soupçonne une portion de code dédiée à la création de ce fichier qui demande rait à être modifiée dès lors que des lignes supplémentaires y sont rajoutées. Il faudrait que je trouve quand est créé le fichier en question si tant est qu'il existe...
30/01/2012, 15h13
souviron34

bon là tu as une routine Fortran...

Si cette routine fonctionne bien ailleurs, c'est qu'il y a un problème en amont...

Alors soit effectivement le fichier n'est pas ouvert de la même façon (voire il est fermé par une routine avant) dans ton cas que dans les autres, soit il y a un problème de dimensions ou de contenu d'un des paramètres..

Qu'as-tu utilisé (en C) pour les paramètres REAL*8 ?

Reprend exactement une fonction qui marche en l'appelant, et regarde les différences avec ton appel...
30/01/2012, 15h23
anacharsis

oups !

Citation:

je comprends que la variable ecrcont permet d'accéder à ce fichier.

plutôt uncont non ?

A+
30/01/2012, 15h24
Anthony_CTI

Exact :D
30/01/2012, 15h33
souviron34

:aie:

eh oui..

En Fortran, un "fichier" est une Unité Logique (comme une imprimante, un lecteur de bandes, un lecteur de DVD, etc)..

D'où l'appelation Unité.

Et comme Fortran utilise des entiers pour les distinguer, en général le corps de la varaible s'aplle unit..

quand on utilise les "implicites" on utilise par exemple iunit, et quand on met "implicite none", unit..

Dans ton cas, ça a été tronqué, mais c'est bien ça..
:D

Voici la fonction dans laquelle a toujours été appelée ecrcont:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 INT defconpu(INT *uncont, INT numtyp,INT iele,REEL *Fl,REEL *caraelempou, REEL *travR) { char *routine="defconpu"; INT n=1,error; REEL *eps,*sig; /* Initialisation -------------- */ eps=travR; sig=&travR[6]; sig[1]=eps[1]=sig[2]=eps[2]=sig[4]=eps[4]=sig[5]=eps[5]=c__zero; sig[0]=sig[3]=Fl[0]/caraelempou[0]; eps[0]=eps[3]=sig[0]/caraelempou[1]; /* sauvegarde */ //___________________________________________________________________ printf("%d\t%d\t%d\t%d\t%d\t%d\t%d\t%f\t%f\t\n",*uncont,uncont,iele,n,c__1,c__2,numtyp,sig[0],eps[0]); //___________________________________________________________________ ecrcont(uncont,&iele,&n,&c__1,&c__2,&numtyp,sig,eps,&error); if (error) { dammsg(ERR_ECRCDSEC_,&n,routine); return(-1); } return(0); }
Les arguments sont soit des constantes entières (uncont, iele, n, c__1, c__2, numtyp, error) soit des tableaux de 6 réels (sig et eps)

Sur ce constat j'ai choisi de rappeler la fonction ainsi:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 REEL eps[6],sig[6]; for(i=0;i<6;i++)eps[i]=27; for(i=0;i<6;i++)sig[i]=22; INT n=1,err; char *routine="celress"; /* printf("uncont = %d(%d)\n",*uncont,uncont); //printf("iele = %d\n",iele); printf("*pnumelt = %d\n",*pnumelt); printf("n = %d\n",n); printf("c__1 = %d\n",c__1); printf("c__2 = %d\n",c__2); printf("numtyp = %d\n",numtyp); for(i=0;i<6;i++)printf("sig[%d] = %f\t",i,sig[i]); printf("\n"); for(i=0;i<7;i++)printf("eps[%d] = %f\t",i,eps[i]); printf("\n"); */ ecrcont(uncont,pnumelt,&n,&c__1,&c__2,&numtyp,sig,eps,&err); // printf("err = %d\n",err); if (err) { dammsg(ERR_ECRCDSEC_,&n,routine); return(-1); } }
J'ai pris soin de vérifier la disponibilité de chaque donnée d'entrée en les imprimant avec succès avant l'appel de ecrcont. Je pars aussi un peu du principe que si un type de mes données d'entrée ne collait pas avec la déclaration faite dans le prototype de la fonction, je serais prévenu à la compilation.

Malgré tout, j'ai confiance :

-dans les constantes globales (c__1 et c__2)qui sont déclarée en tout début de programme.
-dans les entiers n et err qui ne présentent aucune ambiguïté/difficulté
-dans numtyp, qui est appelé de la même façon dans les deux cas

un peu moins confiance:
-en sig et eps dont l'espace mémoire est attribué différemment
-en pnumelt, auparavant iele, passé comme argument de manière un peu différente

La question qui me vient: Est-ce qu'une erreur dans le passage d'un de ces arguments permettrait quand même l'impression correcte du fichier de sortie comme c'est le cas !?

Autre question: Est-ce qu'une fermeture "anticipée" du fichier de sortie permettrait quand même son remplissage comme c'est le cas ?! A ce sujet, j'ai trouvé les fonctions d'ouverture et de fermeture du fichier de sortie. Je vais vérifier la bonne chronologie de leurs appels...

30/01/2012, 17h20
anacharsis

ça n'a peut-être rien a voir, puisque c'est un commentaire

Code:

for(i=0;i<7;i++)printf("eps[%d] = %f\t",i,eps[i]);

mais, des fois ...

A+
30/01/2012, 17h34
Anthony_CTI

A un moment, J'ai changé la dimension de mes tableaux pour évaluer l'influence d'un tel changement. Une des boucles for a en effet échappé au retour à la dimension 6 de mes tableaux, mais tu as raison, ça n'a pas d'importance car ce paragraphe est commenté depuis un moment. :D
30/01/2012, 18h49
souviron34

par contre, fait attention qu'en Fortran les tableaux 2D sont inversées : on boucle le plus profond sur les lignes, au dessus sur les colonnes, au contraire du C..