<div style="font-family: 'Times New Roman'; font-size: 16px;"><br /><br /><span>On 01/20/10, <b class="name">Leontyev Igor </b> <ileontyev@ucdavis.edu> wrote:</span><blockquote cite="mid:000801ca9992$cde65620$0400a8c0@HP163H" class="iwcQuote" style="border-left: 1px solid rgb(0, 0, 255); padding-left: 13px; margin-left: 0pt;" type="cite"><div class="mimepart text plain">Hi.<br />I am trying to split a trajectory onto smaller parts using "trjconv". The trajectory has 5001 configurations saved with interval 0.1 ps, i.e. all together 500ps. I want to split the trajectory onto 16 smaller parts (31.2ps each) saving only each 5-th configuration of the original trajectory.<br /><br />1) However, the command:<br />"trjconv -b 0.001 -skip 5 -split 31.2 -f long_trajectory.xtc"<br />generate only 4 smaller parts: 3 of them contain 312 configurations and last one has 64. Thus, the number of configurations in parts is 1000, i.e. each 5-th conf of the original trajectory, but lenth of the parts is 156 ps (0.1ps*5*312) instead of expected 31.2 ps. The same command with only "-skip 6" seems to work well, i.e. generate 16 parts with 52 configuration per each. Why it is so?</div></blockquote>If split is implemented exactly as described in trjconv -h, then if you choose an unlucky value for skip, then t mod split might not be tested at all for frames for which it would equal the first time (which is set with -b?). It's a matter of how split and skip interact. You may need two passes with trjconv, or to use -dt cunningly.<br /><blockquote cite="mid:000801ca9992$cde65620$0400a8c0@HP163H" class="iwcQuote" style="border-left: 1px solid rgb(0, 0, 255); padding-left: 13px; margin-left: 0pt;" type="cite"><div class="mimepart text plain"><br />2) My original trajectory is saved with precision 0.0001 (nm) and I expected (according to manual) that output trajectories will be also with the same precision, since I did not set "-ndec" . However, trjconv says "Using output precision of 0.001 (nm)", see below.</div></blockquote><br />Well, be glad you read your output... -ndec has a default of 3, not "preserve input precision", for better or worse... A default of preserving the input xtc precision if the input is in xtc format would be very reasonable, however. Perhaps -ndec should have a default value of -1, which maintains the precision of xtc input, and defaults to 0.001 precision otherwise. That maintains backward compatibility with all previous usage of -ndec except "erroneous" trjconv of higher-precision xtc to lower-precision xtc, and fixes this issue.<br _moz_dirty="" /><br _moz_dirty="" />Mark<br _moz_dirty="" type="_moz" /></div>