Hi everyone-
I have a question about read_restart. I am taking a system of atoms and equilibrating it, then throwing in a PKA. After equilibration (at 300 K) I write a restart file. If I directly continue the simulation and add a PKA, the temp goes up to 478. If I kill the run and start a new one, reading in the restart file then adding a PKA, the temp only goes up to 317. It's the same atom becoming the PKA, all other setting are the same. I'm just wondering what the difference would be... if I just read the restart file without a PKA, it shows the correct temp (300). Thanks,
Erin
What's a PKA and how do you do it in LAMMPS?
Steve
Sorry, a PKA is a primary knock-on atom, for damage cascades. Basically, I use a velocity command to assign a velocity equivalent to 20 keV (for example) to one atom. That simulates it being hit by a neutron or some other force disturbing it from its lattice site.
Erin
Hi Erin,
If you continue directly in a single run, the previously
specified fixes are still in effect. If you continue from
a restart file, you have to re-specify all the fixes you need,
since restart does not resume the fixes specified previously.
You can check the doc pages of restart/write_restart for
more details. Hope this helps.
L. Wan
2009/6/2 Hayward, Erin M Gillilan <erin@…123…>
Thanks for the idea, but I don't think that is the problem... During equilibration, I have a fix all nvt, then before I put in the PKA, I change to fix all nve. I'm turning off the first fix and turning on the second between writing the equilibration and running again, so it should not affect anything.
Erin
liang wan wrote:
Dear LAMMPS users,
are there any restrictions in using fix spring tether in the granular style?
I get the following segmentation fault:
LAMMPS (9 Jan 2009)
Lattice spacing in x,y,z = 1 1 1
Reading data file ...
orthogonal box = (-11 -11 -11) to (11 11 11)
1 by 1 by 1 processor grid
1 atoms
Setting up run ...
[buxtehude:18463] *** Process received signal ***
[buxtehude:18463] Signal: Segmentation fault (11)
[buxtehude:18463] Signal code: Address not mapped (1)
[buxtehude:18463] Failing at address: 0x8
[buxtehude:18463] [ 0] /lib/libpthread.so.0 [0x7faa449c17b0]
[buxtehude:18463] [ 1] lmp_openmpi(_ZN9LAMMPS_NS9FixSpring13spring_tetherEv+0x51e) [0x5aeede]
[buxtehude:18463] [ 2] lmp_openmpi(_ZN9LAMMPS_NS6Modify5setupEi+0x4d) [0x5e913d]
[buxtehude:18463] [ 3] lmp_openmpi(_ZN9LAMMPS_NS6Verlet5setupEv+0x228) [0x700178]
[buxtehude:18463] [ 4] lmp_openmpi(_ZN9LAMMPS_NS3Run7commandEiPPc+0x1f0) [0x6df720]
[buxtehude:18463] [ 5] lmp_openmpi(_ZN9LAMMPS_NS5Input15execute_commandEv+0xe0e) [0x5dc2be]
[buxtehude:18463] [ 6] lmp_openmpi(_ZN9LAMMPS_NS5Input4fileEv+0x27d) [0x5dcc1d]
[buxtehude:18463] [ 7] lmp_openmpi(main+0x4a) [0x5e311a]
[buxtehude:18463] [ 8] /lib/libc.so.6(__libc_start_main+0xe6) [0x7faa4467e5a6]
[buxtehude:18463] [ 9] lmp_openmpi(__gxx_personality_v0+0x3a9) [0x470f69]
[buxtehude:18463] *** End of error message ***
Speicherzugriffsfehler
With kind regards,
Thomas Wagner.
data.particles (106 Bytes)
in.dump (469 Bytes)
The current version of LAMMPS (fully patched) should
allow for this. Check your fix_spring.cpp and verify
it has logic for rmass() and mass(). The former is
needed for granular particles with per-particle mass.
This may have been a more recent patch than 9 Jan 09.
Steve
I'm not clear on exactly what you're doing. But conceptually,
I wouldn't include the high-energy knock-on in the temperature
computation or thermostatting. I.e. I would do those
operations on a group of atoms that exclude the PKA, else
you might get odd results.
Steve
Steve Plimpton schrieb:
The current version of LAMMPS (fully patched) should
allow for this. Check your fix_spring.cpp and verify
it has logic for rmass() and mass().
No, it hasn't. I'm going to recompile.
Thank You.
Thomas.
Fair enough... but I'm not actually using the temperature for anything, just reading it from the standard thermo output - and the point is, there is a difference between restarting and not. Let me try to outline more clearly the two scenerios.
1) a. Equilibrate perfect lattice at 300 K for 10 ps with fix nvt.
b. Write restart file
c. Turn off fix nvt and turn on fix nve
d. Continue run by assigning lots of velocity to one atom (the PKA) to initiate damage.
-> Shows temp of 478 in standard thermo output at the time run is continued.
2) a. Read in the equilibrated file created in scenario 1
b. Turn on fix nve (I believe the restart file should not remember the first fix, from reading the doc - anyway, I don't put any ref to it in the new input).
c. Continure run by assigning lots of velocity to one atom to initiate damage.
-> Shows temp of 315 in standard thermo output.
The two scenarios both assign the same velocity to the same atom ID, so they should be the same, at least at first. It's just strange, and I can't figure out what's going on. Could the fix nvt from the restart somehow still be in effect, trying to keep the temperature down?
Erin
Steve Plimpton wrote:
ok - the high T in (1) could be b/c you include the PKA
in the T.
The fix nvt should have no affect on this. It does put
a bit of info in the restart file, but it is ignored if your
new script doesn't define a fix nvt with the same ID.
You can verify this is a non-issue by unfixing the NVT
before step 1b instead of after.
The more general question is why 1 and 2 differ. It
could be just round-off causing two trajectories to
diverge. Restarts are not always exact. If you output
thermo frequently in the 2 cases, do they slowly diverge?
If you are doing anything in your script with random
numbers (e.g. fix langevin for thermostat) then that
will also diverge quickly after a restart as the
state of the RN is not maintained.
Steve
I will verfiy the non-issue about unfixing, and report back... As for diverging, they diverge immediately. I output thermo every 1 step, and it's the very first timestep after adding the PKA that is different. Nothing random (at least after equilibration). I'm using Nose-Hoover for the initial equilibration. It's an extreme difference though, for both to start at 300 K, then one to jump to 478 and the other to 315. The PKA is 10 keV, so I guess I expect to see the higher temperature, since I'm making no effort to not include the PKA...
Erin
Verified... turning off the fix nvt before writing the restart doesn't matter...
Erin
Alright, I've found something... on scenario b, with the restart, my lattice spacing is getting reset from 2.8553 in each direction to .888095. I have no idea why... the simulation box is actually the same size in each case. In the input file with the restart, I do state "lattice bcc 2.8553" again, because some of my future commands are specified in lattice units, and lammps need it. With the smaller lattice spacing, my PKA would be less energetic, and the lower temperature is explained. Now, why is lammps resetting my spacing like that?
erin
This is puzzling - nothing about the former lattice command is stored
in the restart file.
Can you post your lattice command, presumably the same in both cases?
And the resulting xyz spacings LAMMPS printed out?
Steve
I figured it out. Stupid human error as usual, nothing wrong with LAMMPS... I had put the lattice command above the read_restart command, so it was by default using lj units, until it read the metal units from the restart file, thus creating smaller spacings. Anyway, thanks for the help.
Erin