[gmx-users] problem with g_density

chris.neale at utoronto.ca chris.neale at utoronto.ca
Tue Nov 9 15:04:14 CET 2010

Is it though? There were actually two problems in g_density. I saw the  
list of fixes previously and it only says "Fixed normalization of  
g_density using only the last frame". To me, this reads like somebody  
fixed the most trivial problem (now dividing by the NPT averaged  
volume instead of the volume from the last frame) and not the problem  
with fact that the histogram boxes are placed from the minimal  
coordinate and moving up along z with a constant width. The proper fix  
to this would be to ignore some values below and above a range in z  
that is either predefined or automatically determined. I have my own  
fixed version of g_density that does this, but I'm hesitant to  
distribute it because I did things like hard code this range.

Berk, can you comment?


Justin A. Lemkul jalemkul at vt.edu
Tue Nov 9 14:53:14 CET 2010

     * Previous message: [gmx-users] problem with g_density
     * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

chris.neale at utoronto.ca wrote:
> vinothkumar,
> The roughness of the interface that Justin is suggesting is only one  
> possible explanation for this feature. The other possible  
> explanation is that you are running a NPT simulation and your volume  
> fluctuations are causing the Z-dimension to fluctuate. In this case,  
> g_density will give somewhat incorrect results exactly like this.  
> While I suspect that there is at least some interface spatial  
> roughness that is contributing to your result, there is no way to  
> tell from your plot if this is the dominant reason for apparent  
> mixing, or if, rather, the mixing is mostly temporal based on z-axis  
> fluctuations and not much spatial mixing at all.
> There are probably trjconv-based solutions to your problem, but at a  
> first pass I'd say that g_density is broken so don;t use it.

As of version 4.5.2, this should be fixed.  Berk implemented per-frame
normalization on Sept. 14.


> Chris.
> vinothkumar mohanakrishnan wrote:
>> Hi all
>> I also faced a similar problem like Ozge Engi when i used the  
>> g_density command for water-DCE interface. when i saw the final  
>> .gro file in VMD i saw some 20-25 molecules of water came on one  
>> side (end of DCE side) of the box and  few molecules of DCE say 5  
>> molecules on the end of water side. i have attached the graph that  
>> i got. what is the problem due to? why are we not getting the  
>> density profile starting from zero on both side of the box? any  
>> help is highly appreciated.
> The thread you quote contains the answer.  The densities likely will not go
> completely to zero; the layers interact with each other in some way, so there
> will be some fluctuations at the interface between the two.
> -Justin
>> Regards
>> Vinoth
>> On Mon, Oct 25, 2010 at 4:36 PM, Tsjerk Wassenaar <tsjerkw at  
>> gmail.com <mailto:tsjerkw at gmail.com>> wrote:
>>     Hi,
>>      > You're not
>>      > seeing complete mixing of your two species, but there is some
>>     diffusion
>>      > between the phases, otherwise both of your particles should drop
>>     to exactly
>>      > zero density on either side of the box middle, wouldn't they?
>>     No, not if there are undulations of the interface.
>>     Cheers,

More information about the gromacs.org_gmx-users mailing list