Menu
Comment installer la chaîne d'outils, écrire un modèle, le compiler, l'exécuter et lire ses diagnostics. Cette page couvre l'usage ; la norme elle-même est publiée sur igl-lang.org.
Repères
Un binaire IGL accompagne IsoFind, mais une installation séparée prend le dessus : le langage évolue à son rythme.
Rien à faire. La commande est disponible et la version livrée est celle validée avec la version d'IsoFind installée.
Une installation système de la chaîne d'outils est détectée et employée en priorité, ce qui permet de suivre les versions du langage sans attendre une mise à jour du logiciel.
pip install igl-lang installe les liaisons Python, utiles pour engendrer ou lire des modèles depuis un script.
La commande s'appelle igl. Elle porte une option --profile pour déclarer le profil attendu, et rend un code de sortie qui distingue une erreur de source d'un défaut du programme.
| Sous-commande | Effet |
|---|---|
| check | Analyse et valide la source. Ne produit aucun fichier. |
| parse [--json] | Rend l'arbre syntaxique, en JSON avec l'option. |
| build [-o] | Compile vers le graphe intermédiaire .iglir.json, provenance comprise. |
| run [-o] | Exécute un graphe et écrit un document de résultats au format 1.0. |
| fmt [--check] | Reformate ligne à ligne en préservant les commentaires ; --check n'écrit rien. |
| explain | Affiche l'explication d'un code de diagnostic. |
Codes de sortie
La source se compile en un graphe intermédiaire, que le moteur exécute pour produire un document de résultats. Les deux formats sont versionnés indépendamment du langage.
# 1. Vérifier la source sans rien produire $ igl check model.igl ok # 2. Compiler vers le graphe intermédiaire $ igl build model.igl -o model.iglir.json # 3. Exécuter le graphe et écrire les résultats $ igl run model.iglir.json -o results.json # 4. Comprendre un diagnostic $ igl explain IG211
La séparation a une raison pratique : un moteur tiers n'a pas à savoir analyser IGL, il lui suffit de lire le graphe. Et une exécution qui échoue écrit tout de même son fichier de résultats, avec la provenance du modèle, capturée avant que quoi que ce soit puisse échouer.
Un en-tête de bloc commence en colonne zéro, ses instructions sont indentées. Un bloc se termine implicitement au suivant, sans accolade ni imbrication.
Un réservoir et un processus ne peuvent pas porter le même nom, sans quoi un chemin qualifié deviendrait ambigu. Aucun mot n'est réservé globalement : la position décide de ce qu'un jeton signifie.
Les rapports s'écrivent 53Cr/52Cr et les deltas delta53Cr. Le rendu typographique est réservé aux rapports et aux exports, jamais à la source.
Un code signifie la même chose dans toute implémentation conforme. C'est l'intérêt de les numéroter : on cherche IG211 et on trouve une page de référence, pas un fil de discussion.
Elle ne dit pas quelle phase l'a détectée. Un code syntaxique émis par le lieur reste dans la plage syntaxique.
Rencontrer un bloc d'un profil non déclaré produit IG005 et arrête la compilation. Ignorer le bloc rendrait un résultat plausible depuis un modèle amputé.
Une référence inconnue proche d'un nom existant est signalée avec la correction probable, la distance étant bornée pour éviter les suggestions absurdes.
Le moteur lit les fichiers .igdb nommés, complète les standards absents avec leur citation, résout les facteurs qu'un processus ne déclare pas, et rapporte l'origine de chaque valeur dans les diagnostics du fichier de résultats.
ISOTOPES mode relative dispense de standard, un écart de deltas ne dépendant pas de la référence contre laquelle les deux ont été mesurés. Il se déclare et ne se déduit jamais.
Le bloc PHREEQC lance l'exécutable en sous-processus et lie les colonnes de sa sortie à des paramètres. Il exige la version batch, des chemins absolus, et une base toujours passée explicitement.
La spécification, la référence de chaque bloc et les quarante et un diagnostics sont publiés sur igl-lang.org. En cas de désaccord entre cette page et la spécification, c'est la spécification qui a raison.
All Rights Reserved by IsoFind