fix_deposit cycles not introducing atoms everywhere

LAMMPS LAMMPS Mailing List Mirror
1

Hello people,

I have a puzzling problem with a cycle of fix_deposit runs.

I’m simulating a large number of ion impacts on a surface to study reflected vs. absorbed energy of the incoming ions. An ion impacts at the beginning of a simulation, the simulation runs for a short while until the ion has either reflected and escaped from the system or it has penetrated the surface and thermalised. Then the next short simulation starts from the same starting substrate, with the He being introduced at a different random location. And so on.

I’m passing a random seed from bash when invoking the lammps executable. The script I’m using for a short test of just 100 impacts looks as follows:

counter=1
while [ $counter -lt 101 ]; do
~/bin/lammps-Oct2014-USERMISC-mpi -var seed1 bash -c 'echo $RANDOM' < in.WHe
mv dump dump.$counter
mv log.lammps log.lammps.$counter
let counter=counter+1
done

The problem is that while the x-y region where ions are supposed to be inserted is 64A x 64A, ions are introduced over the entire y-range, but only in an x-range of 0-17A, see attached tiff. I can’t figure out why. The surface is bcc (100) W, equally large and symmetrical in x and y. I checked if the simple bash random number generator was maybe producing very bad random numbers, but that was not the case. While the numbers produced weren’t perfectly evenly spread, they did cover the intended 0-32768 range without major gaps or strong concentrations in one value range, see second attached tiff picture. And I don’t see how bad random numbers would explain why things are ok in the y direction but wrong in the x direction.

My stripped-down in-file for an extremly short 1-impact run (just enough to introduce the He ion) is pasted below. An archive with all the relevant files (including the tiff figures, in case the tiffs don’t make it through to the mailing list post, plus the dump file lines of the introduced He’s called ‘He_lines’) is at

http://131.180.120.142/testdir.tar.gz

Would anyone have an idea why the ions are being introduced only over a part of the surface rather than evenly over the whole surface?

greets,
Peter

Pure W crystal

processors 1 1 1

units metal
atom_style atomic
dimension 3
boundary p p f

read_data begindata
lattice bcc 3.1983
region inserthere block EDGE EDGE EDGE EDGE 52.98 52.99

mass 1 183.84 # W
mass 2 4.0026 # He

pair_style hybrid eam/fs table spline 10000 table spline 10000
pair_coeff * * eam/fs Juslin_W_W.eam.fs W NULL
pair_coeff 2 2 table 1 Juslin_He_He.table HeHe
pair_coeff 1 2 table 2 Juslin_W_He.table.2 WHe

neighbor 1.50 bin
group Heatoms type 2

neigh_modify every 10 delay 10 check yes

fix keepE all nve

print "seed: {seed1}" fix Heflux Heatoms deposit 1 2 2 {seed1} region inserthere id next vx 0.0 0.0 vy 0.0 0.0 vz -538 -538 units box

dump mydump Heatoms custom 3 dump id type x y z vx vy vz fx fy fz
dump_modify mydump element W He
dump_modify mydump sort id

fix vartime all dt/reset 1 NULL NULL 0.025 units box

thermo_style custom step time temp etotal pe ke press pxx pyy
thermo_modify norm no
thermo 1
run 3

xy-intro_coord.tiff

seed_values.tiff

2

Fix deposit is picking the insertion locations within

the extent of the region you gave it. Note that regions

use lattice vs box coords depending on how you define it.

You can put a print statement inside fix_deposit to

assure yourself that it is using the right region extent.

Look for the values of xlo, xhi, etc.

Steve

xy-intro_coord.tiff (28.6 KB)

seed_values.tiff (29.9 KB)

3

Hello people,

I've found out what the problem is.

The random integer that bash generates, ranges from 0-32768. That relatively low maximum limits the x-range of the first particle that is introduced. Limiting the seed to still smaller values constrains the x-range where particles are introduced even further.

Subsequent particles in the same run are introduced over the entire designated area, so only the first introduced particle is affected.

