[CP2K:520] Re: cp2k release goals

[Teodoro Laino]

The present input library is totally OO. This means that if it would  
be used in an OO way these problems would not exist.
Let me explain better. If you have option A, B, C and combinations  
you could just
cast the different combinations in different sections (each one for  
each combination).

The misuse of the library is anyway allowed. Then if you don't want  
to specify these keywords in an OO way the fix
for the unimplemented features is only one (non OO):
1) go through the code and put stop statements checking if the  
running version is a release or a development if
      the combination is not tested or does not work

==> Or rewrite the input control in an OO way. <==
According to me this should be the way to go. But since I cannot  
force anybody in doing that I can only offer a solution for
a rationale and easy to implement way.

Teo

On 7 Jan 2008, at 17:35, Juerg Hutter wrote:

>
> 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.
>>
>>
>>>
>>
>
> >