<DIV>Thanks both Mark and chris.neale@utoronto.ca&nbsp;'s advises.&nbsp;Listening to these words of yours,is better than learning for ten years. Most people uses the AMBER force field to run HEME simulation,I should focus on suitable force field and associated correct parameters.thanks </DIV>
<DIV><BR>&gt;&nbsp;&nbsp; 1. Re: HEME-cysteine gromacs simulation <BR>&gt;&nbsp;&nbsp; 2. HEME-cysteine gromacs simulation (chris.neale@utoronto.ca)<BR>&gt;<BR>&gt;Message: 1(Mark Abraham)<BR>&gt;Date: Wed, 26 Aug 2009 12:46:24 +1000<BR>&gt;From: Mark Abraham &lt;Mark.Abraham@anu.edu.au&gt;<BR>&gt;Subject: Re: [gmx-users] HEME-cysteine gromacs simulation</DIV>
<DIV>&gt;<BR>&gt;Visualization programs have to use heuristics to guess where bonds are <BR>&gt;and what names occur for which atoms (HG1 might be mercury or the first <BR>&gt;hydrogen on a gamma carbon, NE might be neon or an epsilon nitrogen, <BR>&gt;etc.). Only if you are able to read in a .tpr (such as with ngmx <BR>&gt;distributed inside GROMACS) can you get any visual confirmation of what <BR>&gt;GROMACS thinks you have described in your topology. There is no <BR>&gt;standardized widely-used mechanism for including such information in a <BR>&gt;PDB file, and so such usage of a file is unreliable.<BR>&gt;<BR>&gt;<BR>&gt;Read the .log files as well. GROMACS almost never segfaults (except when <BR>&gt;subjected to buggy MPI libraries), and when it does it will normally <BR>&gt;write some diagnostic information to stdout or the .log file.<BR>&gt;<BR>&gt;Sorry, I can't help there.<BR>&gt;<BR>&gt;&gt; please help me how handle those problems,how can i go on the simulation?<BR>&gt;Mark<BR>&gt;<BR>&gt;Message: 2<BR>&gt;Date: Tue, 25 Aug 2009 23:10:17 -0400<BR>&gt;From: chris.neale@utoronto.ca<BR>&gt;Subject: [gmx-users] HEME-cysteine gromacs simulation<BR><BR>&gt;You always need a correct topology. The main issue here is that you&nbsp; <BR>&gt;need to have correct parameters. Where did you get your heme and Fe&nbsp; <BR>&gt;parameters? Were you careful about the Fe state oxidation state? I&nbsp; <BR>&gt;suspect that most people use Amber because of their antechamber&nbsp; <BR>&gt;program, which seems like a brilliant idea even if it may overstretch&nbsp; <BR>&gt;it's own parameterization without letting you know. I have no specific&nbsp; <BR>&gt;advice for you here beyond saying that it is worth spending a month&nbsp; <BR>&gt;figuring out what parameters you should really be using (hint: why&nbsp; <BR>&gt;would you be using ffG43a1 if most others use Amber here? do you know&nbsp; <BR>&gt;something that they don't?). This will end up saving you time in the&nbsp; <BR>&gt;long run.<BR>&gt;<BR>&gt;Note that ffG43a1 is the GROMOS forcefield, not the&nbsp; GROMACS&nbsp; <BR>&gt;forcefield. It is unfortunate that many programs (Amber, Charmm,&nbsp; <BR>&gt;gromacs) have their own similarly named forcefield, but that does not&nbsp; <BR>&gt;mean that the forcefield must be used with the associated program.&nbsp; <BR>&gt;There are forcefields that are not associated with a program (OPLS)&nbsp; <BR>&gt;and programs that never developed their own force field (NAMD,&nbsp; <BR>&gt;Desmond, Tinker, LAMMPS), so it is perfectly ok for you to use the&nbsp; <BR>&gt;amber forcefield with the gromacs program.<BR>&gt;<BR>&gt;Bottom line: read, read, read.<BR>&gt;<BR>&gt;Chris.</DIV><br><br><span title="neteasefooter"/><hr/>
<a href="http://www.yeah.net/?from=footer">没有广告的终身免费邮箱,www.yeah.net</a>
</span>