The reason that I had a problem, was that I was doing doing short runs with only 1 impact and then restarting with a new seed from bash in the 0-32768 range.

The 'problem' is easily resolved by first multiplying the bash seed by 10 or 100 or so, then passing the resulting value to lammps as seed number. Then even the first particle is introduced randomly over the entire x-range.

greets,
Peter

4

Maybe I am misunderstanding. Are you saying that for all seeds between 0 to 32768, LAMMPS picks a random number for x that is somewhere between 0 and 0.2 of the bounds of the region? That seems like really weird design to me, but I am not an expert in generating random numbers.

I did a little test, the attached script generates series for all seeds from 1 to $MAXSEED (I tested up to 3000 or so) that seem to spread out nicely over the range (0,1), you can use the attached scripts to test. The function random for variables uses a Marsaglia generator rather than the Park-Miller/Lehmer variant from fix deposit, maybe that is the difference? If you would replace the Park-Miller generator (RanPark) with the Marsaglia one (RanMars), does it make a difference?

lawl.in (339 Bytes)

test_randoms.sh (308 Bytes)

randoms.dat (78.8 KB)

5

One thing to notice is that the method chosen for depositing particles is mathematically speaking not the best given the the PRNG is initialized each time a deposition event is required. There are certainly things like bad seeds which could lead to small period problems, etc. I certainly have not look into the code details but wonder if perhaps there is a better way to do the whole operation within the Lammps
input script using a combination of shell commands, deleting and re-reading the initial config but with “only one” call to fix deposit.
Carlos

6

Hi Stefan,

Maybe I am misunderstanding. Are you saying that for all seeds between 0 to 32768, LAMMPS picks a random number for x that is somewhere between 0 and 0.2 of the bounds of the region? That seems like really weird design to me, but I am not an expert in generating random numbers.

Yes, that is what happened *for the first particle introduced* in the run. If I introduced multiple atoms, then all atoms after the first one did cover the entire range perfectly normally.

I did a little test, the attached script generates series for all seeds from 1 to $MAXSEED (I tested up to 3000 or so) that seem to spread out nicely over the range (0,1), you can use the attached scripts to test. The function random for variables uses a Marsaglia generator rather than the Park-Miller/Lehmer variant from fix deposit, maybe that is the difference? If you would replace the Park-Miller generator (RanPark) with the Marsaglia one (RanMars), does it make a difference?

Uhm, that set of input files doesn't do any fix_deposit. I'm not sure what that is supposed to tell me about the fix_deposit issue?

greets,
Peter

7

What I meant tot say is that it is strange that someone would make a random number generator output as first pseudorandom number something between lo and lo+0.2*(hi-lo), independent of the seed. The Marsaglia generator does not do that, but from your description, it seems that fix_deposit does this, as it seems like the first random number it generates (the x-coordinate) was in a range of rougly 0 to 0.2 * your box dimensions. The input file was a test to see if the Marsaglia did this, and it does not. I understand that it does not matter that much if you have multiple deposits in a run, it just seems like a weird way to make a pseudo-random number generator work.

8

I’m not clear on how you are using fix deposit.

The way it is intended to be used is you provide

one random # seed, and let it deposit a large number

of atoms (over a long run). If you do that, the RNG

used inside fix deposit will do its job and spread the

particles out randomly. It uses a RNG well-suited

to that purpose.

At the other extreme, if you are calling fix deposit many times, to have

it deposit only one atom, and you are providing a “bad” seed

each time, meaning they are correlated in a bad way,

then I suppose fix deposit may insert single atoms

in a correlated way. I suggest the fix for that is

for you to give it better RN seems, e.g. ones that

are spread uniformly over the size of 32-bit int, since

that is what kinds of seeds fix deposit expects.

Steve

9

Hello Steve,

It is exactly as you say, and I was using the second scenario you describe: one impact in a short run, doing 10000 such runs through a unix command line script.

My 'bad' seed consisted of using the RANDOM variable in bash as seed, which runs only from 0-32768. Using seeds that run up to a larger value solves the issue, as you suggested.

greets,
Peter