[CP2K:157] Re: merged wannier center and coordinate output file

[Teodoro Laino]

On 9 Jul 2007, at 18:03, Axel wrote:

>
>
> thanks teo and fawzi for your explanations.
>
> unfortunately, it raises another question,
> that i'll better ask in a separate thread.
>
> it is obvious that i can fix everything up with
> postprocessing later, but i'd rather have everything
> merged in one file from within the code so that i don't
> have to synchronize multiple sets of parameters all the time,
> preferably binary as postprocessing text format files can
> become very time consuming (e.g. in QM/MM!) and also
> for the kind of calculations that i have in mind the
> text files would be _huge_ and writing them would also
> affect parallel performance.
>
IONS+CENTER.xyz is a text file as far as I understand from the CPMD..
So writing a text files takes as much time in cp2k as in cpmd..
Now rises the question.. why creating a new format?
The world is already full of a messiness of formats (many of them not  
even documented (have a look at the time we both spent together for  
the PSF))..

But since we live in a democratic world, if you want a single file  
this is what you've to do:

Immediatey after you've your wannier centers you can create a fake  
particle_set with the dimension of particles+wannier centers
(you can do this locally.. no need to have one allocated since the  
very beginning of the calculation..
the cost of allocating/deallocating this particle_set is negligible  
w.r.t. the QS calculation)
and fill the particle_set with all information of the real particles  
and the fake informations from wannier centers..
You can limit yourself to fill the information in the particle_set  
only printed out from the routines that write the coordinates..
Once the particle_set is filled you can call the routine that dumps  
the atomic coordinates (at the moment supports only XYZ, DCD no PDB)..
Remember to apply PBC (if you want them) because normally the  
particle_set is never processed regarding PBC...
In this way you get one single file with all informations you need...

> so if cp2k cannot do it as it is right now, can you give
> me any hints, on how i could implement this without having
> to read through all of the source code? the way i see it,
> i'd need to allocate some memory somewhere and potentially
> have a proxy topology for it, copy the coordinates into the
> allocated memory, then the wannier centers, apply PBC and
> then write using the normal write functionality (so one can
> have either .xyz, .pdb, .dcd or whatever else format will
> be supported in the future).

>
> apropos parallel performance, would there be a way to tell
> cp2k to keep files open during a run? on several machines
> that we are running on, frequent open/close of files can
> have serious impact on (parallel) performance.
This cannot *easily* be avoided due to the general idea behind of the  
print_keys and the high potentiality they have..
Let me just say that in general I/O (even if not continuously opening/ 
closing the unit) has great impact on the
parallel performance (since we don't do parallel IO).. So people are  
highly invited to write to the disk only
with a reasonable frequency.. obviously there are cases in which you  
have to write with an high frequency..
Well in these cases I could never imagine that opening/closing a unit  
has an impact on the performance greater
than writing data on files..
Just for my curiosity can you provide some numbers regarding this  
behavior?

ciao,
Teo


>
> ciao,
>    axel.
>
>
>
> >