Aide pour la Directive order


Revenir à la page d'accueil
order
Cette directive sert à indiquer l’enchaînement, le déroulement des calculs.

Les calculs sont effectués en déroulant de façon synchronisée les différentes trajectoires. 
? Ce qui doit être décrit dans le document : ?multiop?.
Lorsque le pas de temps d’une trajectoire doit être calculé, on déclanche le calcul pour tous les espaces associés à cette trajectoire pour autant qu’on en ait manifesté l’intention, ce qui est l’objet de la directive suivante :

order modinspace spacename
	         baseorder
forder

spacename est le nom de l’espace concerné. 
baseorder correspond à la syntaxe, décrite ci-après, qu’il convient d’utiliser pour définir le sens de parcourt de l’espace et l’ordre d’enchaînement de ses modules .

Un espace peut ne pas faire l’objet de cette directive, auquel cas il ne sera jamais instancié. Cela prend par exemple un sens pour les espaces qui
 ne sont porteur que de modules noward souvent utilisés pour des paramètres à contrôler ou des constantes.

rem : Concernant les opérateurs, cette directive n’a pas à être utilisée. Les opérateurs sont déclanchés automatiquement selon les besoins algorithmiques.

De la même façon que l’on donne l’ordre d’exécution des modules à l’intérieur d’un espace, il faut également dire l’ordre d’exécution des 
espaces pour un pas de temps de trajectoire. La directive suivante, qui parle d’elle-même, le permet :

order spaceintraj trajname
:->liste des espaces de la trajectoire trajname dans l’ordre où ils doivent être    
     calculés.
forder

_______________________________________________________________
baseorder : syntaxe d’ordre d’enchaînement des modules sur les axes de l’espace :

   (ordre (Ascending, Backwarding) ; Syntaxe et règles d’utilisation de l’instance order )

ORD 		: ‘order’, Axe, List_AXE, Mod, List_inst , ‘forder’
List_AXE	: vide  |  Axe, List_AXE
Axe		: ‘YA1'  |  ‘YA2'  |  ‘YA3'  |  ‘YB1'  |  ‘YB2'  |  ‘YB3'
list_inst 	: vide  |  Mod, List_inst  |  ORD, list_inst
Mod		: ’doit exister parmi les classes de l’utilisateur’

nb les mots du language (terminaux) sont entre quotes.

rdg CHEKED :
=> le référencement à un ou plusieurs axes doit suivre immédiatement le token ‘order’
=> le token ‘order’ ne doit pas apparaître consécutivement.
=> il doit y avoir autant de ‘forder’ (fin order) que de ‘order’
=> un axe déjà référencé à un niveau supérieur de la hiérarchie ne doit plus l’être à un niveau inférieur 


rdg NON CHECKED :
Yao ne sait pas encore vérifier une utilisation cohérente des axes :
=> les modules doivent être intégrés à un niveau où ils ont une correspondance avec les axes antérieurement déclarés. (voir exemple ci-dessous 
avec Adj qui est défini sur les axes 1 et 2 et qui est à tord intégré sous les axes 2 et 3) Les résultats sont unpredictables (au mieux, il ne 
passe pas la phase de compilation du projet ce qui n’est pas plus mal !


Un exemple :

 	order YA1 YA2 Adj
              	order YA3 Bio forder
              	order YA3 Lin forder
              	order YA3 Dyn forder
              	order YA3 Nit forder
forder
___________________________________________________________________________


rem : module sans connexion (ni aval, ni amont) sera détecté comme étant :
          - un module « ghost » si il est dans l’order
          - un module « parasit » si il n’est même pas dans l’order.