[CP2K:159] about output handling in cp2k
teodor... at gmail.com
Mon Jul 9 17:06:49 UTC 2007
Fawzi can comment about these better than I do:
> hi all!
> i have a couple more questions about how cp2k handles output:
> it may be my ignorance towards the inner workings of cp2k, but to me
> the flags ADD_LAST, EACH, COMMON_ITERATION_LEVELS and
> the filename naming conventions are rather confusing or maybe the
> the description in the documentation needs to be 'translated' into
> layman's terms,
> perhaps with a few examples. in particular, i'd like to understand
> is meant by 'iteration level', as it obviously does not refer to the
> SCF iterations
> alone. i also noticed that the example for ADD_LAST: ADD_LAST NO
> does generate an parser error.
Regarding this one:
At the moment we had no time to convert the RESTART of QS to a
When it will be a print_key you will be able to do it.. i.e. print
every n-th step of MD..
It's in our todo list.. but as you can imagine with a low priority...
> also, is there a way to have the (quickstep) RESTART file (or whatever
> name i assign it)
> been written only at the end of every n-th MD step (not SCF step)? as
> far as i
> understood, a postitive number writes the restart at every n-th scf
> iteration and 0
> when convergence is reached or SCF_MAX. how about having negative
> being matched against the time step number?
> finally, i noticed that .dcd files are missing the header part
> when i am using &EXT_RESTART to continue a calculation but
> rename the files for each run. the only workaround i found so far
> is to set RESTART_COUNTERS to .false., but since my jobs can
> have different length (due to dynamic backfill queueing they can
> be allowed to run for anything between 2 and 12 hours) it would be
> extremely nice to have my cake and eat it, i.e. .dcd files with
> and restarted counters. is there an alternative way to get the header
This was a bug but as far as I know Will fixed it.. are you using a
> since cp2k already seems to append some sort of serial number to
> outputs, the most desirable (to me) way of writing output would
> be to have a parameter that specifies how many steps would go into
> a single file (e.g. 2000, derived from the time step number) and then
> start a new file when that is reached and step up the serial number.
> could that be implemented with reasonable effort?
don't think so.. again Fawzi can comment on the print_keys better
than I can do..
(i.e. I like this way of numbering ;-) )
More information about the CP2K-user