Weighted poisson integration

[jhenin]

Implements weighted Poisson integration of free energy gradients.
Also fixes a small error in Neumann boundary conditions for the existing unweighted case.

TODO:

• revert formatting changes (braces and indents)
• user flag to enable/disable
• Documentation
• Fix failing tests due to boundary condition fixes in unweighted Poisson
• Add test for new feature, weighted Poisson

[HanatoK]

I'm not familiar with the algorithm details, but random insertion in a vector should be quite slow. Why not just push_back and then std::sort?

[jhenin]

Agreed, thanks!

[HanatoK]

Each time when comparing i with the end of loop, it has to recalculate pow, which might be slow. Is it possible to cache the index of the end of loop? Also, you should consider using cvm::integer_power.

[HanatoK]

When restarting 000_eulerangles_ext_abf2d_euler_weighted, NAMD crashes. The GDB backtrace:

#0  0x00007ffff763dd3c in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x00007ffff75e27b6 in raise () from /lib64/libc.so.6
#2  0x00007ffff75c934b in abort () from /lib64/libc.so.6
#3  0x00007ffff7889972 in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) () from /lib64/libstdc++.so.6
#4  0x00000000009b1cd7 in std::vector<double, std::allocator<double> >::operator[] (this=0x1d85b08, __n=0) at /usr/include/c++/15/bits/stl_vector.h:1263
#5  0x00000000013ba889 in colvargrid_integrate::update_weighted_div_local (this=0x1d85770, ix0=std::vector of length 2, capacity 2 = {...}) at colvars/src/colvargrid_integrate.cpp:344
#6  0x00000000013b8029 in colvargrid_integrate::set_weighted_div (this=0x1d85770) at colvars/src/colvargrid_integrate.cpp:151
#7  0x00000000012b8869 in colvargrid_integrate::set_div (this=0x1d85770) at colvars/src/colvargrid_integrate.h:50
#8  0x00000000012c48fb in colvarbias_abf::read_state_data_template_<std::basic_istream<char, std::char_traits<char> > > (this=0x1d5a880, is=...) at colvars/src/colvarbias_abf.cpp:968
#9  0x00000000012b66ab in colvarbias_abf::read_state_data (this=0x1d5a880, is=...) at colvars/src/colvarbias_abf.cpp:1017
#10 0x00000000012a9a2a in colvarbias::read_state_template_<std::basic_istream<char, std::char_traits<char> > > (this=0x1d5a880, is=...) at colvars/src/colvarbias.cpp:641
#11 0x00000000012a43fb in colvarbias::read_state (this=0x1d5a880, is=...) at colvars/src/colvarbias.cpp:665
#12 0x00000000013d2c5e in colvarmodule::read_objects_state (this=0x1b92970, is=...) at colvars/src/colvarmodule.cpp:1811
#13 0x00000000013e7d2f in colvarmodule::read_state_template_<std::basic_istream<char, std::char_traits<char> > > (this=0x1b92970, is=...) at colvars/src/colvarmodule.cpp:1724
#14 0x00000000013d25b9 in colvarmodule::read_state (this=0x1b92970, is=...) at colvars/src/colvarmodule.cpp:1732
#15 0x00000000013d11fe in colvarmodule::setup_input (this=0x1b92970) at colvars/src/colvarmodule.cpp:1562
#16 0x00000000014274e0 in cvscript_cv_load (pobj=0x1b4b140, objc=3, objv=0x7fffffffb9b0) at colvars/src/colvarscript_commands.h:484
#17 0x000000000141c9c1 in colvarscript::run (this=0x1b4b140, objc=3, objv=0x7fffffffb9b0) at colvars/src/colvarscript.cpp:439
#18 0x000000000141e87f in tcl_run_colvarscript_command (my_interp=0x1a75410, objc=3, objv=0x1a79790) at colvars/src/colvarscript.cpp:740
#19 0x00007ffff7de3ab8 in TclNRRunCallbacks () from /lib64/libtcl8.6.so
#20 0x00007ffff7dea234 in ?? () from /lib64/libtcl8.6.so
#21 0x00007ffff7e90587 in Tcl_FSEvalFileEx () from /lib64/libtcl8.6.so
#22 0x00007ffff7e90807 in Tcl_EvalFile () from /lib64/libtcl8.6.so
#23 0x0000000001121e77 in ScriptTcl::load (this=0x1a742b0, scriptFile=0x7fffffffd459 "test.restart.namd") at src/ScriptTcl.C:2423
#24 0x00000000009c463c in after_backend_init (argc=2, argv=0x7fffffffce68) at src/mainfunc.C:181
#25 0x00000000009c3f88 in main (argc=3, argv=0x7fffffffce68) at src/mainfunc.C:52

[HanatoK]

I feel that the calls to convert_base_two is unnecessary because an integer has already all its bits itself. convert_base_two simply checks the bits of i and stores them into a vector of nd size. But maybe I am wrong, and I am not sure how to optimize this.

[jhenin]

This is not performance-critical, and this form is more legible than a bunch of (n >>i)&1 throughout the code.