Documentation

Using IGL with IsoFind

How to install the toolchain, write a model, compile it, run it and read its diagnostics. This page covers usage; the standard itself is published on igl-lang.org.

Reference points

Commandigl
Language version0.5
Engine inputmodel.iglir.json
Engine outputresults.json, format 1.0
Python packagepip install igl-lang
Installation

Shipped with IsoFind, updated separately

An IGL binary ships with IsoFind, but a separate installation takes precedence: the language moves at its own pace.

With IsoFind

Nothing to do. The command is available and the shipped version is the one validated against the installed version of IsoFind.

Separate installation

A system-wide installation of the toolchain is detected and used first, which allows following language releases without waiting for a software update.

From Python

pip install igl-lang installs the Python bindings, useful to generate or read models from a script.

The command line

Six subcommands, one program

The command is called igl. It takes a --profile option to declare the expected profile, and returns an exit code that distinguishes a source error from a defect in the program.

SubcommandEffect
checkParses and validates the source. Produces no file.
parse [--json]Returns the syntax tree, as JSON with the option.
build [-o]Compiles to the .iglir.json intermediate graph, provenance included.
run [-o]Runs a graph and writes a results document in format 1.0.
fmt [--check]Reformats line by line preserving comments; --check writes nothing.
explainPrints the explanation of a diagnostic code.

Exit codes

0Nothing to report
1Errors in the source
2Invocation or read error
3Defect in the program
The workflow

Three files, two contracts

The source compiles to an intermediate graph, which the engine runs to produce a results document. Both formats are versioned independently of the language.

igl
# 1. Check the source without producing anything
$ igl check model.igl
ok

# 2. Compile to the intermediate graph
$ igl build model.igl -o model.iglir.json

# 3. Run the graph and write the results
$ igl run model.iglir.json -o results.json

# 4. Understand a diagnostic
$ igl explain IG211

The separation has a practical reason: a third-party engine does not need to parse IGL, it only needs to read the graph. And a run that fails still writes its results file, with the provenance of the model, captured before anything can fail.

Writing a model

Three rules worth knowing

Header in column zero

A block header begins in column zero; its statements are indented. A block ends implicitly at the next one, with no closing token and no nesting.

Names are global

A reservoir and a process cannot share a name, or a qualified path would become ambiguous. No word is globally reserved: position decides what a token means.

Strict ASCII notation

Ratios are written 53Cr/52Cr and deltas delta53Cr. Typographic rendering belongs to reports and exports, never to the source.

Diagnostics

Forty-one codes, numbered once

A code means the same thing in every conforming implementation. That is the point of numbering them: you search for IG211 and find a reference page, not a forum thread.

The range says what kind of fault

Not which phase detected it. A syntactic code emitted by the binder stays in the syntactic range.

An unclaimed profile refuses

Meeting a block from an undeclared profile produces IG005 and stops compilation. Skipping the block would return a plausible result from an incomplete model.

Nearest-name suggestion

An unknown reference close to an existing name is reported with the likely correction, the distance being bounded to avoid absurd suggestions.

Databases and coupling

What the engine fetches elsewhere

DATABASE block

The engine reads the named .igdb files, fills in absent standards with their citation, resolves factors a process does not declare, and reports the origin of every value in the diagnostics of the results file.

Relative mode

ISOTOPES mode relative dispenses with a standard, since a difference of deltas does not depend on what both were measured against. It is declared and never inferred.

PHREEQC coupling

The PHREEQC block runs the executable as a subprocess and binds its selected output columns to parameters. It requires the batch version, absolute paths, and a database always passed explicitly.

The standard is authoritative, not this page

The specification, the reference for every block and the forty-one diagnostics are published on igl-lang.org. Where this page and the specification disagree, the specification is right.