<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><div dir="ltr">you are right, the information about the alignment of the cell with respect to the Cartesian axes is lost. Thus it is currently not possible to retrieve the scaled coordinates for an atomic configuration in an unique manner from the dcd file information involving non-orthorhombic cells. This is however something which could be fixed. CP2K adopts a common convention for the cell alignment when an explicit cell vector definition is not available, namely, the cell vector <b>a</b> is aligned with the x axis and the cell vectors <b>a</b> and <b>b</b> lie in the xy plane. I think this convention could also be applied in this case and the Cartesian coordinates could be dumped only after the cell has been mapped to this representation using scaled coordinates.<br></div></blockquote><div><br></div></div><div>Either that or allowing to dump into a format with support for non-aligned unit cell (like xtc: <a href="http://manual.gromacs.org/online/xtc.html">http://manual.gromacs.org/online/xtc.html</a>). Otherwise, people currently using DCD files might get annoyed that the unit cell is constrained along an axis, which makes it not very suitable for visualization (it looks like it’s jumping all around).</div><div><br></div><div>In my particular case, since my simulations have already run, I’m writing a short program to reconstruct fractional coordinates from the .cell file and the .xyz trajectory.</div><div><br></div><div>FX</div></body></html>