Dear Giacomo,
Thanks for your prompt response. The fix worked great!
Another minor issue is that now “upperWall” depends explicitly on “upperBoundary”. For example, if the keyword “upperWall” is used, then “upperBoundary” must be specified as well. Otherwise, the following error will be invoked:
colvars: Feature unavailable: “upper boundary” in colvar three
colvars: …required by “upper wall” in colvar three
colvars: Error: Failed dependency in colvar three.
ERROR on proc 0: Fatal error in the collective variables module.
(…/colvarproxy_lammps.cpp:306)
I am not sure it is a feature or not, but this seems to be caused by the following line in “colvardeps.cpp”
f_req_self(f_cv_upper_wall, f_cv_upper_boundary);
Best,
Bin
Dear Giacomo,
Thanks for your prompt response. The fix worked great!
Another minor issue is that now “upperWall” depends explicitly on
“upperBoundary”. For example, if the keyword “upperWall” is used, then
“upperBoundary” must be specified as well. Otherwise, the following error
will be invoked:
colvars: Feature unavailable: "upper boundary" in colvar three
colvars: ...required by "upper wall" in colvar three
colvars: Error: Failed dependency in colvar three.
ERROR on proc 0: Fatal error in the collective variables module.
(../colvarproxy_lammps.cpp:306)
I am not sure it is a feature or not, but this seems to be caused by the
following line in “colvardeps.cpp”
f_req_self(f_cv_upper_wall, f_cv_upper_boundary);
Indeed upperBoundary is not necessary in your case. The requirement is
only there because it follows a typical usage pattern where one does a PMF
calculation with ABF or metadynamics, and the grid parameters (lowerBoundary
/ upperBoundary) must be given.
This behavior is being simplified.
In the latest version of Colvars, you can set explicitly walls as a
separate restraint acting on the colvar, and even do free-energy
calculations on a time-changing strength of that restraint. This is done
by the new bias harmonicWalls, which of course does not need boundary
definitions.
Giacomo