[gmx-users] ffamber99sb error
Dear GROMACS users, I'll be most thankful for any comment/help you might have regarding the following error that I'm encountering in grompp_d : Atomtype amber99_34 not found In ffamber99sb.rtp, amber99_34 refers to the N atom of each amino acid. Thanks a lot Arik -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] grompp error(Segmentation fault)
In continuation with my previous e-mail, I'm sorry to continue bothering you with this but after reevaluating, it seems that problem might just be with the amber forcefield after all as I manged to run grompp just fine and to start the minimization by applying the OPLS forcefield(with another OPLS compatible protein: bpti). I'm still interested in running my program with the amber forcefiled as to be compatible with other calculations being done in the group. I would be most thankful for any suggestion you might have. Thanks a lot Arik On 4/24/2010 5:23 PM, Arik Cohen wrote: Thanks again for the ultrafast response. 1. The extra '.' is a typo. (I apologize for that). In the command the file name appears as 1bgq_Complex_b4ion.tpr in addition, Both the single precision and double precision(grompp_d) gives this error. The compilation was done with gcc-4.4.3 with and without the option of --disable-float for the double and single precision version respectively. 2a. This is the first call to grompp b. The following programs such as pdb2gmx_d, editconf_d and genbox are working properly. c.grompp/_d -h is working , giving a description on the program with the different options available. 3. With regards of running grompp with different forcefield *Apparently the problem is with the l-bfgs option in the em.mdp file. This is due to the fact that when changing the integrator option to steep, the program runs fine * I'm sorry but I just saw this now. The l-bfgs integrator was chosen since I need to do normal mode analysis Thanks a lot Arik On 4/24/2010 2:26 PM, Justin A. Lemkul wrote: I suppose the next set of questions to ask would be: 1. How was Gromacs compiled? What options were specified? 2. Does every instance of grompp fail? Do other inputs work? What does "grompp -h" do? 3. Does grompp seg fault with totally different systems (different force fields)? -Justin Arik Cohen wrote: Thank a lot for your very fast response !. Here are the requested details: 1. Version 4.07 is being used. 2. Upgrading from version 4.04 to 4.07 doesn't help. 3. The grompp command given is: grompp -f MDP/em.mdp -c 1bgq_Complex_b4ion.pdb -p 1bgq_Complex.top -o 1bgq_Complex_b4ion..tpr 4. em.mdp: integrator = l-bfgs nsteps = 5 nstlist = 1 rlist = 1.0 coulombtype = PME rcoulomb= 1.0 vdw-type= cut-off rvdw= 1.0 nstenergy = 10 emtol= 5.0 ; tolerance kJ/(Mol -1 nm-1) instead of 10.0 define = -DFLEXIBLE ; using flexible water model 5. The grompp command is issued in this case, before genion. However, even when running it alone the same problem arises. 6. The program is being run on Fedora 12 inside VMware(2.6.32.11-99.fc12.i686, 32-bit). 7. Running the same command on another OS and type of machine(fc10.x86_64) does not solve the problem 7. The output: :-) G R O M A C S (-: Gnomes, ROck Monsters And Chili Sauce :-) VERSION 4.0.7 (-: Written by David van der Spoel, Erik Lindahl, Berk Hess, and others. Copyright (c) 1991-2000, University of Groningen, The Netherlands. Copyright (c) 2001-2008, The GROMACS development team, check out http://www.gromacs.org for more information. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. :-) grompp_d (double precision) (-: Option Filename Type Description -f MDP/em.mdp Input, Opt! grompp input file with MD parameters -po mdout.mdp Output grompp input file with MD parameters -c 1bgq_Complex_b4ion.pdb InputStructure file: gro g96 pdb tpr tpb tpa -r conf.gro Input, Opt. Structure file: gro g96 pdb tpr tpb tpa -rb conf.gro Input, Opt. Structure file: gro g96 pdb tpr tpb tpa -n index.ndx Input, Opt. Index file -p 1bgq_Complex.top InputTopology file -pp processed.top Output, Opt. Topology file -o 1bgq_Complex_b4ion..tpr Output Run input file: tpr tpb tpa -t traj.trr Input, Opt. Full precision trajectory: trr trj cpt -e ener.edr Input, Opt. Energy file: edr ene Option Type Value Description -- -[no]h bool no Print help info and quit -niceint0 Set the nicelevel -[no]v bool yes Be loud and noisy -timereal -1 Take frame at or first
Re: [gmx-users] grompp error(Segmentation fault)
Thanks again for the ultrafast response. 1. The extra '.' is a typo. (I apologize for that). In the command the file name appears as 1bgq_Complex_b4ion.tpr in addition, Both the single precision and double precision(grompp_d) gives this error. The compilation was done with gcc-4.4.3 with and without the option of --disable-float for the double and single precision version respectively. 2a. This is the first call to grompp b. The following programs such as pdb2gmx_d, editconf_d and genbox are working properly. c.grompp/_d -h is working , giving a description on the program with the different options available. 3. With regards of running grompp with different forcefield *Apparently the problem is with the l-bfgs option in the em.mdp file. This is due to the fact that when changing the integrator option to steep, the program runs fine * I'm sorry but I just saw this now. The l-bfgs integrator was chosen since I need to do normal mode analysis Thanks a lot Arik On 4/24/2010 2:26 PM, Justin A. Lemkul wrote: I suppose the next set of questions to ask would be: 1. How was Gromacs compiled? What options were specified? 2. Does every instance of grompp fail? Do other inputs work? What does "grompp -h" do? 3. Does grompp seg fault with totally different systems (different force fields)? -Justin Arik Cohen wrote: Thank a lot for your very fast response !. Here are the requested details: 1. Version 4.07 is being used. 2. Upgrading from version 4.04 to 4.07 doesn't help. 3. The grompp command given is: grompp -f MDP/em.mdp -c 1bgq_Complex_b4ion.pdb -p 1bgq_Complex.top -o 1bgq_Complex_b4ion..tpr 4. em.mdp: integrator = l-bfgs nsteps = 5 nstlist = 1 rlist = 1.0 coulombtype = PME rcoulomb= 1.0 vdw-type= cut-off rvdw= 1.0 nstenergy = 10 emtol= 5.0 ; tolerance kJ/(Mol -1 nm-1) instead of 10.0 define = -DFLEXIBLE ; using flexible water model 5. The grompp command is issued in this case, before genion. However, even when running it alone the same problem arises. 6. The program is being run on Fedora 12 inside VMware(2.6.32.11-99.fc12.i686, 32-bit). 7. Running the same command on another OS and type of machine(fc10.x86_64) does not solve the problem 7. The output: :-) G R O M A C S (-: Gnomes, ROck Monsters And Chili Sauce :-) VERSION 4.0.7 (-: Written by David van der Spoel, Erik Lindahl, Berk Hess, and others. Copyright (c) 1991-2000, University of Groningen, The Netherlands. Copyright (c) 2001-2008, The GROMACS development team, check out http://www.gromacs.org for more information. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. :-) grompp_d (double precision) (-: Option Filename Type Description -f MDP/em.mdp Input, Opt! grompp input file with MD parameters -po mdout.mdp Output grompp input file with MD parameters -c 1bgq_Complex_b4ion.pdb InputStructure file: gro g96 pdb tpr tpb tpa -r conf.gro Input, Opt. Structure file: gro g96 pdb tpr tpb tpa -rb conf.gro Input, Opt. Structure file: gro g96 pdb tpr tpb tpa -n index.ndx Input, Opt. Index file -p 1bgq_Complex.top InputTopology file -pp processed.top Output, Opt. Topology file -o 1bgq_Complex_b4ion..tpr Output Run input file: tpr tpb tpa -t traj.trr Input, Opt. Full precision trajectory: trr trj cpt -e ener.edr Input, Opt. Energy file: edr ene Option Type Value Description -- -[no]h bool no Print help info and quit -niceint0 Set the nicelevel -[no]v bool yes Be loud and noisy -timereal -1 Take frame at or first after this time. -[no]rmvsbds bool yes Remove constant bonded interactions with virtual sites -maxwarn int0 Number of allowed warnings during input processing -[no]zerobool no Set parameters for bonded interactions without defaults to zero instead of generating an error -[no]renum bool yes Renumber atomtypes and minimize number of atomtypes Ignoring obsolete mdp entry 'title' Back Off! I just backed up mdout.mdp to ./#mdout.mdp.6# checking input for internal co
Re: [gmx-users] grompp error(Segmentation fault)
Thank a lot for your very fast response !. Here are the requested details: 1. Version 4.07 is being used. 2. Upgrading from version 4.04 to 4.07 doesn't help. 3. The grompp command given is: grompp -f MDP/em.mdp -c 1bgq_Complex_b4ion.pdb -p 1bgq_Complex.top -o 1bgq_Complex_b4ion..tpr 4. em.mdp: integrator = l-bfgs nsteps = 5 nstlist = 1 rlist = 1.0 coulombtype = PME rcoulomb= 1.0 vdw-type= cut-off rvdw= 1.0 nstenergy = 10 emtol= 5.0 ; tolerance kJ/(Mol -1 nm-1) instead of 10.0 define = -DFLEXIBLE ; using flexible water model 5. The grompp command is issued in this case, before genion. However, even when running it alone the same problem arises. 6. The program is being run on Fedora 12 inside VMware(2.6.32.11-99.fc12.i686, 32-bit). 7. Running the same command on another OS and type of machine(fc10.x86_64) does not solve the problem 7. The output: :-) G R O M A C S (-: Gnomes, ROck Monsters And Chili Sauce :-) VERSION 4.0.7 (-: Written by David van der Spoel, Erik Lindahl, Berk Hess, and others. Copyright (c) 1991-2000, University of Groningen, The Netherlands. Copyright (c) 2001-2008, The GROMACS development team, check out http://www.gromacs.org for more information. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. :-) grompp_d (double precision) (-: Option Filename Type Description -f MDP/em.mdp Input, Opt! grompp input file with MD parameters -po mdout.mdp Output grompp input file with MD parameters -c 1bgq_Complex_b4ion.pdb InputStructure file: gro g96 pdb tpr tpb tpa -r conf.gro Input, Opt. Structure file: gro g96 pdb tpr tpb tpa -rb conf.gro Input, Opt. Structure file: gro g96 pdb tpr tpb tpa -n index.ndx Input, Opt. Index file -p 1bgq_Complex.top InputTopology file -pp processed.top Output, Opt. Topology file -o 1bgq_Complex_b4ion..tpr Output Run input file: tpr tpb tpa -t traj.trr Input, Opt. Full precision trajectory: trr trj cpt -e ener.edr Input, Opt. Energy file: edr ene Option Type Value Description -- -[no]h bool no Print help info and quit -niceint0 Set the nicelevel -[no]v bool yes Be loud and noisy -timereal -1 Take frame at or first after this time. -[no]rmvsbds bool yes Remove constant bonded interactions with virtual sites -maxwarn int0 Number of allowed warnings during input processing -[no]zerobool no Set parameters for bonded interactions without defaults to zero instead of generating an error -[no]renum bool yes Renumber atomtypes and minimize number of atomtypes Ignoring obsolete mdp entry 'title' Back Off! I just backed up mdout.mdp to ./#mdout.mdp.6# checking input for internal consistency... WARNING 1 [file MDP/em.mdp, line unknown]: For efficient BFGS minimization, use switch/shift/pme instead of cut-off. processing topology... Opening library file /usr/local/gromacs/share/gromacs/top//ffamber99sb.itp Opening library file /usr/local/gromacs/share/gromacs/top//ffamber99sbnb.itp Opening library file /usr/local/gromacs/share/gromacs/top//ffamber99sbbon.itp Segmentation fault (core dumped) Thanks a lot in advance for all your help Arik On 4/23/2010 4:45 PM, Mark Abraham wrote: On 24/04/2010 7:28 AM, Arik Cohen wrote: I'll be most thankful if any one would be able to help me with the following problem. Giving more complete information will give you a much better chance. It's not our job to be the family doctor and ask questions :-) What GROMACS version is it? Does upgrading to 4.0.7 help? While running the grompp (in both single and double precision) command I get a Segmentation fault (core dumped) error. When? What was the output to date? The error persist even after recompiling the GROMACS with gcc-4.4.3(previously I was running 4.04 compiled with the buggy gcc-4.1 compiler). Does it happen on another machine? The command I'm using is: grompp_d -f MDP/em.mdp -c 1bgq_Complex_b4ion.pdb -p 1bgq_Complex.top -o 1bgq.tpr What's in the .mdp file? Mark -- gmx-users mailing listgmx-users@gromacs.org http://lists.gro
[gmx-users] grompp error(Segmentation fault)
I'll be most thankful if any one would be able to help me with the following problem. While running the grompp (in both single and double precision) command I get a Segmentation fault (core dumped) error. The error persist even after recompiling the GROMACS with gcc-4.4.3(previously I was running 4.04 compiled with the buggy gcc-4.1 compiler). The command I'm using is: grompp_d -f MDP/em.mdp -c 1bgq_Complex_b4ion.pdb -p 1bgq_Complex.top -o 1bgq.tpr Thanks Arik -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] Amber and protonation state
Thanks a lot for the quick response Arik On 2/26/2010 3:54 AM, Justin A. Lemkul wrote: Arik Cohen wrote: Dear users, I would be most thankful for any comment or advice on the following problems: 1. I'm running GROMACS 4.04 with amber V_4.0. /amber99sb forcefield. While executing the pdb2gmx command as: pdb2gmx -f 1bgq.pdb -water tip3p -his the -his option does not work regardless of the choice in the protonation state 2. Is there any way to change the protonation state not via an interacticve mode and thus to enable to run the pdb2gmx in an automatic way(echo 10 | pdb2gmx ... | -his echo 2 will not work of course) Point #10 in the ffamber "Installation and Testing" section: http://chemistry.csulb.edu/ffamber/#install You can solve all protonation issues by having the right residue names to start. The Gromacs conventions for, e.g. histidine, are HISA, HISB, and HISH. For Amber, the corresponding residue names are HID, HIE, and HIP. If you go through your .pdb file and re-name residues in advance, the proper protonation states will be assigned. This also applies to any other titratable residues, and termini, which must be prefixed with N and C. -Justin Thanks a lot Arik -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
[gmx-users] Amber and protonation state
Dear users, I would be most thankful for any comment or advice on the following problems: 1. I'm running GROMACS 4.04 with amber V_4.0. /amber99sb forcefield. While executing the pdb2gmx command as: pdb2gmx -f 1bgq.pdb -water tip3p -his the -his option does not work regardless of the choice in the protonation state 2. Is there any way to change the protonation state not via an interacticve mode and thus to enable to run the pdb2gmx in an automatic way(echo 10 | pdb2gmx ... | -his echo 2 will not work of course) Thanks a lot Arik -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]
Thanks a lot the ultrafast response ! Arik Justin A. Lemkul wrote: Arik Cohen wrote: Dear Gromacs users, In continuation to the problem below, it seems that self interaction is not the problem since a -d 1.5nm around the protein should have been more than enough. Not noticing earlier, I see strange files being created with the name "step1150b_n1.pdb" (a bug like structural report of that step ?). In those files and in the pdb created after applying trjconv, the protein is drifted from the cell's center to one of the edge and a fragment appears at the other side. Saying that, trjconv does not solves the problem. I would be most thankful for any comment/suggestion as to how to prevent this drift which causes in turn to the "fragment" problem. Check your log file for LINCS warnings, etc. These step_*.pdb files are written when the system becomes unstable and is on the verge of collapse. Your system is probably blowing up, hence the weird coordinates. -Justin Thank Arik Mark James Abraham wrote: On 01/01/10, *"Justin A. Lemkul" * wrote: Arik Cohen wrote: >No, sorry for the confusion. The images are only from a simulation of one protein(tmRBP_Unliganded, PDB: 2FN9). The problem seen with BPTI was a bit different in a way that only 1 C-alpha was "detached" (cell size ?). > If there is supposed to be only a single protein in the images you've shown (and after having a look at the 2FN9 structure from the PDB), it seems pretty clear to me that part of your protein has simply crossed a periodic boundary and trjconv -pbc mol (or some such command) should fix it. Indeed. Further, note that the reappearance of a subset of the seemingly detached atoms back with the main group is totally normal. With domain decomposition in GROMACS 4, such "broken" molecules can be written to the trajectory. Judicious use of trjconv fixes the appearance of this non-problem. Mark >Arik > >Justin A. Lemkul wrote: >> >> >>Arik Cohen wrote: >>>Which two proteins ? I have at least in beginning only one protein which some how is divided into two along the calculation. >>>Any way I'll try both increasing the cell and fix it with trjconv. >>> >> >>Quoting your original message: >> >>"While running a simple MD simulation with both a small protein such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb..." >> >>I assumed that what I was seeing in the images was a set of two proteins. My concern was that you defined a box relative to the larger protein, then inserted the smaller one (BPTI?), leaving insufficient space in the box to satisfy the minimum image convention. If that's not what we're looking at, then that'd be useful to know :) >> >>If you have a single protein, "divided into two" then the problem is almost certainly a simple periodicity artifact. Bonds do not break in a normal MD calculation (in fact they can't using the standard MM approximations). >> >>-Justin >> >>>Thanks a lot >>> >>>Arik >>> >>>Justin A. Lemkul wrote: >>>> >>>> >>>>Arik Cohen wrote: >>>>>I'm using dodecahedron -d 0.7 >>>>> >>>>> >>>> >>>>Was that distance specified with respect to both of the protein molecules in the unit cell? You can check for spurious PBC interactions with g_mindist -pi. Anyway, I'd be curious to see how you do with trjconv. >>>> >>>>-Justin >>>> >>>>> >>>>>Justin A. Lemkul wrote: >>>>>> >>>>>> >>>>>>Arik Cohen wrote: >>>>>>>Hi, >>>>>>> >>>>>>>I have not tried yet to fix it with trjconv which I will . Attached is a picture with 4 snapshots taken from the simulation. The C-alphas in question are emphasized with red color. >>>>>>> >>>>>> >>>>>>Is your unit cell sufficiently large? It looks like the C-alphas indicated are simply crossing the periodic boundary on the "left" of the frame and interacting with the protein molecule in the "right" of the frame, which would indicate to me that the unit cell is too small and you're seeing spurious PBC interactions (i.e., violation of the minimum image convention). >>>>>> >>>>>>-Justin >>>>>> >>>>>>>Thanks >>>>>>> >>>>>>>Arik >>>>>>> >>>>>>>Justin A. Lemkul wrote: >>>>>>>> >>>>
Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]
Dear Gromacs users, In continuation to the problem below, it seems that self interaction is not the problem since a -d 1.5nm around the protein should have been more than enough. Not noticing earlier, I see strange files being created with the name "step1150b_n1.pdb" (a bug like structural report of that step ?). In those files and in the pdb created after applying trjconv, the protein is drifted from the cell's center to one of the edge and a fragment appears at the other side. Saying that, trjconv does not solves the problem. I would be most thankful for any comment/suggestion as to how to prevent this drift which causes in turn to the "fragment" problem. Thank Arik Mark James Abraham wrote: On 01/01/10, *"Justin A. Lemkul" * wrote: Arik Cohen wrote: >No, sorry for the confusion. The images are only from a simulation of one protein(tmRBP_Unliganded, PDB: 2FN9). The problem seen with BPTI was a bit different in a way that only 1 C-alpha was "detached" (cell size ?). > If there is supposed to be only a single protein in the images you've shown (and after having a look at the 2FN9 structure from the PDB), it seems pretty clear to me that part of your protein has simply crossed a periodic boundary and trjconv -pbc mol (or some such command) should fix it. Indeed. Further, note that the reappearance of a subset of the seemingly detached atoms back with the main group is totally normal. With domain decomposition in GROMACS 4, such "broken" molecules can be written to the trajectory. Judicious use of trjconv fixes the appearance of this non-problem. Mark >Arik > >Justin A. Lemkul wrote: >> >> >>Arik Cohen wrote: >>>Which two proteins ? I have at least in beginning only one protein which some how is divided into two along the calculation. >>>Any way I'll try both increasing the cell and fix it with trjconv. >>> >> >>Quoting your original message: >> >>"While running a simple MD simulation with both a small protein such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb..." >> >>I assumed that what I was seeing in the images was a set of two proteins. My concern was that you defined a box relative to the larger protein, then inserted the smaller one (BPTI?), leaving insufficient space in the box to satisfy the minimum image convention. If that's not what we're looking at, then that'd be useful to know :) >> >>If you have a single protein, "divided into two" then the problem is almost certainly a simple periodicity artifact. Bonds do not break in a normal MD calculation (in fact they can't using the standard MM approximations). >> >>-Justin >> >>>Thanks a lot >>> >>>Arik >>> >>>Justin A. Lemkul wrote: >>>> >>>> >>>>Arik Cohen wrote: >>>>>I'm using dodecahedron -d 0.7 >>>>> >>>>> >>>> >>>>Was that distance specified with respect to both of the protein molecules in the unit cell? You can check for spurious PBC interactions with g_mindist -pi. Anyway, I'd be curious to see how you do with trjconv. >>>> >>>>-Justin >>>> >>>>> >>>>>Justin A. Lemkul wrote: >>>>>> >>>>>> >>>>>>Arik Cohen wrote: >>>>>>>Hi, >>>>>>> >>>>>>>I have not tried yet to fix it with trjconv which I will . Attached is a picture with 4 snapshots taken from the simulation. The C-alphas in question are emphasized with red color. >>>>>>> >>>>>> >>>>>>Is your unit cell sufficiently large? It looks like the C-alphas indicated are simply crossing the periodic boundary on the "left" of the frame and interacting with the protein molecule in the "right" of the frame, which would indicate to me that the unit cell is too small and you're seeing spurious PBC interactions (i.e., violation of the minimum image convention). >>>>>> >>>>>>-Justin >>>>>> >>>>>>>Thanks >>>>>>> >>>>>>>Arik >>>>>>> >>>>>>>Justin A. Lemkul wrote: >>>>>>>> >>>>>>>> >>>>>>>>Arik Cohen wrote: >>>>>>>>>Hi, >>>>>>>>> >>>>>>>>>Sorry to bother you again ,but its not only a periodic effect since only *some of the atoms* in the "Detached"
Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]
thanks Arik Mark James Abraham wrote: On 01/01/10, *"Justin A. Lemkul" * wrote: Arik Cohen wrote: >No, sorry for the confusion. The images are only from a simulation of one protein(tmRBP_Unliganded, PDB: 2FN9). The problem seen with BPTI was a bit different in a way that only 1 C-alpha was "detached" (cell size ?). > If there is supposed to be only a single protein in the images you've shown (and after having a look at the 2FN9 structure from the PDB), it seems pretty clear to me that part of your protein has simply crossed a periodic boundary and trjconv -pbc mol (or some such command) should fix it. Indeed. Further, note that the reappearance of a subset of the seemingly detached atoms back with the main group is totally normal. With domain decomposition in GROMACS 4, such "broken" molecules can be written to the trajectory. Judicious use of trjconv fixes the appearance of this non-problem. Mark >Arik > >Justin A. Lemkul wrote: >> >> >>Arik Cohen wrote: >>>Which two proteins ? I have at least in beginning only one protein which some how is divided into two along the calculation. >>>Any way I'll try both increasing the cell and fix it with trjconv. >>> >> >>Quoting your original message: >> >>"While running a simple MD simulation with both a small protein such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb..." >> >>I assumed that what I was seeing in the images was a set of two proteins. My concern was that you defined a box relative to the larger protein, then inserted the smaller one (BPTI?), leaving insufficient space in the box to satisfy the minimum image convention. If that's not what we're looking at, then that'd be useful to know :) >> >>If you have a single protein, "divided into two" then the problem is almost certainly a simple periodicity artifact. Bonds do not break in a normal MD calculation (in fact they can't using the standard MM approximations). >> >>-Justin >> >>>Thanks a lot >>> >>>Arik >>> >>>Justin A. Lemkul wrote: >>>> >>>> >>>>Arik Cohen wrote: >>>>>I'm using dodecahedron -d 0.7 >>>>> >>>>> >>>> >>>>Was that distance specified with respect to both of the protein molecules in the unit cell? You can check for spurious PBC interactions with g_mindist -pi. Anyway, I'd be curious to see how you do with trjconv. >>>> >>>>-Justin >>>> >>>>> >>>>>Justin A. Lemkul wrote: >>>>>> >>>>>> >>>>>>Arik Cohen wrote: >>>>>>>Hi, >>>>>>> >>>>>>>I have not tried yet to fix it with trjconv which I will . Attached is a picture with 4 snapshots taken from the simulation. The C-alphas in question are emphasized with red color. >>>>>>> >>>>>> >>>>>>Is your unit cell sufficiently large? It looks like the C-alphas indicated are simply crossing the periodic boundary on the "left" of the frame and interacting with the protein molecule in the "right" of the frame, which would indicate to me that the unit cell is too small and you're seeing spurious PBC interactions (i.e., violation of the minimum image convention). >>>>>> >>>>>>-Justin >>>>>> >>>>>>>Thanks >>>>>>> >>>>>>>Arik >>>>>>> >>>>>>>Justin A. Lemkul wrote: >>>>>>>> >>>>>>>> >>>>>>>>Arik Cohen wrote: >>>>>>>>>Hi, >>>>>>>>> >>>>>>>>>Sorry to bother you again ,but its not only a periodic effect since only *some of the atoms* in the "Detached" group are vanishing from this group and reappearing in the main protein group. The rest of the atoms are either always in the detached or the main group. >>>>>>>>>In addition, the "detached" group includes three segments of the protein(8 residues(126-131), 8 residues(157-164) and 4 residues186-189). >>>>>>>>> >>>>>>>> >>>>>>>>From your description, this sounds exactly like a periodicity problem - some of the atoms are crossing the periodic boundary and are appearing in strange locations. Have you even tried trjconv to fix it? That would be useful information, as I see that
Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]
Again Thanks a lot Arik Justin A. Lemkul wrote: Arik Cohen wrote: No, sorry for the confusion. The images are only from a simulation of one protein(tmRBP_Unliganded, PDB: 2FN9). The problem seen with BPTI was a bit different in a way that only 1 C-alpha was "detached" (cell size ?). If there is supposed to be only a single protein in the images you've shown (and after having a look at the 2FN9 structure from the PDB), it seems pretty clear to me that part of your protein has simply crossed a periodic boundary and trjconv -pbc mol (or some such command) should fix it. -Justin Arik Justin A. Lemkul wrote: Arik Cohen wrote: Which two proteins ? I have at least in beginning only one protein which some how is divided into two along the calculation. Any way I'll try both increasing the cell and fix it with trjconv. Quoting your original message: "While running a simple MD simulation with both a small protein such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb..." I assumed that what I was seeing in the images was a set of two proteins. My concern was that you defined a box relative to the larger protein, then inserted the smaller one (BPTI?), leaving insufficient space in the box to satisfy the minimum image convention. If that's not what we're looking at, then that'd be useful to know :) If you have a single protein, "divided into two" then the problem is almost certainly a simple periodicity artifact. Bonds do not break in a normal MD calculation (in fact they can't using the standard MM approximations). -Justin Thanks a lot Arik Justin A. Lemkul wrote: Arik Cohen wrote: I'm using dodecahedron -d 0.7 Was that distance specified with respect to both of the protein molecules in the unit cell? You can check for spurious PBC interactions with g_mindist -pi. Anyway, I'd be curious to see how you do with trjconv. -Justin Justin A. Lemkul wrote: Arik Cohen wrote: Hi, I have not tried yet to fix it with trjconv which I will . Attached is a picture with 4 snapshots taken from the simulation. The C-alphas in question are emphasized with red color. Is your unit cell sufficiently large? It looks like the C-alphas indicated are simply crossing the periodic boundary on the "left" of the frame and interacting with the protein molecule in the "right" of the frame, which would indicate to me that the unit cell is too small and you're seeing spurious PBC interactions (i.e., violation of the minimum image convention). -Justin Thanks Arik Justin A. Lemkul wrote: Arik Cohen wrote: Hi, Sorry to bother you again ,but its not only a periodic effect since only *some of the atoms* in the "Detached" group are vanishing from this group and reappearing in the main protein group. The rest of the atoms are either always in the detached or the main group. In addition, the "detached" group includes three segments of the protein(8 residues(126-131), 8 residues(157-164) and 4 residues186-189). From your description, this sounds exactly like a periodicity problem - some of the atoms are crossing the periodic boundary and are appearing in strange locations. Have you even tried trjconv to fix it? That would be useful information, as I see that Mark long ago also suggested the same sort of fix. It is hard for me to envision what you are seeing. It would be enormously helpful if you could post images (screenshots, etc) of the problematic structures to get a more expedient resolution. -Justin Thanks a lot Arik Justin A. Lemkul wrote: Arik Cohen wrote: Hi, With regards to your question I do see some periodicity in which for a section of time in the trajectory some of the Calphas in the "detached group" are vanishing from it and reappear in the main protein. In addition, I would appreciate as before any suggestion you might have in the matter. If this is just a periodicity artifact, fix it with trjconv. -Justin Thanks Arik Mark Abraham wrote: Arik Cohen wrote: Hi, Thanks for answering so quickly !. Apparently whole residues have detached from the protein. So... like I asked last time, are you seeing a periodicity artefact? "Detached" covers a whole gamut of possibilities. Another strange thing that happens in pyMol and VMD is that when I select an atom or a residue in the detached group the selection appears twice: one in the detached group and one in the main part. If you've got atoms duplicated, then it sounds like something's going wrong with how they're interpreting the structure file, or how you're manipulating it afterwards. Either way, it's not a problem for the GROMACS mailing list unless you can demonstrate the atoms are duplicated in the structure file (which they aren't!). Mark Ari
Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]
No, sorry for the confusion. The images are only from a simulation of one protein(tmRBP_Unliganded, PDB: 2FN9). The problem seen with BPTI was a bit different in a way that only 1 C-alpha was "detached" (cell size ?). Arik Justin A. Lemkul wrote: Arik Cohen wrote: Which two proteins ? I have at least in beginning only one protein which some how is divided into two along the calculation. Any way I'll try both increasing the cell and fix it with trjconv. Quoting your original message: "While running a simple MD simulation with both a small protein such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb..." I assumed that what I was seeing in the images was a set of two proteins. My concern was that you defined a box relative to the larger protein, then inserted the smaller one (BPTI?), leaving insufficient space in the box to satisfy the minimum image convention. If that's not what we're looking at, then that'd be useful to know :) If you have a single protein, "divided into two" then the problem is almost certainly a simple periodicity artifact. Bonds do not break in a normal MD calculation (in fact they can't using the standard MM approximations). -Justin Thanks a lot Arik Justin A. Lemkul wrote: Arik Cohen wrote: I'm using dodecahedron -d 0.7 Was that distance specified with respect to both of the protein molecules in the unit cell? You can check for spurious PBC interactions with g_mindist -pi. Anyway, I'd be curious to see how you do with trjconv. -Justin Justin A. Lemkul wrote: Arik Cohen wrote: Hi, I have not tried yet to fix it with trjconv which I will . Attached is a picture with 4 snapshots taken from the simulation. The C-alphas in question are emphasized with red color. Is your unit cell sufficiently large? It looks like the C-alphas indicated are simply crossing the periodic boundary on the "left" of the frame and interacting with the protein molecule in the "right" of the frame, which would indicate to me that the unit cell is too small and you're seeing spurious PBC interactions (i.e., violation of the minimum image convention). -Justin Thanks Arik Justin A. Lemkul wrote: Arik Cohen wrote: Hi, Sorry to bother you again ,but its not only a periodic effect since only *some of the atoms* in the "Detached" group are vanishing from this group and reappearing in the main protein group. The rest of the atoms are either always in the detached or the main group. In addition, the "detached" group includes three segments of the protein(8 residues(126-131), 8 residues(157-164) and 4 residues186-189). From your description, this sounds exactly like a periodicity problem - some of the atoms are crossing the periodic boundary and are appearing in strange locations. Have you even tried trjconv to fix it? That would be useful information, as I see that Mark long ago also suggested the same sort of fix. It is hard for me to envision what you are seeing. It would be enormously helpful if you could post images (screenshots, etc) of the problematic structures to get a more expedient resolution. -Justin Thanks a lot Arik Justin A. Lemkul wrote: Arik Cohen wrote: Hi, With regards to your question I do see some periodicity in which for a section of time in the trajectory some of the Calphas in the "detached group" are vanishing from it and reappear in the main protein. In addition, I would appreciate as before any suggestion you might have in the matter. If this is just a periodicity artifact, fix it with trjconv. -Justin Thanks Arik Mark Abraham wrote: Arik Cohen wrote: Hi, Thanks for answering so quickly !. Apparently whole residues have detached from the protein. So... like I asked last time, are you seeing a periodicity artefact? "Detached" covers a whole gamut of possibilities. Another strange thing that happens in pyMol and VMD is that when I select an atom or a residue in the detached group the selection appears twice: one in the detached group and one in the main part. If you've got atoms duplicated, then it sounds like something's going wrong with how they're interpreting the structure file, or how you're manipulating it afterwards. Either way, it's not a problem for the GROMACS mailing list unless you can demonstrate the atoms are duplicated in the structure file (which they aren't!). Mark Arik Mark Abraham wrote: Arik Cohen wrote: Dear GROMACS users, While running a simple MD simulation with both a small protein such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb, I'm encountering an odd situation in which one (in the case of BPTI) or several Calphas (in the later case) are "detaching them selfs" from the main group. "main group" of what? Do
Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]
Which two proteins ? I have at least in beginning only one protein which some how is divided into two along the calculation. Any way I'll try both increasing the cell and fix it with trjconv. Thanks a lot Arik Justin A. Lemkul wrote: Arik Cohen wrote: I'm using dodecahedron -d 0.7 Was that distance specified with respect to both of the protein molecules in the unit cell? You can check for spurious PBC interactions with g_mindist -pi. Anyway, I'd be curious to see how you do with trjconv. -Justin Justin A. Lemkul wrote: Arik Cohen wrote: Hi, I have not tried yet to fix it with trjconv which I will . Attached is a picture with 4 snapshots taken from the simulation. The C-alphas in question are emphasized with red color. Is your unit cell sufficiently large? It looks like the C-alphas indicated are simply crossing the periodic boundary on the "left" of the frame and interacting with the protein molecule in the "right" of the frame, which would indicate to me that the unit cell is too small and you're seeing spurious PBC interactions (i.e., violation of the minimum image convention). -Justin Thanks Arik Justin A. Lemkul wrote: Arik Cohen wrote: Hi, Sorry to bother you again ,but its not only a periodic effect since only *some of the atoms* in the "Detached" group are vanishing from this group and reappearing in the main protein group. The rest of the atoms are either always in the detached or the main group. In addition, the "detached" group includes three segments of the protein(8 residues(126-131), 8 residues(157-164) and 4 residues186-189). From your description, this sounds exactly like a periodicity problem - some of the atoms are crossing the periodic boundary and are appearing in strange locations. Have you even tried trjconv to fix it? That would be useful information, as I see that Mark long ago also suggested the same sort of fix. It is hard for me to envision what you are seeing. It would be enormously helpful if you could post images (screenshots, etc) of the problematic structures to get a more expedient resolution. -Justin Thanks a lot Arik Justin A. Lemkul wrote: Arik Cohen wrote: Hi, With regards to your question I do see some periodicity in which for a section of time in the trajectory some of the Calphas in the "detached group" are vanishing from it and reappear in the main protein. In addition, I would appreciate as before any suggestion you might have in the matter. If this is just a periodicity artifact, fix it with trjconv. -Justin Thanks Arik Mark Abraham wrote: Arik Cohen wrote: Hi, Thanks for answering so quickly !. Apparently whole residues have detached from the protein. So... like I asked last time, are you seeing a periodicity artefact? "Detached" covers a whole gamut of possibilities. Another strange thing that happens in pyMol and VMD is that when I select an atom or a residue in the detached group the selection appears twice: one in the detached group and one in the main part. If you've got atoms duplicated, then it sounds like something's going wrong with how they're interpreting the structure file, or how you're manipulating it afterwards. Either way, it's not a problem for the GROMACS mailing list unless you can demonstrate the atoms are duplicated in the structure file (which they aren't!). Mark Arik Mark Abraham wrote: Arik Cohen wrote: Dear GROMACS users, While running a simple MD simulation with both a small protein such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb, I'm encountering an odd situation in which one (in the case of BPTI) or several Calphas (in the later case) are "detaching them selfs" from the main group. "main group" of what? Do the atoms bound to them move also? Are you seeing a periodicity artefact? Mark The problem appeared only after adding salt to the simulation(at least in the case of BPTI). I would appreciate any suggestions and comments on the matter. Thanks Arik The run files are: *em.mdp:* title = tmRBP_Unliganded_2FN9 Minimization integrator = steep ; (steep)using steepest descent nsteps = 5 nstlist = 1 rlist = 1.0 coulombtype = PME rcoulomb= 1.0 vdw-type= cut-off rvdw= 1.0 nstenergy = 10 emtol = 5.0 ; tolerance kJ/(Mol -1 nm-1) instead of 10.0 *pr.mdp * title = tmRBP_Unliganded_2FN9 PR integrator = md nsteps = 5 dt = 0.002 ;(in ps) doing a 100ps traj. constraints = all-bonds nstlist = 10 ; neighbour list updates every number of steps rlist = 1.0 coulombtype = PME rcoulomb= 1.0 vdw-
Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]
I'm using dodecahedron -d 0.7 Justin A. Lemkul wrote: Arik Cohen wrote: Hi, I have not tried yet to fix it with trjconv which I will . Attached is a picture with 4 snapshots taken from the simulation. The C-alphas in question are emphasized with red color. Is your unit cell sufficiently large? It looks like the C-alphas indicated are simply crossing the periodic boundary on the "left" of the frame and interacting with the protein molecule in the "right" of the frame, which would indicate to me that the unit cell is too small and you're seeing spurious PBC interactions (i.e., violation of the minimum image convention). -Justin Thanks Arik Justin A. Lemkul wrote: Arik Cohen wrote: Hi, Sorry to bother you again ,but its not only a periodic effect since only *some of the atoms* in the "Detached" group are vanishing from this group and reappearing in the main protein group. The rest of the atoms are either always in the detached or the main group. In addition, the "detached" group includes three segments of the protein(8 residues(126-131), 8 residues(157-164) and 4 residues186-189). From your description, this sounds exactly like a periodicity problem - some of the atoms are crossing the periodic boundary and are appearing in strange locations. Have you even tried trjconv to fix it? That would be useful information, as I see that Mark long ago also suggested the same sort of fix. It is hard for me to envision what you are seeing. It would be enormously helpful if you could post images (screenshots, etc) of the problematic structures to get a more expedient resolution. -Justin Thanks a lot Arik Justin A. Lemkul wrote: Arik Cohen wrote: Hi, With regards to your question I do see some periodicity in which for a section of time in the trajectory some of the Calphas in the "detached group" are vanishing from it and reappear in the main protein. In addition, I would appreciate as before any suggestion you might have in the matter. If this is just a periodicity artifact, fix it with trjconv. -Justin Thanks Arik Mark Abraham wrote: Arik Cohen wrote: Hi, Thanks for answering so quickly !. Apparently whole residues have detached from the protein. So... like I asked last time, are you seeing a periodicity artefact? "Detached" covers a whole gamut of possibilities. Another strange thing that happens in pyMol and VMD is that when I select an atom or a residue in the detached group the selection appears twice: one in the detached group and one in the main part. If you've got atoms duplicated, then it sounds like something's going wrong with how they're interpreting the structure file, or how you're manipulating it afterwards. Either way, it's not a problem for the GROMACS mailing list unless you can demonstrate the atoms are duplicated in the structure file (which they aren't!). Mark Arik Mark Abraham wrote: Arik Cohen wrote: Dear GROMACS users, While running a simple MD simulation with both a small protein such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb, I'm encountering an odd situation in which one (in the case of BPTI) or several Calphas (in the later case) are "detaching them selfs" from the main group. "main group" of what? Do the atoms bound to them move also? Are you seeing a periodicity artefact? Mark The problem appeared only after adding salt to the simulation(at least in the case of BPTI). I would appreciate any suggestions and comments on the matter. Thanks Arik The run files are: *em.mdp:* title = tmRBP_Unliganded_2FN9 Minimization integrator = steep ; (steep)using steepest descent nsteps = 5 nstlist = 1 rlist = 1.0 coulombtype = PME rcoulomb= 1.0 vdw-type= cut-off rvdw= 1.0 nstenergy = 10 emtol = 5.0 ; tolerance kJ/(Mol -1 nm-1) instead of 10.0 *pr.mdp * title = tmRBP_Unliganded_2FN9 PR integrator = md nsteps = 5 dt = 0.002 ;(in ps) doing a 100ps traj. constraints = all-bonds nstlist = 10 ; neighbour list updates every number of steps rlist = 1.0 coulombtype = PME rcoulomb= 1.0 vdw-type= cut-off rvdw= 1.0 tcoupl = Berendsen tc-grps = Protein non-protein tau-t = 0.1 0.1 ref-t = 298 298 Pcoupl = Berendsen tau-p = 1.0 compressibility = 5e-5 5e-5 5e-5 0 0 0 ref-p = 1.0 nstenergy = 100 define = -DPOSRES ; include posre.itp(position restraint) file *run.md *title = tmRBP_Unliganded_2FN9
Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]
Hi,
Sorry to bother you again ,but its not only a periodic effect since only
*some of the atoms* in the "Detached" group are vanishing from this
group and reappearing in the main protein group. The rest of the atoms
are either always in the detached or the main group.
In addition, the "detached" group includes three segments of the
protein(8 residues(126-131), 8 residues(157-164) and 4 residues186-189).
Thanks a lot
Arik
Justin A. Lemkul wrote:
Arik Cohen wrote:
Hi,
With regards to your question I do see some periodicity in which for
a section of time in the trajectory some of the Calphas in the
"detached group" are vanishing from it and reappear in the main protein.
In addition,
I would appreciate as before any suggestion you might have in the
matter.
If this is just a periodicity artifact, fix it with trjconv.
-Justin
Thanks
Arik
Mark Abraham wrote:
Arik Cohen wrote:
Hi,
Thanks for answering so quickly !. Apparently whole residues have
detached from the protein.
So... like I asked last time, are you seeing a periodicity artefact?
"Detached" covers a whole gamut of possibilities.
Another strange thing that happens in pyMol and VMD is that when I
select an atom or a residue in the detached group the selection
appears twice: one in the detached group and one in the main part.
If you've got atoms duplicated, then it sounds like something's
going wrong with how they're interpreting the structure file, or how
you're manipulating it afterwards. Either way, it's not a problem
for the GROMACS mailing list unless you can demonstrate the atoms
are duplicated in the structure file (which they aren't!).
Mark
Arik
Mark Abraham wrote:
Arik Cohen wrote:
Dear GROMACS users,
While running a simple MD simulation with both a small protein
such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb,
I'm encountering an odd situation in which one (in the case of
BPTI) or several Calphas (in the later case) are "detaching them
selfs" from the main group.
"main group" of what? Do the atoms bound to them move also? Are
you seeing a periodicity artefact?
Mark
The problem appeared only after adding salt to the simulation(at
least in the case of BPTI).
I would appreciate any suggestions and comments on the matter.
Thanks
Arik
The run files are:
*em.mdp:*
title = tmRBP_Unliganded_2FN9 Minimization
integrator = steep ; (steep)using steepest descent
nsteps = 5
nstlist = 1
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
nstenergy = 10
emtol = 5.0 ; tolerance kJ/(Mol -1 nm-1) instead
of 10.0
*pr.mdp
*
title = tmRBP_Unliganded_2FN9 PR
integrator = md
nsteps = 5
dt = 0.002 ;(in ps) doing a 100ps traj.
constraints = all-bonds
nstlist = 10 ; neighbour list updates every number
of steps
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
tcoupl = Berendsen
tc-grps = Protein non-protein
tau-t = 0.1 0.1
ref-t = 298 298
Pcoupl = Berendsen
tau-p = 1.0
compressibility = 5e-5 5e-5 5e-5 0 0 0
ref-p = 1.0
nstenergy = 100
define = -DPOSRES ; include posre.itp(position
restraint) file
*run.md
*title = tmRBP_Unliganded_2FN9
integrator = md
nsteps = 30
dt = 0.001
constraints = all-bonds
nstlist = 10
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
tcoupl = V-rescale ;V-rescale
tc-grps = Protein non-protein
tau-t = 0.8 0.8
ref-t = 298 298
nstxout = 1000
nstvout = 1000
nstxtcout = 1000
nstenergy = 1000
The runs commands are(integrated inside a C++ code):
SysCommand1 = "echo 6 | pdb2gmx -f " + FileName + " -water tip3p";
system("editconf -f conf.gro -bt dodecahedron -d 0.7 -o box.gro");
system("genbox -cp box.gro -cs spc216.gro -p topol.top -o
solvated.gro");
minimization:
if(Mode == "NoSalt")
{
system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o
em.tpr");
//system("mpirun -np 4 mdrun -v -deffnm em");
}
if(Mode == "WithSalt")
{
system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro
-o em.tpr");
system("mpirun -np 4 mdrun -v -deffnm em");
}
Salting
Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]
Hi,
With regards to your question I do see some periodicity in which for a
section of time in the trajectory some of the Calphas in the "detached
group" are vanishing from it and reappear in the main protein.
In addition,
I would appreciate as before any suggestion you might have in the matter.
Thanks
Arik
Mark Abraham wrote:
Arik Cohen wrote:
Hi,
Thanks for answering so quickly !. Apparently whole residues have
detached from the protein.
So... like I asked last time, are you seeing a periodicity artefact?
"Detached" covers a whole gamut of possibilities.
Another strange thing that happens in pyMol and VMD is that when I
select an atom or a residue in the detached group the selection
appears twice: one in the detached group and one in the main part.
If you've got atoms duplicated, then it sounds like something's going
wrong with how they're interpreting the structure file, or how you're
manipulating it afterwards. Either way, it's not a problem for the
GROMACS mailing list unless you can demonstrate the atoms are
duplicated in the structure file (which they aren't!).
Mark
Arik
Mark Abraham wrote:
Arik Cohen wrote:
Dear GROMACS users,
While running a simple MD simulation with both a small protein such
as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb, I'm
encountering an odd situation in which one (in the case of BPTI) or
several Calphas (in the later case) are "detaching them selfs" from
the main group.
"main group" of what? Do the atoms bound to them move also? Are you
seeing a periodicity artefact?
Mark
The problem appeared only after adding salt to the simulation(at
least in the case of BPTI).
I would appreciate any suggestions and comments on the matter.
Thanks
Arik
The run files are:
*em.mdp:*
title = tmRBP_Unliganded_2FN9 Minimization
integrator = steep ; (steep)using steepest descent
nsteps = 5
nstlist = 1
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
nstenergy = 10
emtol = 5.0 ; tolerance kJ/(Mol -1 nm-1) instead of
10.0
*pr.mdp
*
title = tmRBP_Unliganded_2FN9 PR
integrator = md
nsteps = 5
dt = 0.002 ;(in ps) doing a 100ps traj.
constraints = all-bonds
nstlist = 10 ; neighbour list updates every number of
steps
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
tcoupl = Berendsen
tc-grps = Protein non-protein
tau-t = 0.1 0.1
ref-t = 298 298
Pcoupl = Berendsen
tau-p = 1.0
compressibility = 5e-5 5e-5 5e-5 0 0 0
ref-p = 1.0
nstenergy = 100
define = -DPOSRES ; include posre.itp(position
restraint) file
*run.md
*title = tmRBP_Unliganded_2FN9
integrator = md
nsteps = 30
dt = 0.001
constraints = all-bonds
nstlist = 10
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
tcoupl = V-rescale ;V-rescale
tc-grps = Protein non-protein
tau-t = 0.8 0.8
ref-t = 298 298
nstxout = 1000
nstvout = 1000
nstxtcout = 1000
nstenergy = 1000
The runs commands are(integrated inside a C++ code):
SysCommand1 = "echo 6 | pdb2gmx -f " + FileName + " -water tip3p";
system("editconf -f conf.gro -bt dodecahedron -d 0.7 -o box.gro");
system("genbox -cp box.gro -cs spc216.gro -p topol.top -o
solvated.gro");
minimization:
if(Mode == "NoSalt")
{
system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o
em.tpr");
//system("mpirun -np 4 mdrun -v -deffnm em");
}
if(Mode == "WithSalt")
{
system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o
em.tpr");
system("mpirun -np 4 mdrun -v -deffnm em");
}
Salting:
system("echo 12 | genion -s em.tpr -conc 0.1 -neutral -o
solvated.gro");
pr:
system("grompp -f MDP/prmd.mdp -p topol.top -c em.gro -o pr.tpr");
/* The actual run*/
system("mpirun -np 4 mdrun -v -deffnm pr");
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
[Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]
Hi,
Thanks for answering so quickly !. Apparently whole residues have
detached from the protein. Another strange thing that happens in pyMol
and VMD is that when I select an atom or a residue in the detached group
the selection appears twice: one in the detached group and one in the
main part.
Thanks allot for all your help
Arik
Mark Abraham wrote:
Arik Cohen wrote:
Dear GROMACS users,
While running a simple MD simulation with both a small protein such
as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb, I'm
encountering an odd situation in which one (in the case of BPTI) or
several Calphas (in the later case) are "detaching them selfs" from
the main group.
"main group" of what? Do the atoms bound to them move also? Are you
seeing a periodicity artefact?
Mark
The problem appeared only after adding salt to the simulation(at
least in the case of BPTI).
I would appreciate any suggestions and comments on the matter.
Thanks
Arik
The run files are:
*em.mdp:*
title = tmRBP_Unliganded_2FN9 Minimization
integrator = steep ; (steep)using steepest descent
nsteps = 5
nstlist = 1
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
nstenergy = 10
emtol = 5.0 ; tolerance kJ/(Mol -1 nm-1) instead of 10.0
*pr.mdp
*
title = tmRBP_Unliganded_2FN9 PR
integrator = md
nsteps = 5
dt = 0.002 ;(in ps) doing a 100ps traj.
constraints = all-bonds
nstlist = 10 ; neighbour list updates every number of steps
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
tcoupl = Berendsen
tc-grps = Protein non-protein
tau-t = 0.1 0.1
ref-t = 298 298
Pcoupl = Berendsen
tau-p = 1.0
compressibility = 5e-5 5e-5 5e-5 0 0 0
ref-p = 1.0
nstenergy = 100
define = -DPOSRES ; include posre.itp(position
restraint) file
*run.md
*title = tmRBP_Unliganded_2FN9
integrator = md
nsteps = 30
dt = 0.001
constraints = all-bonds
nstlist = 10
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
tcoupl = V-rescale ;V-rescale
tc-grps = Protein non-protein
tau-t = 0.8 0.8
ref-t = 298 298
nstxout = 1000
nstvout = 1000
nstxtcout = 1000
nstenergy = 1000
The runs commands are(integrated inside a C++ code):
SysCommand1 = "echo 6 | pdb2gmx -f " + FileName + " -water tip3p";
system("editconf -f conf.gro -bt dodecahedron -d 0.7 -o box.gro");
system("genbox -cp box.gro -cs spc216.gro -p topol.top -o
solvated.gro");
minimization:
if(Mode == "NoSalt")
{
system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o
em.tpr");
//system("mpirun -np 4 mdrun -v -deffnm em");
}
if(Mode == "WithSalt")
{
system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o
em.tpr");
system("mpirun -np 4 mdrun -v -deffnm em");
}
Salting:
system("echo 12 | genion -s em.tpr -conc 0.1 -neutral -o
solvated.gro");
pr:
system("grompp -f MDP/prmd.mdp -p topol.top -c em.gro -o pr.tpr");
/* The actual run*/
system("mpirun -np 4 mdrun -v -deffnm pr");
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
[gmx-users] A problem with a "detaching Calpha/s"
Dear GROMACS users,
While running a simple MD simulation with both a small protein such as
BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb, I'm
encountering an odd situation in which one (in the case of BPTI) or
several Calphas (in the later case) are "detaching them selfs" from the
main group.
The problem appeared only after adding salt to the simulation(at least
in the case of BPTI).
I would appreciate any suggestions and comments on the matter.
Thanks
Arik
The run files are:
*em.mdp:*
title = tmRBP_Unliganded_2FN9 Minimization
integrator = steep ; (steep)using steepest descent
nsteps = 5
nstlist = 1
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
nstenergy = 10
emtol = 5.0 ; tolerance kJ/(Mol -1 nm-1) instead of 10.0
*pr.mdp
*
title = tmRBP_Unliganded_2FN9 PR
integrator = md
nsteps = 5
dt = 0.002 ;(in ps) doing a 100ps traj.
constraints = all-bonds
nstlist = 10 ; neighbour list updates every number of steps
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
tcoupl = Berendsen
tc-grps = Protein non-protein
tau-t = 0.1 0.1
ref-t = 298 298
Pcoupl = Berendsen
tau-p = 1.0
compressibility = 5e-5 5e-5 5e-5 0 0 0
ref-p = 1.0
nstenergy = 100
define = -DPOSRES ; include posre.itp(position restraint) file
*run.md
*title = tmRBP_Unliganded_2FN9
integrator = md
nsteps = 30
dt = 0.001
constraints = all-bonds
nstlist = 10
rlist = 1.0
coulombtype = PME
rcoulomb= 1.0
vdw-type= cut-off
rvdw= 1.0
tcoupl = V-rescale ;V-rescale
tc-grps = Protein non-protein
tau-t = 0.8 0.8
ref-t = 298 298
nstxout = 1000
nstvout = 1000
nstxtcout = 1000
nstenergy = 1000
The runs commands are(integrated inside a C++ code):
SysCommand1 = "echo 6 | pdb2gmx -f " + FileName + " -water tip3p";
system("editconf -f conf.gro -bt dodecahedron -d 0.7 -o box.gro");
system("genbox -cp box.gro -cs spc216.gro -p topol.top -o solvated.gro");
minimization:
if(Mode == "NoSalt")
{
system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o em.tpr");
//system("mpirun -np 4 mdrun -v -deffnm em");
}
if(Mode == "WithSalt")
{
system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o em.tpr");
system("mpirun -np 4 mdrun -v -deffnm em");
}
Salting:
system("echo 12 | genion -s em.tpr -conc 0.1 -neutral -o solvated.gro");
pr:
system("grompp -f MDP/prmd.mdp -p topol.top -c em.gro -o pr.tpr");
/* The actual run*/
system("mpirun -np 4 mdrun -v -deffnm pr");
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] g_energy
Thanks allot for the ultrafast response and above all your help !. Arik Mark Abraham wrote: Arik Cohen wrote: Hi, Is there a way to tell the g_energy program the output option(i.e. Potential, Temperature ) in advance when you run the program. Namely, I would like to know if there is a flag that I can give the program and thus skip the part when the g_energy program asks for an input for the Potential/Temperature... option(much like -ff for the force field in the runmd program) See http://www.gromacs.org/Documentation/How-tos/Making_Commands_Non-Interactive Mark No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.425 / Virus Database: 270.14.57/2492 - Release Date: 11/09/09 12:11:00 -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
[gmx-users] g_energy
Hi, Is there a way to tell the g_energy program the output option(i.e. Potential, Temperature ) in advance when you run the program. Namely, I would like to know if there is a flag that I can give the program and thus skip the part when the g_energy program asks for an input for the Potential/Temperature... option(much like -ff for the force field in the runmd program) Thanks allot Arik -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] Extended trajectory
Thanks allot for all your help
Arik
Justin A. Lemkul wrote:
Arik Cohen wrote:
Hi,
I'll be most thankful if someone could tell me how to run a
fragmented trajectory using only the mdrun command. As of now I'm
using :
while(SimuTime < SimTime)
{
...
system("tpbconv -s run.tpr -f run.trr -e run.edr -extend 1.0 -o
run.tpr");
system("mdrun -cpi run.cpt -cpo run.cpt -append -npme 0 -v
-deffnm run");
}
When I ran the above mdrun command alone, the run got stack
No error message? Just stuck? It could be that you're trying to read
and write to the same file names. I think your method of preparing
the extended run is also malformed, since the advent of checkpoint
files. See here:
http://www.gromacs.org/Documentation/How-tos/Extending_Simulations
Try with the syntax and naming convention given there (to avoid
potential I/O confusion) and see if your run works.
-Justin
Thanks
Arik
___
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before
posting!
Please don't post (un)subscribe requests to the list. Use the www
interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.423 / Virus Database: 270.14.24/2449 - Release Date: 10/20/09 18:42:00
___
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
[gmx-users] Extended trajectory
Hi,
I'll be most thankful if someone could tell me how to run a fragmented
trajectory using only the mdrun command. As of now I'm using :
while(SimuTime < SimTime)
{
...
system("tpbconv -s run.tpr -f run.trr -e run.edr -extend 1.0 -o
run.tpr");
system("mdrun -cpi run.cpt -cpo run.cpt -append -npme 0 -v -deffnm
run");
}
When I ran the above mdrun command alone, the run got stack
Thanks
Arik
___
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
[gmx-users] A fragmented trajectory
Dear users,
I'll be most thankful if someone could give me an example as how to
restart a MD simulation that is been fragmented into several sections. I
have tried several flags according to the manual with no success. Every
time a different problem emerges, i.e. either the simulation get stuck
and a massage such as, npme is different for the current and previous
run, or .tpr file can not be found and so on.
The general spirit of the simulation is as follows:
void ScaffHandler::MD(double SimTime)
{
system("grompp -f MDP/runmd.mdp -p topol.top -c pr.gro -o run.tpr");
system("mdrun -v -deffnm run");
while(SimuTime < SimTime)
{
system("mdrun -cpi run.tpr -v -deffnm run");
SimuTime += 0.001;
...
}
}
Thanks allot
Arik
___
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] Snapshots in different files
Thanks for replaying. Indeed thats what i did with the BALL library which was inefficient. This led me eventually to change the library by adding a feature to it. Any way thanks again Arik Dallas B. Warren wrote: If the time frame between snapshots is not too short, you could have that as the length of each MD run, then simple extend the run to keep on going. Could be a bit inefficient. (This is how you should run MD anyway, to ensure don't lose a lot of information if the computer system you are running on crashes etc.) I wouldn't be too surprised if it was possible to hack the code so that a coordinate file is spat out at some interval (even with a limited index of atoms). But that is something for those that know the ins and outs of the code to tell you. Catch ya, Dr. Dallas Warren Department of Pharmaceutical Biology Pharmacy and Pharmaceutical Sciences, Monash University 381 Royal Parade, Parkville VIC 3010 dallas.war...@pharm.monash.edu.au +61 3 9903 9167 - When the only tool you own is a hammer, every problem begins to resemble a nail. *From:* gmx-users-boun...@gromacs.org [mailto:gmx-users-boun...@gromacs.org] *On Behalf Of *Arik Cohen *Sent:* Thursday, 8 October 2009 9:27 AM *To:* Discussion list for GROMACS users *Subject:* Re: [gmx-users] Snapshots in different files Thanks for answering. This would not be the case so much since another program(sniffer) can be working along side gromacs examining each snapshot(Max 400 residues == atoms. I'm only interested in the C-alpha) and then if all criteria are met to extract/or save the coor and if not to erase the snapshot. The aim here is to do an MD from which an ensemble of the C-alpha will be created. Thanks again Arik Mark Abraham wrote: Arik Cohen wrote: Thanks allot, but isn't trjconv should be executed after the trajectory has finished ?. I would like to put each snapshot in a different file on the fly. As Justin said, you can't do that. For starters, it consumes vast amounts of disk. Also, it doesn't take long to do it after the fact on some workstation, and it is wasteful to spend your (limited) main compute resources doing I/O while post-processing output. GROMACS workflows are intended to run the simulation fast and efficiently, and then allow you to process the results with the various tools/filters to extract the data you need. You can even post-process with mdrun -rerun if you want to get only a subset of forces or something. The main exception to this principle is the use of xtc-groups, IIRC. Why do you even want separate PDB frames? Visualization tools like VMD will read the trajectory files. Mark ___ gmx-users mailing listgmx-users@gromacs.org <mailto:gmx-users@gromacs.org> http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org <mailto:gmx-users-requ...@gromacs.org>. Can't post? Read http://www.gromacs.org/mailing_lists/users.php No virus found in this incoming message. Checked by AVG - www.avg.com <http://www.avg.com> Version: 8.5.421 / Virus Database: 270.14.5/2419 - Release Date: 10/07/09 05:18:00 ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.5/2419 - Release Date: 10/07/09 05:18:00 ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] Snapshots in different files
Thanks for answering. This would not be the case so much since another program(sniffer) can be working along side gromacs examining each snapshot(Max 400 residues == atoms. I'm only interested in the C-alpha) and then if all criteria are met to extract/or save the coor and if not to erase the snapshot. The aim here is to do an MD from which an ensemble of the C-alpha will be created. Thanks again Arik Mark Abraham wrote: Arik Cohen wrote: Thanks allot, but isn't trjconv should be executed after the trajectory has finished ?. I would like to put each snapshot in a different file on the fly. As Justin said, you can't do that. For starters, it consumes vast amounts of disk. Also, it doesn't take long to do it after the fact on some workstation, and it is wasteful to spend your (limited) main compute resources doing I/O while post-processing output. GROMACS workflows are intended to run the simulation fast and efficiently, and then allow you to process the results with the various tools/filters to extract the data you need. You can even post-process with mdrun -rerun if you want to get only a subset of forces or something. The main exception to this principle is the use of xtc-groups, IIRC. Why do you even want separate PDB frames? Visualization tools like VMD will read the trajectory files. Mark ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.5/2419 - Release Date: 10/07/09 05:18:00 ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] Snapshots in different files
Thanks allot for all your help and ultrafast response. Arik Justin A. Lemkul wrote: Arik Cohen wrote: Thanks allot, but isn't trjconv should be executed after the trajectory has finished ?. I would like to put each snapshot in a different file on the fly. Not possible, as far as I'm aware. -Justin Thanks Arik Justin A. Lemkul wrote: Arik Cohen wrote: Dear users, Is there a way to take a snapshot along the trajectory and write it into a different file, so that each snapshot will be written into its own file named with its own index ?(e.g. snap_1, snap_2 ) trjconv -sep -Justin Thanks Arik ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.5/2419 - Release Date: 10/07/09 05:18:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.5/2419 - Release Date: 10/07/09 05:18:00 ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] Snapshots in different files
Thanks allot, but isn't trjconv should be executed after the trajectory has finished ?. I would like to put each snapshot in a different file on the fly. Thanks Arik Justin A. Lemkul wrote: Arik Cohen wrote: Dear users, Is there a way to take a snapshot along the trajectory and write it into a different file, so that each snapshot will be written into its own file named with its own index ?(e.g. snap_1, snap_2 ) trjconv -sep -Justin Thanks Arik ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.5/2419 - Release Date: 10/07/09 05:18:00 ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
[gmx-users] Snapshots in different files
Dear users, Is there a way to take a snapshot along the trajectory and write it into a different file, so that each snapshot will be written into its own file named with its own index ?(e.g. snap_1, snap_2 ) Thanks Arik ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] Snapshot taken under certain condition
Thanks allot for all your help Arik Mark Abraham wrote: Arik Cohen wrote: Dear users, Is there a way(in the mdp file) to take a snapshot of only the C-alpha atoms along a trajectory if certain condition are met(tested every time a snapshot needs to be taken) ? If you know in advance you'll only ever want the C-alpha atoms for analysis (dangerous) then you can use xtc-groups to write only that set. Better is to savee all the data you might want, and then filter for the C-alpha atoms with trjconv at a suitable point. You cannot apply your condition during the simulation, but must apply it after the fact. For example, use a suitable analysis tool, and then perhaps post-process that output to provide input to trjconv to extract the frames of interest. The detail of the necessary procedure will depend on the nature of the condition you want to apply. Mark ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.420 / Virus Database: 270.14.5/2418 - Release Date: 10/06/09 18:34:00 ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Re: [gmx-users] Snapshot taken under certain condition
Thanks for all your help and rapid response. Arik Justin A. Lemkul wrote: Arik Cohen wrote: Dear users, Is there a way(in the mdp file) to take a snapshot of only the C-alpha atoms along a trajectory if certain condition are met(tested every time a snapshot needs to be taken) ? No, but you could probably script it after the trajectory is run, using whatever analysis tool is appropriate to evaluate your condition, then trjconv to dump out the appropriate frame. -Justin Thanks Arik ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.420 / Virus Database: 270.14.5/2418 - Release Date: 10/06/09 18:34:00 ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
[gmx-users] Snapshot taken under certain condition
Dear users, Is there a way(in the mdp file) to take a snapshot of only the C-alpha atoms along a trajectory if certain condition are met(tested every time a snapshot needs to be taken) ? Thanks Arik ___ gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
