# AiiDA Team Meeting 2025-01-23 ###### tags: `team meetings` ###### time: 14:00 CET [TOC] ### Present - Alex - Marnik - Ali - Miki - Julian - Kristjan - Giovanni ### Catch-up round *Max. 3 minutes each* Alex: - Release v2.7.0 - If you have anything you want to be in please mark the issue or PR with Project v2.7.0. You can add the issues/PRs that you would like to be included in the release. Next meeting we will discuss a timeline. - @Kristjan Should we push the pydantic PR for release? - KE: I would wait until we have the aiida-restapi built/tested on it. (or if the pr looks perfect, i guess we can also merge.) - We have very new features like async and it would be nice to include them but should we mark them somehow as experimental with no API guarantee? If we do not mark it as experimental, then should we do a pre-release to test it in plugins aiida-quantumespresso? Jason (as Alex remembers it): There is no real problem with the python API, since we have separated the API into async and sync. Giovanni (as Alex remembers it): Creating an infrastructure to mark things as beta needs to be also maintained, we might end up in the state where we mark everything as experimental, so I prefer to use a prerelease and test it on aiida-quantumespresso - Jason: We need to make sure that the docker workflow works so a new image is pushed in the next release for Sasha - There seems to be interest in running AiiDA on windows (see PR [#6715](https://github.com/aiidateam/aiida-core/pull/6715)), has this been the first time? Should we support in CI? Giovanni: We will not offer any offical support but as in this case we will review and merge fixes for windows if they come from outside of the community - @Sebastiaan I think circus works with py3.13 (almost all aiida tests pass except two ssh tests that are probably related to paramiko), can we push a release on circus? - Want to make aware about the kubernetes scheduler [kueue](https://github.com/kubernetes-sigs/kueue) that CERN is standing behind, we should keep an eye on it to know if we should support it in AiiDA (There was [a workshop in Zürich](https://indico.cern.ch/event/1487613/) two weeks ago, maybe one can join such a workshop next year) Marnik: * Who has access to the `aiidateam` RTD account? Ali: * There is a [PR](https://github.com/aiidateam/aiida-core/pull/6715) open from the community, that requires a Windows users to review. Who's gonna reveiw? @Edan ? * [AsyncTransport](https://github.com/aiidateam/aiida-core/pull/6626) ready to merge :sunglasses: * aiida-website: [PR updated contributors](https://github.com/aiidateam/aiida-website/pull/84) --Disclaimer: might include mistakes-- * @Sebastiaan still re-review [PR 6567](https://github.com/aiidateam/aiida-core/pull/6567) ? * AEP: read below Miki: * aiida-atomistic * finalizing the plugin migration guide (meeting with Marnik planned next week, to discuss aiida-quantumespresso migration) * [PR](https://github.com/aiidateam/aiida-core/pull/6632) to `aiida-core` is ready, but I will merge it after the above mentioned meeting (in case we need to change something else in the API) * I expect to make an "official" release before the end of February Jason: - GSoC 2025 projects. - [#6707, #6701, #6698] to improve the daemon debugging and memory leak testing. - [#6722](https://github.com/aiidateam/aiida-core/pull/6722) rethink the public APIs. - Github has arm64 CI runners. - [#6704](https://github.com/aiidateam/aiida-core/pull/6704) mypy check by Daniel, I gave it a review, but since it invole storage part, better one more expert or orm module give it a look. - Plumpy PRs to separate rmq module and simplify Savable interfaces. Xing: * Nothing to report for aiida-core. Julian: * [[#6619] QueryBuilder: Implementation of `contains` Filter Operator applied to JSON Fields for SQLite backend](https://github.com/aiidateam/aiida-core/pull/6619): From Zisen, merged -> Should now have full feature parity between PSQL and SQLite (https://github.com/aiidateam/aiida-core/issues/6435) * Start thinking about AiiDA tutorial 2025 with Ali: https://hackmd.io/FDrb1oVkT5uOWGcvMbG8jw * Would like to get the `profile mirror` feature to a state for dogfooding soon: https://github.com/aiidateam/aiida-core/pull/6723 Kristjan - nothing to report Edan: - Nothing to report --- ### Discussion #### Aiida mentor program - Instead of an aiida tutorial session this year, we could do an "AiiDA mentor program" where people can submit a project they want to implement with AiiDA and one AiiDA developer is deligated for each project. This will be 3 full days of commitments and afterwards bi-weekly checkups for 3 months. #### AEP on Stashing Right now, `RemoteStashFolderData` which serves as a “symlink” for stashed data, is immutable. That causes some difficulties, especially when users are required to move their stashed data to somewhere else. All `RemoteStashFolderData` point to a wrong path, and they cannot be updated. Solution is to make that information mutable. To do this, there are two possible ways we could think of. 1) `RemoteStashFolderData` would save the relative paths instead of absolute paths (still immutable). However, this path is relative to a *root* path where all stashed data of that computer node is stored. The *root* path can be set globally for each computer with `verdi computer config`. This way to update `RemoteStashFolderData`, one just needs to reconfigure a computer. - Pros: - User friendly - Super easy to update `RemoteStashFolderData` nodes, all at once. - Cons: - All stashed data associated with a computer node must share the root path. 2) Store the absolute path in extras -mutable- of `RemoteStashFolderData`. In case of a data movement one has to update extras for each node. - Pros: - Flexibility, every `RemoteStashFolderData` node associated with a computer don’t need to be on the same root. - Cons: - A little bit of hassle to update all `RemoteStashFolderData` that share the same root. - Less intuitive and more “hacky”