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

[Szilárd Páll]

On Tue, Feb 5, 2013 at 8:19 PM, Teemu Murtola <teemu.murtola at gmail.com>wrote:

> Hi,
>
>
> On Mon, Feb 4, 2013 at 5:51 PM, Roland Schulz <roland at utk.edu> wrote:
>
>> On Mon, Feb 4, 2013 at 4:00 AM, Alexey Shvetsov <alexxy at omrb.pnpi.spb.ru>wrote:
>>
>>> 1. Its incompatible with most functions in old gmxlib (e.g. Cannot use
>>> functions like reset_x, do_fit, calc_xcm etc.).
>>>
>> You can convert sel to atom_id by:
>> sel_[i].atomIndices().data()
>>
>>
>>>  For #1 may be its time to reimplement needed functions using new api.
>>>>
>>> Any help with that is greatly appreciated :-)
>>>
>>
> 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).



>
>  2. It may be easyer to work with atomdata if selections will not be marked
>>> static. E.g. sel.position(i).x()
>>>
>> 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.
>>
>
> 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).
>
> Teemu
>
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130205/e8961ca7/attachment.html>