mcmd

[brucefan1983]

• Implement MCMD, solving Add support for Monte-Carlo #236
• Largely follow mchammer in icet: https://icet.materialsmodeling.org/moduleref_mchammer/index.html
• Only for canonical ensemble in this PR. Will do other ensembles in the future.
• Only for NEP models.
• For a 1 : 1 ratio of MD : MC, the overall computation time is usually increased by < 20% (for sufficiently large systems).
• Proposed syntax:

# fininished:
mc canonical  <md_steps> <mc_trials> <initial_temperature> <final_temperature> [group <grouping_method> <group_id>]

# to be implemented:
mc sgc <md_steps> <mc_trials> <initial_temperature> <final_temperature> <mu> [group <grouping_method>  <group_id>]
mc vcsgc <md_steps> <mc_trials> <initial_temperature> <final_temperature> <phi> [kappa <kappa>] [group <grouping_method> <group_id>]

# example:
potential    nep.txt
velocity     300

ensemble     nvt_lan 300 300 100
mc           canonical  10 10 800 300 group 1 0
run          100

• During the running, a file named mcmd.out will be updated. It reads like the following (my test example is cyrstalline PbTe and no swapping will be accepted):

# num_MD_steps  acceptance_ratio
10  0
20  0
30  0
40  0
50  0
60  0
70  0
80  0
90  0
100  0

[erhart1]

I have been testing this branch on a couple of systems now. The system does evolve energetically but it seems that the species that are written to the movie.xyz file are not updated. The atomic distribution at the beginning of the simulation is identical to the one in the end, safe for thermal displacements of the atoms.

[erhart1]

Thanks. Now it seems to work. Amazing response time 🐎

[erhart1]

Atm the data in the mcmd.out file is cumulative.
In my experience the "instantaneous" acceptance ratio (the number since the last dump) is the one to keep track of.
Also there is no need afaics to print the number of trials, rather I would print the instantaneous acceptance ratio only.

Could one also consider adding this information to the thermo.out file (also see #473).

[erhart1]

Wishlist

I thought about how the interface/input parameters could be structured from a user perspective and also looking forward in terms of additional ensembles to implement as well as future applications.
Here is a suggestion

# basic format
mc <ensemble> <md_steps> <mc_trials> <initial_temperature> <final_temperature> {<ensemble_specific_parameters} [group <group_id>]

It should be possible to specify both an initial and a final temperature to enable simulated annealing, which is a common approach in mixed system used to find ground states and low energy structures.

The group <group_id> block is meant to allow selecting a subset of species/sites/atoms to work on.
Consider, e.g., mixed oxides, carbides or nitrides, say Mg(1-x)Zn(x)O.
In such a case one should only consider swaps between Mg and Zn.

The canonical ensemble does not need additional parameters or keywords.

mc canonical  <md_steps> <mc_trials> <initial_temperature> <final_temperature> [group <group_id>]

For the semi-grandcanonical ensemble one would need to specify the chemical potential

mc sgc <md_steps> <mc_trials> <initial_temperature> <final_temperature> <mu> [group <group_id>]

For the variance constrained semi-grandcanonical ensemble one would need to specify the parameters that constrain the mean (phi) and the variance (kappa).
For the latter one can set a suitable default.

mc vcsgc <md_steps> <mc_trials> <initial_temperature> <final_temperature> <phi> [kappa <kappa>] [group <group_id>]

What do you think?

[brucefan1983]

Atm the data in the mcmd.out file is cumulative. In my experience the "instantaneous" acceptance ratio (the number since the last dump) is the one to keep track of. Also there is no need afaics to print the number of trials, rather I would print the instantaneous acceptance ratio only.

Could one also consider adding this information to the thermo.out file (also see #473).

"instantaneous" acceptance ratio is ok for me, but dumping in thermo.out seems to be nontrivial as the intervals might not be consistent.

[brucefan1983]

Wishlist

I thought about how the interface/input parameters could be structured from a user perspective and also looking forward in terms of additional ensembles to implement as well as future applications. Here is a suggestion

# basic format
mc <ensemble> <md_steps> <mc_trials> <initial_temperature> <final_temperature> {<ensemble_specific_parameters} [group <group_id>]

It should be possible to specify both an initial and a final temperature to enable simulated annealing, which is a common approach in mixed system used to find ground states and low energy structures.

The group <group_id> block is meant to allow selecting a subset of species/sites/atoms to work on. Consider, e.g., mixed oxides, carbides or nitrides, say Mg(1-x)Zn(x)O. In such a case one should only consider swaps between Mg and Zn.

The canonical ensemble does not need additional parameters or keywords.

mc canonical  <md_steps> <mc_trials> <initial_temperature> <final_temperature> [group <group_id>]

For the semi-grandcanonical ensemble one would need to specify the chemical potential

mc sgc <md_steps> <mc_trials> <initial_temperature> <final_temperature> <mu> [group <group_id>]

For the variance constrained semi-grandcanonical ensemble one would need to specify the parameters that constrain the mean (phi) and the variance (kappa). For the latter one can set a suitable default.

mc vcsgc <md_steps> <mc_trials> <initial_temperature> <final_temperature> <phi> [kappa <kappa>] [group <group_id>]

What do you think?

This look very good. I will change the syntax to largely follow this, although currently there is only canonical.

[erhart1]

"Bug"

At the moment the gpumd executable gets stuck if there are no possible moves (e.g., a system that contains only a single element).
It just consumes GPU time without producing any further output or warning.

[brucefan1983]

"Bug"

At the moment the gpumd executable gets stuck if there are no possible moves (e.g., a system that contains only a single element). It just consumes GPU time without producing any further output or warning.

Yes, this can be confirmed, and it was caused by not checking if there are sufficiently many species to swap. The code entered an ifinite while loop for looking for a different atom pair. I have added a check and now you will get the following error message:

Input Error:
    File:       mc/mc_ensemble.cu
    Line:       65
    Error text: MCMD only supports multi-component models.