Cycle d’hystérésis magnétique

[invite5f15b46e]

Bonjour, je souhaite faire un programme sous fortran qui trace le cycle d’hystérésis magnétique. J'arrive à obtenir la première phase qui part de l'aimantation de saturation négative à l'aimantation de saturation positive. Mon problème est que: lorsque je fais le chemin inverse, c'est la même courbe que j'obtiens exactement, c'est à dire le champ coercitif est toujours nul alors que ca ne devrait pas être le cas. Pourriez-vous, s'il vous plait me proposer quelque chose? Merci d'avance.
Pour vous donner une petite idée de ce que je fais:
Je dois tracer l'Aimantation (M) en fonction du champ magnétique (H).

      implicit real (a-h,o-z)
      open(1,file='Aimta.dat')

      Hf=10
      Hi=-10
      pas=0.1

23     DO 10 H=Hi,Hf,pas
      ! Les calculs 
      WRITE(1,*)H,M
10   CONTINUE  ! Fin des calculs

      IF(H.GE.Hf) goto 23     ! Pour faire le chemin inverse 
      Hi=Hf
      Hf=Hi
      pas=-0.1
      IF(H.GE.Hf) goto 24    ! Pour arreter le programme. (Il ne s'arrete jamais!)
24    END

-----

[invite6dffde4c]

Bonjour et bienvenu au forum.
C’est un peu plus compliqué que ça.
Regardez :
https://en.wikipedia.org/wiki/Bouc%E..._of_hysteresis
Au revoir.

[phys4]

Bonjour,

Pour le chemin inverse, vous ne faites qu'inverser les bornes, mais pas les points.

Pour la valeur H, le couple H,M reste identique,
il faudrait faire deux boucles distinctes avec valeurs opposées de H et de M à mettre dans le graphique.

[obi76]

Bonjour,

je fais juste une parenthèse, quitte à coder en fortran, autant le faire en fortran 90 : beaucoup plus de possibilités, bien plus rapide et plus libre en écriture. De plus votre code est faux (si à la fin de la boucle, H < Hf, le code ne fait rien de plus et s’arrête). Et dans une boucle do, tout doit etre en integer (y compris le pas). Et troisième erreur, si vous faites Hi=Hf, puis Hf=Hi, alors au final ils auront tous les deux la meme valeur (celle de Hf avant ces opérations). Pour intervertir la valeur de deux variables, il faut passer par une troisième :

buffer = Hi
Hi = Hf
Hf = buffer


Cordialement,

[A voir en vidéo sur Futura]

[invite5f15b46e]

Bonjour,
Je vous remercie infiniment pour toutes vos remarques et suggestions (#obi76, #phys4, #LPFR). Maintenant j'arrive à faire le chemin inverse sans problème. Voici ce que j'ai fait (Peut-être que je dois encore faire des corrections?):

           implicit real (a-h,o-z)
           open(1,file='Aimta.dat')

      Hf=10
      Hi=-10
      pas=1

23     DO 10 H=Hi,Hf,pas

         ! Les calculs 

        WRITE(1,*)H,M

        IF(H.EQ.Hf) THEN      ! Pour faire le chemin inverse
        H0=Hi
        Hi= Hf
        Hf=H0
        pas=-1
        goto 23
        endif
10    CONTINUE  ! Fin des calculs

      IF(H.EQ.Hf) goto 24    ! Pour arreter le programme.
24    END

Encore merci pour votre aide.

[invite6dffde4c]

Bonjour.
L’égalité entre réels n’est jamais garantie dans un programme.
Au lieu de tester l’égalité, il faut tester si la valeur absolue de leur différence ou de leur différence relative est assez petite.
Au revoir.

[obi76]

Re-,

alors pour votre programme :
- le "GOTO 23" ne sert à rien. Si vous ne le faites pas, vous sortez du if et vous retournez là haut
- vous ne pouvez pas changer le pas, la valeur de départ ou d'arrivée d'un DO dans la boucle
- la manière dont vous avez codé risque planter : une boucle qui se relance elle meme, ça risque de faire des boucles infinies
- il faut SURTOUT éviter les GOTO : c'est moche, et en plus les compilateurs ne savent pas faire d'optimisation lorsque votre code en contient

@LPFR : l'égalité concerne des entiers, donc à priori pas de soucis de ce coté là. Cependant je ne vois quand meme pas ce que le code est censé faire...

[invite6dffde4c]

Bonjour Obi76.
Non. Les ‘h’ sont des réels :
implicit real (a-h,o-z)
Il faudrait que les noms commencent par i, j, k, …, n pour qu’ils soient des entiers.
Cordialement,

[invite6dffde4c]

Re.
Je suis d’accord que trop des GOTO rendent un programme illisible.
Mais utilisés pour des cas particuliers (erreurs, rupture de séquence, etc.) ils peuvent, au contraire, rendre le programme plus lisible.
Je crois que, comme pour l’alcool, quelques GOTO ça va. Trop : bonjour le sac de nœuds.

Je pense que le conseil de bonne programmation sur lequel on n’insiste jamais assez est celui des commentaires. Sans assez de commentaires on n’arrive pas à se retrouver quelques semaines plus tard.
A+

[stefjm]

Je suis d’accord que trop des GOTO rendent un programme illisible.
Mais utilisés pour des cas particuliers (erreurs, rupture de séquence, etc.) ils peuvent, au contraire, rendre le programme plus lisible.

try catch en programmation moderne

Je pense que le conseil de bonne programmation sur lequel on n’insiste jamais assez est celui des commentaires. Sans assez de commentaires on n’arrive pas à se retrouver quelques semaines plus tard.

+ nom explicite pour les données avec préfixe de type pour savoir de quoi l'on cause...

[phys4]

Je ne comprends pas comment cette boucle s'arrête, elle est relancée à chaque fois pour le IF !!!!

D'accord avec obi pour la modification à l'intérieur de la boucle, c'est une chance si le compilateur l'accepte.
Il suffit de mettre le changement des bornes en sortie de boucle.

[stefjm]

Je ne comprends pas comment cette boucle s'arrête, elle est relancée à chaque fois pour le IF !!!!
D'accord avec obi pour la modification à l'intérieur de la boucle, c'est une chance si le compilateur l'accepte.

En C et assimilé, c'est accepté et donc très casse gueule...

[obi76]

Re-,

Bonjour Obi76.
Non. Les ‘h’ sont des réels :
implicit real (a-h,o-z)
Il faudrait que les noms commencent par i, j, k, …, n pour qu’ils soient des entiers.
Cordialement,

Dans ce cas on ne peut pas les utiliser comme variables dans la boucle DO... La compilation ne passe pas chez moi (et c'est normal).

[invite6dffde4c]

Re.
C’est vrai que, en regardant le programme de près, on peut dire qu’il est bourré d’erreurs de Fortran.
Je pense que Bidright devrait s’entraîner avec des programmes de problèmes banals pour apprendre le langage, avant de s’attaquer à des problèmes qui le sont vraiment en dehors de la programmation.
A+

[invite5f15b46e]

Bonjour à tous,
A propos de la boucle DO, que puis-je faire si je désire avoir un pas inférieur à 1 (Vu que "dans une boucle do, tout doit être en integer (y compris le pas)")?

Peut-être une explication sur le fait que la boucle s'arrête: "Au début, elle part de Hi=-10 à Hf=10. Ensuite lorsqu'elle arrive à Hf=10, donc au niveau de IF, elle est relancée et part désormais de Hi=10 à Hf=-10. Lorsqu'elle arrive une nouvelle fois sur IF, elle ne rencontre plus la condition Hf=10, car elle s'est arrêtée à Hf= -10. Ainsi elle peut s’arrêter, aussi grâce à GOTO 24" !!

Pour information, le code marche chez moi tel que je vous l'ai présenté (J'ai utilisé I, Ii et If au lieu de H, Hi et Hf; Software: Force 2.0, Fortran 90!)! Mais, je préfère avoir un code sans erreurs qui me donne des résultats sûrs.

En même temps la programmation n'est pas mon domaine (Pas une excuse). Mais, je dois terminer un projet, et un code sous Fortran m'est exigé. J'ai encore 1 mois avant de le rendre. Quelqu'un peut-il me proposer un bon cours ou un lien pour apprendre l'essentiel dans le langage, s'il vous plait?

Merci encore pour vos remarques et conseils.

Cordialement,

[obi76]

Pour information, le code marche chez moi tel que je vous l'ai présenté

Ca sent le compilateur micro$oft à plein nez. La norme de base de Fortran empeche ed compiler au moins pour 3 raisons que je vous ai cité. Et pour maitriser le fortran, je vous garantis que MEME si un compilo accepte tout ça, votre résultat donnera n'importe quoi (ajouter 0.1 à un integer dans une boucle DO, comment dire... que c'est un compilateur de m**** ?). J'utilise un compilateur fortran serieux, et meme sans les options restrictives d'erreurs comme il y en a des centaines, dès le départ il me dit non.

Clairement, vous devez apprendre le fortran, comme l'a dit LPFR, en commençant par la base, et complexifier ensuite; Maitriser ce langage,ça se fait sur plusieurs années (comme tous les langages). Ca, par exemple, c'est un code fortran bien écrit : http://forums.futura-sciences.com/ph...ml#post4986958, ou encore ça : http://forums.futura-sciences.com/sc...ml#post4745815 (et encore, on peut pas mal les améliorer). Vous constaterez que ça n'a rien à voir.

PS : compilez avec un vrai compilo aussi, au moins il décèlera des erreurs qui vous aideront, pas un compilo comme ça. La pour le coup ça m'épate qu'un compilo soit capable de laisser passer des trucs aussi gros... Comme on dit "Un mauvais ouvrier a toujours de mauvais outils." En un mot : oubliez ce compilo.

[stefjm]

Edit : croisement Obi76
Vous faites une boucle sur integer (pour faire, faire tant que ou tant que faire) et vous multiplier cet entier par le pas.

[stefjm]

PS : compilez avec un vrai compilo aussi, au moins il décèlera des erreurs qui vous aideront, pas un compilo comme ça. La pour le coup ça m'épate qu'un compilo soit capable de laisser passer des trucs aussi gros... Comme on dit "Un mauvais ouvrier a toujours de mauvais outils." En un mot : oubliez ce compilo.

C'est la mode actuelle : Si ça compile, ça marche.

Les compilos $ ont toujours été très permissifs pour ne pas embêter les programmeurs débutants (Par ex, VB permettait de ne pas déclarer les données, autorisait les boucles avec flottant, avait une option pour compter les cases de tableaux à partir de 1 ou de 0), de vraies merdveilles...

[obi76]

(Par ex, VB permettait de ne pas déclarer les données, autorisait les boucles avec flottant, avait une option pour compter les cases de tableaux à partir de 1 ou de 0), de vraies merdveilles...

Génial ça pour le passage à l'échelle mémoire... Enfin bon le jour ou on fera du HPC avec VB, effectivement on pourra se poser la question

[invite6dffde4c]

Bonjour.
En principe, rien n’oblige une boucle à utiliser des entiers. Le langage C et le Basic n’en ont pas besoin. Et le Basic ne connaît pas les entiers. Il travaillait et digital codé binaire pour toutes les variables.
Donc, que les Fortrans actuels acceptent des réels n’a rien d’aberrant.
Au revoir.

[stefjm]

En principe, rien n’oblige une boucle à utiliser des entiers. Le langage C et le Basic n’en ont pas besoin.

Je sais le C très permissif, mais je ne pense pas qu'on puisse utiliser un float pour une boucle for. (char ou int)

[pm42]

Je sais le C très permissif, mais je ne pense pas qu'on puisse utiliser un float pour une boucle for. (char ou int)

Si puisqu'en C, la boucle est "généraliste" : initialisation; condition de fin; opération

[obi76]

Donc, que les Fortrans actuels acceptent des réels n’a rien d’aberrant.

En tous cas, ce n'est pas dans la norme IEEE, et TOUS les compilos que j'ai essayé (à part celui de microsoft) refusent ça. Sans doute pour la meme raison que la comparaison entre 2 réels sont assujettis aux erreurs d'arrondi, comme vous avez dit, ce qui fait que le nombre exact d'itérations dans une boucle FOR gérée par des réels est difficilement maitrisable.

[stefjm]

Si puisqu'en C, la boucle est "généraliste" : initialisation; condition de fin; opération

Logique effectivement et sacrément casse gueule.

[invite6dffde4c]

Bonjour.
J’imagine que ces conversations sur les mérites et les méthodes des langages et de la programmation doivent ennuyer Bidright

N’importe quel langage permet de programmer n’importe quoi, avec plus ou moins de facilité (je pense aux complexes et Fortran).
On vous a demandé d’écrire le programme en Fortran. Est-ce qu’on vous a fixe des exigences particulières ?

Si non. Vous pouvez programmes en n’importe quel Fortran, même en Fortran 2 (chiant).
Vous demandiez un manuel. Voici un tutoriel pour Fortran 77 :
https://www.google.fr/url?sa=t&rct=j...,d.d2s&cad=rja
Il n’est pas trop lourd ni trop chargé de théorie inutile (je l’ai regardé en diagonale). Il a l’air alimentaire.
Au revoir.

[invite5f15b46e]

Bonjour,

Vous faites une boucle sur integer (pour faire, faire tant que ou tant que faire) et vous multiplier cet entier par le pas.

Je pourrais ensuite passer d'un entier à un réel...Donc le résultat va être stocker dans un compteur réel! Mais j'aurais seulement au tant de sorties réelles que entieres, et si je veux faire les calculs directement avec un pas par exemple égal à 0.1?

[phys4]

En programmation FORTRAN on utilise un indice entier, par exemple par pas de 1, et ensuite on utilise l'index pour le multiplier par le pas réel, ce qui donne la valeur de base que l'on a besoin dans la boucle.

La variable de pas ne sert ainsi que d'index, à partir duquel se font tous les calculs.

J'ai aussi utilisé des compilateurs C avec des valeurs réelles, mais dans ce cas je mettais une limite de fin de boucle légèrement supérieure, afin qu'il n'y ait pas d’ambiguïté sur le test de fin de boucle. Je déconseille aussi de commencer de cette façon.
Bon travail.