olcaBASIC: Script openLCA in Plain BASIC Commands

Last updated 27/09/2026 for olcaBASIC 0.3.0

olcaBASIC is a free, open-source scripting language for openLCA. It lets LCA practitioners build models, run calculations, compare scenarios and check data quality using plain commands such as MAKE PROCESS, INPUT USE PROCESS, CALCULATE and SCENARIO, written in a text file and run from the command line. olcaBASIC sits on top of openLCA’s Python tools and borrows its style from BASIC, the language John Kemeny and Thomas Kurtz created at Dartmouth College in 1964 so that students of any subject could write their own programs.

olcaBASIC is experimental. Version 0.3 has been tested end to end against a live openLCA database, and we want people to try it on their own models and tell us where it breaks.

View olcaBASIC on GitHub →

What it is	A BASIC-style scripting language for openLCA
Status	Experimental (version 0.3.0)
Licence	Open source, MPL-2.0
Install	pip install olcabasic from PyPI
Requires	openLCA 2.x with the IPC server running, Python 3.10 or later
Built by	Below280, the UK partner for openLCA

What is olcaBASIC?

olcaBASIC is a small programming language for scripting openLCA. You write a program describing your model: what the process makes, what goes into it, and which parameters vary. olcaBASIC turns each line into the right calls to openLCA through its IPC server, so the model appears in your openLCA database the same as if you’d built it by hand. Results come back as tables you can save to CSV.

A complete olcaBASIC model with a scenario comparison looks like this:

basic

LET cement_mass = 300
LET aggregate_ratio = 2.667
LET sand_mass = cement_mass * aggregate_ratio

SET PROCESS FOLDER "00: My Project"

MAKE PROCESS "Concrete block; at plant"
  OUTPUT MAKE FLOW "Concrete block", 1, m3, PRODUCT
  INPUT USE PROCESS "Portland cement; at plant", cement_mass, kg
  INPUT USE PROCESS "Construction sand and gravel; at mine", sand_mass, kg
END PROCESS

SYSTEM "Concrete block; at plant"
CALCULATE "Concrete block; at plant" USING "IPCC"

SCENARIO "Low cement"
  LET cement_mass = 240
END SCENARIO

RUN SCENARIOS ON "Concrete block; at plant" USING "IPCC"

Anyone who has built a process in openLCA can read that and see what it does. That’s the whole idea.

Why does olcaBASIC exist?

olcaBASIC exists because scripting openLCA properly asks for real programming, and most LCA practitioners are environmental scientists and engineers.

openLCA’s scripting interface is excellent. Through the IPC server, Python can do anything the desktop application can do, and automate the work that would take hours by hand. R and Fortran can too. The rest of this knowledge base shows how, and our article on why you’d automate LCA calculations covers the case for doing it.

Scripting openLCA directly means working with its data model: an exchange points to a flow, a provider is a process, a parameter lives in a context, and a scenario is a list of parameter redefinitions attached to a calculation setup. Getting any of that slightly wrong rarely produces an error. It produces a model that calculates and gives the wrong answer.

So we built a layer that handles the data model for you. You write INPUT USE PROCESS "Portland cement; at plant", 300, kg and olcaBASIC finds the process, takes its reference flow, links it as the provider, and sets the amount. You write LET cement_mass = 300 and it becomes an openLCA parameter. You write SCENARIO and it builds the redefinitions. The concepts stay the same as in openLCA, and the plumbing is handled for you.

There was probably no good reason to base it on BASIC, but we wanted to make it. BASIC’s founding purpose, programming for everyone, turned out to fit LCA scripting well.

How does olcaBASIC work?

olcaBASIC works as a layer on top of openLCA’s Python tools. Each layer does one job:

