input coordinates & charges

[Axel]

On May 12, 6:19 am, Csilla Varnai <cv... at cam.ac.uk> wrote:
> Dear all,

dear csilla,

> I have redefined the atomic types, and regenerated the CHARMM22
> potential file according to the new atomic types, at first sight in a
> very simple-minded way, substituting all the possible new atomic types
> (say, CC1, CC2) into the old ones (CC). But in this case, due to the
> large potential file, running the program is hopeless.

what program? cp2k? hopeless in which sense?

it would be much easier to help you, if you'd explain
in more detail what you are actually trying to achieve
and what kind of systems you are planning to model.

> I must confess I have not tried the VMD psfgen, since I would like to
> invoke CP2K from another program, and that is the reason why I would
> like to avoid the use of other programs like the VMD psfgen. If I

whatever you do you _have_ to generate a "topology".
using a .psf and .par file is a very convenient way.
if you don't like using psfgen, you could consider
creating your topology directly. have a look at

http://www.ks.uiuc.edu/Training/Tutorials/namd/namd-tutorial-unix-html/node21.html

and the following pages for a minimal description of the format.
more details are in the parametrization tutorial on the same
server and - of course - on http://www.charmm.org/

unless you have to generate a large number of topologies
on the fly, i would guess that actually using psfgen with
some smart VMD/tcl scripting will be much faster than
writing your own tool.

> the cp2k f77_interface, would it make any difference concerning to
> this problem? Should I also have a potential file containing atomic
> types with unambiguously defined charges? If that is the case then I
> run into the same memory problem. Does the psfgen seem to be the only
> solution?

what memory problem?

cheers,
    axel.


> Best regards,
>
> Csilla
>
> On 7 May 2008, at 17:04, Teodoro Laino wrote:
>
> > Dear Csilla,
> > you got exactly the point.
> > In CP2K we take the CHARMM convention where a type has associated a
> > charge.
> > This is different from AMBER where the same type can have different
> > charges.
>
> > So the best thing to do is to redefine your types according the
> > convention that a type
> > has a well defined charge (this most of the times is terribly easy..
> > just append a letter or a number to
> > the existing type).
>
> > Cheers
> > Teo
>
> > p.s.: even with PDB this won't necessarily work. I'm not TOTALLY
> > sure but  in case you define two different
> > charges for the same type, only the first one may be assigned to
> > that type. The result is that the
> > charges of your system will be wrong. I will add a warning for
> > handling this exception, though reading
> > the charges from the beta column of the PDB is not something really
> > standard.
>
> > On 7 May 2008, at 17:55, Csilla Varnai wrote:
>
> >> in case of peptides. Hence, I need to read in the charges. I have
> >> found only 1 way to do it so far, namely reading it from a PDB file.
> >> My problem is that in this case I loose the accuracy of the
> >> coordinates, since this format is fairly restricted and I cannot read
> >> the coordinates only at a +/-0.001 level.
> >> Could anyone please help me, if there is a better way I've missed to
> >> get both the charges and the coordinates at a given accuracy?