<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 5, 2013 at 8:19 PM, Teemu Murtola <span dir="ltr"><<a href="mailto:teemu.murtola@gmail.com" target="_blank">teemu.murtola@gmail.com</a>></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><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Mon, Feb 4, 2013 at 5:51 PM, Roland Schulz <span dir="ltr"><<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><div class="im">On Mon, Feb 4, 2013 at 4:00 AM, Alexey Shvetsov <span dir="ltr"><<a href="mailto:alexxy@omrb.pnpi.spb.ru" target="_blank">alexxy@omrb.pnpi.spb.ru</a>></span> wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">1. Its incompatible with most functions in old gmxlib (e.g. Cannot use<br>
functions like reset_x, do_fit, calc_xcm etc.).<br></blockquote></div></div><div class="im"><div>You can convert sel to atom_id by:</div><div>sel_[i].atomIndices().data()<br></div></div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
For #1 may be its time to reimplement needed functions using new api.<br></blockquote></div><div class="im"><div style="color:rgb(34,34,34)">Any help with that is greatly appreciated :-)</div><div></div></div></div></div>
</div></blockquote>
<div></div></div></div></div></div></blockquote><div><br></div><div>It is also possible to add a few methods to the Selection class that give out the data as raw arrays (or rather, as ConstArrayRef<>), similar to the atomIndices() example. That should make it possible to pass the data into any function that expects a C array. Having accessors like this places some restrictions on the internal implementation (since the implementation needs to be able to produce such continuous arrays, preferably without copying), but right now, that is not a problem.</div>
</div></div></div></blockquote><div><br></div><div>Just a minor note and please correct me if my assumptions/statement are not correct. Right now considering such aspects might not be in the scope of the new analysis framework, but such hidden, and not immediately obvious aspects can have a potentially large performance impact. For instance, not being able to get a raw array of coordinates might make it impossible to interface (easily) with an external library, but as you note above, such an accessor will put restrictions on the implementation and might even lead to considerable and non-obvious performance degradation due to the way things will work behind the scenes (e.g if in some case non-contiguous large memory areas will be frequently requested as arrays by some code which will require copying).<br>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2. It may be easyer to work with atomdata if selections will not be marked<br>
static. E.g. sel.position(i).x()<br></blockquote></div><div>I suppose you mean const? I think it makes sense that they are const. I think you should make a copy of them before modifying them.</div></div></div></div></blockquote>
<div><br></div></div><div>It makes a lot of sense for them to be const, as it makes the structure of the code a lot clearer. The selection code is responsible for evaluating the selections in any way it sees fit (including sharing the memory that is used for the results), and giving any caller the possibility to change the internals makes the code more difficult to understand and maintain. As Roland says, you can always copy them into a separate array (will comment on the mechanism for that separately).</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Teemu</div><div><br></div></font></span></div></div></div>
<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></div></div>