<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote" style>Hi,</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Feb 5, 2013 at 9:41 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</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"><div class="gmail_extra"><div class="gmail_quote"><div class="im">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"><div class="gmail_extra"><div class="gmail_quote"><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.<br>
</div>
</div></div></div></blockquote><div><br></div></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>
</div></div></div></div></blockquote></div><br></div><div class="gmail_extra" style>Yes, this was what I was also saying. Right now, the array of coordinates is actually continuous in memory (as an array of rvecs), so it is not a problem to expose it, and it probably makes a lot of sense to make it easier to write tools in the near future. And even if we later would like to change the memory layout (I see no pressing need), creating that copy once (on first request) doesn't have a huge performance impact (compared to other stuff that is happening when anything but the simplest selections get evaluated). The biggest impact would actually be on memory consumption, which is already a bit bad with the current selection approach with very large systems.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>So all in all, even with these caveats, I think that adding that accessor is a good way forward. The current interface isn't something fixed, since I simply wrote a minimal interface that was required to be able to implement those simplistic tools that there currently are. Additions based on need are very welcome.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Teemu</div></div>