1. Your program: a .baslca text file, or commands typed at the > prompt.
2. The olcaBASIC interpreter reads each line, checks it, and works out what it means in openLCA terms.
3. The b280-olca-mcp functions do the openLCA work. This is the same tested code that powers the openLCA MCP server, which connects AI assistants to openLCA.
4. olca-ipc, GreenDelta’s official Python client, sends the requests.
5. openLCA’s IPC server carries out the work in your database and runs the calculations.

Sharing the middle layer with the MCP server means both tools improve together. Version 0.2 changed how scenarios and sensitivity handle a parameter shared by several processes, so that one change now reaches every process that uses it, and version 0.3 added the upstream tree with pedigree scores and flow property editing. The work went into the shared functions, and the MCP server gained each of them in the same release.

What can olcaBASIC do?

Building openLCA models

olcaBASIC builds foreground models with MAKE PROCESS blocks, where every line says what it works with. INPUT USE PROCESS finds a process in the database and links it as the provider, which is what connects your foreground model to the background supply chain. INPUT USE FLOW links a flow on its own, MAKE FLOW creates a new one, and SYSTEM builds the product system.

Elementary flows take a compartment:

basic

OUTPUT "Carbon dioxide", 5, kg TO AIR

olcaBASIC searches only that compartment, and understands both ecoinvent-style categories (‘Emission to air’) and the Federal LCA Commons (FLCAC) style (’emission/air’). Where a database has several processes with the same name, one per location, LOCATION "RoW" picks the right one.

Changing a model

olcaBASIC changes existing processes and flows in place. EDIT PROCESS adds, removes and updates exchanges and parameters; LINK adds a supplier to a process; MOVE puts a process in another folder:

basic

EDIT PROCESS "Concrete block; at plant"
  UPDATE INPUT "Portland cement; at plant", cement_mass * 0.95, kg
  REMOVE INPUT "Water, deionised"
  SET DESCRIPTION "Reduced cement mix"
END EDIT

EDIT FLOW adds a flow property or changes the reference property. A property is written as a relation between units, ADD PROPERTY "Mass" AS 2400 kg PER m3, so there’s no conversion factor to enter the wrong way round, and changing the reference rescales every factor so results don’t change.

Parameters and scenario analysis

olcaBASIC turns variables into openLCA parameters, and treats them carefully, because parameters are where scripting earns its keep. Our guide to parameters in openLCA explains the openLCA side.

A LET at the top of a program becomes an openLCA global parameter, shared by every process that uses it. A LET defined from other variables becomes a formula parameter:

basic

LET cement_mass = 300
LET aggregate_ratio = 2.667
LET sand_mass = cement_mass * aggregate_ratio

openLCA recalculates sand_mass whenever cement_mass changes. A scenario that lowers the cement therefore lowers the sand too, in every process that uses either. A LET inside a PROCESS block stays local to that process, and UPDATE PARAMETER cement_mass = 280 writes a new value straight to the database.

Sensitivity analysis, Monte Carlo and contribution analysis

olcaBASIC runs one-at-a-time sensitivity analysis, moving each parameter up and down by a percentage while holding the rest at baseline:

basic

SENSITIVITY ON "Concrete block; at plant" USING "IPCC" BY 10%
  VARY cement_mass, aggregate_ratio
END SENSITIVITY

MONTECARLO runs uncertainty analysis, CONTRIBUTION shows which processes drive each impact category, and INVENTORY returns elementary flow results. SAVE RESULTS writes impact, scenario and sensitivity results to CSV.

Loops, conditions and subroutines

olcaBASIC supports the usual BASIC structures: FOR loops, IF ... THEN ... ELSE, WHILE, SUB and FUNCTION, and INCLUDE to split a large model across files. A loop that builds a family of product variants or runs a batch of calculations takes a few lines.

How does olcaBASIC show data quality?

olcaBASIC shows data quality on a contribution tree. TREE follows the supply chain down from your product for one impact category, and puts the pedigree scores of each link beside its share of the result, for your own data and the background alike:

