MCMC step too slow as compared to MD

LAMMPS
1

Hi,
When I use LAMMPS to run a pure MCMC simulation as,

fix 1 all gcmc 1 0 1 1 12345  1800 10.0 0.2
run 10000

I get total walltime of 0:01:18. I would expect MD to have similar walltime (if not slower) for 10000 MD steps

fix nvt all nvt temp 1800.0 1800.0 $(100.0*dt)
run 10000

but I get 0:00:08.

Detailed output is given below.

MCMC:

MPI task timing breakdown:
Section |  min time  |  avg time  |  max time  |%varavg| %total
---------------------------------------------------------------
Pair	| 7.7544 	| 7.7544 	| 7.7544 	|   0.0 |  9.94
Neigh   | 17.265 	| 17.265 	| 17.265 	|   0.0 | 22.13
Comm	| 0.59392	| 0.59392	| 0.59392	|   0.0 |  0.76
Output  | 0.0065886  | 0.0065886  | 0.0065886  |   0.0 |  0.01
Modify  | 52.324 	| 52.324 	| 52.324 	|   0.0 | 67.07
Other   |        	| 0.07375	|        	|   	|  0.09

Nlocal:        	512 ave     	512 max     	512 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost:       	1436 ave    	1436 max    	1436 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs:          	0 ave       	0 max       	0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs:    	18578 ave   	18578 max   	18578 min
Histogram: 1 0 0 0 0 0 0 0 0 0

Total # of neighbors = 18578
Ave neighs/atom = 36.285156
Neighbor list builds = 30000
Dangerous builds = 0
System init for write_data ...
  generated 0 of 0 mixed pair_coeff terms from geometric mixing rule
WARNING: Fix gcmc is being applied to the default group all (src/MC/fix_gcmc.cpp:657)
Neighbor list info ...
  update every 1 steps, delay 10 steps, check yes
  max neighbors/atom: 2000, page size: 100000
  master list distance cutoff = 5.77118
  ghost atom cutoff = 5.77118
  binsize = 2.88559, bins = 8 8 8
  1 neighbor lists, perpetual/occasional/extra = 1 0 0
  (1) pair kim, perpetual
  	attributes: full, newton off, cut 5.77118
  	pair build: full/bin/atomonly
  	stencil: full/bin/3d
  	bin: standard
Total wall time: 0:01:18

MD

MPI task timing breakdown:
Section |  min time  |  avg time  |  max time  |%varavg| %total
---------------------------------------------------------------
Pair	| 7.8686 	| 7.8686 	| 7.8686 	|   0.0 | 93.21
Neigh   | 0.18398	| 0.18398	| 0.18398	|   0.0 |  2.18
Comm	| 0.17472	| 0.17472	| 0.17472	|   0.0 |  2.07
Output  | 0.0028456  | 0.0028456  | 0.0028456  |   0.0 |  0.03
Modify  | 0.17596	| 0.17596	| 0.17596	|   0.0 |  2.08
Other   |        	| 0.03559	|        	|   	|  0.42

Nlocal:        	512 ave     	512 max     	512 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost:       	1433 ave    	1433 max    	1433 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs:          	0 ave       	0 max       	0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs:    	18630 ave   	18630 max   	18630 min
Histogram: 1 0 0 0 0 0 0 0 0 0

Total # of neighbors = 18630
Ave neighs/atom = 36.386719
Neighbor list builds = 151
Dangerous builds = 0
System init for write_data ...
  generated 0 of 0 mixed pair_coeff terms from geometric mixing rule
Neighbor list info ...
  update every 1 steps, delay 10 steps, check yes
  max neighbors/atom: 2000, page size: 100000
  master list distance cutoff = 5.77118
  ghost atom cutoff = 5.77118
  binsize = 2.88559, bins = 8 8 8
  1 neighbor lists, perpetual/occasional/extra = 1 0 0
  (1) pair kim, perpetual
  	attributes: full, newton off, cut 5.77118
  	pair build: full/bin/atomonly
  	stencil: full/bin/3d
  	bin: standard
Total wall time: 0:00:08

Is this expected? Given that MCMC does not need forces, and should have limited neighbor list recomputations, should it not be faster?

2

Yes.

It may not need forces, but in LAMMPS you only have the options to either compute the forces and then energy and/or stress in addition (or not).

It is the other way around, after every MC move, you may more likely need a neighbor list rebuild.
Please keep in mind, that with calling fix gcmc you have additional computations on top of the force computation for every time step. The time spent in “Pair” is about the same and that is the regular force computation for every step which applies to both input. The additional time for fix gcmc you’ll find in the Modify category and you can see that it triggers additional neighbor list rebuilds as well.

Bottom line, LAMMPS cannot do a pure MC calculation. At its core it is an MD code and MC is rather inefficiently implemented (and difficult to do in parallel with domain decomposition in the first place). The fixes in the MC package are meant to be used for hybrid calculations where you may do a few MC steps embedded in a larger chunk of MD steps and thus the overhead of those MC moves does not matter that much.