[gmx-developers] Any interest in a g(x, y.z) functionality for g_rdf?

chris.neale at utoronto.ca chris.neale at utoronto.ca
Thu Mar 17 21:50:41 CET 2011


Michael:

I have a bit more time to explain what I have done and learned, so I  
wanted to revisit this. This is just a collection of what I have  
learned from trying to do this myself a few months ago. I gave up  
before completing it, but thought that some of this might be useful.

I made an SDF for a small solute interacting with a bilayer using  
g_spatial after using trjconv to align the bilayer COM along z and the  
solute COM along xy. The resolution was not that great, so in the end  
I modified trjconv to rotate my trajectory and then I created 36  
versions of that trajectory all rotated by 10 deg about the z axis and  
then used trjcat to put them together and then ran g_spatial.

I actually spent a few days trying to enhance g_spatial to do this  
automatically, but I gave up when I realized that I could hack it in  
an hour.

I did, however, learn a few things in the process. If you are going to  
make a SDF like this, then you should construct it in polar  
coordinates, even if you are going to convert it into a 3D cartesian  
file for visualization. This allows you to average over the desired  
dimensions as the data is binned. Second, you will want the bins to be  
large enough that the SDF is not too noisy, but this will lead to the  
obvious appearance of block edges in your 3D cartesian SDF near the  
polar origin. My solution (though never fully implemented) was to take  
this SDF, which is 'blocky' near the polar origin, and interpolate it  
near the origin into a much smoother SDF. Further away from the  
origin, one would need to either interpolate or simply create many  
boxes for each parent box if using the gaussian98 cube format, which  
requires a standard grid spacing.

Good luck. I think that a clean tool to do this would be a very useful  
replacement for g_spatial. Ideally, the new tool would retain the  
current functionality of g_spatial too so that users can preprocess in  
whatever way they desire.

Chris.

Quoting "Shirts, Michael (mrs5pt)" <mrs5pt at eservices.virginia.edu>:

> g_spatial looks like it has the correct capabilities - though a big of a
> pain - it really should be set up so that the alignment can be done more
> automatically.  Sorry for not looking more carefully!
>
> Best,
> ~~~~~~~~~~~~
> Michael Shirts
> Assistant Professor
> Department of Chemical Engineering
> University of Virginia
> michael.shirts at virginia.edu
> (434)-243-1821
>
>
>> From: "chris.neale at utoronto.ca" <chris.neale at utoronto.ca>
>> Reply-To: Discussion list for GROMACS development   
>> <gmx-developers at gromacs.org>
>> Date: Fri, 11 Mar 2011 12:59:46 -0500
>> To: "gmx-developers at gromacs.org" <gmx-developers at gromacs.org>
>> Subject: Re: [gmx-developers] Any interest in a g(x, y.z) functionality for
>> g_rdf?
>>
>> g_spatial does this for a single solute. A bizarre hacking of trjconv
>> and trjcat with .ndx file reordering could be used to do this with
>> g_spatial and a final .xtc file that is Nwat*Nframes. Not perfect, but
>> can be done right now without coding if I understand your interest
>> correctly.
>>
>> Chris.
>>
>> Quoting "Shirts, Michael (mrs5pt)" <mrs5pt at eservices.virginia.edu>:
>>
>>> Hi, all-
>>>
>>> Is there any interest in a g(x,y.z) functionality for g_rdf?  For many
>>> molecules, the liquid structure can be more complicated, and the ability to
>>> visualize it in three dimensions could be useful.  We're looking at this in
>>> my lab, and were thinking about just writing an easier postprocessing
>>> script, but if there is more demand for it, we can implement it in Gromacs
>>> as well.
>>>
>>> Best,
>>> ~~~~~~~~~~~~
>>> Michael Shirts
>>> Assistant Professor
>>> Department of Chemical Engineering
>>> University of Virginia
>>> michael.shirts at virginia.edu
>>> (434)-243-1821
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> 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.
>
> --
> 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.
>






More information about the gromacs.org_gmx-developers mailing list