[gmx-users] gmx angle memory consumption

Hi, I want to calculate dihedral angles for long trajectories at high sampling rates using gmx angle as follows: gmx angle -f traj.xtc -n dih_indices.ndx -ov dih.xvg -type dihedral -all After some time, it completely fills my RAM without having written anything to the output file. As the

Re: [gmx-users] Dihedral PCA documentation

Sorry for the delay, but I wanted to add a few points to this discussion as I am doing my PhD in the group where dPCA was developed. I hope these will clarify a little bit what's done in the tutorial and why (took me a while to figure it out). Obviously, it would be worth to rewrite my comments in

[gmx-users] eneconv and timestamps

Hi, I don't understand the behaviour of eneconv(_d) in Gromacs 4.6.7 I have a long trajectory saved every .5ps in single precision and want to save it every ps. Unfortunately, there is no -skip option. So, I figured with your help some time ago to first save the edr file in double precision using

Re: [gmx-users] PCA problems

In addition to what Tsjerk said, may I point out that a publication by a colleague of mine treats exactly these problems that arise when trying to fit cartesian structures: http://scitation.aip.org/content/aip/journal/jcp/141/1/10.1063/1.4885338 Regards, Matthias On 06/08/2016 06:10 PM, Tsjerk

[gmx-users] Shrink simulation box while maintaining ensemble

Hi, I am running a protein folding simulation, starting with an extended structure that needs a lot of water molecules to fulfill the minimial image convenction. Is there a way to "shrink" a simulation box and get rid of unnecessary solvent molecules while keeping velocities (to preserve the

[gmx-users] another trjconv issue

I found another strange thing with trjconv. Still working on my large trajectories, I want to cut them into smaller pieces and reset the times, like suggested by Mark: trjconv_mpi -f md.xtc -b 1600 -e 1700 -o t_t0.xtc -t0 0 But the output file contains only every second frame. If I

Re: [gmx-users] trjconv -dt issue

precision. That won't help if they're stored wrongly in the first place, but may help you handle some longer trajectory (at cost of more disk space). Mark On Wed, Aug 19, 2015 at 11:50 PM Matthias Ernst matthias.er...@physik.uni-freiburg.de wrote: Hello, I have a quite long continuous

[gmx-users] trjconv -dt issue

Hello, I have a quite long continuous trajectory coming from several initial input pieces (cluster crashed...) that I want to downsample, as a start from 0.5ps timestep in the source files to just 1ps and later bigger timesteps. Using the -dt option of trjconv (GROMACS 4.6.5.), there seem to be

Re: [gmx-users] Multiple writing to same trajectory issue

Just one more question on that topic: according to the Hoempage (http://www.gromacs.org/Documentation/How-tos/Doing_Restarts - After a crash), it used to be possible to resume a crashed run by employing tpbconv and supplying the trr file. As I did not save my cpt-files, would that still be an

[gmx-users] Multiple writing to same trajectory issue

Dear users, I usually resume calculation of a trajectory from a checkpoint file appending to the old files (which, as I learned, is obviously not a good idea..). Due to some issue with our queueing system, several jobs that were marked as depending on each other started at once and all wrote at

Re: [gmx-users] extracting from TRR

Judging from what you wrote: Justin's answer is perfectly fine but your understanding of RMSD obviously is not. RMSD is not a quantity of one structure only. Rather, it is defined as root mean square deviation (kind of a measure of difference) between two structures one from another. If one of