Hi Sebastian
Thank you for your detailed explanation, and forgive me for having
not given Vipster its due attention for so long! (Steve, if you are
reading this, please add Vipster to the "prepost.html" page.)
Regarding the improvement-part:
As I see it, the basic functionality of what you propose here is already
present.
Please tell me if you find it reasonable as far as the current >
implementation goes, what do you miss?
It honestly does sound as though you already implemented the main
functionality that I was hoping for. (Being able to explicitly type
in an arbitrary atom type name is the most important feature as far as
moltemplate is concerned. Automatic angle, dihedral, and improper
generation is a great feature as well. More on that below.)
Again, I haven't tried Vipster yet. From your description, the
only extra features I might ask for would be some minor changes to
make it easier for ordinary end-users to read Vipster-generated files
directly into moltemplate. The file moltemplate file format is
slightly different, but it's almost the same as a LAMMPS data file. I
am happy to elaborate, but let's postpone that for now, and discuss it
in June (once my current deadline is over).
I wasn't under the impression that Vipster can generate angles,
dihedrals, or impropers.
Am I wrong about this?
They're limited to being generated from the bond-topology, but so far
they can be generated.
That's an important feature. And ussually, this will work. There are
some irritating caveats. Sometimes the same angle or dihedral
interaction is used for different atom types, so you don't necessarily
want to define a new angle or dihedral type for every new combination
of 3 or 4 atom types that you run across in the user's molecule. (I
assume that is what you are doing.) Another thing which is incredibly
frustrating and stupid is that some force-fields use strange symmetry
rules for generating improper interactions. This means that the number
of improper interactions which should be generated can depend on which
force field the user has selected. (I seem to recall that some class2
force fields may also have strange symmetry rules for angles and
dihedrals as well, so the problem is not limited to improper
interactions.)
This means that if you ever decide to export directly into
moltemplate format, I might request that you omit all angles,
dihedrals and impropers from the file that you generate in that case.
Moltemplate can take over this ugly aspect of the problem, and lookup
angle, dihedral, and improper parameters for these interactions in a
way that depends on the force field the user has selected. (But I
don't think you should remove this feature from your program. For
most force-fields, the normal rules for generating dihedrals and
impropers should probably work.)
I know that the gaff.dat files e.g. specify their types in lower-case,
which clashes with my type-assignment.
How does moltemplate handle capitalization?
---- Atom type names: ----
Moltemplate is often used for building extremely coarse-grained
models (where every particle could represent an entire protein, for
example). As such it doesn't have an innate concept of what a carbon
atom is, and it does not interpret capitalization in any special way.
Unfortunately, the atom type name in some force-fields is numeric
(such as the version of OPLSAA used by TINKER and by moltemplate). I
wonder if it might be possible to automatically guess the element type
(ie carbon) by examining the mass (atomic weight) of the atom. (Off
the top of my head I can't think of a lot of examples where this would
fail except for isotopes. Perhaps I could use this strategy to
rewrite the OPLSAA force field so that the atom type names suggest
what kind of element it is. I don't have time to worry about this
now, but it seems doable.)
>> I am trying to model epoxy molecule. At the beginning I made the epoxy molecule and then I used Vipster to prepare an initial Lammps data file. However, this procedure does not work.
>> Since, for example, Vipster does not consider any difference between Cs with 3 and 4
>> connections. Therefore, quantity of bond types and angle types are less than the reality.
>> I am also concern about dihedrals and impropers which are more difficult to analysis.
This is (unfortunately) intended behavior.
You need to assign the different carbon types by hand, e.g. "C3" or "CA"
for sp3 and aromatic carbon.
These will retain the properties of carbon, but will lead to
distinguished bond-types for C3-C3, C3-CA and CA-CA bonds (and of
course, angles and dihedrals).
I agree. I don't like the idea of Vipster choosing or limiting the
number of bonds that an atom can form. Is it really too hard to ask
the user to draw the correct number of bonds coming out of each atom?
(As you mentioned earlier, it's difficult to try and guess the number
of bonds available to a "Ca" atom: Is that a calcium atom or an
alpha-carbon, or an aromatic carbon? I also say this partially for
selfish reasons: If Sebastian were to implement this feature, then it
will be impossible to use Vipster to build coarse grained models with
exotic particle types which do not correspond to atoms. I admit that
most users don't care about coarse grained modeling, but some do. And
they use LAMMPS because LAMMPS is nearly the only kind of software
gives you the freedom to do what you want.)
Anyway, don't worry about this for now.
> I'm curious to hear
> your impressions about Vipster.
> Is it worth the investment of time and effort? Is Vipster (otherwise)
> useful and easy to use?
I'm even more curious 
Well, it sounds like he was able to get it to work. He was only
confused by the need to supply detailed atom type names. It's not
surprising that Bahman ran into this difficulty. Perhaps, once we get
our tools working well together, we would need to do is create some
good tutorials for how to use them.
Let's talk more in mid-late June, after I am done with my current
deadline and get a chance to try out Vipster. I'd love to get these
tools to work well together.
Cheers!
Andrew