From: Jim Phillips (jim_at_ks.uiuc.edu)
Date: Fri May 13 2011 - 08:18:37 CDT
The processControlPoints output is from a Charm++ function that is called
periodically by the runtime. It should probably be limited to debug mode
but it's not an error message. It does indicate that the runtime is alive
and the hang is due to a control logic bug in NAMD.
On Fri, 13 May 2011, Bjoern Olausson wrote:
> On Wednesday 13 April 2011 17:39:41 Jim Phillips wrote:
>> There was a memory leak in trajectory/restart output that was introduced
>> after 2.7 and fixed April 10 (so it is in 2.8b1 also). That could explain
>> some of what you are seeing.
>> On Tue, 12 Apr 2011, Dong Luo wrote:
>>> In case someone will research the problem in the future, I add another
>>> problem appeared during the simulation with NAMD2.7 on BlueGene/L in the
>>> safe time range (i.e., running 250k steps for the 50k atoms system per
>>> simulation). Randomly a simulation may stopped with an error: 
>>> processControlPoints() haveControlPointChangeCallback=0
>>> It appeared not often, and a repeat of the same simulation normally runs
>>> ok. A rough search shows the error is throw out by charm++.
>>> Again, the NAMD/charm++ are compiled from cvs code of 03/03/2011.
> sory to bring up this discussion, but did anyone solve this
>  processControlPoints() haveControlPointChangeCallback=0
> frameworkShouldAdvancePhase=0 error from charm++?
> For me it happens on a normal Linux Cluster with 288 Cores and Infiniband
> I compiled NAMD 2.8b2 with charmm++ (60305) yesterday.
> You can find all the details in my other post:
> Bjoern Olausson
> Martin-Luther-Universitšt Halle-Wittenberg
> Fachbereich Biochemie/Biotechnologie
> Kurt-Mothes-Str. 3
> 06120 Halle/Saale
> Phone: +49-345-55-24942
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 05:23:56 CST