[CP2K:1980] Re: Data output from CP2K

[Ondrej Marsalek]

Thanks, that is all I needed to hear and it is certainly not a big thing.

Ondrej


On Wed, Apr 8, 2009 at 01:07, Teodoro Laino <teodor... at gmail.com> wrote:
>
> Hi Ondrej,
> It is not stupid at all. Give us some time to look into that. As you
> can realize, it is not such a big bug.
> Will keep you updated.
> Regards
> Teo
>
> ---------------------------------------------
> Teodoro Laino
> Zurich Switzerland
>
> Contact info:
> Tel.:     http://www.jajah.com/Teo
> E-mail: teo... at laino.eu
>              teodor... at gmail.com
> ---------------------------------------------
>
> On 8 Apr 2009, at 00:57, Ondrej Marsalek <ondrej.... at gmail.com>
> wrote:
>
>>
>> Umm... bump? Because stuff does usually not pass silently through this
>> group, I would like to check - is the below quoted thing totally
>> stupid or just totally low priority for everyone? I would not mind
>> either, but it is probably better to know, as a kind of sanity check.
>>
>> Best,
>> Ondrej
>>
>>
>> On Sat, Mar 21, 2009 at 01:39, Ondrej Marsalek
>> <ondrej.... at gmail.com> wrote:
>>> Dear developers,
>>>
>>> I have a bugreport / feature request related to the way CP2K handles
>>> file output.
>>>
>>> I have a setup that I use for all my runs that makes sure that there
>>> is always an up-to-date restart file and wavefunction restart at the
>>> end of an MD step. It works well for any continuation, with one
>>> exception. If there is a cube file written for the MD step that is
>>> last in one run and therefore first in the restart, the cube file is
>>> written again in the restart and it is appended to the same file.
>>> Therefore, you get an invalid data file (disregarding the
>>> non-existence of a specification for the cube file format) in an
>>> otherwise correct run. I would probably call this a bug.
>>>
>>> In general it would be nice to have any files that get overwritten
>>> backed up first. Appending is of course not a problem for file
>>> formats
>>> where it makes sense (xyz, ener, ...). In other cases (like a cube
>>> file), I'd rather see a backup of the old file and a creation of a
>>> new
>>> one, rather than having the old file overwritten or appended to.
>>>
>>> Thank you for considering this.
>>>
>>> Best regards,
>>> Ondrej
>>>
>>
>> >
>
> >
>