[gmx-developers] Lowpass trajectory implementation

John Haberstroh jhaberstroh at berkeley.edu
Thu Apr 13 01:22:01 CEST 2017

Hi Justin,

Thanks for the recommendation, but the filter implementation is not really
my question. I am trying to update mdrun to include this filtering so that
it can be done on a signal with the proper sampling rate.

I'm thinking that I should update md.c with some sort of do_filter_update()
and do_filter_writing() function called right before
do_md_trajectory_writing(). I can maintain the value of the cumulative sum
for the filter with arrays managed by md.c, and then I need to:
(1) make sure that each DD node computes only their own filtered positions
independently every time step
(2) they communicate their results when appropriate
(3) cumulative sums for atoms move with the atoms when atoms move across
domains (not sure how to do this)
(4) I add nstfilterxtcout or something like that to the options

Does this sound like a sufficiently canonical approach?

Just to be clear on my intention, low pass filtering is only
useful/rigorously correct if the original signal being filtered is not
polluted with aliasing, i.e. it is sampled at the nyquist frequency of the
system, e.g. the sampled signal from every time step. I think it is a
reasonable approximation to say that all of the high frequency noise is
"white" noise relative to conformational dynamics and just do the filtering
on the 1ps-10ps sampled frames, but that is not really rigorous. If it
doesn't cost additional memory and only adds O(N) computation at each step,
it seems like a useful thing to have in the program, and in particular a
thing that I am quite interested in.

Thanks for all the timely responses.


On Wed, Apr 12, 2017 at 3:25 PM, Justin Lemkul <jalemkul at vt.edu> wrote:

> It sounds like you may want to start by looking at gmx filter -ol and the
> underlying code.
> -Justin
> On 4/12/17 1:50 PM, John Haberstroh wrote:
>> Hello Mark,
>> Thank you for the suggestion, but as you suggested it kind of misses the
>> point
>> of what I was asking. Maybe *I* misunderstand the -aver option in
>> g_energy if
>> that's the case. I'll give an example of what I want.
>> I want an additional trajectory output that averages over all steps
>> (every 2fs),
>> but I want it to be output every 10ps. This should result in a fairly
>> smooth
>> trajectory without sacrificing temporal resolution below 10ps. I am
>> referring to
>> this averaging procedure as "lowpass" filtering, though the square window
>> form
>> would need to be more complicated to be strictly a lowpass filter.
>> Alongside that, I want the instantaneous samples at every 10ps (i.e. the
>> current
>> .xtc output), which includes fluctuations with random phases from
>> frequency
>> components with periods much higher than 10ps, but in exchange obeys
>> boltzmann
>> statistics.
>> If I could do it "in post", I would be fine, but I can't do it in post
>> without
>> writing out every single time step, which is far too resource intensive
>> for my
>> needs.
>> Thanks,
>> John
>> ps: I was subscribed to digest so I apologize if this does not remain
>> within the
>> original thread, but I have fixed it now, so there should be no further
>> issues.
>>     Date: Wed, 12 Apr 2017 16:55:01 +0100
>>     From: David van der Spoel <spoel at xray.bmc.uu.se <mailto:
>> spoel at xray.bmc.uu.se>>
>>     To: gmx-developers at gromacs.org <mailto:gmx-developers at gromacs.org>
>>     Subject: Re: [gmx-developers] Lowpass trajectory implementation
>>     Message-ID: <1d2ce3f6-2a0f-6137-e351-6a84b5eab007 at xray.bmc.uu.se
>>     <mailto:1d2ce3f6-2a0f-6137-e351-6a84b5eab007 at xray.bmc.uu.se>>
>>     Content-Type: text/plain; charset=windows-1252; format=flowed
>>     On 12/04/17 16:30, John Haberstroh wrote:
>>     > Hello developers,
>>     >
>>     > I am interested in implementing a lowpass filter system for
>> position and
>>     > dihedral trajectories akin to the -aver option in g_energy ("Also
>> print
>>     > the exact average and rmsd stored in the energy frames (only when 1
>> term
>>     > is requested)") . I have found that a lot of computational effort
>> goes
>>     > into eliminating aliased noise from very high frequencies in these
>>     > position coordinates, and it would be nice to turn this noise down
>> a few
>>     > decibels. As it stands, it is not even possible to output dihedrals
>>     > during simulation though they are ostensibly be computed, let alone
>> to
>>     > print moving averages alongside samples. That said, my first step
>> would
>>     > be doing these averages for atomic positions as it would be (maybe)
>>     > pretty benign to extract dihedrals from the filtered atomic
>> positions.
>>     >
>>     > I understand that averaged positions will not necessarily be
>> physical
>>     > configurations and do not obey boltzmann statistics. I am
>> interested in
>>     > this procedure for the sake of getting a degree of spectral
>>     > separability. I also realize that the fluctuations will have to be
>>     > captured in a covariance matrix to be appropriately described. These
>>     > concerns are secondary to getting a signal with some semblance of
>> low
>>     > pass filtering.
>>     >
>>     > Any recommendations of where I should start for storing a rolling
>> mean
>>     > of atomic positions? I can probably piggy back on the trajectory
>> dump
>>     > procedures without issue if I can update this rolling mean every
>>     > timestep, so if you know where I can create a new array that is
>>     > persistent throughout the simulation, that would be the right kind
>> of tip.
>>     >
>>     I must say it is not clear to me what you would get out of this, but
>>     making a variant of gmx trjconv that reads the first N frames and
>> writes
>>     out the time averaged coordinates to a new trajectory could do the
>>     trick. A couple of lines of code should suffice.
>>     > Thanks!
>>     > John
>>     >
>>     > PS: I have edited gromacs source before, but only "brute forcing" a
>>     > modification to the pull.c function for alternative biased sampling,
>>     > which did not require generating any new persistent data variables.
>> I do
>>     > have some experience with the gromacs internals, though!
>>     >
>>     >
>>     --
>>     David van der Spoel, Ph.D., Professor of Biology
>>     Head of Department, Cell & Molecular Biology, Uppsala University.
>>     Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205
>> <tel:%2B46184714205>.
>>     http://www.icm.uu.se
> --
> ==================================================
> Justin A. Lemkul, Ph.D.
> Ruth L. Kirschstein NRSA Postdoctoral Fellow
> Department of Pharmaceutical Sciences
> School of Pharmacy
> Health Sciences Facility II, Room 629
> University of Maryland, Baltimore
> 20 Penn St.
> Baltimore, MD 21201
> jalemkul at outerbanks.umaryland.edu | (410) 706-7441
> http://mackerell.umaryland.edu/~jalemkul
> ==================================================
> --
> Gromacs Developers mailing list
> * Please search the archive at http://www.gromacs.org/Support
> /Mailing_Lists/GMX-developers_List before posting!
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail 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/20170412/7a6778cb/attachment-0001.html>

More information about the gromacs.org_gmx-developers mailing list