cell step size scaling

[bernstei]

step_size_shear multiplies the unit vectors parallel to two of the lattice vectors. First, its magnitude should probably be scaled with some representative length scale, so default values make sense. Second, original definition in Baldock thesis had the random step be a circle in the plane formed by the two vectors, not an ellipse as now - should this be fixed?

step_size_stretch multiplies the existing cell vectors. We concluded this kind of thing was a bad idea for volume changes, since increasing by max x% can't be reversed by decreasing by max -x%. Why doesn't that argument apply to these moves? Is it the exp(s) factor?

[bernstei]

Also, cell volume moves seem to be scaled with expected cell volume/atom, but not actually with number of atoms

This is actually fine for ASE

pymatnext/pymatnext/ns_configs/ase_atoms/walks_ase_calc.py

Line 125 in 951c3b0

step_size_volume = N_atoms * ns_atoms.step_size["cell_volume_per_atom"]

and for LAMMPS

pymatnext/pymatnext/ns_configs/ase_atoms/walks_lammps.py

Line 200 in 951c3b0

step_size_volume = len(atoms) * ns_atoms.step_size["cell_volume_per_atom"]

[bernstei]

@VGFletcher can you take a look at this and the corresponding #27 and let me know what you think?

[VGFletcher]

I think the shear sampling in both cases is the same. I spoke to Livia, and we concluded that in both cases the move is the same. So I think doing the sampling this way won't lead to any differences.

I'm not sure why the volume move argument wouldn't apply to the stretch move either. In either case it probably doesn't make much of a difference if you update the step size frequently though.

[bernstei]

I think it's the exp(rv). The idea we had for fractional volume steps doesn't work because V * (1 + rv) * (1 - rv) != V so e.g. for the max rv it's not reversible. But the way the stretch step does it, a * exp(ev) * exp(-rv) = a, so it is reversible (probably only if p(rv) == p(-rv)). If we wanted to go to fractional volume steps I suspect we could use exp(rv) instead of 1+rv and that would work.

@VGFletcher are you happy with the way I rescaled the shear steps in this #27?

[VGFletcher]

I see, we could use that instead. Do you agree that either scaling or adding is just the same if the steps are updated frequently enough? If that's true then there shouldn't be any difference to the results, I just assume there would be less updates for the step size if it were scaled?

I think the shear step max needs to start off larger, instead of multiplying by 0.2, just multiply by 1.0. That's what nest does and my acceptance rate maxes out for the first few 100-1000 iterations with the max multiplied by 0.2 but it doesn't in nest.

[bernstei]

I don't think it makes any fundamental difference, as long as the exp is used. It's just a question of whether the user (or the default heuristic) needs to be aware of an absolute volume scale (needed for +/- a fixed amount) or not.

Without the exp, scaling isn't reversible, so I don't know what to expect. I guess in the limit that the max rv is very small, scaling without exp might be OK, because you'll be in the exp(rv) =~ 1+rv limit.

I'll increase the default max shear, which will increase the default value as well.

[bernstei]

Let's leave the question of changing from steps sizes that depend on a length scale to step sizes that are fractional to #28 (which I will rename) and a corresponding future PR.

If you are happy with the scaling and defaults (once I push the update, hopefully in an hour or so when the pytests pass) in this PR, I'll merge these and we can deal with that later.

[VGFletcher]

Okay I see, I've never needed to manually adjust the step sizes so if that is something people do then a fractional value would be more practical.

The starting default value doesn't matter too much as I assume it'll get adjusted before use so that's OK.