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