[gmx-developers] Wednesday's GROMACS teleconference

[Mark Abraham]

On Mon, Feb 18, 2013 at 6:58 PM, Alexey Shvetsov <alexxy at omrb.pnpi.spb.ru>wrote:

> Hi all!
>
> Who can attend this meeting?
>

In principle, anybody interested to contribute to the discussion is
welcome. It's an open source project, and stakeholders need to be able to
contribute effectively and cooperatively. However, we don't really want 50
spectators in a teleconference :-) Hence trying to have some preliminary
discussion and summarizing results afterwards.

PS btw may be also talk about policy for tools can be usefull. Currently new
> framework cannot use with old functions like reset_x() , do_fit(), etc..
> directly.
>

OK. Some of that is a natural consequence of being in transition mode. Some
of the legacy code might not be suitable for writing temporary wrapper APIs
on; other parts might be so broken from a C++ point of view they just need
to be re-written. I'll check out your discussion threads here and see what
can be done.

Mark

В письме от 18 февраля 2013 18:14:43 пользователь Mark Abraham написал:
> > Hi again devs,
> >
> > We've got our fortnightly teleconference scheduled again this Wednesday.
> > Thinking of topics to discuss has been a bit challenging - they can
> neither
> > be too vague we can't decide anything or too detailed that only a few
> > people can make useful input. Suggestions are most welcome!
> >
> > So far I've come up with
> >
> > 1. replacing rvec with something more friendly to C++
> > 2. coding strategy for whatever will replace do_md()
> >
> > I've put some initial thoughts on these together, which you can find
> below.
> > If someone can identify other suitable topics, do speak up.
> >
> > Details will be the same as last time
> > * a Google Hangout will be run by the mark.abraham at scilifelab.seaccount.
> > Please mail that account from the Google account with which you might
> want
> > to connect, so that I can have you in the Circle before the meeting is
> due
> > to start
> > * start 6pm, end 6:30pm Stockholm time, Wed 20 Feb (should be during
> > working hours for Americans)
> > * if there's interest in continued discussion, perhaps on implementation
> > details, those people can continue on after 6:30
> > * please use the best quality hardware and connection you reasonably can
> > (not on your laptop at the local cafe, or with your kids screaming at
> you).
> > Know how to mute yourself, or we might have to drop you!
> > * I'll issue the hangout invitation shortly after 5pm if you want to test
> > your connection or setup
> > * I'll post a summary after the meeting of what was
> > discussed/decided/whatever
> >
> > People who haven't attended before are welcome. We had 10 connections
> last
> > time and things were pretty good, so the technology seems to scale
> > reasonable well. If you're new, please let me know what part(s) of the
> > meeting programme is of interest to you so I can help manage discussion
> > suitably.
> >
> > If you can't attend, please feel free to contribute in this thread, or
> > email me, etc.
> >
> > Cheers,
> >
> > Mark
> > GROMACS development manager
> >
> > Thoughts for Wed 20 Feb
> > ========
> >
> > *1. planning for an internal coordinate format
> >
> >    - can't keep using rvec
> >       - rvec can't be put into STL containers (need copy constructor,
> etc.)
> >       - rvec guarantees we can't use aligned loads anywhere (important
> for
> >       leveraging SIMD possibilities)
> >       - makes using RAII harder
> >       - probably makes writing const-correct code harder
> >    - we want to be able to use STL containers when that makes code
> writing,
> >    review and maintenance easier
> >    - we need to be able to get flat C arrays of atom coordinates with no
> >    overhead for compute kernels
> >    - straightforward suggestion: switch to using an RVec class with a
> >    4-tuple of reals and use them for x, y, z and q
> >       - in many places q won't be used
> >       - 16-byte alignment for free (opportunities for compiler auto-SIMD)
> >       - perhaps 4/3 increase in cache traffic where q is not being used
> >       - std::vector< std::vector<real> > doesn't map to a flat C array -
> >       need to write/find a "tuple" class that lets the compiler know
> what is
> > going on, so that std::vector< tuple<real,4> > ends up as a flat C array
> of
> >       xyzqxyzqxyzq...
> >    - separate vectors for x, y, z and q could be useful because that
> would
> >    help avoid the swizzling (group kernels) and coordinate copying
> (Verlet
> >    kernels) that currently occurs
> >       - downside is that x, y, and z are normally used together, so a
> naive
> >       approach pretty much guarantees we need 3 cache lines for each
> > point... if
> >       we don't re-use that data a few times, that could kill us
> >    - internally use some kind of "packed rvec" laid out
> xxxxyyyyzzzz(qqqq)
> >    and have some kind of intelligent object that we can use just like we
> use
> > rvec now, e.g. coords[3][YY] magically returns the 8th element of
> > xxxxyyyyzzzz
> >    - the needs of mdrun and analysis tools are different, and we can
> >    perhaps explore different implementations for each - but a common
> > interface would be highly desirable
> >    - ideally we would not commit in 2013 to an internal representation
> that
> >    we might regret in the future... how can we plan to be flexible?
> >       - run-time polymorphism, e.g. have the coordinate representation
> >       classes share a common base with virtual functions - probably
> > too slow, and
> >       we don't want to store the virtual function tables
> >       - code versioning - ugh
> >       - bury our heads in the sand - we might get lucky and never want to
> >       change our coordinate representation
> >       - compile-time polymorphism, e.g. mdrun<RVec> vs
> mdrun<PackedRVec,4>
> >          - might also allow a more elegant implementation of double- vs
> >          mixed-precision
> >          - code bloat if we want binaries that can run on any x86 if
> >          different CPUs will want different packings
> >          - compile-time bloat if compiling more than one such
> >          representation, as a lot of routines would now be parameterized
> >
> > 2. planning for do_md()
> >
> >    - http://redmine.gromacs.org/issues/1137 discusses some thoughts
> about
> >    how we might like to make the integrator more awesome
> >    - Main loop inside do_md() is currently ~1300 lines, mostly with
> heavily
> >    nested conditionality
> >    - Currently, the need to pass lots of arguments to and from the
> >    functions it calls limits our ability to change anything, else we
> could
> >    probably break it into
> >       - ManageSpecialCases()
> >       - DoNeighbourSearching()
> >       - CalculateForces()
> >       - DoFirstUpdate()
> >       - WriteTrajectories()
> >       - DoSecondUpdate()
> >       - WriteEnergies()
> >       - MoreManagementOfSpecialCases()
> >       - PrepareForNextIteration()
> >    - In C++, being able to construct an MDLoop object that contains (lots
> >    of) objects that already have their own "constant" data will mean we
> only
> > need to pass to methods of those objects any remaining control values for
> > the current operation
> >       - passing of state information managed by letting the MDLoop own
> that
> >       data and have the object implementing the strategy ask for what it
> > needs? - Those objects will have a lot of inter-relationships, so
> probably
> > need a common interface for (say) thermostat algorithms so that (say) the
> > MDLoop update method knows it can just call (say) the thermostat object's
> > method and the result will be correct, whether there's a barostat
> involved,
> > or not - easily done with an (abstract?) base class and overriding
> virtual
> > functions
> >          - however, that kind of *dynamic-binding* run-time polymorphism
> is
> >          overkill - likely any simulation knows before it gets into
> > the main loop
> >          that it's only ever going to call (say) AndersenThermostat's
> > methods - the overhead from such function calls is probably not a big
> deal
> > - this loop is always going to be heavily dominated by
> > CalculateForces()
> >          - inheritance can maximise code re-use
> >       - can be done by having function pointers that get set up correctly
> >       in the MDLoop constructor (i.e. "static" run-time polymorphism,
> > as dictated
> >       by the .tpr)
> >          - this might lead to code duplication?
> >          - might lead to the current kind of conditional-heavy code,
> >          because it is now the coder's job to choose the right code path,
> > but hopefully only in construction
> >       - could be done with compile-time polymorphism (i.e. templates)
> >          - lots of duplicated object code because of the explosion of
> >          templated possibilities
> >       - Need to bear in mind that probably this pretty front end will be
> >    queueing up work requests that will be dynamically dispatched to
> > available hardware (obviously the dispatcher will focus on hardware that
> > has the right data locality). That seems OK to Mark:
> >       - we need an interface that makes it reasonably easy to see that
> the
> >       physics of our algorithm should be working
> >       - how the work gets done *should* be somewhat opaque to MDLoop
> >       - separating the two makes for future extensibility and
> >       customizability
> >    - perhaps a good way to start to get a handle on what kinds of objects
> >    and relationships we needs is to make an ideal flowchart for a
> plausible
> >    subset of mdrun functionality, and see what data has to be known
> where.
> >    Perhaps Michael can sketch something for us that illustrates what the
> >    algorithmic requirements of a "full Trotter decomposition framework"
> > would be. (But probably not in time for this week!)
> >
> > *
> --
> Best Regards,
> Alexey 'Alexxy' Shvetsov
> Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
> Gatchina, Russia
> Department of Molecular and Radiation Biophysics
> Gentoo Team Ru
> Gentoo Linux Dev
> mailto:alexxyum at gmail.com
> mailto:alexxy at gentoo.org
> mailto:alexxy at omrb.pnpi.spb.ru
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130219/489751a0/attachment.html>