Problem with atom_list being frozen atoms or empty

[Frederic.Houlle]

Hi,

I'm Frederic Houlle, a PhD student working at the University of Erlangen-Nuremberg, in Prof. Erik Bitzek's group - I hope this is the right place to post this.

We're trying to use EON to find some vacancy migration processes at a grain boundary (GB) in Al, modeled with an lammps format embedded atom method potential.

To this end, we've generated our structure, converted it to a .con format that EON can read, based on the pos.con in the akmc-al example folder.

It's essentially a cylinder centered on the GB, where the atoms in a hollow cylinder of a given thickness at the surface of the cylinder are kept frozen. (At least, I give them a type of 1...) The other atoms all have a type of 0.
This structure is picked in order to have periodicity in the axis of the GB.
It contains 3771 atoms, a lot of which are uncoordinated, given that the cylinder has a surface and contains a GB.
The last atom in the pos.con should be the epicenter of our saddle search.

When running eon, I get the following output:
Eon version svn revision 2325M
Traceback (most recent call last):
File "/data/houlle/TOOLS_/eon/bin/eon", line 3, in <module>
main()
File "/data/houlle/TOOLS_/eon/eon/main.py", line 33, in main
akmc.main()
File "/data/houlle/TOOLS_/eon/eon/akmc.py", line 589, in main
akmc(config)
File "/data/houlle/TOOLS_/eon/eon/akmc.py", line 109, in akmc
explore_state, superbasin=sb)
File "/data/houlle/TOOLS_/eon/eon/explorer.py", line 140, in __init__
MinModeExplorer.__init__(self, states, previous_state, state, superbasin)
File "/data/houlle/TOOLS_/eon/eon/explorer.py", line 101, in __init__
self.displace = displace.DisplacementManager(self.reactant, moved_atoms)
File "/data/houlle/TOOLS_/eon/eon/displace.py", line 42, in __init__
displace_all=config.displace_all_listed)
File "/data/houlle/TOOLS_/eon/eon/displace.py", line 301, in __init__
raise DisplaceError("Listed atoms are all frozen")
eon.displace.DisplaceError: Listed atoms are all frozen

And this is whether I used -1 or 3770 in displace_atom_list=

I can't see what we're doing wrong. The akmc-al example does work, and when centering displacements on the last atom of type 1 in the pos.con it gives the same error. Beyond that, it works.
It's also not really clear to me how to define the box' periodic directions - any help would be great.

[graeme]

I will certainly take a look at this. Can you post a .tar.gz file of the entire initial directory for the calculation? That way, I will also be able to make sure that the calculation will start properly.

[Frederic.Houlle]

Hi again,

I logged back into my computer this morning, copied pos.con, config.ini and potfiles/ into a new folder - tried eon in there, and it worked.

I suspect the problem was due to having other files in the folder whose name started with pos. Cleaning up my old folder also worked.

Indirectly, you solved the problem. :) Thanks.

EDIT: However, (sorry, celebrated too quickly) even with the options specified it seems to only find processes through random displacements. So I've attached the initial folder in a tar.gz.

[graeme]

Can you say a little more about what you mean that the the calculation only seems to find processes through random displacements? In your config.ini, I see that it is set to only do random displacements and when I run the calculation, I see that it is finding saddles. I set it up to run on a 24 core node and saw it make a transition after a few minutes with the following rate table from state 0:

proc # saddle energy prefactor product product energy product prefactor barrier rate repeats
0 -12287.41936 1.00000e+12 -1 -12287.41948 1.00000e+12 0.01826 7.67304e+11 28
1 -12287.40746 1.00000e+12 -1 -12287.44675 1.00000e+12 0.03016 6.45655e+11 11
2 -12287.26370 1.00000e+12 -1 -12287.29482 1.00000e+12 0.17393 8.02215e+10 0
3 -12287.11891 1.00000e+12 -1 -12287.17064 1.00000e+12 0.31872 9.82100e+09 0
4 -12287.41371 1.00000e+12 1 -12287.46895 1.00000e+12 0.02392 7.06823e+11 60
5 -12287.34230 1.00000e+12 -1 -12287.36651 1.00000e+12 0.09533 2.50870e+11 4
6 -12287.33977 1.00000e+12 -1 -12287.35566 1.00000e+12 0.09785 2.41865e+11 1
7 -12287.03170 1.00000e+12 -1 -12287.48587 1.00000e+12 0.40593 2.77177e+09 0
8 -12286.87123 1.00000e+12 -1 -12287.44838 1.00000e+12 0.56640 2.70298e+08 0
9 -12287.27708 1.00000e+12 -1 -12287.27787 1.00000e+12 0.16054 9.74191e+10 1
10 -12286.66715 1.00000e+12 -1 -12287.36295 1.00000e+12 0.77047 1.40043e+07 0
11 -12287.32185 1.00000e+12 -1 -12287.32890 1.00000e+12 0.11578 1.86474e+11 0
12 -12287.38684 1.00000e+12 -1 -12287.41064 1.00000e+12 0.05079 4.78672e+11 0
13 -12287.39498 1.00000e+12 -1 -12287.41611 1.00000e+12 0.04265 5.38663e+11 0
14 -12286.92713 1.00000e+12 -1 -12287.13327 1.00000e+12 0.51049 6.08218e+08 1

If you are saying that there is another way that you are trying to find saddles (perhaps with MD?) that is not working, then please post the files for that calculation and describe the problem. Then I should be able to debug it.

One small comment: with such a large and disordered system, you may find that things so a little slow in terms of simulation time. With barriers as low as 0.018 eV (see proc #0), the time evolved in the transition to state 1 is less than a ps:

step-number reactant-id process-id product-id step-time total-time barrier rate
---------------------------------------------------------------------------------------------------------------
0 0 4 1 9.248700e-14 9.248700e-14 0.023920 7.068233e+11

If these small barriers cause the system to anneal then you may see more progress as the simulation proceeds. If not, the AKMC approach could be slower than simply running dynamics. Depending upon the number of small barriers, you can turn on coarse graining to escape from a set of transient states to an adsorbing state over higher barriers.

[Frederic.Houlle]

Thanks for getting back to me on this.
I see similar results, actually.

I thought displace_atom_list=-1 in my config.ini was meant to center the epicenter on a specific atom in the configuration (as opposed to displace_random_weight), but I guess the 'random' from reported processes found actually refers to the displacements, and not where the epicenter was positioned?

If so, that just means I was confused by the output and it's all working fine.

Thanks for the further tips. It does move significantly, although yes, given the number of transient states (the kMC moves do show a lot of back and forth between similar states) it may be better to coarse grain.

[graeme]

Yes, you are right: the displacements are set for a specific atom with a random displacement.