[CP2K:818] Re: applicability of TEMP_TOL to thermostat regions...

[Fawzi Mohamed]

evolution needs both memory, history and innovation ;)
You need to find an equilibrium between keeping the old and replacing  
it with new.
Both have their place.

Some want to use cp2k as a tool, maybe combined with others.
In this case some stability if needed.
Some things like the f77_interface and cp2k_shell can help to achieve  
this, and the idea of a "release" goes exactly in that direction.

But not to be slaves backward compatibility is also important, but in  
this case I also did like TEMP_TOL :)

Fawzi
On Mar 13, 2008, at 10:10 PM, Axel wrote:

>
>
>
> On Mar 13, 4:04 pm, Teodoro Laino <teodor... at gmail.com> wrote:
>> On 13 Mar 2008, at 20:28, Axel wrote:
>>
>>> it is hard to let go of something that has been
>>> around for a very long time. after having slept over
>>> the choices, i'd rather go with a change in the documentation,
>>> i.e. keep TEMP_TOL 'as is' and add two remarks stating that this
>>> is global only and that regional recaling should use CSVR with
>>> short tau instead.
>>
>> Where does evolution and innovation fits in your remark?
>
> by encouraging people to try out something new without
> forcing them to do it right away you have some evolution,
> albeit more adiabatic.
>
>> I honestly don't agree with your point.. habits can be (and must be)
>> changed and adapted to something different (possibly better).
>
> it may be that with increasing age one gets more prone
> to be conservative and also occasionally tired of fighting
> for something that is a rather small issue (from the perspective
> of a user).
>
>> Due to the continuous computational challenges and growth in
>> algorithmic developments, all codes have necessarily
>> to evolve into a direction where the organization of the code itself
>> has to be revisited, restructured and improved (even when a structure
>> was planned since the very beginning).
>> The price for not doing that is just an incredible amount of time
>> lost in code-maintenance and an incredible increase of the
>> difficulties in expanding the code capabilities.
>
> i don't mind people breaking with backwards compatibility,
> if it is for a _good_ reason. the problem is that people have
> different definitions of "good reason". with a code the size
> of cp2k i consider consistency and maintainability _very_ good
> reasons. i would rate them even higher than performance or number
> of (current) features, as the future potential depends on it.
>
> as you know from the (non-cp2k) stuff i was working on a few weeks
> ago, you can easily reach a point where adding a new feature can
> become a nightmare, if consistency and maintainability have been
> lost during the course of development.
>
>> You touched the real problem. People fight because you move/delete/
>> reorganize keywords.. they just see that this creates them the waste
>> of (maybe) 5 minutes in order to update their mental scheme. They
>> don't see the necessity of these reorganization, They don't see the
>> time you spent when you've to modify the code. They want just to
>> find the same keywords (used maybe the last time in the 80s) at  
>> the same place.
>
> in my opinion, the trick is to find the right balance between
> changing something and keeping things the way they were. and
> people on both "sides" have to acknowledge the usefulness of
> the other view, despite the occasional pain and frustration.
>
>> I wonder: for someone that consider him/herself a scientist shouldn't
>> a flexible mind be the key to do research?
>
> absolutely, but then again, to be flexible requires that you
> practice a lot and become and expert in the tools you are using.
> particularly with scientific software development this is a tricky
> issue. you usually don't get paid for the software development, but
> for the science you are doing with the result and since few scientists
> are really trained in software development/maintenance one is prone to
> make all kinds of mistakes in this and quite a few finally adopt a
> view
> that doing a minimalistic job is the best solution, as it minimizes
> the
> "pain" of having to work with a tool they are not that comfortable
> with
> in the first place. this is also the way how you get the most "out of
> it".
>
> of course, this logic neglects the effort from others that have
> invested
> into the infrastructure and particularly in the case of cp2k this
> is the part, i appreciate the most because this is where the
> potential of the code is: not the individual features, but the
> flexibility of how you can combine them and adapt to new problems,
> that nobody thought about when implementing the features.
> this encourages creativity and to me this is about as important
> as flexibility in a scienfic mind.
>
>> The controversial is purely philosophical (don't take me too
>> serious). Of course you can change the documentation (I won't do
>> that ;-) ).
>
> it is a point that is worth spending a few thoughts
> on every once in a while. :)
>
> cheers,
>     axel.
>
>>
>> Teo
>