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