Dear Hai,
That worked, thanks a lot.
I guess I will go for the version without the 2d array though, because distances are still sensitive to the molecule on which I image.
It is safer for this particular application to be sure that minimum image is applied to all distances.
But everything is clear now and I can make it work the way I intend.
Thanks again for your help and availability.
All the best,
Antoine
> On 26 Feb 2019, at 17:10, Hai Nguyen <nhai.qn.gmail.com> wrote:
>
> Hi Antoine,
>
> I see what’s going on now. For distance of 2D array, pytraj uses its own
> implementation and not using cpptraj public API directly. And this does not
> support imaging within the “distance” method itself. Awaring of that
> limitation, I added “autoimage” for on-disk trajectory too.
>
> traj = py.iterload(your big trajectories)
> traj.autoimage()
> pytraj.distance(traj, 2d_array,…)
> Please let me know if that work for you
>
>> For future, would it be more convenient for you if I open a thread
> directly on GitHub or on this mailing list?
>
> If the issue is helpful for other users, it would be best to open in Amber
> mailing list (e.g: your issue). Otherwise, open it in github (e.g: feature
> request, bug report ...)
>
> Thanks
> Hai
>
>> On Tue, Feb 26, 2019 at 5:29 AM Antoine MARION <amarion.metu.edu.tr> wrote:
>>
>> Dear Hai,
>>
>> Thanks a lot for your prompt answers and interest.
>> Sharing the files I am working on won’t be possible, but I can try to be
>> more explicit.
>>
>> I initially wrote a long email with details of my trials and ran a final
>> one which actually changes my question. I’ll try to summarize it.
>>
>> The box is a truncated octahedron with the following dimensions as read
>> from my initial structure:
>> 73.9541653 73.9541653 73.9541653 109.4712190 109.4712190 109.4712190
>>
>> Here is the result of “print traj” for a trajectory loaded with
>> “pt.iterload()":
>> pytraj.TrajectoryIterator, 50 frames:
>> Size: 0.000000 (GB)
>> <Topology: 41210 atoms, 10153 residues, 10135 mols, PBC with box type =
>> truncoct>
>>
>> With cpptraj:
>> distance .573 .284 out dist.dat
>> result: 38.94 …
>> This is the result I would expect from visual inspection of the structures.
>>
>> With pytraj, I initially wanted to use the an array to define the mask,
>> because I will have many to compute at the same time and this will
>> potentially change from one system to another. Here is what I did:
>> traj = pt.iterload(traj_file, parm_file)
>> dist = pt.distance(traj, top = traj.top, mask = [[572, 283]], image = True)
>> result: 73.14 …
>> This seems way too large, especially considering the dimensions of the box.
>>
>> Now if I load the trajectory with pt.load() instead of pt.iterload()
>> (which won’t be convenient for huge trajectories, right?), I get the same
>> result as cpptraj:
>> traj = pt.load(traj_file, parm_file)
>> traj = pt.autoimage(traj)
>> dist = pt.distance(traj, top = traj.top, mask = [[572, 283]], image = True)
>> result: 38.94 …
>>
>> I also tried your suggestion with pt.compute(), without imaging first, and
>> this gives the expected result:
>> traj = pt.iterload(traj_file, parm_file)
>> dist = pt.compute(“distance .573 .284”, traj)
>> result: 38.94 …
>>
>> But finally, I tried another way to define the mask with the pt.distance
>> command and this surprisingly (or not) gave me the result I am looking for:
>> traj = pt.iterload(traj_file, parm_file)
>> dist = pt.distance(traj, top = traj.top, mask = "@573 @284”, image = True)
>> result: 38.94 …
>>
>> So here is a better statement of my new issue:
>> [[572, 283]] and "@573 @284” are not equivalent in the pt.distance()
>> command regarding imaging. But as you can see above, on an imaged
>> trajectory, both give the same result.
>> Notice that mask = ".573 .284” and mask = [".573 @284”] yield the same
>> result (if that can help).
>> And similarly, mask = [572, 283] and mask = [[572, 283]] are also
>> equivalent.
>>
>> The usage with a mask defined as an array of atom indices (with
>> potentially many pairs) would be more convenient for me, although I could
>> find an easy way to work with the masks defined as strings. I might have
>> done something wrong with it, or misunderstood its usage.
>>
>> I hope I was clear enough. Don’t hesitate to ask for more details.
>> If needed, I will try to prepare a sample system to better illustrate the
>> issue.
>>
>> For future, would it be more convenient for you if I open a thread
>> directly on GitHub or on this mailing list?
>>
>> Thanks again for your help.
>>
>> All the best,
>> Antoine
>>
>>
>>> On 26 Feb 2019, at 02:47, Hai Nguyen <nhai.qn.gmail.com> wrote:
>>>
>>> On Mon, Feb 25, 2019 at 10:54 AM Antoine MARION <amarion.metu.edu.tr>
>> wrote:
>>>
>>>> Dear Amber Community,
>>>>
>>>> However, I faced a first little issue when calculating distances with
>>>> PBCs: i.e., minimum image is not applied and the “image” option seems
>> to be
>>>> ignored.
>>>
>>> Hi again, I've double-checked pytraj's code and ran some tests and its
>> code
>>> seems to work fine.
>>>
>>> Could you please send me (may be offline):
>>> - small trajectory + its topology file (prefer non-confidential files).
>>> - your exact command
>>> - your expectation (why you think the minimum image is not applied (e.g:
>> by
>>> comparing to cpptraj or by visualizing? ...).
>>>
>>> Thanks.
>>> Hai
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Feb 27 2019 - 00:30:02 PST
