[gmx-developers] Some thoughts about new trajectory analisys api

[Teemu Murtola]

Hi,

On Tue, Feb 5, 2013 at 9:41 PM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:

> On Tue, Feb 5, 2013 at 8:19 PM, Teemu Murtola <teemu.murtola at gmail.com>wrote:
>
>> 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.
>>
>
> 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).
>

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.

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.

Teemu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130206/070f7c04/attachment.html>