[gmx-users] pressure coupled systems explode

Hey, I'm still working on the system where I pull two flexible diamod slabs in opposite direction and study the distance dependent speed of the water in between. I attached the mdp file below. The system is scaled extremely in z and pressure looks wrong as well (see attached graph of both). There

Re: [gmx-users] Is anyone also using lammps?s

Hey, are you running single or double precision gromacs? Afaik, depending on the circumstances the energy drift in gromacs can be rather bad for single precision. Alex Peng Yi schrieb: > > On Wed, 28 Oct 2009, Mark Abraham wrote: > >> Peng Yi wrote: >>> >>> I am trying to simulate alkane melt a

Re: [gmx-users] direction_periodic

Hi, thx for suggesting the workaround, just to make sure I understand the workaround correctly: I devide each slab in 2 sections, one section contains 90% of the atoms (section A), the other the rest (section B). Now I set the pbc_atom to the center atom of section A and pull it using constraints

Re: [gmx-users] direction_periodic

Hi, did you look at the actual trajectory (trr/xtc) or the velocity of one of the diamond slabs (using g_traj) ? I do get a sawtooth style COM distance (pullx.xvg) but both the veloc.xvg and the trajectory show that the slabs are not actually moving much (the speed of the slab fluctuates wildly ar

Re: [gmx-users] direction_periodic

Hey, could you mail me the complete input files you are using for your test? I'd like to compare them with the stuff I have to see what's wrong. alexander.h...@mytum.de Thx! Berk Hess schrieb: > Hi, > > I just ran a simulation with your input files. > I only changed the geometry to direction_pe

Re: [gmx-users] direction_periodic

Hey, did you find the time to look at it? Thx, Alex Berk Hess schrieb: > I am not sure I continued the simulation long enough. > I'll run it again tomorrow. > > Berk > > > Date: Mon, 28 Sep 2009 16:57:19 +0200 > > From: alexander.h...@mytum.de > > To: gmx-users@gromacs.org > > Subject: Re: [gmx-

Re: [gmx-users] direction_periodic

Well..they do move forward for a few ps and then they move back (they oscillate). Did you check for a longer period? Alex Berk Hess schrieb: > Strange... > I tested the code on the files you sent me > and the slabs were moving smoothly. > > Berk > > > Date: Mon, 28 Sep 2009 15:40:16 +0200 > > Fro

Re: [gmx-users] direction_periodic

Hey, so using the new direction_periodic with some kernels that actually work and the sources from the git (unmodified) gives a nice smooth pull force but no actual mean displacement of the groups to be pulled (on average they just stay where they are,see attached graph). I'm still trying to pull

Re: [gmx-users] Re: help with gmx C source code

You will have to set the right environment variable for CFLAGS to get debug symbols: cd gromacs_directory CFLAGS="-O0 -g3" ./configure might do the trick. you can use gdb to check whether there are debug symbols in an executable. Alex Inon Sharony schrieb: > > reply to: > http://lists.gromac

Re: [gmx-users] direction_periodic

Hey, ok, I checked this. It works ok with the assembly kernels on my local machine, but it fails with fortran kernels on the HPC and on my local machine. Alex Berk Hess schrieb: > Yes. > > Berk > > > Date: Mon, 21 Sep 2009 14:42:43 +0200 > > From: alexander.h...@mytum.de > > To: gmx-users@gromac

Re: [gmx-users] direction_periodic

With master branch you mean the code I get via |git clone git://git.gromacs.org/gromacs.git right? Alex | Berk Hess schrieb: > I tested on your system and got good results. > There is still a tricky issue: the pull COM is still determined > in the "standard" way by summing distances from the

[gmx-users] direction_periodic

Hey, after some pain of merging the dev branch into our 4.0.5 version I got the new pull mode "direction_periodic" running over the weekend. There's some weird rotation of the pulled objects going on and pbc seem weird as well (there are water molecules in those positions where I'd expect the peri

Re: [gmx-users] generation of kernels

actually it's the other way around, it should be "nb_kernel410_f77_single.h" but the c file contains "nbkernel410_f77_single.h" Alex aherz schrieb: > Hi, > > I'm having some problems compiling the latest development build from the > git using for

[gmx-users] generation of kernels

Hi, I'm having some problems compiling the latest development build from the git using fortran kernels. The nb_kernel_f77_single.c file includes lot's of headers which are incorrect (e.g. "nb_kernel410_f77_single.h") the proper file name has no underline after nb ("nbkernel410_f77_single.h"). I tr

Re: [gmx-users] non isotropic kinetic energy

the trr. > > > > > > > > All this appears to hint at a problem with the constraints for the > > > > waters and might also hint at an incorrect ensemble as a > consequence. > > > > > > > > Alex > > > > > > > > samp

Re: [gmx-users] non isotropic kinetic energy

file (several variants of this file have been used): > > > > title = pure water > > cpp = /usr/bin/cpp > > integrator = md > > nsteps = 250 > > nstlist = 50 > > nstxout = 1000 > > nstvout = 1000 > > nstlog = 1000 > > dt = 0.002 > >

[gmx-users] non isotropic kinetic energy

Hi, we're running simulations of a water slab sandwiched by vacuum (ca. 2k waters, 3x3x12 nm^3 box) in NVT and look at the pressure tensor. We are surprised to find that the kinetic energy is equivalent (within statistical uncertainty) for x and y dim(parallel to the interface) but not in z dim. T

Re: [gmx-users] t_trxframe speed units

I understand. I would look at it myself, but the time for my thesis is running out so I cannot spend much time looking at issues unrelated to my actual problem. Next week sounds great. Alex Berk Hess schrieb: > I should have time next week to do this. > The problem with these kind of things is th

Re: [gmx-users] t_trxframe speed units

sure, I'll update to the head revision as soon as a fix is available. Any idea how long this will take? Alex Berk Hess schrieb: > Thinking about this, I will probably not fix it in 4.0, > but only in git master for 4.1. > > There are several issues with pulling "infinitely" long/far. > One of th

Re: [gmx-users] t_trxframe speed units

Great! Berk Hess schrieb: > Ah, now I see what the problem is. > The pull code works correctly when the distance is shorter or longer > than half the box length. But when the distance crosses half the box > length, > the code might take the "wrong" periodic distance. > I'll see if I can fix this.

Re: [gmx-users] t_trxframe speed units

Hi yes, I tried pull_start=yes (you also suggested trying constraint instead of umbrella, which I tried as well). my box is rectangular. Alex Berk Hess schrieb: > Hi, > > The only thing I suggested was using pull_start=yes, > otherwise you will start at a "random" distance and you will have enor

Re: [gmx-users] t_trxframe speed units

Hey, I tried everything you suggested and a couple more things and still it is not possible to get a reasonable speed for the pulled groups (always way beyond the 0.01nm/ps set in the mdp file and mostly containing some high frequence patttern probably related to pbc). (I tried: constraint, pbcato

Re: [gmx-users] Gromacs 4.0.4 - Pull.pdo File

Hi, in gromacs 4 the pulling commands are part of the mdp file so copy the contents of your ppa file into your mdp file. Alex V Hariharan schrieb: > Hello, > > My .mdp file, .ppa file and mdrun command are provided below. After > running a constraint simulation, I am not getting a .pdo file out

Re: [gmx-users] t_trxframe speed units

Yes, the diamond moves through the complete sim box (eg. from left to right) before it pops back to the left side due to pbc. But looking at the diamond speed (which is increasing) it looks as if the afm tip is not shifted back to the left side when it leaves the sim box at the right side. If that

Re: [gmx-users] t_trxframe speed units

hm.. after thinking about this for a sec I'd say I'm missing an option to apply the pbc to the pull position. Currently it looks as if the position of the "afm tip" is moving in absolute coordinates further and further away from the original position while the diamonds stay in the original box due

Re: [gmx-users] t_trxframe speed units

I will try this, thx for the help. Anyways, what is the correct way to do what I want with gromacs 4? (apparently the setup I tryed to use worked for gromacs 3, since I ported the input data from old sims and now I'm trying to recreate the old results). Alex Berk Hess schrieb: > The simple issue

Re: [gmx-users] t_trxframe speed units

We wanted to use 2 slabs so that the net impuls is conserved. Also I'm looking at the slip length, so I actually want to extract the velocity profile of the water in between the two diamond slabs. I'm pulling in x (the pull setup is reproduced at the bottom of the old mail) and I'm using pbc in 3d.

Re: [gmx-users] t_trxframe speed units

I'm studying shear flow, so I exspect the two slabs to be pulled in opposite x direction with the pull speed given. Looking at pull.xvg the slabs are pulled apart with about 1.5nm/ps until the box end (in x) is reached, then they jump back due to pbc. So this is what I would exspect, exept that the

[gmx-users] t_trxframe speed units

Hey, I averaged the speed of the diamond slabs, so I wrote a small gmx tools which averages t_trxframe.v[i] where i iterates over the diam atoms. I calc the avrg speed for a production run of 5ns after 0.5ns equilib. I get an avrg speed of 1.2 [nm/ps], so this is not just some fluctuation (last

[gmx-users] gro file format /pulling

Hi, I'm pulling 2 diamond slabs (which enclose two water slabs) in opposite direction with pull_rate1=0.01 (nm/ps) in x direction (pbc in 3d). Now looking at the gro file that is finally output when the sim is finshied and averaging the speeds of the two diamonds I get ca. +/-1.78 (I guess [nm/ps

Re: [gmx-users] continuation

Hi, yes, the trr is 7GB. Alex Berk Hess schrieb: > Hi, > > -append yes is incorrect, it should be -append without the yes. > In this case this error has no effect though. > > Is your trr file larger than 2 GB? > We have fixed a bug with this in the upcoming 4.0.6 release. > > Berk > > > Date: Fr

[gmx-users] continuation

Hi, I'm trying to continue a sim using: old cmd line + -cpi state.cpt -append yes where old cmd line = mpirun -np 1 $GROMACS_T37/mdrun -s shear -c shear_final -g shear_final -o shear All files exist. and I get: --- Program mdrun, VERSION 4.0

[gmx-users] Pressure for froozen atoms

Hi guys, does gromacs use the following scheme to calculate the virial/pressure for systems including froozen atoms: http://www.ccp5.ac.uk/infoweb/wsmith22/wsmith22/wsmith22.html ?? Thx, Alex ___ gmx-users mailing listgmx-users@gromacs.org http://li

[gmx-users] pulling

Hey, has anyone actually succeeded doing pulling with gromacs 4.0.5 keeping the distance between a froozen and a non froozen group (so not pulling into a direction but just applying the harmonic potential to the distance). If so, could you send me the mdp file showing how you set up the whole thin

Re: [gmx-users] Re: pulling

Hm..setting > >>> pull_geometry = direction > >>> pull_vec1 = 0 0 1 should fix the pbc prob or do I need to set pull_pbcatom0 as well? Cause it still aint working using these settings (without the pull_pbcatom0). Thx, Alex Berk Hess schrieb: > No (completely) frozen group

Re: [gmx-users] pulling

Thx for the quick reply! I use 4.0.5, pbc z=yes Box height = 17.5nm gld slab is from z=0 to z= 9.5; So distance=5.5 should give 1.0nm above surface right? What do I have to put for pull_init1 if i use direction?? Thx, Alex Berk Hess schrieb: > Hi, > > I hope you are using 4.0.5, I fixed several

[gmx-users] pulling

Hey, I appear to have serious trouble understanding how to set up the pulling properly. I have many configurations of a protein partially adsorbed to a froozen surface (the configs differ in the amount of the protein that has been desorbed). Now I want the pulling to keep the distance of the deso

[gmx-users] TI with nonbond_params

Hi, I'm running a TI perturbing the lennard jones parametters of an ion. In addition I have specified the lj interaction of that ion with water using nonbond_params like this: #include "ffG53a6.itp" [ atomtypes ] ;name at.num mass charge ptypec6 c12 NaMod CA1 0.