From: Peter Freddolino (petefred_at_ks.uiuc.edu)
Date: Mon Jul 30 2007 - 21:21:01 CDT
Hi Vincent,
I'll do my best, but again some of this is beyond my routine travels.
>
> a) The patch business is getting clearer, but I'm still missing where
> the periodicity resolution (for particle-particle distances) is getting
> addressed. Not having a C preprocessor hardwired into my brain I'm
> currently trodding along (just in case someone else might find this
> useful) with the output of
>
> $ g++ -E ComputeNonbondedStd.C -I../charm-5.9/include/
> -I../MacOSX-i686-SMP-g++/inc
>
Aww, but trying to keep 6 macros defined in your head is part of the fun ;-)
> which seems to contain a definition of calc_pair_energy (which in turn
> seems to be doing pairlist creation and interaction evaluation). If I
> understand things correctly, neither the pairlist creation nor the
> interaction evaluation routines are doing periodicity resolution. Given
> that we're dealing with the interactions between two given patches (or a
> self-interaction) and invoking a number of constraints on the geometry
> of the patches and the computational box, one can probably perform the
> periodicity resolution on a patch-patch basis. I assume this is being
> done, but I'm not exactly sure. If so, does the code contain corner
> cases to watch out for? I imagine there must be some trickery going on
> for NPT simulations.... if not, where does periodicity resolution take
> place? In particular, is there a reason why the virial is calculated on
> a atom-atom basis (I'm seeing this correctly, right?), rather than using
> a (significantly more efficient) box based approach [1]?
>
This is being done at the level of compute objects -- when they request
distances, they do so for the appropriate periodic image. I don't know
the rationale for the per-atom virial calculation, though.
>
> b) This is a hacking question: I'm having trouble using gdb with namd.
> Basically, I tried the following warmup exercise:
> -- start a gdb session, break at main();
> -- step my way through the program to my heart's content.
>
> However, it seems my plan was flawed -- I'm getting something which
> (grossly edited for brevity) boils down to the log below. I have little
> experience using gdb with multithreaded applications, it might be
> standard behavior for the latter (and the main thread is perhaps really
> just four steps). Then again, this behavior might be NAMD- or charm++ -
> specific, in which case I would gladly avoid spending a few days reading
> documentation that won't solve my problem ;-)
>
> To make a long story short: Does someone have tips for using gdb with namd?
>
>
As far as I'm concerned, parallel debugging is a black art best avoided
(this doesn't mean it can't be done, but I can't help ;-). I debug in
serial wherever possible, and just verify that proper output is produced
from parallel runs. The only exception is when bugs show up in parallel
but not serial, but there are only a few things which can cause this; it
can usually be isolated to code involving inter-node communication and
then debugged via print statements. Note that when doing output in
paralle runs you should use CkPrintf instead of printf to avoid issues.
Best,
Peter
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:45:01 CST