[gmx-users] g_cluster: optimal cutoff
francesco.oteri at gmail.com
Thu Apr 7 22:34:07 CEST 2011
the problem is the type of the variable nrms. It is stored in as an int.
This means that whenever nframe*(nframe-1)/2 is greater than the maximum
positive value representable by a signed int there is an overflow and
nrms restarts from a negative value.
A workaround could be to declare nrms, as well as any other variable
related with frame counting, as unsigned long.
At this point the problem should be less frequent.
The complete solution should involve a more complex implemention (i.e.
using list or more complex data structure).
Though the answer is related to a problem to 4.5.1 version, the problem
is still present in the 4.5.4 version, therefore is still useful
addressing the issue.
Il 05/11/2010 17:29, Xiaohu Hu ha scritto:
> I am also trying to do clustering analysis, but g_cluster version
> 4.5.1 seems to have a bug. it does not crash but show strange std
> output like
> # : -897758633
> and the stopps after some time.
> Which version do you guys use?
> On 11/05/2010 06:57 AM, Fabio Affinito wrote:
>> On 10/31/2010 08:20 PM, Valeria Losasso wrote:
>>> Dear all,
>>> for my cluster analysis I am using the g_cluster tool with the
>>> gromos method.
>>> The problem is that I have to compare the results for system of
>>> different lengths, and of course the result of the cluster analysis
>>> changes according to the cutoff chosen. So what will be a great
>>> choice in this case?
>>> I was thinking about different possibilities, namely: i) choosing -
>>> as it is quite frequent in the literature - an arbitrary cutoff
>>> (like the default 0.1), but using the same for different systems
>>> would be probably not suitable...
>>> ii) looking for every case at the RMSD distribution and choosing the
>>> minimum value between the two peaks - in this case the cutoff would
>>> vary for every system; iii) choosing for every system the cutoff
>>> that allows to have in the largest cluster the 50% of the
>>> structures, and also in this case the cutoff would be different for
>>> the different cases...
>>> Any hint?
>>> Thanks a lot,
>> Option ii) is the right one.
More information about the gromacs.org_gmx-users