VMD-L Mailing List

From: Vermaas, Joshua (Joshua.Vermaas_at_nrel.gov)
Date: Wed Apr 25 2018 - 17:11:42 CDT

Oh. I see what you mean now, and had misinterpreted your question. The "charge" field in the atomtype is used when atomtypes directly map onto unique charges (ie. every atom with type CT2 has charge -0.02 or something like that). This is not true for CHARMM in general (CT2, for instance, has at least 5 different values in the protein force field), so instead every atom within molecule needs to specify its own charge. So if you go to an "[atoms]" directive, you'll see that your charges are just as you left them, and these are the charges grompp uses when building a tpr file.

-Josh

On 2018-04-25 14:07:55-06:00 fan li wrote:

Hi Josh

The procedures are listed below:
(1)open the vmd under linux
(2)load the AFM.txt via Tk console

I checked the AFM.top, the charges at [ atomtypes ] directive are zeros.

All the files are attached.

Thanks

Fan Li

2018-04-25 18:23 GMT+01:00 Vermaas, Joshua <Joshua.Vermaas_at_nrel.gov<mailto:Joshua.Vermaas_at_nrel.gov>>:
Hi Fan,

When I ran the script, I got charges, so I don't think the error is in the script. Can you recapitulate exactly what you did? A charge of zero makes me think that the original psf wasn't loaded first, or somehow all the charges were set to zero after they were loaded.

-Josh

On 2018-04-25 11:18:06-06:00 fan li wrote:

Hi -Josh

I tried the script and I found a possible potential bug of topo writegmxtop. The charge is zero for all atoms. I checked the "reordered" psf file, and I has the charge which means that topo writegmxtop can not get the charge. You can also look at the test.top you generated, and I has no charge as well. Any solutions for it apart from manually adding it?

Fan Li

2018-04-23 23:44 GMT+01:00 Vermaas, Joshua <Joshua.Vermaas_at_nrel.gov<mailto:Joshua.Vermaas_at_nrel.gov>>:
Ahh, ok. This makes more sense. I hadn't realized the trouble the "+" sign causes. VMD's atomselection language has some special characters that have different meanings to let the language do math. "+" is one of them, which normally means they'd need to be escaped to not break the atomselection language. This will be fixed in the next version of topotools, but that doesn't solve your immediate problem. However, text replacement does! Replacing all instances of "K+" with Kp in the psf and prm files yields the attached top file. You may want to consider naming all of your potassiums "K" so that topogromacs doesn't recognize them as being different molecules, which might also be valuable for your other fragments, depending on if the larger assemblies are supposed to repeat or not.

Now, I don't know your system as well as you do, but I'm going to warn you of my own experience dealing with GROMACS: it expects the input coordinates to be given in the exact order that they are given in the .top file, so you can't do what I think you are doing here and intersperse connected elements with ions, or otherwise have fragments that are nonconsecutive, since that will throw off your indexing, and grompp will badly distort your system geometry as a result. I had to deal with this in one of my own projects, and this is what I used to reorder the system so that everything was in the same order in the psf and pdb as it would be in the .top file (adjusted to fit your system after renaming).

set fragsellist [list ]
set asel [atomselect top "not type Kp"]
foreach frag [lsort -unique [$asel get fragment]] {
set fsel [atomselect top "fragment $frag"]
lappend fragsellist $fsel
}
set potsel [atomselect top "type Kp"]
$potsel set name K
lappend fragsellist $potsel
set newmol [::TopoTools::selections2mol $fragsellist]
animate write psf reordered.psf $newmol
animate write psf reordered.pdb $newmol

This "reordered" pdb/psf pair is what you'd pass into topogromacs as well as grompp.

-Josh

On 2018-04-23 14:56:45-06:00 fan li wrote:

Hi

Sorry. I made a mistake. I used the wrong forcefiled parameters which I attached in previous email to generate the top file, so I got the top file which I have described. Then I used the correct one which I have attached, but I got an error

"atomselect: cannot parse selection text: type K+".

I think you can produce the error with the two files I provided.

Fan Li

2018-04-23 17:43 GMT+01:00 Vermaas, Joshua <Joshua.Vermaas_at_nrel.gov<mailto:Joshua.Vermaas_at_nrel.gov>>:
Hi,

This looks like the topotools output. I was actually hoping to get the parameterfile1.prm if you could. Thanks!
-Josh

On 2018-04-23 10:02:18-06:00 fan li wrote:
Hi Josh

Sure. The forcefiled file is attached.
Thanks for your time.

Fan Li

2018-04-23 16:51 GMT+01:00 Vermaas, Joshua <Joshua.Vermaas_at_nrel.gov<mailto:Joshua.Vermaas_at_nrel.gov>>:
Hi Fan,

Could you also send along the parameter file you are trying to use? From what you've provided, this should totally have worked if the parameter is in CHARMM format, so I'd like to try it for myself to see where the script is going wrong.

-Josh

On 2018-04-23 08:16:39-06:00 fan li wrote:
Hi Josh
I have loaded the psf file. And I also checked the "type" filed, and it does contain atom type. Although the psf is not originally generated by vmd, so I think vmd can still handle it as long as vmd can read it. I could not find any problems, so I have attached psf I used. Would you mind trying it and telling me what is wrong?
Thanks
Fan Li

2018-04-21 19:52 GMT+01:00 Vermaas, Joshua <Joshua.Vermaas_at_nrel.gov<mailto:Joshua.Vermaas_at_nrel.gov>>:
Hi Fan,

Did you load the psf first? topotools isn't doing anything magic, it is just matching what VMD has stored internally in the "type" field, which is not set correctly if you only load a pdb, since it does not contain type information! To correctly load the system, load the psf first, and then (optionally), the pdb. Have you also checked the contents of your psf file? It may also be that you created it in such a way that it does not have atomtype information contained within it.

-Josh

On 2018-04-21 08:31:59-06:00 owner-vmd-l_at_ks.uiuc.edu<mailto:owner-vmd-l_at_ks.uiuc.edu> wrote:
Hi everyone
I am using the topo writegmxtop to conver the psf file to top file. The command I used is "topo writegmxtop my.top [list parameterfile1.prm]". The angles and dihedrals are correct, but the "type" column in atoms directive is same as the "atom" column (I mean C1, C2 are the labels for the "atom", but it should be same label as the one in the forcefiled in the "type" column ,but it is not in my case). The atom type is already in my psf file and parameterfile1.prm file, and there is no errors and warnings during the conversion.
Is there something wrong or it the right result?
Fan Li