users forum
- Quantum ESPRESSO is on Facebook, on Twitter, on LinkedIn, and on Youtube
- The main place where to discuss Quantum ESPRESSO related issues among users is the users@lists.quantum-espresso.org mailing list (note the change). Only subscribed users can post: you can subscribe and browse the archives here. Searchable archives are available on mail-archive.com. Please see the posting guidelines and how to report problems before posting!
- Questions about the GPU version of Quantum ESPRESSO should also be addressed to the users’ mailing list. In this case please tag your message subject with [QE-GPU] to better identify your email.
- If you need to contact the developers, please send an e-mail to the developers’ mailing list: developers@lists.quantum-espresso.org. Please use it only for bug reports, for specific technical subjects or for topics that are not appropriate for the users’ mailing list. Generic or inappropriate questions will be ignored. You can register or browse the archives here.
Posting guidelines
Life for mailing list subscribers will be easier if everybody complies with the following guidelines:
- Before posting, please: browse or search the archives – links are available above. Most questions are asked over and over again. Also: make an attempt to search the available documentation, notably the FAQ, the General documentation, and the Input Data Description. The answer to most questions is already there.
- Reply to both the mailing list and the author or the post, using “Reply to all”.
- Sign your post with your name and affiliation.
- Choose a meaningful subject. Do not use “Reply” to start a new thread: it will confuse the ordering of messages into threads that most mailers can do. In particular, do not use “Reply” to a Digest!!!
- Be short: no need to send 128 copies of the same error message just because this is what came out of your 128-processor run. No need to send the entire compilation log for a single error appearing at the end.
- Do not post large attachments: post a link to a place where the attachment(s) can be downloaded from, such as e.g. DropBox, Google Docs, or one of the various web temporary storage spaces (e.g.: Uguu.se, WeTransfer, ExpireBox)
- Avoid excessive or irrelevant quoting of previous messages. Your message must be immediately visible and easily readable, not hidden into a sea of quoted text.
- Remember that even experts cannot guess where a problem lies in the absence of sufficient information. One piece of information that must always be provided is the version number you are using.
- Remember that the mailing list is a voluntary endeavour: nobody is entitled to an answer, even less to an immediate answer. Please check in the archive if your e-mails have gone through before thinking or even worse complaining that nobody is answering my questions. Also please remember that “smart ” mailers may recognize that a message from a mailing list was sent by you and may not show it as a new message.
- Finally, please note that the mailing list is not a replacement for your own work, nor is it a replacement for your thesis director’s work.
Reporting bugs or bug fixies
- Problems should be preferably reported as GitLab issues, or to the developers mailing list. Bug fixes should be preferably submitted as GitLab merge requests or to the developers mailing list. Please do not write to a single developer.
- Before reporting an unexpected behavior as a problem,
- check your input data: most problems originate from there
- if you have a problem with examples, look for the error message printed by the code in the output file: few things irritate developers like messages saying I got error 137 in example 24.
- carefully read the error message issued by the code, if present: sometimes it explains everything. For the provided examples, you must look inside the output files.
- trust the code if it says this doesn’t exist or this is wrong!
- check if a similar or same problem hasn’t already been reported
- Before deciding that a problem is due to a bug in the codes, verify if it is reproducible on different machines/architectures/phases of the moon: erratic or irreproducible problems, especially in parallel execution, are often an indication of buggy compilers or libraries
- Bug reports should include enough information to be reproduced, e.g. version number (mandatory!), hardware/software combination(s) for which the problem arises, whether it happens in serial or parallel execution or both, and, most important, an input and output exhibiting such behavior (fast to execute if possible). The error message alone are seldom a sufficient piece of information. Segmentation violation or obscure MPI error messages are never a sufficient piece of information.
(Last updated 10 January 2020)