Contact information and user mailing lists

  • The main place where to discuss Quantum ESPRESSO related issues among users is the pw_forum@pwscf.org mailing list. Only subscribed users can post: you can subscribe (note that @yahoo.com e-mails do not work any longer) 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 pw_forum@pwscf.org mailing list. In this case please tag your message subject with [QE-GPU] to better identify your email.
  • If you need to contact developers, please send an e-mail to the developers’ mailing list: q-e-developers@qe-forge.org. Please use it only for specific technical subjects or for topics that are not appropriate for the general mailing list pw_forum. Generic or inappropriate questions will be ignored. You can register or browse the archives here.
  • … and finally, Quantum ESPRESSO is on Facebook and on Twitter.

POSTING GUIDELINES

Life for subscribers of pw_forum 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: point a linker 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.: ExpireBox, File.Town, Uguu.se)
  • 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 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

  • Problems should be reported to the pw_forum mailing list (not 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 preferably be filed using the bug tracking facility of qe-forge.org: http://qe-forge.org/gf/project/q-e/tracker/
  • 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 is usually not a sufficient piece of information. Segmentation violation or obscure MPI error messages are never a sufficient piece of information.

(Last updated 5 December 2016)