document presence of code-specific python/C/... interfaces?

[ltalirz]

The "APIs" column currently documents which codes support standard programming interfaces like the QCSchema that are supported by multiple codes.

One could also use this column to record the presence of code-specific python/C/... interfaces - however, this would muddy the waters a bit.

For example, lammps has a python interface that simply takes a regular lammps input file and runs it (to be fair, it can also parse the output file to some extent).
Other codes have python interfaces that allow for very deep control of the execution (or you may even embed Python inside the regular input file, as in NWChem).

Should we add values like "Python", "C", ... to the "APIs" column when codes support some way of interacting with the code from that language?

[ltalirz]

Comment by Luca Ghiringhelli

Regarding APIs, for all codes that can run via ASE and ASR (or other workflow managers), shouldn't ASE etc. be mentioned as available APIs?

We can think about it but we will need to be careful about drawing a clear line.

From the point of view of the simulation code these "APIs" will typically just wrap the standard input file / output file interface. In the case of ASE, AiiDA etc. the interfaces are implemented in a separate codebase from the code itself, potentially by different developers.
This means they can be semi-official, out of sync, and makes it more difficult to keep the information up to date.

Happy to discuss further

[lucamghi]

I see this gets quickly complicated. For instance, in the case of ASE, for instance, there are some codes (I can speak about GPAW and FHI-aims, because I know the people involved) whose support is going to be maintained for quite a while - even though indeed ASE's interface is not complete, i.e., not all input features of the specific code are operable via ASE - but in general I see the problem. This reminds be also about PLUMED (which I guess was mentioned by one referee), where again the interface to other codes might be discontinued due to new updates, etc.
In short, I guess there will be a period of collecting suggestions from developers and "the community" in general and then see what seems really urgent to be added/changed, provided it stays in the "objective" (possibly measurable) domain.