cp2k release goals

[Axel]

hi teo, luca.


On Jan 5, 11:11 am, Teodoro Laino <teodor... at gmail.com> wrote:
> Ciao Luca,
>
> On 5 Jan 2008, at 16:03, luca wrote:
>
> > Most persons with not equivalent CV can use famous (some not free
> > and not good ) programs because there are
> > a lot of documentations, user guides, howto, and case studies.
> > In contrast there are some very good and free program that are
> > unknow/unused to the community
> > and they seem do not have a lot of documentation. Is there a
> > relationship?

yes. first off. many commercial software packages have been around
for a looooong time and thus _more_ experience exists and is
accessable.
many open source projects have started much later, and people who have
less experience tend to stick to what they know.
secondly, commercial packages can pay people to do "unpleasant" jobs
due to their revenues (although you have to charge ridicolously high
amounts of money to really make some money off computational
software).

it is also that people tend to forget the "contract" of open source
software: everybody contributes, therefore everybody benefits.

unfortunately, over the last decade it seems as if fewer and fewer
people are willing to invest any effort beyond of what they need
for themselves and their own project. this goes up to the point of
simply not reporting bugs and using (bad) workarounds instead of
having the problem solved properly and in rare cases even being
happy that others have not (yet) found that bug, so that their
calculations could not work. also, too many people seem to be afraid,
that posting a (stupid?) may have a negative effect on their
reputation
and thus remain "lurkers".

i have been trying to encourage people to participate more in open
source projects for almost as long, and so far the most common
response was: i am not a programmer/expert, i cannot do anything.

this is PLAIN WRONG. it is the newbie who has problems understanding
and documenting while you figure out how things work, is the fastest
and best way to learn a package properly. if you document what you
figure it out, it is likely that another newbie will understand it,
or from the questions of other newbies you can learn more about the
method and look into questions, you didn't ask yourself up to now,
but _should_ have asked. this is how i learned CPMD, and a tutorial
can be easily created from the outcome of that. it will be even better
if several people would "gang up" and share the workload and have some
expert overlooking it. this would make the most out of everybody's
time.

IMNSHO, the real trick is to be confident enough to take your time,
pick examples that are simple enough to predict the results, do the
calculations quickly and find out what went wrong, if you don't get
what you expect. if you learn a craft, you don't start by doing the
most complicated work either. you learn each technique in steps and
_then_ move on to the more complicated work.

> > Make some tutorials or case studies, can help to debug the program
> > and  can be
> > a good start point for old user and new user.

those suggestions are easily made. but everybody has to stop
saying what should be done and rather ask themselves "what can
_I_ do?". this is why i didn't suggest to have a release (i guess
everbody agrees on that), but rather was asking what do you all
want to see in it? what do you think is working well enough?

>
> That's absolutely true. But the power of the open source community is
> mainly based on the fact that everybody
> contributes even with a small stone to the construction of the main
> building, under a continuous refereed work
> (since each line (of source, tutorials, case studies, documentation)
> you make public can in principle be double-checked
> by trillions of people).
> But exactly as I said previously for the release topic:
> documentation, tutorials and case studies requires lots of
> human power (ask Axel how much efforts he put in the CPMD
> tutorial ;-) at the same time I think that once the
> tutorial was made public he also received many comments about it..

yes, the CPMD stuff on the bochum servers took a lot of time,
but it also helped to save a lot of time, since one no longer
had to explain everything in detail. you can tell people to
try that one out first and then come back if they have more
questions. on top of that i would say, that i attribute to a
large degree my current employment (and opportunities of future
employment) to exactly those efforts. the investment of time
has paid off in many expected and unexpected ways.

> and also possible bug fixes of things he wrote)..
> well the point is that  human power specifically for these kind of
> things is always highly appreciated..

the sad side of this whole business is that the turnout is always
very low. so far only about 5% of the subscribers of the group
have participated. i guess several are still on vacation, but...

> cp2k can become better and better if more and more people will start
> contributing to it.. not necessarily implementing
> new things.. also offering help, as you said, in writing a more clear
> documentation, tutorials, case studies or offering
> help for maintaining a release.


> Sooo Sooo... what should I say more? ;-)

i cannot make any final commitment until in about a month or so,
but due to my large experience in CVS and moving patches around
with other packages, i would volunteer for a "release coordinator",
i.e. i could keep an eye on changes/bugfixes in the development
branch that may need to be carried over to the release branch,
review bug reports and oversee the writing of a user's guide
and a tutorial. i won't have time to do the legwork on those,
but as stated above, that would be a perfect opportunity for
a few newbies to gain valuable insight in cp2k with comparatively
little extra effort _and_ demonstrate their appreciation for
the (huge!!) effort that the other developers have put into
the code until now. if there would be 2-3 people willing to take
the material already available on this webserver and re-edit it
and then take input examples provided by others or taking from
other codes and turn them into some useful expamples, we should
have a good chance to get something done within a few months.

as written before, the most important decision would be to
identify features, that should be labeled as supported. i would
recommend to not remove anything from the release version, but
rather add a flag to check clear supported features. the input could
have a keyword (in &GLOBAL) ENABLE_UNSUPPORTED_FEATURES which
would be set to false by default in releases and true in developement
versions. that would make maintenance easier and every developer of
a subsystem can decide on a fine grained level whether a feature
is production ready or not.

cheers,
    axel.

>
> Teo
>
> > It is only another suggestion....I hope that it is interesting
>
> > Ciao
> >   Luca
>