# AiiDA Team Meeting 2022-03-23 ###### tags: `team meetings` ###### time: 10am CET [TOC] ### Present * Sebastiaan * Simon * Francisco * Jason * Chris * Giovanni ### Catch-up round *Max. 3 minutes each* Sebastiaan: * Merged PRs: * CLI: fix shell completion of script for `verdi run` [[#5430]](https://github.com/aiidateam/aiida-core/pull/5430) * CLI: fix choices of `InteractiveOption` not being displayed [[#5432]](https://github.com/aiidateam/aiida-core/pull/5432) * CLI: fix prompt info being shown in `verdi code setup --config` [[#5434]](https://github.com/aiidateam/aiida-core/pull/5434) * `verdi code setup`: make `--input-plugin` optional [[#5436]](https://github.com/aiidateam/aiida-core/pull/5436) * `CalcJob`: always call `Scheduler.parse_output` [[#5458]](https://github.com/aiidateam/aiida-core/pull/5458) * `aiida-core==2.0.0b1` released. Should ask developers soon if they have gotten the chance to test it and start migrating plugins. * Confirmed the [SqlAlchemy recursion error](https://github.com/aiidateam/aiida-core/issues/4876) with just a single daemon worker under heavy load. This is a critical issue that should be resolved with priority. * Created the [`aiida-shell` plugin](https://github.com/sphuber/aiida-shell) which presents the current state of my ideas for the [AEP to make running shell commands easy](https://github.com/aiidateam/AEP/pull/32). It supports running shell commands on local and remote computers. It works out of the box without setting up codes or computers and so makes it very easy for new users. Most simple example running the `date` command: ```python from aiida_shell import launch_shell_job results, node = launch_shell_job('date') print(results['stdout'].get_content()) ``` Developed the required features and interface with use of two external people active in pharma and finite element modelling, to get an idea of typical workflows in other domains. * Been looking into [Research Object Crate](https://www.researchobject.org/) as a way to export AiiDA data in interoperable manner. Is in the context of a collaboration with ELN developers (Chemotion, OpenBIS, Cheminfo, Elabftw, AiiDAlab) to allow to easily exchange data. Opened [a discussion](https://github.com/ResearchObject/ro-crate/discussions/196) on their Github and they said that they were working on this use case. They invited me to their public meeting ([meeting notes](https://docs.google.com/document/d/1shvkoowuCVUy8E2ujnVPclaoQO4jGKmZpafjOR0OfBw)) and gave a presentation of AiiDA. They are now working on an extension to represent executed workflows, called [process run crates](https://docs.google.com/document/d/14IaXEMdi0Ue8zRSZcPP1_H6seusefavYdettgX2X1YY). Seeing if we could use this. * Been invited to submit an entry for [Nature reviews physics: Tools of the Trade](https://www.nature.com/natrevphys/news-and-comment?type=tools-of-the-trade) on AiiDA. Small piece of 500 - 600 words on AiiDA and the common workflow project. Trying to time its release with release of v2.0 for publicity. Unfortunately they only allow a single author, but I can add acknowledgments. My idea was to simply add [link to contributors](https://github.com/aiidateam/aiida-core/graphs/contributors). Any other preferences suggestions to add to acknowledgments? * Open questions in discussion on PRs to reduce number of methods in `Node` namespace: * Should the deprecation warnings be hidden by default and made visible by setting an environment variable? Instead of an environment variable, should we use a config option instead? There are already options to hide/show very specific deprecation warnings * Ideally all attribute related methods should be moved under a single subnamespace. Ideal choice would be `Node.attributes` but unfortunately this currently already exists, so we cannot use it without breaking. Alternatives, such as `attrs`, are probably worse, but might be necessary if we don't want to break it. * Moving all repository related functionality proposed to `Node.repo`. This goes a bit against the recent effort to decouple the implementation details of the default storage backend (`psql_dos`) from the language in the API. For example, the difference the user should be concerned with, with respect to data stored by AiiDA, is that which is queryable and that which isn't: JSON-serializable data versus binary blobs. One other suggestions would have been `Node.objects` (since the repository already uses "object" in its terminology lent from object stores, such as `get_object`, `list_objects` etc.). But this is already in use to expose the `NodeCollection`. Chris: - demo time - drop master/develop split Francisco: - Assisted in the release of `aiida-core==2.0.0b1` but been focusing on other scientific / admin tasks since. Jason: - After checkout to `.post0`, verdi autocomplete not work again. - [PR merged #5350](https://github.com/aiidateam/aiida-core/pull/5350): `JobTemplateCodeInfo` class is dedicately created and decoupled to handle the `code_info` for runline generation of job script. - Keeps working on migrate aiida-optimade to `v2.0.0`, the primary new feature added is querying on the archive directly through sqlite_zip backend. Giovanni: - added list of .aiida files from Materials Cloud to the [discussion](https://github.com/aiidateam/aiida-core/discussions/5407#discussioncomment-2405502). Someone has time to test them? (I won't for the next two weeks :-( ) Simon: - _Mostly focused on MarketPlace and AiiDAlab these past two weeks._ - [ongoing] Fixing [plumpy test failures](https://github.com/aiidateam/plumpy/issues/227). ### Specific Agenda Items