TREE "Test pedigree check" USING "IPCC" CATEGORY "AR6-100" LEVELS 2 TOP 3

  AR6-100: 13.2698 kg CO2 eq  (Test pedigree check, IPCC)

  Test pedigree check                                            100.0%
  `-- Portland cement; at plant [US]                             100.0%  (1;2;4;1;3)  ! geographical correlation 4
      +-- Bituminous coal; combusted in industrial boiler [US]    23.6%  n.a.  ! no pedigree
      +-- Electricity; at user; consumption mix - US - US [US]     5.1%  n.a.  ! no pedigree
      +-- Natural gas; combusted in industrial boiler [US]         1.0%  n.a.  ! no pedigree
      `-- Other (6)                                                0.3%

  Weak data (score 4 or 5) on the path to the result, in the branches shown:
    Flow Reliability             0.0%
    Temporal Correlation         0.0%
    Geographical Correlation   100.0%
    Technological Correlation    0.0%
    Data Collection Methods      0.0%
  No pedigree scores:   29.7%

Scores of 4 or 5 are flagged by indicator name, and so are links with no scores at all. The summary gives the share of the result that passes through at least one weak link, counting each branch once, so ‘90% of the result comes through something with poor temporal correlation’ shows up on one screen. The pedigree scores stay as scores: olcaBASIC uses them to find where weak data matters, and doesn’t convert them into uncertainty distributions.

Your own scores go on the exchange lines, and are stored as openLCA’s own data quality entries, so the openLCA app shows them too:

basic

INPUT USE PROCESS "Portland cement; at plant", 300, kg PEDIGREE (1,2,4,1,3) COMMENT "Supplier EPD, 2025"

PRINT DQ SYSTEMS lists the data quality systems in a database with their indicators numbered in the order the scores are written.

Can you navigate openLCA from the command line?

Yes. olcaBASIC lets you move through an openLCA database’s folders and list the processes, flows and product systems in them from the command line, the same way you’d move through folders on a computer.

Because olcaBASIC is based on BASIC, the navigation commands borrow from the machines many of us first learned BASIC on. Acorn’s computers ran BBC BASIC, and their operating system (Acorn MOS) used commands like *CAT to list a disc’s catalogue. Those names made sense for a BASIC-style language, so CAT lists the current folder and DIR moves into one. Linux-style names work too, for everyone who learned on a different machine: LS is the same as CAT, CD the same as DIR, and PWD shows where you are.

Command	Linux alias	What it does
CAT	LS	List the current folder’s subfolders and contents
CAT *concrete*	LS *concrete*	List only what matches a wildcard
CAT PROCESSES / CAT FLOWS / CAT SYSTEMS		List one kind of entity
DIR "folder"	CD "folder"	Move into a folder (relative or full path)
UP	CD ..	Move up one level
BACK		Return to the previous folder
NAVIGATE FLOWS		Browse flows instead (or PROCESSES, SYSTEMS, METHODS)
CDIR "name"		Create a folder, move into it, and build there
	PWD	Show where you’re browsing and where things are built

Browsing the US LCI database for cement processes looks like this:

> DIR "31-33: Manufacturing"
> DIR "3273: Cement and Concrete Product Manufacturing"
> CAT *cement*
  31-33: Manufacturing/3273: Cement and Concrete Product Manufacturing  (filter: *cement*)

    [P]    Portland cement; at plant
    [P]    Cement mortar for ductile iron pipe
    [P]    Cement

  0 folders, 3 entities (filtered)

[P] marks a process, [F] a flow and [S] a product system. DIR checks that a folder exists before moving into it, and FIND PROCESS and FIND FLOW search the whole database by name.

Browsing never changes where things are built. New processes and flows go where SET PROCESS FOLDER, SET FLOW FOLDER or CDIR put them, so you can look round the background database without your model ending up in its folders.

Does olcaBASIC give the right answers?

