[Pw_forum] Change in the behavior of "Reply"
giannozz at democritos.it
Fri May 18 12:25:23 CEST 2012
Please note that the behavior of this mailing list with
respect to the "Reply" command has been reverted to the
previous "Reply-to munging" option, that is: if you hit
"Reply", the message will go to the mailing list, not to
the poster. So please THINK before hitting "Reply" (think
EVEN MORE before hitting "Send"), avoid unnecessary or
inappropriate traffic in this mailing list.
Here is a reminder of the guidelines for posting:
Before posting, please: browse or search the archives – links are
available in the Contacts page of the quantum ESPRESSO web site.
Most questions are asked over and over again. Also: make an attempt to
search the available documentation, notably the FAQ, the User Guide,
and the Input Data Description. The answer to most questions is already
* 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, NEVER use “Reply” to a
* 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.
* 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
* 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.
* Finally, please note that the mailing list is not a replacement
for your own work, nor is it a replacement for your thesis
* 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
* 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", or "What does error # 1924
* 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
* trust the code if it says "this doesn’t exist" or "this
* check if a similar or same problem hasn’t already been
* 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:
* 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.
Paolo Giannozzi, IOM-Democritos and University of Udine, Italy
More information about the users