[CPMD-list] about user's contribution

[Axel Kohlmeyer]

On Fri, 3 Nov 2006, Lan-Feng Yuan wrote:

LFY>   Dear Axel,

dear lan-feng,

LFY>   You plea that every CPMD user contributes something is very reasonable, thanks.

thanks for the support.

LFY> Now the question is: how to contribute? 

there are many ways. actually, already crossing the barrier and getting
from 'this is broken, fix it!' to 'what can _i_ do?' is the most 
important step.
 
LFY>   For example, I am a programmer far from expert, and I meet a bunch of bugs. The
LFY> latest bug is: path integral BO-MD works only when using 1 CPU. With >=2 CPUs,
LFY> only the 1st CPU is working, and the job hangs for ever in the "force
LFY> initialization" step. Unfortunately, my knowledge about parallel programming is
LFY> quite limited. What's my way to contribute? Just to report the bug? Or to learn
LFY> the related computer knowledge and fix it?

the first step always should be to report a problem when it is seen,
describe what you wanted to do and where it fails, and provide input 
examples to reproduce it. this would make people aware of the problem
(quite a few times i noticed that people were not reporting bugs, 
because they thought it is their own fault) and if it is reproducible
have the option of somebody helping you to fix it.

LFY>   I guess that this example is of typical value. Please tell us what's your
LFY> concrete expectation. Thank you very much!

my ideal scenario here is that you report the problem, somebody (e.g. 
me) reproduces it, and gives you some hints on what needs to be done.
you'd then try to implement it and after a couple of iterations the
change should be usable and integrated into the development version
of cpmd for the next release.

i (and probably others, too) also have a list of items that i'd like
to be changed within the code, where it is simply the lack of time
or motivation (when there are other more attractive projects around)
that keep me from doing this. i'd be happy to hand these 'tasks' to
somebody willing to dig into the code and learning how to work on
a larger and complex package program. some are rather trivial but 
tedious, like inconsistencies of fundamental constants that martin 
was reporting, or the use of STOP where one needs to do a CALL STOPGM()
to make sure that a parallel job using this feature does not get stuck.
some are purely technical (e.g. makefile needs a little restructuring,
because some linkers cannot handle large lists of objects. this is bit
tricky to do without breaking portability, all machine configurations
need to be reviewed etc.), some are somewhat challenging and need
some knowledge of the internal flow of control (which of course you
can learn by looking into a somewhat smaller problem first) and finally
there is the need for a user's guide that would be more accessible
for newcomers. i think this one is where the most people here are
qualified to contribute. 


cheers,
    axel.
LFY> 
LFY>   Lan-Feng
LFY> 
LFY> 

-- 
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.