******************************************************************************** ******************************************************************************** ******* Dictionnaire des instructions du ZOOM DESIGN LANGUAGE ****************** ******************************************************************************** ********************************* (mise à jour le vendredi 30/01/1998 Al1) ***** ****** Futura feature : tout ce qui concerne *TrName* (Al1, mercredi 05/08/1998) ******************************************************************************** Cette entrée du manuel ZDL est celle de $ZOOM/Help/Users/Zinit/ZDL/Zdl.html; Pour chaque groupe d'instructions, on trouvera un complément soit sous forme hypertexte dans le fichier réferencé dans Zdl_html.dir/XXX < et repéré par ce signe "<", soit en annexe du texte imprimé. ******************************************************************************** ******** Préliminaires pour faciliter l'utilisation du dictionnaire *********** ******************************************************************************** Le ZDL est un language programmable et permet l'utilisation des instructions Fortran ou Mortran de base. L'interprétation de Zinit donnera une Subroutine ZINIT avec un point d'entrée ZSTEER. La subroutine est appellée une seule fois en tout début du Run. ZSTEER est appelé à chaque nouvel incrément (temporel en dynamique ou itération en stationnaire). Remarque : la notion de language interprèté génèrant une routine éxécutable peut mener à des difficultés de compréhension des contingences d'écriture; en cas d'ambiguité, nous préciserons dans le texte les notions : d'avant - après, en les qualifiant de : - séquencielles : il s'agit alors d'ordre des instructions elles-mêmes dans le corps du Zinit; - a l'éxécution : il s'agit alors de l'ordre dans lequel vont être éxécutées les instructions; La différence entre les deux étant d'autant plus grande que les instructions de déroutage du Fortran seront nombreuses (programmation dite "spaghetti"). Notons au passage que de nombreuses instructions et blocs logiques Mortran permettent de structurer le corps du programme (Do while, Until, Case, if then else etc). Fonctions du Zinit : ==================== Il a pour premier but de créer la structure dite de l'Arbre ZOOM, qui est constituée d'un emboîtement de FAMILLES ayant des objets terminaux dits CELLULES. On remarquera qu'il s'agit de créer un programme créant une structure et non de décrire de manière déclarative cette structure; cela permet en particulier une grande souplesse, puisqu'on peut alors : - utiliser des boucles pour créer des structures répétitives, des emboitements, etc; - programmer sa modification apres création (cf MOVE, GET, FREEZE); - appeler des procédures de créations/instanciations communes à plusieurs objets; Ensuite de relier les cellules à des TRANSFERTS (ou par des transferts : deux facons de dire et de faire mais une seule même structure créée). Il doit - à chaque création de transfert ou cellule - associer un MODèLE à l'objet créé (TYPE=); chaque instruction CREATE constitue donc une instanciation (d'un objet à partir d'un modèle); il s'y associe donc l'attribution de valeurs numériques à certains paramètres libres du modèle et, pour les cellules uniquement (de manière obligatoire) une initilisation du vecteur d'état (fill_Eta). Une partie plus subtile de l'instanciation concerne leur insertion dans une structure : celle ci héritera des connections entre objets (C-PLUG T-PLUG, CONNECT, JOIN TO) Enfin, une tâche (plus classique) est d'attribuer des valeurs aux paramètres du Run : gestion de l'incrément temporel, des niveaux et fréquence de sauvegarde des résultats de calculs, redémarrage de run etc. Ecriture du Zinit : =================== Deux types de blocs logiques sont utilisés dans ce language. Le bloc standard de Mortran - emboîtable - <;>, associé aux instructions NEXT; et EXIT; il est ici mis a profit pour décrire la structure emboitée des cellules/familles. => celà donne un sens fort à la structure, puisqu'un bloc logique n'a d'existence que SITUÉ dans la structure; Un bloc implicite qui détermine une adresse courante dans la structure; tout attribut sous forme de symbole Fi Eta [Paramètre] est attribué à l'objet courant de même nature : famille, cellule ou transfert tant qu'une instruction n'en change; instructions changeant l'objet courant : ---------------------------------------- under< change de Famille courante (celle sous laquelle seront placées les familles ou cellules suivantes); >; ferme le bloc logique préecédent et restore la famille courante séquenciellement précédente; create CL, get *ClNam* ; change de Cellule courante; create TR, get Tr *TrName*; change de Transfert courant; Métasymboles utilisés : *NamObj* pour nom d'objet à choisir par l'utilisateur. ====================== {*Valeur*} Valeur optionnelle. " texte " tout texte entre " " (symbole des commentaires Mortran) est hors ZDL. |Instruction| : permet d'identifier une instruction dans un texte (ou un mot réservé du ZDL). remarque : ces meta symboles ne seront utilisés que s'il y a ambiguité. Vocabulaire : ============= Bloc logique : voir plus haut (<;>). Position courante : voir plus haut. Instructions spécifiques : certaines instructions qui ne peuvent être utilisées que dans certains blocs logiques (cf Fill_CD<;); Bank : nous conservons ce nom pour designer un bloc de données géré par ZEBRA, pour eviter la confusion avec le Bloc au sens logique. Liste des Métasymboles utilisés : ================================= *NamFm* : nom de Famille (Fm); *NamCl* Cellule (Cl); *NamObj* : Cl ou Fm; *NamObj* : se décompose en deux champs *Nam* - *Code* où *ClNam* est une suite d'au plus 5 Character Fortran et *Code* un integer Fortran; les deux champs etant séparés par la copule : - . *AddObj* : permet de creer une adresse universelle associee a un nom d'objet DANS l'arbre ( pour eviter d'y referer via son adresse complete : /z/u/*NamFm*/.../*NamObj*) Universels dans le sens où ils sont reconnus de n'importe quelle famille courante; *NamTr* : donne un nom au transfert courant, qui pourra etre ré-appelé, ou invoqué pour connection Tr à Tr; *ChFTNVar*: Variable Character FTN (par defaut, Character*4) *Code* : integer ajoutant un numero a un symbole; (on utilise aussi *CodFm* et *CodCl*,*CodPlg* pour Futura); *CPlug* : *NamCl*,*NamPlug* (un C-Plug est toujours associe au nom de sa cellule) *NamPlug* : *CodPlg* (integer) Futura : *NamPlug* = *NamPlug* - *CodPlg* for C-Plugs only (comme donc *NamCl* et *NamFm*); atention, Char*4 (au lieu des 5 possibles pour Cl et Fm); *VarList* : une liste d'integers Fortran; syntaxe : (int1,int2,int3,etc) ou (int1 thru int2) qui prend la suite des entiers naturels croissants de int1 a int2. ******************************************************************************** ******** Création d'objets de la structure Familles - Cellules ***************** ******************************************************************************** Zdl_html.dir/Fm_Cell_Create < ; Familles Obligatoires : CREATE ZEUS; CREATE UNIVERSE; Autres familles : CREATE FM *NamFm* - *CodFm*; CREATE FM *NamFm*; Equivalent à CREATE FM *NamFm* - 0; CREATE FM=*ChFTNVar* - *CodFm*; Cellules : CREATE CL *NamCl* - *CodCl* , TYPE = *TypProc , I1, I2, I3; Complément : CREATE N-CL ... FREEZE *NamCl* - *CodCl*; SET FM TYPE:T; Instruction obligatoire et inutile, qui prétend declarer que la famille courante est de type Transfer, et donc que l'on y éliminera les variables d'état - ce qui est exact. L'instruction duale Set Fm Type:S, devrait alors conduire a l'élimination des variables de transfert (non implémenté); ******************************************************************************** ******** Création des Transferts (Objet dual, ou de connection entre cellules) * ******************************************************************************** Zdl_html.dir/Transfer_Create < Naturelle : CREATE TR,TYPE=*TrProc* 1,-9,-9; et gelée : CREATE N-TR,TYPE=*TrProc*; Imposée : CREATE-F TR CREATE-F+ TR CREATE-Z TR CREATE-U TR et gelée : CREATE-Z N-TR,TYPE=*TrProc*; ******************************************************************************** ********* Marque d'objets et de leur position dans la structure **************** ******************************************************************************** Zdl_html.dir/Object_Address < SET *AddObj* = *ObjetDéjàCréé* ; SET *AddObj*(*Indice*) = *NamObj*; SET *AddObj* == *ChFTNVar*; *ChFTNVar* est une variable Fortran CHARACTER*N contenant le *NamObj*; On peut séquentiellement ré-affecter ces symboles universels : RESET *AddObj* = *NouvelObjet* ; exemples : .......... Set MaCl = Z.U.Nord-2.Piece.Mur-4; Set Obj(3) = Mur-4; (on les récupèrent par Get MaCl; etc) ******************************************************************************** ********* Marque de Transferts (en particulier pour connection Tr à Tr) ******** **FUTURA************************************************************************ Zdl_html.dir/Tr_to_Tr_Cx < Name Tr as : *NamTr* ; Name Tr as : *NamTr*(*Indice*) ; Ces noms sont des symboles des mêmes Table que pour SET; il faut donc affecter des symboles tous différents. exemples : .......... Name Tr as Heat(1); Name Tr as Conv; Exemples de /exos/hamb/zinit (on les récupèrent par Get Tr Heat(1); etc) ******************************************************************************** ******** Connections entre Objets élémentaires ********************************* ******************************************************************************** Zdl_html.dir/Connecting < Elles se font en trois temps : 1er temps : création d'un C-Plug sur une cellule; 2ème temps : création d'un T-Plug sur un transfert; 3ème temps : connection d'un C-Plug et d'un T-Plug, sous le transfert courant : ne peut s'effectuer qu'a la création d'un transfert, lorsque la cellule référencée a déjà été créée à l'exécution; 1&2/ Création : --------------- C-Plug : C-PLUG *CodPlg* : *VarList*; (Futura :) C-PLUG *NamPlg*-*CodPlg* : *VarList*; (Default is *NamPlg* :=PLUG) T-Plug : T-PLUG *CodPlug* : *VarList*; exemples : C-Plug n:n thru n+3; C-Plug 1:1; C-Plug 3:1,3,5,7; C-Plug 2:1 thru 7; C-Plug n:n thru n+3; Futura : C-Plug Face-1:1; C-Plug Bulk-3:1,3,5,7; C-Plug Edge-2:1 thru 7; ; 3/ Connection : Join *CodPlg1* To (*ClNam*,*CodPlg2*); --------------- forme abrégée : JOIN TO (*Cl/C-Plug*); JOIN *CodPlg* to (*NamCl*,*NamPlg*); JOIN *CodPlg* to (*NamCl*,); JOIN *CodPlg* to (CPlug1),(CPlug2); exemples : JOIN 2 TO(Mesh-4,5); Futura : JOIN 2 TO(Mesh-4,Face-5); JOIN 2 TO(Obj(3),2); Futura : JOIN 2 TO(Obj(3),Edge-2); JOIN n TO(Mesh,); :> (Mesh,1); Futura :> (Mesh(i),PLUG-1) JOIN 1 TO (Mesh(i)(Mesh(i-1); ; JOIN(I:J) TO (*CPlug*); ; 3s/ Création de T-Plug et connection contractée : CONNECT TO (*1Cl/C-Plug*,*2Cl/C-Plug*) = CONNECT 1 TO(*1Cl/C-Plug*,*2Cl/C-Plug*) CONNECT *VarList* TO (*CPlug*); Type de T-Plug particulier : T-PROBE *PlugNum*; ; ******************************************************************************** ******** Connections directe de Transfert a Transfert ************************** **FUTURA************************************************************************ Zdl_html.dir/Connecting < Join *CodPlg1* To Tr (*TrName*,*CodPlg2*); ******************************************************************************** ********* Déplacements dans la structure *************************************** ********* et modifications de la structure ************************************* ******************************************************************************** Cette facilité est particulièrement appréciée lorsque que la structure de création d'objet orientée par l'utilisation de Do loop Fortran ne satisfait pas à la structure d'emboitement des familles choisies. La première structure est alors utilisée à la création en série des objets (comme deux Do loop emboitées pour un maillage 2-D). Après création de la structure d'arbre choisie, on déplace les objets de leur famille de création à celles où on veut finalement les situer. UNDER *FmNam* < où *FmNam* est soit un nom d'objet accesible de la famille courante soit une adresse définie par SET, définit cette famille comme la famille courante; UNDER=*FmNam*< même chose avec *FmNam* rangée dans une CHAR*n Fortran variable; >; fermant un bloc logique Under ...< , la famille courante redevient celle précédent l'instruction Under ...<; GET *NamCl*; Définit *NamCl* comme la cellule courante; Cette instruction permet par exemple de séparer fonctionnellement la programmation de la création d'une structure ZOOM de celle qui instancie les cellules (initialisation d'Eta et valeurs aux paramètres du processeur associé); exemples : Get Mesh-4; Get Obj(3); Déplacement d'objets dans la structure : ======================================== ; MOVE *NamObj* TO *NamObj*; exemple : Move PIECE-I To COL-J; PIECE-I (Cellule ou Famille) est rangee sous la famille COL-J; ; Gel d'une cellule : =================== Equivalente à Create N-Cl *NamCl*..., cette instruction gèle la cellule courante : FREEZE *NamCl*; exemple : Get MESH-1; Freeze Mesh-1; ******************************************************************************** ******** Directives pour la récupération des Résultats et ********************** ******** le redémarrage d'un Run *********************************************** ******************************************************************************** $ZOOM/Help/Users/Zinit/ZDL/Zdl_html.dir/Results_Output < ******************************************************************************** ******** Directives pour sorties listing *************************************** ******************************************************************************** ********* Print Direct de la routine Zinit ************************************* ******************************************************************************** (Futura, vendredi 30/01/1998) Les nouvelles macros Z_Pr: FTN_symbols; Z_Pr : Var_List; Z_Pr/BlaBla/:...,le même avec commentaire; Z_Pad : idem, les memes avec sorties console; Z2_Pr : Var_List; sortie sur une seule ligne, pas de /blabla/ possible; attention pour les boucles Fortran implicites : Z2_PR : (d(i),i=1,2),a,b,c; ne marche pas, erreur de compil. Z2_PR : a,b,c,(d(i),i=1,2); marche. ******************************************************************************** ***** Print_out,Paw_out et Zprint_out options ********************************* ******************************************************************************** Cet ensemble d'instructions concerne la gestion des sorties gérées par Ker, d'une part, et celles que gère chaque objet ou classe d'objets (processeur). Le premier support est le "listing" ***_exe.run.lis (.lis); le second constituant l'ensemble des fichiers binaires passés a VIZU (DAT et PAR) : OZDAT.CL Contiend les valeurs de Eta,dEta et dEta,dec OZDAT.TR Fi,Omega,Delta OZPAR.CL paramètres des cellules (cf PW bank et PDL) OZPAR.TR paramètres des transferts (cf PW bank et PDL) à chaque pas de temps spécifié par Paw_out; SUPPORT .lis ============ ***Sorties gérées par Ker identifiées par le mot : Print; (routines OPTAU et OPETA) ***Sorties gérées par les processeurs : ZPrint; DEFINITION DE LA FREQUENCE ========================== print_out N times every M steps; paw_out N times every M steps; print_out once every step; print_out twice every M steps; print_out every M steps; paw_out once every M steps; paw_out twice every M steps; paw_out every step; SUPPORT DAT et PAR (pour VIZU) ============================== Elles sont entièrement gérées par Ker suivant les informations fournies par Zinit et les processeurs; identifiées par le mot : Paw; (routine OW2PAW) Note : Paw est l'acronyme d'un progiciel du CERN (Physics Analysis Workstation) au sein duquel a été programmé VIZU (ViZualisation Interface for Zoom User). STRUCTURE GENERALE DES INSTRUCTIONS DE SELECTIONS DES OBJETS DONNANT LIEU A IMPRESSION ====================================================================================== Les instructions fonctionnent selon trois règles : 1/ on fixe les valeurs par défaut en tête de ZINIT 2/ on spécifie une commande hors défaut par objet (Cellule ou Transfert) si nécessaire 3/ si on préfère globaliser ces instructions par famille, on peut le faire lorsque l'arbre ZOOM a été instancié,cad après le CALL OFRAME; Enfin, la fréquence des sorties est gérée par les instructions "print_out" pour .lis; "paw_out" pour DAT et PAR; Rq : la fréquence fixée par Print_out est appliquée aux processeurs en donnant à cette fréquence la valeur .TRUE. a Zprint(LCL) ou ZPRINT(LTR); 1/ DEFAUTS Zprint_options: Default=none Cl,none Tr,none Fm; ![ equivalent a Zprint_options: Default=none; ] Print_options: Default=none; L absence totale de ces options équivaut a une sortie complète de tous les objets de l'arbre, cad à : Zprint_options: Default=all Cl,all Tr,all Fm; [ équivalent à Zprint_options: Default=all; ] Print_options: Default=all; 2/ POUR CHAQUE OBJET CREE L'instruction : ZPrint_Tr; ou ZPrint_Cl; précise au processeur concerné que le dernier objet Tr ou Cl crée sera a imprimer. De même pour Print_Cl ou _Tr par Ker; A l'inverse : Print_not_Cl; et : Zprint_not_Tr; suppriment un éventuel défaut requérant l'impression; 3/ GLOBALISATION DES DIRECTIVES : à la fin de ZINIT, après l'instruction qui instancie l'arbre ZOOM : CALL OFRAME ; ! FM referenced output options. EXEMPLES : sorties de KER : Print top Cl of Fm: U; Eta,Gamma dEta des Cellules immédiatements sous Fm : U; Print all Cl of Fm: U; des Cellules des familles U et sous U jusqu'en bas Print all Tr of FM : PIEC-1; Fi,DElta et Omega des Tranferts du sous-arbre des familles de racine la Fm : PIEC-1; Print all of Fm: Z; sans précision du type d'objet, les deux (Cl et Tr) sont concernés. Zprint all Cl of Fm: PIEC-1; les processeurs traitant les Cl du sous arbre précédent doivent imprimer. Zprint all of Fm: Z; sans précision du type d'objet, les deux (Cl et Tr) sont concernés. COMPLEMENTS =========== */ Pour la programmation des processeurs : ------------------------------------------ Instructions héritant des directives de ZINIT : if zprint(LCL) < Z_Pr: (Gamma(i),i=1,NN) >; */ Fixation d'un niveau d'impression pour les Processeurs -------------------------------------------------------- Dans ZINIT : OZPlvl(2)=1; (seuil d'impression [ici 1] commun à tous les processeurs) Dans un processeur : if Zprint_lvl(1,LTR) < Z_Pr : FI(1),Omega(1),T_Edge(1),T_Edge(2); > cf $ZOOM/Help/Users/Combined_Facilities/Print_levels < On impose donc le même niveau d'impressions pour tous les processeurs. Pour varier d'un processeur à l'autre, il faudra en passer par la déclaration d'une variable dédiée des Description Banks; (ker gère le général, chaque processeur le particulier ...) */ Impressions dans .lis correspondant aux calculs matriciels : --------------------------------------------------------------- 1/DEFAUTS : toutes les familles sous Z de profondeurs au plus égales a mxdeep (integer Fortran) sont sorties sous la forme d'un scatter plot. 2/PAR OBJET (ici des Familles) Zprint_fm; sortie du scatter plot de la dernière Famille créée. Zprint_not_Fm; supprime la sortie par défaut éventuelle. 3/APRES OFRAME Zprint top Mx of Fm : PIEC-1; / sortie des matrices si OZPLVL(4).ge.2 et [soit print fm, soit sa depth.lt.MXDEEP] Zprint all Mx of Fm : TROM; \ sinon, scatter plot seulement Dans ce dernier cas, mxdeep est pris en compte pour sortir les matrices des familles de profondeur relative à la racine susdite [ici TROM]. */ Gestion particulière aux calculs correspondants à la D_Loop: --------------------------------------------------------------- OZPlvl(3)=2; " Print Level of D_loop" Voir ces détails d'impressions dans : $ZOOM/Help/Programmers/Ker/D_Loop < Note : pour les détails concernant le tableau OZPlvl cf : $ZOOM/Help/Users/Combined_Facilities/Print_levels < ************************************************************************** *************************** RESUME FROM ********************************** ************************************************************************** Il s'agit de la reprise d un run par initialisation à partir d un fichier de sorties d'un run précédant (qui aura évntuellement pu être tué, cad que la fin du fichier peut être aléatoire) L'initialisation ne sera faite qu'à partir des états des Cellules non gelées; pour ces dernières, la valeurs du Zinit sera donc retenue (Fill_Eta<;>). RESUME FROM OZDAT.CL1; noms de fichiers autorisés de type OZDAT.CLX (1 seul caractère X) ker se positionne au dernier step du fichier, initialise les Eta et lance le calcul. RESUME FROM OZDAT.CL1, at IT; pareil, mais positionne au ITième step; RESUME FROM OZDAT.CL; ker se positionne au dernier step du fichier, initialise les Eta, se positionne au même step pour OZDAT.TR et les deux OZPAR.XX et lance le calcul; il va donc accroitre ces quatre fichiers des nouvelles sorties. RESUME FROM OZDAT.CL1/OZDAT.TR1; non content d'initialiser les Eta, ker va reprendre la valeur des Fi (Fiz) du même step - ici le dernier - nons gelés, et retiend la valeur du Zinit pour ces derniers. Ce type de Resume from prend son intérêt lorsque la D_loop est coûteuse ou lors de la présence de Pseudo_Cell Tr, qui requièrent - telles des cellules - une initialisation (cf les manuels des Processeurs) ******************************************************************************** ******** Directives pour sorties VIZU **** Les Maps **************************** ******************************************************************************** Lorsque des objets Cellule ou Transfert ont entre eux une relation géométrique, comme dans le cas d'un maillage, on peut associer chacun d'entre eux à un noeud d'une grille 1 ou 2D, dénommée "map"; On respecte cependant la dichotomie Cl/Tr : soit ClMap, soit TrMap, pas de mélange. La définition d'un map aura pour conséquence son apparition dans l'arbre VIZU et le tracé automatique de surfaces. Concrètement, les valeurs tracées - associées à chaque point de la grille, seront Fi,dFi,Omega ou des paramètres définis dans le processeur pour les Tr, Eta, dEta, dEta,dec ou paramètre pour les Cl. On peut associer à chaque point, soit l'objet complet - et alors les valeurs formant la surface correspondront aux mêmes composantes du vecteur choisi pour tous les objets soit (objet,composante) - et alors le profil pourra relier des valeurs de ces composantes diverses (à une translation près définie dans VIZU). Cette définition se fait en deux temps : 1) définition de la grille ++++++++++++++++++++++++++ DEFINE MAP CL01 , "ClMap de nom CL01 a CL99" TITLE= Profil de Grouchot-Langevin, "titre de 60 carateres maxi" DIM=1, " Dimension 1 ou 2, profil ou surface" XLEN=100; "nombres de points de grille en X" DEFINE MAP TR01, TITLE= mon transfert prefere, DIM=2, XLEN=12, YLEN=27; "nombres de points de grille en Y" DEFINE MAP TR02,TITLE=BlaBla,DIM=3,XLEN=10,YLEN=20,ZLEN=10; "non implémenté" 2) Association point de grille / Objet ++++++++++++++++++++++++++++++++++++++ Du fait de l'absence de nom aux Transferts, oon distingue pour les CL0I maps : Z_OUT CL01(I)=*NamCl*; 1D Map, associant une cellule au point I; Z_OUT CL03(I,J)=*NamCl* 2D Map, associant une cellule au point I,J; Z_OUT CL04(I)=*NamCl*,K; 1D Map, associant la composante K de Cl au point I; Z_OUT CL05(I,J)=*NamCl*,K; 2D Map, associant la composante K de Cl au point I,J; ; pour les TR0I maps : (Imperativement a la creation du Tr); Z_OUT TR02(I); 1D Map, associant le Transfert courant au point I; Z_OUT TR01(I,J); 2D Map, associant le Transfert courant au point I,J; Z_OUT TR03(I),K; 1D Map, asssociant la composante K du Tr au point I; Z_OUT TR04(I,J),K; 1D Map, asssociant la composante K du Tr au point I,J; ; Rq : cette information est rangée par Ker dans le fichier binaire OZOUT.MP; ; informations complémentaires dans VIZU manuels; 3) Maillage variable ++++++++++++++++++++ La version Futura (Dev de Oct 97) authorise le maillage variable en une ou deux dimensions; cela ne concerne pas du tout la description des Map précédente qui ne contiend aucune information géométrique, mais conduit à une certaine transformation des sorties DANS Vizu. Mais Vizu utilisant des fichiers qui trouvent leur origine dans ZINIT, pour info Maillage variable, cf : > $ZOOM/Help/Users/Graphics_and_post_treatment/Maps ******************************************************************************** ***** TITRES et INFORMATIONS ASSOCIEES A UN RUN ******************************** ******************************************************************************** On donne un titre général aux sorties graphiques post-traitées par l'instruction U_Title : U_TITLE Mon Titre, O bel exercice que ton Rayleigh est grand; Il est possible de récupérer les infos générales d'un run dans les variables suivantes: * ORDATE = RunDate * ORTIME = RunTime * ORNAME = Zinit title Name * ORVERS = Zinit Version * OZINDA = Zinit Date of Version * OZINTI = Zinit Time of Version * OTITLE = 64 caraterès de titre intitialisé à ORNAME ORVERS OZINDA OZINTI exemple +CDE,OTITLE. dans la partie &F apres +CDE,OPRINT. par exemple ... +SEQ,OGENTIT. print *, otitle; print *,' RunDate ', ordate; print *,' RunTime ', ortime; print *,' Zinit title Name ', orname; print *,' Zinit Version ', orvers; print *,' Zinit Date of Version ',ozinda; print *,' Zinit Time of Version ',ozinti; ******************************************************************************** ********* I N S T R U C T I O N S D I N S T A N C I A T I O N ************** ********* Initialisation et attribution de valeurs aux Paramètres ************** ******************************************************************************** Zdl_html.dir/Model_Instanciation < fill_CD "ou fill_TD" < toute intruction FORTRAN; [Var_Name { (i {,j} ) } ] {:Var_type} = expression; " { } : veut dire optionel" > exemples : - - - - - - CREATE CL Surf-1 , type = ND ; fill_CD < [Heat_capa]:r = CpSol; > ; CREATE TR , TYPE = RAD2 NTOT; " Transfert radiatif" ........ fill_TD < [IntrvMin]:i = 1; [IntrvMax]:i = 4; [Temp_Bias]:r = TBias; [RCoefDif]:r = 1.; do I = 1,NbVolGaz < [Ro(I+1)]:r = RoCtr(I); [Zmoy(I+1)]:r = ZCtr(I); [DZ(I+1)]:r = DzCtr(I); [Sigm(I+1)]:r = SigCtr(I); > > "close fill_TD" ; Remplissage des variables ( Eta ou Fi ) ======================================= FILL_ETA < [1] = T; [3] = 273. >; " Initialise Eta(1) avec la variable T et Eta(3) avec 273." ; fill_Fi< [1 thru 12] = Fi_zero; >; " Fi(1 à = Fi_zero" fill_Eta< [.] = H; >; " Initialise toutes les composantes à H" FILL_ETA< [.] = T_ref, Vx_surface, Vy_surface, Sel_conc, Ro_eau; > ******************************************************************************** ******** Autres Instructions utiles ******************************************** ******************************************************************************** DIMENSION:N,M; comble imparfaitement l'absence de possibilite de decliner des noms d'objets avec deux integer, comme MESH-(I,J); Dimension, instruction SEQUENCIELLE remplacera l'occurence de MESH-(I,J) par MESH-(I+(J-1)*N); ce qui fait que l'information (I,J) ne se retrouvera pas dans le .lis ni dans ViZu. Execute Procedure; DO ((J=1,NL),I=1,NC) " num.max.de liaisons=JZSIG=9 (4 PSI+4 VORTX+RADI)" < CREATE CL MESH-(I:J),TYPE=VORTX 9; "Entry IVORTX" C-PLUG 1:1,2,3,4; C-PLUG 2:1 thru 4; SET MESH(I:J) = MESH-(I:J); Tinit=T_infini; Execute MESH_Fill; Z_OUT CL01(I,J)=MESH-(I:J); " Mapping" IF J.eq.NL/2 .and. I.eq.nc/2 < ZPrint_CL; >; > ....... PROCEDURE MESH_Fill < Fill_Eta < [2] = Tinit ; [3] = RO_AIR; [4] = RO_AIR; > flat = 0.; Fill_CD < [Air_Eau]:i = 1; "Air" [lat_itude]:r = rlat; [long_itude]:r = delta_long*float(I); [f_lat]:r = flat; [Nb_faces]:i = 4; "Carres" [t_side]:r = DX; " should .eq. DY" [Lo_up]:i = Lo_up; [delta_z]:r = DZ; [D_centre]:r = DX/2.; [Ro_fluid]:r = Ro_air; [frozen(4)]:i = 1; "Cancel Temp. dependant parameters computation" [gy_Archimede]:r=0.; [Cp_fluid]:r = Cp; [G_cond(1)]:r = viscosite; [G_cond(2)]:r = conduct/Cp; [G_cond(3)]:r = .1*conduct; "Salinity diffusion" > > ; *************************************************************************** ********** Complément pour les Matrices ********************************** *************************************************************************** En cas d'occurence d'une D_loop (cf TEF manuel), il faut fournir au noyeau (ker) de quoi gérer le critère de convergence. Deux critères sont actuellement implémentés: ******** en bref ******** ============================================ * Standard: TOLQUAD * * ou * > Un critère standard, où : SOMME{ (Fi-Fiz)^2} sur les D_flagged Transfers * User: TOL_US et OPLUS * est comparée à TOLQUA*NTR (Tolérance quadratique, Nombre de D_Tr), avec ************************* la possibilité de fixer TOLQUAD dans Zinit (Valeur par défaut = 1.E-10). > Un critère comparant DEVUS à TOL_US (Tolerance User) : à la sortie de chaque appel à un D_flagged Tr, on accumule le contenu de OPLUS dans DEVUS. C'est donc chaque processeur concerné qui calcule OPLUS - remis à zéro par ker avant l'appel au processeur. DEVUS est comparé a TOL_US (à fixer dans ZINIT). > Le plus sévère des deux critères arrête les itérations. Donc, pour privilégier le critère utilisateur, il faut donner à TOLQUAD une grande valeur. On peut cependant limiter le nombre d'itération, pour éviter les boucles infinies de non convergence par : Nombre d'itérations: ==================== > NITMAX fixe le nombre maximum d'itérations > on peut aussi en imposer un nombre minimum en donnant à NITMIN une valeur non négative (défaut=-1). Pour des raisons historiques, NITMIN=0 entraine au moins une itération, 1 au moins 2, etc. MATRICES ET VIZU ================ Vizu donnant accès aux matrices sous Zeus, un fichier - actuellement en ASCII - MXMX contiend les sorties (évidemment en phase avec les DAT) On peut exiger la sortie des mêmes coefficients, mais dès la fin de la D_Loop, (donc sans les CtA_1B) en ajoutant 100 au contenu de OZPlvl(6) : ker crééra alors MDMX en plus de MXMX. Pour y avoir accès dans VIZU, il faudra cependant jouer avec des softs links pour qu'elle apparaisse sous le nom MXMX. cf $ZOOM/Help/Users/Combined_Facilities/Print_levels < Attention, MDMX possède des coefficients associés aux K-Transferts non significatifs. ********* *************************************************************************** ********** Utilisation du point d'entree ZSTEER *************************** *************************************************************************** =========================================== Gestion du pas de temps de calcul =========================================== dTime= .1;"s" en tête de Zinit initialise l'incrément temporel; On peut le modifier dans ZSTEER (cf Borelienne) Le calcul s'arrête quand on atteind TimaX (Zinit). On peut préférer le gérer soi même dans ZSTEER : if (istep.ge.NbItStop) < ZENDRN =.true.; > "s'arrêtera en fin du step qui démarre" On peut de la même manière gérer les fréquences de sorties sans tenir compte des" Print/Paw every M steps" - on gère alors les Logical variable suivantes : ZPAW déclenche une sortie des DAT/PAR ZPRINT déclenche pour .lis (ker et les processeurs) ZENDRN arrêtera le run à la fin du pas qui démarre. =========================================== ****** Fu t u r a ************************* =========================================== Un tableau commun aux processeurs et a Zinit a ete defini: Time_char(4), avec EQUIVALENCE (Time_char(1),dTime_next),(Time_char(2),Tim_char_Cl), +(Time_char(3),Tim_char_Tr), qui fournit diverses possibilites pour optimiser la gestion de dTime; un exemple valant mieux qu'un long manuel, le voici. Exemple d'utilisation dans un exemple conducto-convectif ------------------------------------------------------- au début de Zinit on initialise les valeurs fixes : ! Temps caractéristiques rNu = Viscosite/Ro_Air; Alpha = Conduct/Ro_Air/Cp; TimeNu = DX*DX/rNu; TimeAlpha = DX*DX/Alpha; Z_Pr/Temps caracteristiques/: TimeNu, TimeAlpha; Z_Pad/Temps caracteristiques/: TimeNu, TimeAlpha; Time_char(3) = TimeNu; Time_char(4) = TimeAlpha; ! init defaults Time_char(1)=99999.; Time_char(2)=99999.; ; puis, dans le ZSTEER, on recupere les valeurs definies dans un ou plusieurs processeurs. ! *********************** ! Gestion du pas de temps ! *********************** Z_Pr/ test/:dTime, Time_char; Z_Pad/ test/:dTime, Time_char; if (istep.ge.1) < dTime = min (4.*dTime, Time_char(1),Time_char(2) ,Time_char(4)/2.5)/float(NITER+1); >; ! reset U & V Courant limit Time_char(1)=99999.; Time_char(2)=99999.; !!!! il a suffit de gerer dans un processeur judicieusement choisi !!!! les deux premiers Time_char : !!!! Zsteer info for steering dTime !!!! DO i=1,2 !!!! < if (abs(VIS_uv(i)) .gt. 1.E-06) then; !!!! Time_char(i) !!!! = min ( Time_char(i), min(t_side(1),t_side(2))/abs(VIS_uv(i)) ); !!!! endif; !!!! >; ; On obtiend un critère en Courant (cad assez rapidement). =========================================== Analyse Borelienne des Matrices de couplage =========================================== L'exemple suivant montre comment sortir une matrice de couplage à un instant donné, mais en faisant varier le pas de temps - ce qui correspond à une analyse du Système Linéaire Tangent en transformée de Borel Contexte : un premier run sert de référence, et on fait un RESUME FROM sur un OZDAT.CL1, at IT; le pas de temps considéré; dans ZSTEER (fin du ZINIT) : ENTRY ZSTEER; ! if (istep.ge.NbItMx) "on a fixe le nombre de pas dans la variable NbItMx" < ZENDRN =.true.; > "le run s'arrêtera à la fin du pas courant" call ORESUME(LZ); "on repositionne le fichier de reéférence au même step" dtime = dtime*2. "cf Borel manuel" time = dtime ; " Ceci permet d'avoir dans viZu la variation des coefs(dtime)" ZPAW = .true. ; " pour transmettre à ViZu ce step" ; RETURN ; END ; "========== END OF ZDL WRITTEN SYSTEM =====================" ; cf Zdl_html.dir/ZSteer_Entry < ******************************************************************************** ******** Parametres du Run ***************************************************** ******************************************************************************** TYPES de fonctionnement Stationnaire ou Dynamique; La variable logique STEADY permet á ker de fonctionner en mode recherche d'une solution stationnaire, en supposant bien sùr que la totalité des processeurs utilisés sache alors quoi faire ... Gestion de l'incrément. Arrêt. dtime; timax; cf ZSTEER ;