csg_boltzmann calculates the wrong angle potential for theta=pi

[GoogleCodeExporter]

The problem is that the Boltzmann inverted potential, 
-k_bT*log(dist(theta)/sin(theta)), is undefined for theta=pi, but the histogram 
(not histogramnew) class returns the wrong values.

Inf, NaN or an extrapolated value would be a better choice.

Original issue reported on code.google.com by christop...@gmail.com on 4 Nov 2013 at 9:51

[GoogleCodeExporter]

Another thing is that when converting the Boltzmann inverted distributions 
(histograms), i.e. angular and dihedral potentials to Gromacs tables, the 
angles (x-axis) are not scaled from rads to degrees (*180/pi), as Gromacs 
expects. So, upon extrapolation, the potential data are simply extended from 
[0,pi] or [-pi,pi] to [0,180] and [-180,180] without scaling up the range.

As a result, the user has to apply scaling to degrees before converting tables 
to Gromacs style.

Original comment by abruk...@googlemail.com on 20 Nov 2013 at 9:59

[GoogleCodeExporter]

That is by design, csg_boltzmann is not made to write Gromacs tables (force 
column is missing), but just generic VOTCA tables (x U(x) flag(x)). The reason 
is that some simulation programs need radian, others need degrees and 
csg_boltzmann is not supposed to be limited to gromacs. It might not be the 
best choice to choose a different default than gromacs, but that is a different 
story.

As I have posted on the mailing list, in VOTCA 1.3 there is a switch (--r2d) to 
csg_call convert_potential gromacs to do this scaling (see csg_call 
convert_potential gromacs --help). In Votca 1.2, one needs to run "awk '{print 
$1*180/pi,$2,$3}'" to do the same.

Original comment by christop...@gmail.com on 20 Nov 2013 at 11:23

[GoogleCodeExporter]

OK, if there is an option for cgs_call (I did not know), then it's fine.

About the issue of x->pi and p(x)/sin(x)->inf, since we are talking about the 
case 
of well defined p(x) (when it has max around pi, and u(x) has min there), I 
think one coudld safely extrapolate to x=pi with a cubic spline or a polynomial 
over the preceding few points. 

Original comment by abruk...@googlemail.com on 20 Nov 2013 at 11:52

[GoogleCodeExporter]

Like I said earlier, extrapolations have the problem that it might not work in 
all cases, like to coarse or fine grids, noise, etc. And in most cases user 
interaction is necessary anyhow.

Additionally, I personally think, a user should have a look at the potential 
before simulating and not just rely on some auto-magic. I had a quick look in 
the code, but I could not find the cause of the issue in 5 min. Due to all 
that, fixing this bug is currently very low on my priority list. However, I am 
open for patches, so if anyone else wants to work on that go ahead.

Andrey, could you attach some test input data to reproduce this problem. This 
would help a lot to get started.

Original comment by christop...@gmail.com on 20 Nov 2013 at 4:45

[GoogleCodeExporter]

Christoph, when reading the manual for Votca, one gets an impression that a
lot of "magic" is done automatically, and that the developers are proud
about it.

Now you say that you discourage using that "magic", without intervening.
This is rather confusing even for me, although I do prefer to check every
aspect of prepared and ongoing simulations. I think, in such cases the
manual should alert the user to check the intermediate BI results etc.

As for reproducing, I am afraid it is troublesome, because this is not my
own problem where we encountered it, and the molecule is not a generic one
either. If I see the same issue in my own research, I will send you an
example.

sorry for typos, if any - sent from my Andreid mobile

Original comment by abruk...@googlemail.com on 20 Nov 2013 at 5:17

[GoogleCodeExporter]

As the manual was written by multiple people it does not necessarily represent 
my personal opinion! If you think the manual is unclear or incomplete open an 
issue, preferably with a patch, and we will fix it.

For the extrapolation, I might be a bit biased as too much magic has led to a 
lot of problems in the early versions of csg_inverse (see the mailing list). 
And if I would implement the same thing again today, I would most likely do it 
less automatic.

As I said above, I currently lack the time and motivation to find and fix this 
issue, especially without test data, which makes is even harder. So, if you 
want to have it fixed soon, do it yourself!

Additionally, csg_boltzmann also needs a major rewrite, but that is a different 
issue....

Original comment by christop...@gmail.com on 21 Nov 2013 at 1:41

[GoogleCodeExporter]

Original comment by christop...@gmail.com on 1 Jul 2015 at 11:26

• Changed state: WontFix