Parameters control the variable parts of an LCA model. A transport distance, an electricity consumption figure, a material density: when these sit behind named parameters rather than hard-coded numbers, they can be changed from a script, a CSV, or a scenario definition. Before changing them, you need to know what exists.
openLCA’s GUI shows parameters in several places: the global parameter list, individual process editors, and the product system parameter tab. For a handful of parameters that works fine. For a model with dozens or hundreds of parameters spread across multiple processes, it becomes a scoping exercise in its own right. The script covered here pulls them all at once and writes them to CSV.
The script is on GitHub.
What the script does
B280_olca_parameters.py connects to openLCA’s IPC server and pulls parameter names, values, formulas, and descriptions into CSV files. It runs in three modes:
Global parameters are database-wide values. They appear in openLCA under Tools > Global Parameters. Running the script with no flags pulls every global parameter and writes it to global_parameters.csv.
Local parameters are defined on individual processes. A process might have a parameter called electricity_kwh that controls an exchange amount. Adding the -l flag scans every process in the database and collects these into local_parameters.csv, with the process name included so you can see where each one lives. On large databases like ecoinvent, this scan can take a few minutes because it needs to retrieve the full process object for each entry.
Product system parameters are the set relevant to a specific product system, pulled with the -p flag. This is the most useful mode when preparing for scenario or sensitivity work, because it returns exactly the parameters you can override in a calculation setup. The output includes the parameter’s context (which process it belongs to), matching the format used by B280_olca_scenarios.py and B280_olca_sensitivity.py.
How openLCA parameters work
A parameter in openLCA is a named variable with a value. An exchange amount can reference a parameter name instead of a number: if a process has an input of electricity with the amount field set to annual_kwh, openLCA looks up the parameter annual_kwh and uses its value.
Parameters come in two scopes. Global parameters are visible across the entire database. Local parameters belong to a specific process and are only visible within it. When a global and a local parameter share the same name, the local one takes precedence inside that process.
Some parameters are input parameters: they hold a fixed value that the user sets. Others are dependent parameters, calculated from a formula. A parameter called total_energy with the formula daily_kwh * operating_days will recalculate whenever daily_kwh or operating_days change. openLCA supports the standard arithmetic operators (+, -, *, /, ^) and mathematical functions (sqrt, ln, lg, exp, abs, sin, cos, tan, min, max, floor, ceil, round) inside these formulas.
This is what makes parameters useful for automation. The scenario calculations script overrides input parameter values from a CSV file. The dependent parameters recalculate automatically. One CSV row can change a transport distance, and every formula that references it updates through the supply chain.
Running the script
Start the IPC server in openLCA (Tools > Developer Tools > IPC Server, port 8080, click the green play button), then run:
# Pull all global parameters
python B280_olca_parameters.py
# Also pull local parameters from every process
python B280_olca_parameters.py -l
# Pull parameters for a specific product system
python B280_olca_parameters.py -p "My Product System"The output is one or two CSV files depending on the mode. Global parameters produce a file with columns for name, value, formula, scope, and description. Local parameters add a process column. Product system parameters include a context column showing which process each parameter belongs to.
Using the output
The CSV is a reference, a checklist, and a starting point for other tools.
For scenario work, the product system mode (-p) gives you the parameter names and current values you need to build a scenario CSV. You can open the output in a spreadsheet, add columns for each scenario, and adjust the values. The parameter names and contexts from that file are the starting point for building a scenario CSV for B280_olca_scenarios.py.
For sensitivity analysis, the global parameter list tells you which parameters exist and what they control. Pick the ones worth testing, list them in a sensitivity CSV, and run B280_olca_sensitivity.py.
For model review, the local parameter scan shows every parameterised exchange in the database. If you are checking whether a model is fully parameterised, or looking for parameters with placeholder values, the CSV gives you a single searchable list rather than clicking through process editors one at a time.
How the script works
The script uses three different parts of the olca-ipc API depending on the mode.
For global parameters, it calls client.get_descriptors(o.Parameter) to get a list of all global parameter references, then client.get(o.Parameter, id) on each one to retrieve the full object with its value, formula, and description.
For local parameters, it calls client.get_descriptors(o.Process) to list every process, then client.get(o.Process, id) on each one and checks the process.parameters list. Any process with parameters has them collected into the output. The progress indicator prints every 500 processes because this loop can take a while on large databases.
For product system parameters, it calls client.get_parameters(o.ProductSystem, id), which returns the full set of parameters relevant to that system, including their context (the process they belong to). This is the same call that the scenario and sensitivity scripts use internally when matching parameter names to their contexts for ParameterRedef objects.
Things to watch
Parameter names are case-sensitive. Transport_km and transport_km are different parameters. The CSV preserves the exact names from the database.
Formulas reference other parameters by name. If a formula says daily_kwh * 365, there needs to be a parameter called daily_kwh in scope. The script exports the formula text as-is, so you can trace these dependencies in the CSV.
Product system parameters include context. When you redefine a parameter in a calculation setup, openLCA needs to know which process it belongs to. The context column in the product system output gives you this. The scenario and sensitivity scripts handle context matching automatically, but if you are writing your own scripts, the parameters article covers how ParameterRedef and context work.
Next steps
The script and example output are on GitHub. The rest of the openLCA scripting knowledge base covers connecting to the IPC server, running scenario calculations, and sensitivity analysis. If you need help parameterising an LCA model or automating your calculations, get in touch.