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

[Teemu Murtola]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130205/ce4b3567/attachment.html>