Channels

• DL_POLY community list (link opens in a new window)
• ChemShell Forum (link opens in a new window)

Users Code of Conduct

1. The main purpose of a community list (it is an all-to-all email facility beyond a traditional Forum and but much less than a Portal) is for all DL_Software users to exchange ideas and help each other.  Please make use of it.  If someone has a smart way to do something, the community list is a good place to describe it.  It is also a good place to ask for advice from the rest of the community.  If you see such a request and you have an answer for it or could comment on it constructively, then please do feed information back to the community and the enquirer.
   
   
2. Please do not bombard the DL_Software authors with ill considered e-mails.  Unfortunately, we get many requests for advice on how to apply the code in areas we are not expert in, and these are difficult for us to deal with effectively.  This is why the community list was set up and such enquiries should be posted there.  Our role, primarily, is to provide working software, not teach basic principles of the particular modelling area and many of the queries we get are basically of that kind.  The time we spend answering queries detracts from improving and adding new features to our codes.  This does not mean you should never contact us directly however.  Reports of suspected bugs (and indeed fixes!) are essential (see below).  Also, contractually speaking, it is only academic researchers and students at UK universities that are entitled to our advice at all times, the rest shall be at our discretion.
   
   
3. If you seek information, please make sure it is specific to the DL_Software program before you ask us.  There are now plenty of good introductory texts detailing the general principles of molecular dynamics and Monte Carlo.  We recommend Allen & Tildesley's "Computer Simulation of Liquids", Frenkel & Smit's "Understanding Molecular Simulation" and Rapaport's "The Art of Molecular Simulation".  Also, please make use of the provided with the programs manuals.  We get many requests for information that is already available, either in the specific manual or on the specific DL_Software program website.  Please check the FAQ section or previous mailshots for possible answers.  You might also search the relevant community lists or scan the CCP5 Infoweb, which has lots of useful articles on methodology.
   
   
4. Please do not post suspected bugs on the community lists. These should be reported directly to the authors by e-mail in the first instance.  Often, such reports are simply misunderstandings or misapplications of the programs and not bugs at all.  These can only serve to damage the confidence of other users unnecessarily.  Similarly, please do not post fixes on the community lists before advising with software authors. Send them directly to us so we can check them out.  Do not leave out essential detail, such as:
   
   • which DL_Software program and version you are using
   • the platform of execution
   • compiler type and version
   • MPI/openMP type and version
   • type of execution (serial, parallel and how many MPI/omp tasks/threads)
   • a brief description of the intended simulation
   • link with uploads of all relevant input and output files (via any file sharing utility).  Avoid uploading executable files.
     
   • your suggestions for possible causes and fixes if you have any
5. If we agree there is a problem that needs sorting out we will undertake to fix it and broadcast the news to everyone in one of our mailshots.  Also, please do not leave a bug you have found for somebody else to fall over.  You have a moral responsibility to report it.
   
   
6. In general it is not reasonable to expect in-depth advice from us by e-mail on how to adapt the source code for purposes beyond what is already available.  It is extremely difficult to provide it succinctly and accurately.  Our experiences are that providing such advice is heavily time consuming and unrewarding.  It almost never leads to usable modifications being fed back to us (or indeed, to an acknowledgement of the assistance given).  Our responses, therefore, tend to be terse and limited, which is regretable but is probably the best we can do.  The only really viable way to manage such requests is through a properly constructed collaboration, but for reasons of workload we must be free to decide upon entering these or not. Otherwise, community lists and Forums are probably the best resource for such advice.
   
   
7. Please do not trade in illegal copies of DL_Software programs. There is no better way to propagate incorrect versions.  Recipients of such bootleg copies may not be on our mailing list and thus never hear about bugs and fixes.  Much misery will follow.
   
   
8. If a user wants to contribute a developed feature they may do so by sending it to the authors in the specific DL_Software program style (Fortran90 for DL_POLY) with documentation outlining the methodology (paper references) and the particular implementation details.  Contributors should understand that they are making a free contribution without conditions or obligations.  We are happy to make appropriate acknowledgements but we will not enter into any contractual agreement.
   

Ilian Todorov