wannier-developers
Improvements to the library mode of Wannier90
There are a number of suggestions of missing features of the library mode, improvements and suggestions. Please reply to this issue with your comments.
Hello Giovanni,
I think the library mode should provide the same features as the normal Wannier90 code (spinors etc). Currently the library mode is quite decoupled from Wannier90 which means that new feature in wannier90 has to be duplicated in the library mode.
Maybe we can try to make the library mode more like a wrapper that call Wannier90 as much a possible (to avoid duplication of code and ease maintainability).
What do you think?
I think it might be useful to have Python bindings for the library mode (using something like f2py). What's your take on that?
I agree with the python bindings. I don't have direct experience of doing this - but it is worth looking at https://github.com/jameskermode/f90wrap . I think the author of f90wrap would be happy to talk to us.
We wrote the original library routines as we thought it a nice idea - but without any use case in mind. I didn't manage to update them when we added the spinor functionality (actually nothing special - just book keeping). In a sense wannierlib.f90 is just a wrapper to the main wannier90 routines.
Before coding anything, I'd like to understand how the interaction with a library should work. At the moment we pass system data (crystal structure, kpoints, overlaps, projections) via the library call. And wannier specific parameters (number of steps etc) via the regular win file. Is this the right way to do it - or is there a smarter way?
Hi all,
as commented by email with Giovanni, it would be nice to have a parallel library, and as Samuel said 2 years ago access to all features. From Giovanni and Jonathan's comments it is not clear to me if the lib mode is just a wrapper on a common code base or not (and if so, why would any refactoring be needed to make things parallel?). Going through files is a bit contradictory, and there are more and more codes which actually do things with the resulting Wannier functions.
ciao Mathieu
Indeed, the plan for the new version is to avoid going through files.
Briefly, the library mode was initially written as a convenience functionality, with a fixed API. As the code evolved, it is also becoming complex or even impossible to support more features (e.g. the function signatures is fixed, and adding new parameters to the functions would break backwards-compatibility).
The correct way to do this (at least we believe at this stage) is to have a single entry point to set internal variables in the code, and call it many time to set all internal variables, and then call a single function to run the Wannierisation and retrieve results.
Moreover, to allow multiple codes to call in parallel (but independently) the Wannier90 kernel (needed by some highly-parallel codes), we need to replace all public, save variables with user-defined fortran types and pass them as parameters between all functions (so that multiple variables can be set by the calling code, and passed to the internal routines independently, e.g. to do different Wannierisations). This is the part that requires significant refactoring, possibly various weeks or, I believe, even months. Also, while doing this, we will probably also change the main code to be only a thin wrapper around the library, ensuring that the library is always working.
I hope this clarifies a bit!
Sounds good - except for the "not scheduled yet" part :) Keep us posted, and if you want to discuss the api we can set this up with the 2-3 other abiniters who contribute to that part of the code.
Best
Matthieu
On Sat, Dec 22, 2018 at 11:11 PM Giovanni Pizzi [email protected] wrote:
Indeed, the plan for the new version is to avoid going through files.
Briefly, the library mode was initially written as a convenience functionality, with a fixed API. As the code evolved, it is also becoming complex or even impossible to support more features (e.g. the function signatures is fixed, and adding new parameters to the functions would break backwards-compatibility).
The correct way to do this (at least we believe at this stage) is to have a single entry point to set internal variables in the code, and call it many time to set all internal variables, and then call a single function to run the Wannierisation and retrieve results.
Moreover, to allow multiple codes to call in parallel (but independently) the Wannier90 kernel (needed by some highly-parallel codes), we need to replace all public, save variables with user-defined fortran types and pass them as parameters between all functions (so that multiple variables can be set by the calling code, and passed to the internal routines independently, e.g. to do different Wannierisations). This is the part that requires significant refactoring, possibly various weeks or, I believe, even months. Also, while doing this, we will probably also change the main code to be only a thin wrapper around the library, ensuring that the library is always working.
I hope this clarifies a bit!
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/wannier-developers/wannier90/issues/2#issuecomment-449600608, or mute the thread https://github.com/notifications/unsubscribe-auth/AGzp75XVWn8QC7Uvu5t3TfqIItqRYqdpks5u7q4hgaJpZM4JygIh .
--
Professor Matthieu J Verstraete
Fellow, American Physical Society
Chair, Steering Committee, European Theoretical Spectroscopy Facility
www.etsf.eu
Member, Young Academy of Europe yacadeuro.org
Group web page: http://www.nanomat.ulg.ac.be/
Nanomat lab
Q-Mat center
CESAM Research Unit
Universite de Liège
Institut de Physique, Bat. B5a, 3/7
Allée du 6 aout, 19
B-4000 Sart Tilman, Liège
Belgium
European Theoretical Spectroscopy Facility (ETSF)
Phone : +32 4 366 90 17
Fax : +32 4 366 36 29
Mail : [email protected]
[email protected]