From: Vincent Kraeutler (vincent_at_kraeutler.net)
Date: Fri Jul 27 2007 - 12:57:28 CDT
Peter, thanks again for your answer, I think I'm starting to get a feel
for the code. It's still a pain to read, but it does contain a number of
little (and larger) gold nuggets which make the effort feel worthwhile.
Kudos to the developers!
Should you feel so inclined, I have two more questions (see below, not
urgent though).
[snip]
Peter Freddolino wrote:
>> c) I don't think I quite understand the pairlist construction algorithm
>> yet. I can see that the partitioning of the system into patches gets it
>> down to O(N)-scaling, but some comments in the code ("// add remaining
>> atoms to pairlist via hydrogen groups") suggest I might missing some of
>> the details. Do I understand it correctly that (i) the pairlist of
>> particles in a given patch are constructed based on particles in the
>> same patch as well as particles in the neighboring patches; (ii)
>> interatomic (rather than inter-group) distances are used in the pairlist
>> construction; (iii) the above comment refers to the assignment of
>> hydrogens to patches based on the atoms they are bound to?
>>
>>
> Again, this isn't a part of the code that I've looked at much. For i I
> think you're correct, note that the patches are decomposed spatially
> based on the cutoff distance (plus a bit of padding) so that you can be
> sure that everything within the cutoff distance is within the home patch
> or its neighbors. Hydrogens get grouped into patches based on their
> parent atoms *unless* splitpatch is set to "position" (in which case
> they can be placed in patches separately), but the pairlists are based
> on interatomic distances. If you're assigning hydrogens to patches based
> on the parent atom, though (which is the default), I believe that
> inter-group distances are used for pairlist construction, rather than
> what you suggest in (ii); to compensate for this, the value of
> hgroupCutoff is added to the cutoff for the purposes of group-group
> pairlist construction (this value is also added to the margin padding
> the patch sizes to ensure that the assumption that only adjacent patches
> need be considered in pairlist construction is correct). The comment
> that troubles you refers to this practice.
>
> Best,
> Peter
>
[snip]
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
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]?
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?
$ gdb ./namd2
(gdb) b main
Breakpoint 1 at 0x4cc7
(gdb) run src/alanin
Starting program: ./namd2 src/alanin
Reading symbols for shared libraries . done
Breakpoint 1, 0x00004cc7 in main ()
(gdb) s
Charm++: standalone mode (not using charmrun)
Charm++: scheduler running in netpoll mode.
Info: NAMD 2.6 for MacOSX-i686
Info: Entering startup phase 8 with 563424 kB of memory in use.
0x002130ee in CthThreadBaseInit ()
(gdb) s
Single stepping until exit from function CthThreadBaseInit,
which has no line number information.
0x00213874 in CthThreadInit ()
(gdb) s
Single stepping until exit from function CthThreadInit,
which has no line number information.
0x00213a19 in CthCreateInner ()
...
(gdb) s
Single stepping until exit from function CthCreateInner,
which has no line number information.
Info: Finished startup with 563680 kB of memory in use.
WRITING VELOCITIES TO OUTPUT FILE AT STEP
9==========================================
WallClock: 10.335024 CPUTime: 0.065263 Memory: 563424 kB
Program finished.
Program exited normally.(gdb)
[1] @PHDTHESIS{Bekker1996,
author = {H. Bekker},
title = {{Molecular Dynamics Simulation Methods Revised}},
school = {Rijksuniversiteit Groningen},
year = {1996},
}
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:45:00 CST