olcaBASIC 0.3 gives the results the test model predicts, to the last printed digit. We tested it against openLCA 2.x with the US LCI database from the Federal LCA Commons, using a two-process model. A concrete process uses cement and sand, with the sand derived from cement_mass, and emits CO2 to air in proportion to the cement. A wall uses the concrete, some cement render set with EDIT PROCESS, and sand bedding added with LINK, both also scaled by cement_mass.

That design gives a sharp test. Every input to the wall scales with cement_mass, so a scenario that reaches all of them must scale the result by the scenario ratio, and a matching ratio proves every input followed. This is the scenario output olcaBASIC printed:

Impact Category  Baseline    Low cement  High cement
---------------  ----------  ----------  -----------
AR4-100          103.947332  69.298222   138.596443
AR5-100          104.004884  69.336590   138.673179
AR6-100          104.025245  69.350163   138.700326

Low cement (200 kg against a 300 kg baseline) should give two thirds of the baseline, and High cement (400 kg) four thirds. Four thirds of 103.947332 is 138.596443, which is what olcaBASIC printed. Two thirds is 69.298221, against a printed 69.298222; the last digit differs only because the printed baseline is itself rounded. That confirms that the shared parameter changed in every process, including the edited and linked exchanges, that openLCA recalculated the derived sand, and that the CO2 landed in the right compartment and was characterised.

Two more checks use the same model:

• Changing a flow’s reference. Giving the concrete a density with EDIT FLOW and making mass its reference left the result at 103.947332, as it should, because every exchange keeps its meaning.
• Writing a parameter directly. UPDATE PARAMETER cement_mass = 200 gave 69.298222, the same as the Low cement scenario reached by a different route.

The figures come from a test model built for these checks. The test program ships with olcaBASIC as test_features.baslca, so you can run the same checks on your own installation.

Why is olcaBASIC so strict?

olcaBASIC checks every line against the openLCA database and stops at anything it can’t match, because an LCA model has to be right to be useful, and a plausible number from a flawed model is the hardest mistake to spot.

Every name in an INPUT or OUTPUT must match a process or flow in the database. Every emission must sit in its compartment. Scenarios set input parameters, and a scenario that names a derived one is told which inputs to change. Re-running a program over an existing process gives a warning with the command to rebuild it. Each message carries the line number and a suggestion, so the fix is usually one edit.

