Office hours, 21 August 2026#

Notes from the monthly BattINFO + Battery Genome community call (56 minutes, online). Written up from the meeting transcript. Pull-request numbers and counts are as of the call date; follow the links for the current state.

Updates from the maintainers#

Three things have been the focus since the last call.

Half-cell OCP dataset as a test case. A paper on measuring half-cell open-circuit potential profiles of various electrode materials is under review, and the dataset behind it is already open on Zenodo (10.5281/zenodo.20086298): 95 cells covering eleven materials across lithium-ion anodes and cathodes, processed by different routes, with the associated metadata. It is being used as the worked example for describing half cells in BattINFO and for making the chain from half-cell characterisation to datasets, to parameters, to models. Without any promotion the dataset is already being downloaded heavily, which is a useful reminder that even a modest dataset with proper annotation finds an audience.

Parameter sets and BPX. Work has started with the BPX maintainers in the UK on using the Battery Genome to document and share battery model parameter files, linked to the half-cell OCPs above. Published parameter sets (Chen 2020 and others) are being broken into their constituent pieces so that a single OCP profile or a single material’s parameters can be reused on their own. The longer-term goal: you build an NMC811/graphite pouch cell with no parameters of your own, find the five published sets closest to it, and use them as the starting point for calibration in PyBOP or similar. The DigiBatt project already runs this loop with PyBOP as the calibration step, pulling the cell’s metadata from the registry. Anyone with parameter sets, published or not, who would like them indexed is invited to get in touch.

Ontology release wave. chemical-substance, domain-electrochemistry and domain-battery have all been bumped to new versions in response to term requests and issues raised since spring, and BattINFO now imports the new versions.

Discussion#

A catalysis extension to the Battery Data Format (Graham)#

Graham presented a catalysis data format built as an extension of BDF 1.3.0: it takes the full BDF schema and adds aliases plus extra columns, mainly per-species faradaic efficiencies, which catalysis groups genuinely measure for fifty or more products. It is published under a w3id namespace. The source file is modest: you define a chemical and say which column shapes apply to it, and the Turtle is generated, so it is less error-prone than hand-writing every term. Each column header still needs its own IRI. A dataset using it needs to be published in the coming weeks (a paper has been accepted).

Points from the discussion:

  • Terms this general (chemical species, faradaic efficiency) could be promoted to domain-electrochemistry or domain-battery; what gives pause is the very specific per-species terms, which are better left in the application ontology where the authors have full control. If they are promoted later, the application terms can be deprecated and replaced.

  • For now the catalysis data ships with a metadata sidecar that points the table schema at the extension. The extra columns are unknown to a plain BDF reader and only come through if you ask for non-BDF columns.

  • The wanted end state is a formal BDF extension mechanism: a set of rules an extension must obey, a validation step, and a metadata key that tells the reader to pull (and cache) the extension schema so it can at least accept the columns and do machine-readable to preferred-label conversion. Nothing more elaborate than that. Reading and writing BDF metadata has to be sorted out first.

  • Several groups want to extend the existing ontologies rather than reinvent them, so a written guide on the standard way to do this would be valuable. Redox-flow groups have been asking similar questions recently.

Outcome: tracked as an issue against BDF 0.3. Graham and Simon will look at it together the following week.

Battery Genome platform: code, docs, API (Marija, for FULLMAP)#

FULLMAP asked for an update on code availability, documentation and API access. Recent platform work has gone into the human-facing surfaces: a dossier view that compiles one cell’s information from its constituent records (cell spec, electrode spec, electrode as built, active material) with KPIs promoted to the top, the measurement dataset plotted and linked back to its protocol, and batch statistics such as loading and areal capacity. An API endpoint exists, but it is not yet considered robust enough to open fully. FULLMAP will be given early access.

Outcome: FULLMAP to send GitHub IDs by email; Simon adds them to the early-access list. A platform update is due the weekend after the call (ahead of a talk at Swiss Battery Days), and registered users will be emailed when it lands. Search and filtering are also being worked on.

Adding BattINFO metadata to BPX files (Carlos)#

Carlos (Imperial College, supporting the Faraday Institution’s BPX standard) is implementing BattINFO on BPX so that BPX, BDF and BattINFO metadata fields can talk to each other. The question: a BPX file is JSON, so should metadata go in a sidecar, be appended as a JSON-LD block, or live in a new metadata section of the same file?

