Dear Axel,
Thank you for your quick reply,
I am going to try to reply in line as you did.
[...]
causes huge relaxations that are not expected nor seeing with other codes.
are you referring to running the *exact same* input geometry and force
field with a different MD software?Yes indeed same structure, same force field and DL_POLY 4. Sorry but If I
was referring to Microsoft Paint and AMBER FF I would not be asking on this
list or bothering you.
you would be surprised to see, how differently people on this very
mailing list would mean such vague descriptions. after 10+ years and
over 14000 response e-mails, you have to accept that i have seen quite
a few cases, where it would be a mistake to assume anything.
I have tried other systems Ca, CO3 ions in solution. The temperature
behaves very well in that case, but as a calcite surface is being published
before, made me think I am missing something important in my input file.you seem to be missing that a) almost any simulation protocol needs
include some steps of equilibration, and b) that many times initial
geometries may not be fully in accord with the force field used, even
if they represent experimental structures.I am not missing (a) on purpose. but thanks to pointing that out, I cannot
find anywhere in the manual instructions that are explicit to equilibration
that is because the purpose of the manual is to describe how to use
LAMMPS, and *not* to teach people how to do MD simulations. in many
parts the LAMMPS manual assumes, that the reader already knows how to
do MD simulations very well. you can compare that to a driver's manual
that comes with a car: it will explain how to operate the various
features of the car, but it does not teach you how to drive.
period. Other than start from lower temperatures, NVE or drastic thermostat
controls like "drag" I have tried several suggestions from the manual to
ease the starting of the simulation without success. And please note these
structure is being already simulated in DL_POLY and is behaving as expected.
Having said so, (b) was done. I would really appreciate the page of the
manual in which equilibrations methods are treated.
as i explained above, this has no place in a software manual. what is
the right way to do a system preparation and an equilibration is
strongly dependent on the actual system being studied.
thus for many complex systems, simulation protocols have to start with
checks for overlaps and high potential energy areas, usually followed
minimization/geometry optimization, followed by a
equilibration/thermalization MD runs. for complex systems and delicate
structures, multiple minimizations alternating with short
equilibration runs may be needed, often also for each subsystem
separately.if you have a polar surface in contact with a polar liquid, it is
*extremely* likely, that there are high potential energy spots where
the two subsystems are in contact, since the tool you are using to
construct the system does not no anything about the strength of the
interactions between the two systems.Oh, I see I was a bit misleading with my use of MOLTEMPLATE. The tool was
used to translate a pdb geometry of the last geometry of the system that was
produced by DL_POLY (same FF) Sorryfurthermore, before starting a simulation with a multi-component
system, you should validate your force field parameter and geometry
input by simulating each component separately and verify, that there
are no typos or unit conversion errors or geometry mistakes.at this point i do feel a bit like a broken record, since i seem to be
giving this kind of advice and suggestion regularly on this mailing
list, so perhaps you need to widen your scope of search through the
mailing list archives a bit.axel.
I am really sorry to make you feel like a broken record. As I said before,
the force field has been used before in this system. I am using a FF file
that was provided in a Supplementary Information of a paper and, I am
actually using the values in another well known MD code. In fact, I have
simulated the water alone, the ions on their own and both systems together
using the same version of lammps. The issues ONLY arise when it is a surface
and, the system is not exploding or going totally crazy. It is just relaxing
far too much (in comparison) and showing initial spikes of temperature that
disappear after the first few steps . It is happening with Nosé-Hoover
thermostat not with the others.
the thermostat thing is a red herring. you don't see it to the same
degree with other thermostats, because you can force other thermostats
to suppress the energy peak because they can transfer energy more
quickly. nose-hoover thermostats are for systems that *are* in
equilibrium, but yours is obviously not. this all sounds like there is
an error in translating the geometry/topology from DL_POLY to LAMMPS.
this would likely be easier to debug, if you translate only the solid
part of your system and study it by itself.
I am sure to be missing some very important parameter to equilibrate the
system. I am 100% sure there are not numerical errors in the FF and the
initial geometry is not far from equilibrium. I am saying this because
i have heard this statement *many* times, but you are excluding a) the
human element, i.e. everybody can make typos or mistakes when
transferring force field parameters from one package to another. some
have different conventions for different interactions, b) the
possibility, that in your attempt to do a conversion of the
topology/geometry you may have used incorrect settings, or made
assumptions that are not true for the software you are using or simply
there is a bug in the translation software. the numbers are against
you. from my experience, only about one in ten people that claim, they
did everything correctly, actually did it.
the only way to make certain is to check out each step and each
operation step by step. best start with a ridiculously small system,
where it is easier to track down issues.
according to what is published the calcite surface and the bulk behaved very
well in lammps. My appeal is for help of finding the right keyword to fire
the simulation.
i seriously doubt, that there is such a magic bullet. it is much more
likely, that there is some overlooked typo or mistake somewhere.
axel.