Aiida to control instruments with SiLA2.0

General Usage
,
1

Hi everyone,

I’m researching the suitability of Aiida for instrument control through the SilA2.0 lab protocol. We are considering Aiida as an orchestrator for an autonomous laboratory. I have looked at some other orchestrators like Alab Management, Chemos2.0, GLAS. Aiida seems like a good candidate, especially considering it’s maturity compared to the others.

But the only thing which I’m still not sure about is instrument control. I know Aiida is really meant for data analysis. But in Chemos2.0 it seems like Aiida is used for instrument control. For communicating with the actual instruments they use SiLA2.0, which is a python communication standard for controlling lab instruments. It works over GRPC with a generated python client. So I could imagine that one could just import this client a task of a workgraph and control the instrument from there. As so:

@task.calcfunction
def step1():
  from sila2.client import SilaClient
  client = SilaClient.discover(...)

This does seem to work. But this approach has a few problems, the SiLA client must connect to the SiLA server on each task. And the SiLA server does not get “locked” whenever a SiLA client connects to it, so this could result in two workgraphs trying to control an instrument at the same time. I know Aiida works with computers, which to my knowledge could solve these issues, so a colleague of me suggested that the SiLA server could act as a computer. But when looking a the examples of computers it seems like the GRPC communication with the generated clients does not work with that.

So that leads to my questions: “Is it possible to implement SiLA2.0 servers as Aiida computers and assign these computers to a step”.

Thanks.

2

Thanks for your interesting question!

I’m not sure your usecase can be covered with AiiDA. Also from your link, I think in ChemOS they are using AiiDA to run some simulations, not really to control experiments.

We have experience controlling experiments, see this paper: A bridge between trust and control: computational workflows meet automated battery cycling - Journal of Materials Chemistry A (RSC Publishing)

However, in that case anyways AiiDA is talking to tomato, an external software developed at Empa that essentially takes the role of a experimental scheduler (in practice, from the point of view of AiiDA, it’s like SLURM. AiiDA submits jobs to it, and then tomato takes care of coordinating the work with the actual hardware.

I imagine you would need to implement the equivalent of tomato to use the SilA2.0 protocol - so that can stay always online, check the experimental hardware status, ensure that there is no concurrent use of the same resources via some sort of queuing system, …

Another alternative (probably similar to what ChemOS is doing) is that you use something else for the lab orchestration, and AiiDA just plays the role of one of the “instruments” that you control (e.g. to run simulations, but possibly to do more).
This is also what we do when interacting with FINALES, see e.g. the AiiDA tenant here: Brokering between tenants for an international materials acceleration platform - ScienceDirect (note that there is a newer version of FINALES, see https://advanced.onlinelibrary.wiley.com/doi/full/10.1002/aenm.202403263)

Note however that FINALES is not an active orchestrator: it’s more like a “queue” to have different instruments orchestrate. But I’d suggest looking into it because it standardizes via JSON schemas how communication should happen. An actual orchestrator will then look like another tenant to FINALES, that can place requests to other instruments (tenants) via FINALES.