<div dir="ltr">My goals for Python bindings would not be to run a Python script from Gromacs, but to run Gromacs from Python. To do so, a lot of work is warranted in generalizing the public and library APIs to decouple Gromacs tools from terminal I/O and file I/O, and to make it easier to implement module runners using a stable interface. The SIP-based project seems to be tightly coupled to some fairly low-level details, while it seems reasonable to me that the bindings for a scripting interface should be entirely against public API functionality.<div><br></div><div>Two more goals are to allow copy-less data access across the bindings (via the Python buffer protocol) and to provide the means for C++ objects to be bound together via the Python interface (potentially from different shared objects) so that the Python interpreter and bindings objects can be invisible non-participants in C++-level API, particularly when MPI is involved.</div><div><br></div><div>I don&#39;t know if these things are possible with SIP, but I&#39;m having good results with pybind11.<br></div><div><br></div><div>Additionally, I think it is important to offer compatibility with things like numpy and Eigen-based tools without introducing dependencies.</div><div><br></div><div>A fair bit of work is warranted on the C++ side that would be influenced by other issues. For instance, the future of reference-counted vector array data structures ( <a href="https://redmine.gromacs.org/issues/1017">https://redmine.gromacs.org/issues/1017</a> )</div><div><br></div><div>I was about to start a Redmine issue looking at just the trajectory read/write interfaces with the idea of bringing the various trajectory editing/manipulation functionality to a public API level, but would it be a hassle in preparing for the 2017 release candidate to have a chain of Gerrit changes sitting there with brand new API features?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 9, 2017 at 11:03 AM, Mark Abraham <span dir="ltr">&lt;<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Thu, Mar 9, 2017 at 3:49 PM Alexey Shvetsov &lt;<a href="mailto:alexxy@omrb.pnpi.spb.ru" target="_blank">alexxy@omrb.pnpi.spb.ru</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br class="m_3441402482575964146gmail_msg">
<br class="m_3441402482575964146gmail_msg">
I&#39;d like to add python api for gromacs as a suggestion (however we need<br class="m_3441402482575964146gmail_msg">
to fix it first to work with current changes for trajectoryanalysis)<br class="m_3441402482575964146gmail_msg"></blockquote><div><br></div></span><div>I suspect we&#39;ve not done anywhere near enough groundwork (yet) for this. Offhand, we should have a clear understanding of the scope (&quot;expose the trajectoryanalysis C++ API&quot; seems to be that of the current RFC patch in gerrit), how that adds value to users, and whether the approach will be able to offer a suitably stable UI. We also need to consider which versions of Python make sense to support</div><div><br></div><div>How does a script using it look? (Your link to <a href="https://biod.pnpi.spb.ru" target="_blank">https://biod.pnpi.spb.ru</a> from the Redmine no longer seems to work?) Does that compare reasonably to offerings like <a href="http://www.mdanalysis.org/pages/basic_example/" target="_blank">http://www.mdanalysis.<wbr>org/pages/basic_example/</a> or <a href="http://mdtraj.org/1.8.0/examples/introduction.html" target="_blank">ht<wbr>tp://mdtraj.org/1.8.0/<wbr>examples/introduction.html</a>. What lessons have we learned from them, and what aspects of other related python toolsets should we plan to incorporate, so that users will find themselves able to get the benefit of rapid compiler-free prototyping?</div><div><br></div><div>There&#39;s widespread interest in something like this, and active work over the medium term from some of our US colleagues, but if SIP is the vehicle for exposing a C++ API to python, then we probably need first to do some design work to make a C++ layer suitable for that, or a python layer on top of the SIP. Particularly because &quot;exposure to Python&quot; was never part of Teemu&#39;s initial design.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Mark</div></font></span><div><div class="h5"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mark Abraham писал 09-03-2017 17:42:<br class="m_3441402482575964146gmail_msg">
&gt; Hi,<br class="m_3441402482575964146gmail_msg">
&gt;<br class="m_3441402482575964146gmail_msg">
&gt; It&#39;s time to start preparing for this year&#39;s release. Consistent with<br class="m_3441402482575964146gmail_msg">
&gt; previous practice, we will have a soft deadline for work proposed for<br class="m_3441402482575964146gmail_msg">
&gt; inclusion to have appeared in Gerrit in approximately final form, then<br class="m_3441402482575964146gmail_msg">
&gt; we&#39;ll make a release candidate from the first patch on a new<br class="m_3441402482575964146gmail_msg">
&gt; release-2017 branch. That branch will thereafter be open, in the usual<br class="m_3441402482575964146gmail_msg">
&gt; way, for all manner of fixes, docs and tests, with patches expected to<br class="m_3441402482575964146gmail_msg">
&gt; focus on stability, correctness and minimal disruption. Thereafter,<br class="m_3441402482575964146gmail_msg">
&gt; from that branch, we might make a future release candidate, and at<br class="m_3441402482575964146gmail_msg">
&gt; some point a final release.<br class="m_3441402482575964146gmail_msg">
&gt;<br class="m_3441402482575964146gmail_msg">
&gt; For target dates I propose:<br class="m_3441402482575964146gmail_msg">
&gt; * April 1 - proposals available in gerrit in approximately final form<br class="m_3441402482575964146gmail_msg">
&gt; * May 1 - ship release candidate<br class="m_3441402482575964146gmail_msg">
&gt; * May 15 - ship second release candidate if that seems useful<br class="m_3441402482575964146gmail_msg">
&gt; * June 1 - ship 2017 final if there are no known serious problems<br class="m_3441402482575964146gmail_msg">
&gt;<br class="m_3441402482575964146gmail_msg">
&gt; There&#39;s a fair bit of work currently in gerrit that is refactoring to<br class="m_3441402482575964146gmail_msg">
&gt; suit long term needs. There&#39;s no strong reason to push to get such<br class="m_3441402482575964146gmail_msg">
&gt; things in the release, but review and submission are welcome in the<br class="m_3441402482575964146gmail_msg">
&gt; usual way. I do suggest that we avoid any further cleanup patches that<br class="m_3441402482575964146gmail_msg">
&gt; touch lots of lines or lots of files until after the 2017 release, to<br class="m_3441402482575964146gmail_msg">
&gt; make life easier on those preparing work for that release and merging<br class="m_3441402482575964146gmail_msg">
&gt; fixes forward.<br class="m_3441402482575964146gmail_msg">
&gt;<br class="m_3441402482575964146gmail_msg">
&gt; After we ship 2017, and have incorporated any bug fixes we want to<br class="m_3441402482575964146gmail_msg">
&gt; back port, I will make a final 5.1 patch release and declare that<br class="m_3441402482575964146gmail_msg">
&gt; branch closed to future work. Similarly, I&#39;ll make another 2016 patch<br class="m_3441402482575964146gmail_msg">
&gt; release, and thereafter that branch will have the policy of being open<br class="m_3441402482575964146gmail_msg">
&gt; only to fixes for things that might affect scientific results.<br class="m_3441402482575964146gmail_msg">
&gt;<br class="m_3441402482575964146gmail_msg">
&gt; My focus will be on the integration of Aleksei&#39;s PME-on-GPU<br class="m_3441402482575964146gmail_msg">
&gt; implementation, as well as several non-code GROMACS activities.<br class="m_3441402482575964146gmail_msg">
&gt;<br class="m_3441402482575964146gmail_msg">
&gt; Erik hopes to rush out some new templated kernel infrastructure, but<br class="m_3441402482575964146gmail_msg">
&gt; he has a grant application on April 6, so perhaps we will relax the<br class="m_3441402482575964146gmail_msg">
&gt; April 1 cutoff for that - but based on history, there will be no<br class="m_3441402482575964146gmail_msg">
&gt; promises either way ;-)<br class="m_3441402482575964146gmail_msg">
&gt;<br class="m_3441402482575964146gmail_msg">
&gt; David&#39;s energy analysis framework is pretty close to good shape, so<br class="m_3441402482575964146gmail_msg">
&gt; some final effort there would be a nice achievement.<br class="m_3441402482575964146gmail_msg">
&gt;<br class="m_3441402482575964146gmail_msg">
&gt; Berk hopes to get in some more of his conserved quantities for<br class="m_3441402482575964146gmail_msg">
&gt; integrators, and perhaps with Viveca some of the AWH implementation<br class="m_3441402482575964146gmail_msg">
&gt; (that needs a lot of refactoring, however...)<br class="m_3441402482575964146gmail_msg">
&gt;<br class="m_3441402482575964146gmail_msg">
&gt; Are there any other things people would like to flag for attention?<br class="m_3441402482575964146gmail_msg">
&gt; Are there good reasons to suggest alternative dates?<br class="m_3441402482575964146gmail_msg">
&gt;<br class="m_3441402482575964146gmail_msg">
&gt; Mark<br class="m_3441402482575964146gmail_msg">
<br class="m_3441402482575964146gmail_msg">
--<br class="m_3441402482575964146gmail_msg">
Best Regards,<br class="m_3441402482575964146gmail_msg">
Alexey &#39;Alexxy&#39; Shvetsov, PhD<br class="m_3441402482575964146gmail_msg">
Department of Molecular and Radiation Biophysics<br class="m_3441402482575964146gmail_msg">
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,<br class="m_3441402482575964146gmail_msg">
Leningrad region, Gatchina, Russia<br class="m_3441402482575964146gmail_msg">
mailto:<a href="mailto:alexxyum@gmail.com" class="m_3441402482575964146gmail_msg" target="_blank">alexxyum@gmail.com</a><br class="m_3441402482575964146gmail_msg">
mailto:<a href="mailto:alexxy@omrb.pnpi.spb.ru" class="m_3441402482575964146gmail_msg" target="_blank">alexxy@omrb.pnpi.spb.ru</a><br class="m_3441402482575964146gmail_msg">
</blockquote></div></div></div></div>
<br>--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/<wbr>Support/Mailing_Lists/GMX-<wbr>developers_List</a> before posting!<br>
<br>
* Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/<wbr>Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/<wbr>mailman/listinfo/gromacs.org_<wbr>gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@<wbr>gromacs.org</a>.<br></blockquote></div><br></div>