displace_listed_type_weight

[sebastianecheverrir]

Dear Forum,

There seems to be an issue with the following command:

Code: Select all

displace_listed_type_weight = 1

When this command is used in the

Code: Select all

config.ini

file, the eon simulation does not run and the following error is shown:

Code: Select all

Traceback (most recent call last):
  File "/home/sebastian/PythonEnvironments/EON35/bin/eon", line 11, in <module>
    load_entry_point('eon==1.0.0', 'console_scripts', 'eon')()
  File "/home/sebastian/eon/eon/main.py", line 15, in main
    config.init()
  File "/home/sebastian/eon/eon/config.py", line 269, in init
    self.disp_listed_types = [ (string.strip(c)) for c in parser.get('Saddle Search', 'displace_type_list').split(',') ]
  File "/home/sebastian/eon/eon/config.py", line 269, in <listcomp>
    self.disp_listed_types = [ (string.strip(c)) for c in parser.get('Saddle Search', 'displace_type_list').split(',') ]
AttributeError: module 'string' has no attribute 'strip'

The exact same input file but without the command

Code: Select all

displace_listed_type_weight = 1

works fine.

Any ideas of what might be the problem?

Attached the files used to run the simulation

Regards,
Sebastián

Some info about the system:
Ubuntu 20.04
python3.5 (Same issue found with 3.7)
Eon version svn revision 2467

[graeme]

Sebastián,

Thank you very much for the note. I am always happy to hear about problems with our code so that we can fix them.

In you case, a line was missed in our python 2->3 transition. If you go into the eon/eon directory and change line 269 in config.py to the following:

self.disp_listed_types = [ (c.lstrip()) for c in parser.get('Saddle Search', 'displace_type_list').split(',') ]

then it should work. I will make this change in our code right now.

Also, note that the atom type(s) should be specified as C or Fe in the variable displace_type_list, not 1, as you had in your config.ini

Graeme

[sebastianecheverrir]

Dear Graeme,

Thanks or your prompt reply. The fix that you suggested indeed got rid of the error.

In a related topic, I am trying to simulate the diffusion of C in Fe. The system contains a single C atom and a dislocation quadrupole.

Initially, I let EON select randomly the epicenter of each transition to a new state. Since the energy barriers for the movement of the dislocations were much smaller than those required for C diffusion, the result was that the dislocations started to move while the carbon remained at the same position. See attached video/gif.

Since I am interested in the diffusion of C, I ran a second try which consisted in including the following 2 commands in the config.ini file :

Code: Select all

displace_type_list = C
displace_listed_type_weight = 1

I was expecting that this would force the transition to occur centred around the C atom. Unfortunately that was not the case. The transitions that EON find still correspond to the motion of dislocations.

Additionally, the following message is printed out.

Code: Select all

No displaceable atoms found in the active region around atoms that moved in the previous transition;  reverting to the full list of any displaceable atoms.

Could you please give me some advice on how to tackle this problem? Is there a way to force the transition to occur centered around the C atom? If needed, I can share the full input files

Regards,
Sebastián

[graeme]

Sebastián,

You have identified the Achilles heal of this simulation methodology. In many cases, when you follow the state-to-state dynamics, you find that there are low-barrier processes that occur (and should occur) even when you don't care about them. We have just a few ways to deal with this problem. One is coarse-graining, where if you revisit states connected by low barriers, they will be lumped into superbasins and the dynamics will proceed outside of those superbasins, where the internal (fast) dynamics in the superbasins are treated analytically. A second strategy is to specify a maximum rate, so that any faster event is set (artificially) to the specified max_rate. This is approximate, and should be used with caution, but it will allow for fast processes that are known to be in quasi-equilibrium to occur at a slower rate than they should. Basically you can say that any event occurring on a time scale faster than say 100 ps is equilibrated, then you can set the rate of that event to the max_rate = 1/100ps, so that you are able to see the slower dynamics of interest.

If you ever want to have someone in the group look into this, we are always happy to help with such projects, especially when they involve method development.

Graeme

[sebastianecheverrir]

Dear Graeme,

Thanks again for your response. I would indeed be interested in having someone from your team looking into this. Some days ago I sent you an email to the address available on your website. Looking forward to hearing from you.

Regards,
Sebastián