The same thinking decides what olcaBASIC won’t do. openLCA’s IPC interface can’t say whether a flow is used elsewhere in a model, and in testing, deleting a flow through IPC succeeded while a process still used it. So olcaBASIC doesn’t delete flows or flow properties; openLCA’s own editor, which checks first, does that. We’ve asked GreenDelta to add a usage query to IPC (olca-modules issue #76).

Strict checking became a design rule in version 0.2. It makes olcaBASIC stricter than BASIC ever was, and the models more trustworthy for it.

Who is olcaBASIC for?

olcaBASIC is for LCA practitioners who know openLCA and spreadsheet formulas, and who want the repeatability of scripting in commands that read like the openLCA model itself. A .baslca file is also a readable record of how a model was built, which helps when someone else needs to check it or rebuild it.

It suits teaching well. A student can see the link between a line of olcaBASIC and the process it creates in openLCA, which makes the openLCA data model easier to learn.

Python users who want full control will find it in the scripts elsewhere in this knowledge base, starting with your first openLCA script and going on to scenario calculations and sensitivity analysis. olcaBASIC trades some of that control for speed and readability.

How do I install and run olcaBASIC?

olcaBASIC installs from PyPI and needs openLCA 2.x and Python 3.10 or later.

pip install olcabasic

Open your database in openLCA and start the IPC server (Tools > Developer Tools > IPC Server). Then start olcaBASIC:

python -m olcabasic

It connects on port 8080, reports the size of your database, and gives you a > prompt. Type HELP for the command list. To run a saved program:

python -m olcabasic run mymodel.baslca

After running a program, press Refresh in openLCA’s toolbar to see the new processes in the navigation panel.

Early release: help us break it

olcaBASIC 0.3 is experimental, and these are the rough edges we know about:

• DELETE PROCESS and DELETE SYSTEM don’t check whether other processes or systems refer to what you’re deleting, because IPC can’t tell olcaBASIC that either. Use them on your own models.
• Product systems keep the links they were built with, so after EDIT PROCESS adds or relinks inputs, delete the system and build it again.
• Global parameters belong to the whole database. If another model already uses a global with the same name, olcaBASIC updates it and prints a note with the old value.
• LOCATION has been tested against FLCAC, which has few duplicate process names. We’d like to know how it behaves on ecoinvent.
• Errors inside a PROCESS block report the line the block starts on.

Try it on your own models and databases. When something breaks, or when you want a command it doesn’t have, open an issue on GitHub with the program you ran and what it printed. Every report makes the next version better.

A note on validation

olcaBASIC makes openLCA easier to drive. The methodological decisions stay with you: the functional unit, the system boundary, the background datasets, allocation, and how the results are interpreted all need a competent LCA practitioner. olcaBASIC checks that your program makes sense as a program. Whether the model makes sense as a representation of your product is your judgement.

Frequently asked questions

Is olcaBASIC free?

Yes. olcaBASIC is open source under the MPL-2.0 licence, and installs from PyPI with pip install olcabasic.

Do I need to know Python to use olcaBASIC?

You write olcaBASIC’s own BASIC-style commands, and olcaBASIC handles the Python underneath. Python needs to be installed, because olcaBASIC runs on it.

Which versions of openLCA and which databases does olcaBASIC work with?

olcaBASIC works with openLCA 2.x through its IPC server. Version 0.3 has been tested with the US LCI database from the Federal LCA Commons, and it recognises both the FLCAC and the ecoinvent-style category naming for elementary flows.

Does olcaBASIC change my openLCA database?

Yes. olcaBASIC creates processes, flows, product systems and global parameters in the database openLCA has open, so we recommend a dedicated folder such as ’00: My Project’, or a copy of the database while you’re learning.

Can olcaBASIC check the data quality of an openLCA model?

Yes. TREE draws a contribution tree for one impact category with the pedigree scores of every link, background data included, and flags scores of 4 or 5 by indicator. A summary gives the share of the result that passes through weak or unscored data.

Can I edit an existing openLCA process with olcaBASIC?

Yes. EDIT PROCESS adds, removes and updates exchanges, pedigree scores, comments and parameters in an existing process, and EDIT FLOW adds flow properties or changes a flow’s reference property.

Can I browse openLCA processes from the command line?

Yes. olcaBASIC’s CAT and DIR commands (or LS and CD) list and move through the folders of an openLCA database from the command line, and FIND PROCESS searches the whole database by name.

How is olcaBASIC related to the openLCA MCP server?

olcaBASIC and the openLCA MCP server share the same underlying functions. The MCP server lets an AI assistant drive openLCA from a conversation, and olcaBASIC lets you drive it from a program you write yourself.

Who makes olcaBASIC?

olcaBASIC is built by Below280, the UK partner for openLCA. openLCA itself is developed by GreenDelta, whose IPC documentation covers the interface olcaBASIC uses.

Related tools

olcaBASIC is part of a wider set of openLCA automation tools from Below280:

• B280-olca-MCP: the MCP server that connects AI assistants to openLCA, and the engine underneath olcaBASIC
• openLCA-IPC-tools-python: standalone Python scripts for scenarios, sensitivity, parameter extraction and prospective electricity parameterisation
• openLCA-IPC-tools-r: R client for openLCA IPC
• openLCA-IPC-tools-fortran: Fortran IPC client and batch calculator

If you’d like help automating your LCA or EPD work, or training for your team, get in touch.