Skip to content

Resolve "BUG: WL simulations can become trapped when en energy window is specified."

Description

The purpose of this MR is to introduce features that allows one to run WL simulations for specified energy limits energy_limit_left (E_{left}) and energy_limit_right (E_{right}) without any risk that these become "trapped" during intial search to find the window. The reason why this might occur is tha trial moves between states with energy E_{cur} and E_{new} are, currently, rejected if E_{cur} < E_{left} and E_{new} < E_{cur} or E_{cur} > E_{right} and E_{new} > E_{cur}.

Summary of changes

  • The strict criteria that restricts the trial step when searching for the energy window has been replaced with a soft version that instead means that a given move is more likely to be accepted if it reduces the distance to either of the energy limits.
  • The tests have been updated so that these include a case where the soft criteria are sure to reject a move.

To consider

Before submitting your merge request make sure that licenses that might apply to the code that is being submitted are compliant with the license used for this code base. By submitting your code to this repository you also agree that your code will be distributed as part of this code base under the license conditions that apply.

Instructions for code review

Please make sure

  • all new code is tested (and works obviously)
  • all new code is documented; examples are strongly encouraged
  • all new code is type hinted (Note: Type hints are automatically rendered in the documentation when they appear in function/method docstrings; parameter descriptions in class docstrings must be annotated explicitly.)
  • variable and function names are in snake_case while class names are in CamelCase
  • imports are in alphabetical order both with respect to module names and imported members; core library imports come first in a separate block; import lines go before from lines (This is done to allow other contributors to quickly find imports.)
  • all "must-pass" jobs in the CI pass (which includes enforcing flake8 compliance); "can-fail" jobs do not deteriorate
  • examples in the documentation use doctest (both sphinx and docstrings)
  • code that is commented out should be removed (unless there are very good reasons not to)
  • comments that are unclear (e.g., "this should work ..." or "I don't know whether this works ...") need to be resolved first
  • todos should be resolved/avoided as much as possible

Closes #501 (closed)

Merge request reports