[CP2K:516] Re: cp2k release goals

[Juerg Hutter]

Hi

there is of course the problem of keyword combinations.
Option A may be fully tested within the framework of option B
but not with option C. Still option C is a tested and useful
option as long as used without Option A.
Now how do you flag this?
Redo this with combinations of 3, 4, etc options.

Therefore this flags can only be a guideline, not a definite
to be trusted flag.

Juerg

----------------------------------------------------------
Juerg Hutter                   Phone : ++41 44 635 4491
Physical Chemistry Institute   FAX   : ++41 44 635 6838
University of Zurich           E-mail: hut... at pci.uzh.ch
Winterthurerstrasse 190
CH-8057 Zurich, Switzerland
----------------------------------------------------------


On Mon, 7 Jan 2008, Teodoro Laino wrote:

> Hi Axel, Hi All,
>
> with a today commit we have the necessary platform for specifying
> things in cp2k as
> ready to be released or still in a development version.
> Each section/keyword of the input has an additional marker
> (supported_feature), by default
> set to .FALSE. and in case that section/keyword is considered
> sufficiently tested to be released
> it can be set to .TRUE. in the source.
>
> CP2K can now be compiled with a prepocessor flag: -D__RELEASE_VERSION.
> Whenever producing a release version and one tried to access keywords/
> sections not upgraded
> as being supported_features cp2k stops with an error message.
> I also introduced, as you suggested Axel, the
> "ENABLE_UNSUPPORTED_FEATURE" keyword in &GLOBAL.
> In case it is specified and in case one runs a release version the
> program prints some warning messages
> but the calculation continues exactly as for a development version.
> For development version no check is performed whether a keyword is
> supported or not.
>
> Now there's the fun part of the game: decide which keywords/sections
> can be considered supported.
> I can do that  for part of the input (but only in my spare time, I
> did it only for few keywords to debug the
> today commit).. If one wants to contribute please just send  me the
> proper patches for the keywords he analyzed.
>
> The other thing to do is to provide for the platforms for which we
> want to support the release the proper
> arch files with the extension .release (an arch file like sopt in
> which the -D__RELEASE_VERSION is added).
> In this case one can compile the release just typing "make release"
> or something similar (I didn't add any arch file at the
> moment)..
>
> The next thing to do is to mark with different color supported/non-
> supported keyword on the on-line reference manual (still
> didn't do that).
>
> Cheers,
> Teo
>
> On 5 Jan 2008, at 22:31, Axel wrote:
>
>> 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.
>
>
> >
>