The view offered: because BPX is already JSON, a JSON-LD interpretation inside the file is the most interesting route; non-JSON-LD keys are simply ignored by JSON-LD processors. A second option, if the metadata is fairly fixed, is to host it at a web address and add a single metadata field to the BPX schema holding that IRI. Sidecars encapsulate cleanly but inevitably get separated from their data. Mapping every BPX parameter to the ontology is best done through a BPX application ontology that maps to the top-level terms; some early work on that exists from when BPX was first proposed, giving one-to-one BPX field to IRI conversions.

Several attendees had not heard of BPX. It came out of the Faraday Institution multi-scale modelling project with support from BMW, AVL, About:Energy, Ionworks and the PyBaMM developers. The Battery Genome is starting to index BPX examples so that cell specs and instances can be linked to their parameter sets and simulated in PyBaMM or BattMo. On the question of what counts as “close enough” when reusing a parameter set, the working rule is about 20 mV RMSE, with no strong basis behind the number.

Source of truth: should records be editable on the platform?#

Simon put a strategic question to the group. Today the Battery Genome is a reorganisation of information published elsewhere: a paper and a Zenodo deposit get read and harmonised into records. If a contributor spots a mistake, the only route is to fix it at the source and wait for the next version to be scraped. The alternative is to let maintainers or named contributors edit records on the platform, at the cost of the record diverging from its source, with all the push-back problems that brings.

The room came down clearly on one side:

  • Graham: leave it to Zenodo. Otherwise there are two records that disagree and it depends where someone happened to get their copy. It is also less work.

  • Marija: agreed, at least to begin with; Zenodo will not be the only source of truth forever, and push-back gets more complicated with each new one. Asked how propagation would work in the second model: technically, the Zenodo API can create a new version, provided the editor has rights on the deposit, but it is a can of worms.

  • Felix: keep it an aggregator rather than opening up the authorisation problems (what if the editor has no ORCID, or the ORCID is not linked to the Zenodo deposit). Be explicit on the page about which version is displayed and point people to the source if they need the latest.

  • Sudeepika (in chat): keep the original immutable and add corrections or annotations as a layer on top. Felix added that a diff-style layer would be feasible if the corrections are a few numbers.

  • Graham: since BattINFO can already upload to Zenodo programmatically, offer “make this a new version of my existing record” there, so Python-comfortable users fix the source through the same tool.

On mechanics, the backend already keeps the full history of every record, so the original is retained when a new version lands; the issue is purely divergence. Checking for new Zenodo versions could run every six months or so, or on a slow crawler that compares versions and only re-downloads what changed (Zenodo checksums files, so it does not re-upload unchanged ones). A “report an issue” or “ping” button on a record, raising its priority for a re-check, was also suggested. Scale is the open worry once records number in the tens of thousands, but it can be handled when it becomes a problem.

Outcome: the Battery Genome stays an aggregator that reads from the source of truth. Contributors who find an error are pointed back to the source, and the fix propagates on the next version.

Back-of-the-envelope cell designer (demo)#

Simon showed a cell design calculator built for the KPI tables that proposals keep asking for. Three levels of detail: spec-sheet (format, chemistry, duty cycle; gives high-level KPIs and benchmarks against the corpus with nearest neighbours), engineering (mass loading, porosity, material ratios, N/P ratio) and laboratory (everything). Designs can be pinned and compared, for example NMC811/graphite against a 10% silicon-graphite variant, shared by link, and exported as a BattINFO cell spec; BPX export is in progress, which will also feed a physics model so the loading sweeps are not purely thermodynamic. The OCV profiles come from literature sources, so the design is traceable back to the parameter-set records. Felix asked how the OCV source is chosen when several exist (graphite has about five): currently the first in the list; making it selectable is a natural next feature. It has been validated against every spec in the corpus; bugs and oddities are welcome as issues.

Action items#

  • FULLMAP sends GitHub IDs; Simon grants early access to the API and backend.

  • Extending BDF semantics to catalysis, or more generally to per-species quantities, goes on the BDF 0.3 list; Graham and Simon review it next week.

  • Battery Genome remains an aggregator of published sources; no in-platform editing for now.

  • Simon indexes more BPX parameter sets over the coming weeks and continues the cherry-pick parameterisation and calibration work.

  • Notes go to this section of the docs.

Prepared slides#

The slides prepared for the call (the call itself was largely demo and discussion): open the deck.