Re: [AMBER] A problem about periodic box dimensions happens to Tutorial 1.7

From: wangwei1669 <>
Date: Wed, 8 Sep 2021 11:44:06 +0800 (CST)

Hi, David,

I have re-run the simulation as This time it stopped at around 21 ns, and the restarted simulation stopped at 32 ns.
I have also run a simulation with an additional line "taup=2" to the file. This time the simulation finished at 125 ns.

For both situation the density and volume in the output file are maintaing stable during the simulation. And they do not change a lot near where it crashes for situation 1. However, the values are also strange since the system in fact is expanding shown in VMD. But the water molecules only expand along x- and y- direction. The final structure is like that two "plates" of water clamp the lipid cube.

Best regards,

Wang Wei

At 2021-09-07 04:27:50, "David A Case" <> wrote:
>On Sun, Sep 05, 2021, wangwei1669 wrote:
>>I don't know why there are larger density and smaller volume recorded after
>>600 ps than those at 105 ps. I see the systems dramatically enlarging after
>>105 ps (hold and production).
>This is because your initial density is much lower than the system wants,
>and commonly is seen in water simulations, depending on exactly how you
>added water to the system. Once the water gets to about the right density,
>there are no futher changes.
>>And I also concern that I sourced ff14SB force field instead of ff12SB
>>that used in tutorial web since I did not find it. Does this significantly
>>influence the result?
>This should make no difference. ff14SB is the "final" version of this force
>field, whereas ff12SB was an intermediate version, but very close (I think)
>to the final version
>>>>The simulation stopped at 80 ns and I received a feedback:
>>>>"ERROR: Calculation halted. Periodic box dimensions have changed too much
>>>>from their initial values.
>As I said, it is unusual to have a simulation halt in this way during the
>middle of a run...or did you get this message near the beginning of a
>restart? You could look not just at the average density over the whole 80
>ns, but rather at the behavior right before the crash. You may need to
>re-run a simulation with a slightly shorter time (before the time of the
>crash), then see if you have problems when restarting. What you are trying
>to get is a way to reproduce the crash without needing a long simulation.
>That would be the first step to tracking down what is going on.
>AMBER mailing list
AMBER mailing list
Received on Tue Sep 07 2021 - 21:00:03 PDT
Custom Search