Dear all,
Dr Case Thanks for you help,
It is to curious how is exactly read an frcmod file, I made several tests
changin only the position of general torsions in the frcmod.
The thing is that when general torsions are put at the
beginning of the TOR section everything seems to be ok, but when they are
somewhere mixed with specific params ... strange things happen (e.g. a
torsion with two terms= general + specific, and both counting)
All in all, the best thing to dois to check what's in the prmtop file
using rdparm and the command "printdihedrals".
Sure, this is helpful for those of you that usually load amber params with
frcmod files
All the best,
Ivan.
On Mon, 12 Dec 2005, David A. Case wrote:
> On Mon, Dec 12, 2005, ivan.mmb.pcb.ub.es wrote:
> >
> > When I create a frcmod file that is going to have a new general torsion
> > parameters and a specific torsion parameter that is included in the
> > general (let's say X-CT-CI-X and CT-CT-CI-HC)
> >
> > two things:
> >
> > - Do they have to be written in the frcmod file in a certain order, I mean
> > firstly the general and then the specific ones ?
>
> Basically, you should be very careful in using wildcards for torsions,
> especially in frcmod files. If you can, avoid them. If this is not possible,
> please check (using rdparm, for example) that you are getting exactly what you
> want in the output prmtop file.
>
> >
> > - If idivf = 9 for the general torsion, do I have to change this to 8 if I
> > am explicitly including one specific torsion or this is already taken
> > into acount by the program itself?
> >
>
> The torsion force constant as listed is divided by idivf. So if you have nine
> terms, you need to check that the overall barrier to rotation is what you want
> it to be. So, if you originally had nine equivalent terms, but now one is
> different, if you want all the remaining ones not to change, you would leave
> idivf alone. Alternatively, you could logically think that all of the idivf
> values are 1, and just treat the force constants as the adjustable parameters,
> often chosen to get an rotational barrier to match some taget value.
>
> The idivf value were originally there to make it easier for humans to read the
> parm.dat files. There is no logic in the programs that checks this value
> against a list of torsions, or modifies it based on the actual molecular
> topology.
>
> ...hope this helps....dac
>
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
>
--
_______________________________________________
/ \
/ Ivan Marchan Carvajal \
| (PhD Student) |
| |
| Institut de Recerca Biomedica de Barcelona |
| Parc Cientific de Barcelona |
| Molecular Modelling & Bionformatics Group |
| http://mmb.pcb.ub.es |
| |
| C/ Josep Samitier 1-5 08028 Barcelona |
| Tel: +34.93.403.71.55 Fax: +34.93.403.71.57 |
| |
| E-mail: ivan.mmb.pcb.ub.es |
| theochem.hotmail.com |
| Website: http://mmb.pcb.ub.es/~ivan |
\ /
\_________________________________________________/
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Tue Dec 13 2005 - 16:53:00 PST
