Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not always fetch gbw files to local folder #68

Open
danielhollas opened this issue Feb 16, 2023 · 0 comments · May be fixed by #72
Open

Do not always fetch gbw files to local folder #68

danielhollas opened this issue Feb 16, 2023 · 0 comments · May be fixed by #72
Assignees
Labels
enhancement New feature or request

Comments

@danielhollas
Copy link
Collaborator

.gbw files store the molecular wavefunction and are typically quite big.

Currently we always fetch them from the remote_folder to the retrieved folder, which is not ideal because the user cannot get rid of them without deleting the whole workflow, due to AiiDAs strict provenance policy. Thus, users need to be able to specify whether this file should be stored before the calculation/workflow is submitted.

There are two design questions here:

  1. What should be the default behaviour
  2. How can the user change the default.

I think that actually changing the default, and fetch this file only when requested, would be an okay thing to do. Typically, users know if they need the MO files before hand, and even if they don't, they can always fetch it aposteriori from the remote folder, where the file is stored until it is cleaned. If that is the case, the users could opt in to this by specifying the the aiida.gbw file in the existing inputs.settings.additional_retrieve_list. This approach would require the minimum changes on the side of the plugin, but the big downside is that this is a breaking change, and would need to be thoroughly documented. The upside is that keeping the default, the users are never able to get rid of these files once they are fetched, as explained above.

If we want to keep the default behaviour, we need a new input. This could be a new input node, of type Bool. Alternatively, we could add a new key to the existing Dict inputs, either inputs.parameters or inputs.settings (the latter seems more appropriate to me).

@pzarabadip do you have any thoughts on this? Whatever we decide, I am happy to implement this because I for sure need this for my app. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant