Re: [gmx-users] Building full GROMACS and mdrun only with MPI and GPU: FFTW and regression tests

[João M . Damas]

On Fri, Jan 10, 2020 at 4:01 PM Mark Abraham 
wrote:

> Hi,
>
> On Fri, 10 Jan 2020 at 10:49, João M. Damas  wrote:
>
> > Hi all,
> >
> > I am trying to build GROMACS in a similar fashion to what is described in
> > section 2.3.5 of the manual (weblink
> > <
> >
> http://manual.gromacs.org/documentation/2019.5/install-guide/index.html#testing-gromacs-for-correctness
> > >),
> > i.e. a full build of GROMACS without any particular flags, and then a
> build
> > of mdrun only, with MPI and GPU enabled.
> >
> > My first issue would be with the compilation of the FFT library, namely
> the
> > recommended FFTW through -DGMX_BUILD_OWN_FFTW=ON. I find that flag very
> > useful, but with a recipe as described in section 2.3.5, it would mean
> > compiling FFTW twice, which is a waste of time. Do you recommend for me
> to
> > compile FFTW separately on my own or is there a way/flag to pass the
> > compiled static library to the mdrun building step?
> >
>
> No, the only way to do that is to have installed FFTW somewhere and have
> both builds pick it up, e.g. through using cmake
> -DCMAKE_PREFIX_PATH=/path/to/your/fftw. It's also not a lot of time, for
> something you do rarely, so I would just ignore the inefficiency.
>
Thanks, that's what I thought. I'll see which of the two options is the
best for my case.

>
>
> > My second issue is with the regression tests. Using the procedure of
> > section 2.3.5, with a mdrun building recipe like this:
> >
> > cmake3 .. \
> >-DCMAKE_INSTALL_PREFIX=${SOFTWARE_INSTALL_PREFIX} \
> >-DGMX_BUILD_OWN_FFTW=ON \
> >-DGMX_DEFAULT_SUFFIX=OFF \
> >-DGMX_BINARY_SUFFIX=_mpi \
> >-DGMX_LIBS_SUFFIX=_mpi \
> >
>
> There's no need to do this - you're turning off the suffixing and then
> doing the default behaviour yourself. It should work, but we don't try to
> test it :-)
>
Oh, a bit of over-engineering from my part, I see . I didn't actually
test that the -DGMX_MPI=ON changed the default suffix. Thanks for the
feedback.

>
>-DGMX_MPI=ON \
> >-DGMX_GPU=ON \
> >-DGMX_BUILD_MDRUN_ONLY=ON
> > make -j ${NPROCS}
> > make install
> >
> > there are issues with running `./gmxtest.pl all -np ${NPROCS} -mdrun
> > mdrun_mpi`. Since I am using the same install prefix for both building
> > steps, I am using the suffix flags stated, but then I need to fix
> > gmxtest.pl (namely
> > change the autosuffix variable from 1 to null) to make the tests run
> > (succesfully). Am I doing something wrong with the suffixes? I believe I
> > need them if I want to install on the same prefix.
> >
>
> No. ./gmxtest.pl -nosuffix is useful for testing in the case you are
> doing,
> and even though you're over-managing the suffixes, nothing's wrong.
>
I guess that's the flag I was looking for! I'll try it. Thanks.

>
>
> > Finally, is there a better way of doing this process to achieve the same
> > result (i.e. a full build of GROMACS without any particular flags, and
> then
> > a build of mdrun only, with MPI and GPU enabled)? In the case that
> section
> > is outdated.
> >
>
> This is the current procedure. There's currently no significant difference
> between gmx_mpi mdrun and mdrun_mpi, except that one could reasonably want
> to try harder to build the latter to link in a fully static way (which can
> be worth a percent or two of performance).
>
Thanks for the extra input on this matter, I appreciate it.

>
> Mark
>
> Thank you in advance,
> > João
> > --
> > Gromacs Users mailing list
> >
> > * Please search the archive at
> > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> > send a mail to gmx-users-requ...@gromacs.org.
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

[gmx-users] Building full GROMACS and mdrun only with MPI and GPU: FFTW and regression tests

[João M . Damas]

Hi all,

I am trying to build GROMACS in a similar fashion to what is described in
section 2.3.5 of the manual (weblink
),
i.e. a full build of GROMACS without any particular flags, and then a build
of mdrun only, with MPI and GPU enabled.

My first issue would be with the compilation of the FFT library, namely the
recommended FFTW through -DGMX_BUILD_OWN_FFTW=ON. I find that flag very
useful, but with a recipe as described in section 2.3.5, it would mean
compiling FFTW twice, which is a waste of time. Do you recommend for me to
compile FFTW separately on my own or is there a way/flag to pass the
compiled static library to the mdrun building step?

My second issue is with the regression tests. Using the procedure of
section 2.3.5, with a mdrun building recipe like this:

cmake3 .. \
   -DCMAKE_INSTALL_PREFIX=${SOFTWARE_INSTALL_PREFIX} \
   -DGMX_BUILD_OWN_FFTW=ON \
   -DGMX_DEFAULT_SUFFIX=OFF \
   -DGMX_BINARY_SUFFIX=_mpi \
   -DGMX_LIBS_SUFFIX=_mpi \
   -DGMX_MPI=ON \
   -DGMX_GPU=ON \
   -DGMX_BUILD_MDRUN_ONLY=ON
make -j ${NPROCS}
make install

there are issues with running `./gmxtest.pl all -np ${NPROCS} -mdrun
mdrun_mpi`. Since I am using the same install prefix for both building
steps, I am using the suffix flags stated, but then I need to fix
gmxtest.pl (namely
change the autosuffix variable from 1 to null) to make the tests run
(succesfully). Am I doing something wrong with the suffixes? I believe I
need them if I want to install on the same prefix.

Finally, is there a better way of doing this process to achieve the same
result (i.e. a full build of GROMACS without any particular flags, and then
a build of mdrun only, with MPI and GPU enabled)? In the case that section
is outdated.

Thank you in advance,
João
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] gmx mindist error

[João M . Damas]

t;
> > >> > > >> box (3x3):
> > >> > > >> box[0]={ 8.16756e+00,  0.0e+00,  0.0e+00}
> > >> > > >> box[1]={ 0.0e+00,  8.25175e+00,  0.0e+00}
> > >> > > >> box[2]={ 0.0e+00,  0.0e+00,  9.73586e+00}
> > >> > > >>
> > >> > > >> Is gmx mindist reading the box vector lengths from the
> structure
> > >> file
> > >> > > >> instead?
> > >> > > >>
> > >> > > >
> > >> > > > When you don't provide a .tpr file, the program does not know
> what
> > >> type
> > >> > > of
> > >> > > > periodicity the simulation used, so it cannot do the requested
> > >> > > calculation
> > >> > > > because the shifts cannot be calculated.
> > >> > > >
> > >> > > > -Justin
> > >> > > >
> > >> > > > --
> > >> > > > ==
> > >> > > >
> > >> > > > Justin A. Lemkul, Ph.D.
> > >> > > > Assistant Professor
> > >> > > > Virginia Tech Department of Biochemistry
> > >> > > >
> > >> > > > 303 Engel Hall
> > >> > > > 340 West Campus Dr.
> > >> > > > Blacksburg, VA 24061
> > >> > > >
> > >> > > > jalem...@vt.edu | (540) 231-3129
> > >> > > > http://www.thelemkullab.com
> > >> > > >
> > >> > > > ==
> > >> > > >
> > >> > > > --
> > >> > > > Gromacs Users mailing list
> > >> > > >
> > >> > > > * Please search the archive at http://www.gromacs.org/Support
> > >> > > > /Mailing_Lists/GMX-Users_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-users
> > >> or
> > >> > > > send a mail to gmx-users-requ...@gromacs.org.
> > >> > > --
> > >> > > Gromacs Users mailing list
> > >> > >
> > >> > > * Please search the archive at
> > >> > > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users
> > or
> > >> > > send a mail to gmx-users-requ...@gromacs.org.
> > >> > --
> > >> > Gromacs Users mailing list
> > >> >
> > >> > * Please search the archive at
> > >> > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users
> or
> > >> > send a mail to gmx-users-requ...@gromacs.org.
> > >> --
> > >> Gromacs Users mailing list
> > >>
> > >> * Please search the archive at
> > >> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> > >> send a mail to gmx-users-requ...@gromacs.org.
> > >
> > >
> > --
> > Gromacs Users mailing list
> >
> > * Please search the archive at http://www.gromacs.org/
> > Support/Mailing_Lists/GMX-Users_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-users or
> > send a mail to gmx-users-requ...@gromacs.org.
> >
> --
> Gromacs Users mailing list
>
> * Please search the archive at http://www.gromacs.org/
> Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Test particle insertion for all atom force field

[João M . Damas]

Hi,

You can put the entire molecule the the end of .gro file, it shall work.
Remember that the molecule should be centered at 0, 0, 0.

João

On Thu, Apr 6, 2017 at 1:06 PM, Badmos, Sakiru <sakiru.badmos...@ucl.ac.uk>
wrote:

> Hi everyone,
>
>   I want to calculate excess chemical potential for some
> molecules in water. I found a tutorial on this but it was on methane
> (united atom). The insertion of the test particle requires that it is
> included as the last atom in the .gro file with coordinate 0.000 0.000
> 0.000. This works for United atom. How do I do this for molecule like CO2
> with three atoms?
>
>  Thank you as you help.
>
> Sakiru.
>
> --
> Gromacs Users mailing list
>
> * Please search the archive at http://www.gromacs.org/
> Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] GROMACS3.3.1 - configure: error: invalid variable name: –-with-fft

[João M . Damas]

Hi Simon,

Assuming you are copying/pasting the command you are running, it seems to
me that the first hyphen of the flag is rather a dash or a minus sign
(weirdly).

Can you rather try: ./configure --with-fft=fftpack

Regards,
João

On Thu, Apr 6, 2017 at 10:12 AM, Simon Kit Sang Chu <simoncks1...@gmail.com>
wrote:

> Hi everyone,
>
> Due to some technical issues, I have to install gromacs 3.3.1 in order to
> incorporate my desired forcefield. Following the instructions, I have to
> switch the FFT library to fftpack. However, I run into this error whenever
> I choose the option --with-fft, regardless the library chosen.
>
> ./configure –-with-fft=fftpack
> configure: error: invalid variable name: –-with-fft
>
>
> I checked ./configure and ./configure -h. Indeed, the option is available.
>
> From ./configure,
>
> --with-fft=[fftw3/fftw2/mkl(>=6.0)/fftpack]
>   FFT library to use. fftw3 is default, fftpack
> built
>   in.
>
>
> Would anyone kindly suggest possible solution or items that I could look
> into?
>
> Thank you.
>
> Regards,
> Simon
> --
> Gromacs Users mailing list
>
> * Please search the archive at http://www.gromacs.org/
> Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

[gmx-users] Fwd: Research Position at Acellera, Barcelona

[João M . Damas]

-- Forwarded message --
From: ACELLERA <i...@acellera.com>
Date: Thu, Nov 3, 2016 at 12:56 PM
Subject: Research Position at Acellera, Barcelona
To: jmda...@gmail.com


Research Position at Acellera, Barcelona
View this email in your browser
<http://us2.campaign-archive2.com/?u=b07ef035de297a424fe623964=f657ad7f0d=6e5d1ea489>
Research Position at Acellera, Barcelona

DEVELOPING AND APPLYING SIMULATIONS METHODS FOR DRUG DISCOVERY

Acellera is seeking an exceptional medicinal chemist / computational
biologist / biophysicist, with a strong background in development of
scientific software, to join our Barcelona-based team.

This is a unique opportunity to participate in the design and development
of new tools for computational chemistry of interest for pharmaceutical
companies based on the in-silico software platform, HTMD (
http://www.htmd.org
<http://acellera.us2.list-manage1.com/track/click?u=b07ef035de297a424fe623964=e44e38bb60=6e5d1ea489>
).

We invite you to visit our career webpage for more details:
https://www.acellera.com/careers/
<http://acellera.us2.list-manage1.com/track/click?u=b07ef035de297a424fe623964=61c630b529=6e5d1ea489>

If you know anybody that could be interested in this position please
forward it.

Thank you for your interest,

The Acellera team.
<http://acellera.us2.list-manage.com/track/click?u=b07ef035de297a424fe623964=648518a51b=6e5d1ea489>
<http://acellera.us2.list-manage1.com/track/click?u=b07ef035de297a424fe623964=0df9c7a289=6e5d1ea489>
<http://acellera.us2.list-manage.com/track/click?u=b07ef035de297a424fe623964=8e33262444=6e5d1ea489>
<http://acellera.us2.list-manage1.com/track/click?u=b07ef035de297a424fe623964=1348294c9c=6e5d1ea489>
*Copyright © 2016 ACELLERA LTD., All rights reserved.*
You receive this email because you have downloaded HTMD and we estimate we
could be interested in the information sent.

*Our mailing address is:*
ACELLERA LTD.
Devonshire House, Honeypot Lane 582, Stanmore
London, HA7 1JS
United Kingdom

Add us to your address book
<http://acellera.us2.list-manage.com/vcard?u=b07ef035de297a424fe623964=39f687ec45>


Want to change how you receive these emails?
You can update your preferences
<http://acellera.us2.list-manage.com/profile?u=b07ef035de297a424fe623964=39f687ec45=6e5d1ea489>
or unsubscribe from this list
<http://acellera.us2.list-manage.com/unsubscribe?u=b07ef035de297a424fe623964=39f687ec45=6e5d1ea489=f657ad7f0d>

[image: Email Marketing Powered by MailChimp]
<http://www.mailchimp.com/monkey-rewards/?utm_source=freemium_newsletter_medium=email_campaign=monkey_rewards=b07ef035de297a424fe623964=1>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] TPI and chemical potential

[João M . Damas]

I think the Widom particle insertion method can also apply to NPT as long
as the volume fluctuations are taken into account (see equation 2.69b in
Allen and Tildesley's Computer Simulation of Liquids ). From what I recall
from the code, I think they are.

Do not forget the result is the excess chemical potential and not the
chemical potential. I don't know if this is relevant for you or not.

TPI is not going to work for a big molecule. I would say impossible to
converge, but someone correct me if I am wrong. TPI is very limited in that
sense. You can try to explore more recent methods.

João

On Wed, Aug 17, 2016 at 10:18 AM, Gmx QA <gmxquesti...@gmail.com> wrote:

> Thanks again
>
> In my hands at least, -pbc mol -ur compact seems to be necessary, as
> without it I get a lot of  instead of actual numbers.
>
> I tried to find a reference for the chemical potential of TIP3P, but
> haven't succeeded yet. Related to gromacs, I find one thread in the
> archives that claims that for TIP3p as well as SPC/E the agreement with
> experiment is reasonable, but with problems for TIP5P.
>
> https://mailman-1.sys.kth.se/pipermail/gromacs.org_gmx-
> users/2014-May/089540.html
>
> Also, does it matter if the rerun is performed on a NVT or NPT trajectory?
> This I could of course easily test, but it seems that formally at least the
> Widow formula is applicable to NVT only?
>
> Anyway, I think I now know enough to proceed. How reliable are TPI results
> if I want to measure the chemical potential of a drug molecule? How hard
> are they to converge?
>
> Best
> /PK
>
>
> 2016-08-16 16:38 GMT+02:00 João M. Damas <jmda...@itqb.unl.pt>:
>
> > I don't recall any necessary post-processing of the trajectory being
> > necessary, as it should deal well with PBC conditions.
> >
> > I really don't know what is happening, but it seems like the fixes are
> > going in the right direction.
> >
> > Try to plot the  along time, to see if it's converging or not.
> > Depending on the trend, you may want to extend the simulation time. Other
> > reasons for incorrect excess chemical potential may be that the TIP3p
> model
> > may not reproduce well that quantity.
> >
> > And yeah, it's kJ/mol.
> >
> > João
> >
> > On Tue, Aug 16, 2016 at 2:12 PM, Gmx QA <gmxquesti...@gmail.com> wrote:
> >
> > > Thanks Joao
> > >
> > > The water box is equilibrated at 298K (I checked density and
> temperature
> > >  with gmx energy, and they show no drift from reasonable averages).
> > >
> > > However, I am a bit confused as I just tried the approach on the same
> > > trajectory, but extended to 2.5 ns and after one pass through trjconv
> > with
> > > -pbc mol -ur compact options.
> > >
> > > This seems to work in the sense that I no longer get any infs, but the
> > > value of , while having the right magnitude, is still off by about
> a
> > > factor of 2.
> > > After 2.5 ns I get  = -45 (I assume the unit is kJ/mol), whereas
> if i
> > > read correctly the chemical potential should be -23.5 or so. Can it be
> > that
> > > I now need to increase the run time of my water simulation even more?
> > >
> > > Thanks
> > > /PK
> > >
> > >
> > >
> > > 2016-08-16 13:47 GMT+02:00 João M. Damas <jmda...@itqb.unl.pt>:
> > >
> > > > Well, 5 insertions per frame, doesn't look bad. 1 ns should not
> be
> > an
> > > > issue.
> > > >
> > > > Well, actually that value normally starts at inf and should go to the
> > > > equilibrium  as you increase sampling. But to be inf after 5
> > > > inserts, it does sound weird.
> > > >
> > > > How did you build your box of water? Is it equilibrated at that
> > > temperature
> > > > (298 K)?
> > > > Please make make that the water molecule to be inserted has the
> correct
> > > > geometrical coordinates and that it is centered at 0,0,0.
> > > >
> > > > João
> > > >
> > > > On Tue, Aug 16, 2016 at 12:45 PM, Gmx QA <gmxquesti...@gmail.com>
> > wrote:
> > > >
> > > > > Hi Joao
> > > > >
> > > > > Thank you for your reply. My mdp-file is pasted below:
> > > > >
> > > > > integrator  = tpi
> > > > > emtol = 1000.0
> > > > > emstep  = 0.01
> > > > > nsteps= 5
> > > > >
> > > > > nstlist = 1
> > > &g

Re: [gmx-users] TPI and chemical potential

[João M . Damas]

I don't recall any necessary post-processing of the trajectory being
necessary, as it should deal well with PBC conditions.

I really don't know what is happening, but it seems like the fixes are
going in the right direction.

Try to plot the  along time, to see if it's converging or not.
Depending on the trend, you may want to extend the simulation time. Other
reasons for incorrect excess chemical potential may be that the TIP3p model
may not reproduce well that quantity.

And yeah, it's kJ/mol.

João

On Tue, Aug 16, 2016 at 2:12 PM, Gmx QA <gmxquesti...@gmail.com> wrote:

> Thanks Joao
>
> The water box is equilibrated at 298K (I checked density and temperature
>  with gmx energy, and they show no drift from reasonable averages).
>
> However, I am a bit confused as I just tried the approach on the same
> trajectory, but extended to 2.5 ns and after one pass through trjconv with
> -pbc mol -ur compact options.
>
> This seems to work in the sense that I no longer get any infs, but the
> value of , while having the right magnitude, is still off by about a
> factor of 2.
> After 2.5 ns I get  = -45 (I assume the unit is kJ/mol), whereas if i
> read correctly the chemical potential should be -23.5 or so. Can it be that
> I now need to increase the run time of my water simulation even more?
>
> Thanks
> /PK
>
>
>
> 2016-08-16 13:47 GMT+02:00 João M. Damas <jmda...@itqb.unl.pt>:
>
> > Well, 5 insertions per frame, doesn't look bad. 1 ns should not be an
> > issue.
> >
> > Well, actually that value normally starts at inf and should go to the
> > equilibrium  as you increase sampling. But to be inf after 5
> > inserts, it does sound weird.
> >
> > How did you build your box of water? Is it equilibrated at that
> temperature
> > (298 K)?
> > Please make make that the water molecule to be inserted has the correct
> > geometrical coordinates and that it is centered at 0,0,0.
> >
> > João
> >
> > On Tue, Aug 16, 2016 at 12:45 PM, Gmx QA <gmxquesti...@gmail.com> wrote:
> >
> > > Hi Joao
> > >
> > > Thank you for your reply. My mdp-file is pasted below:
> > >
> > > integrator  = tpi
> > > emtol = 1000.0
> > > emstep  = 0.01
> > > nsteps= 5
> > >
> > > nstlist = 1
> > > cutoff-scheme   = group
> > > ns_type = grid
> > > coulombtype = pme
> > > rcoulomb= 1.0
> > > rvdw= 1.0
> > > pbc = xyz
> > > nstxtcout = 5000
> > >
> > > ; Temperature coupling is on
> > > tcoupl = V-rescale
> > > tc-grps  = system
> > > tau_t  = 0.1
> > > ref_t= 298
> > >
> > > ; Pressure coupling is on
> > > pcoupl  = no
> > > pcoupltype  = isotropic
> > > tau_p   = 2.0
> > > ref_p   = 1.0
> > > compressibility = 4.5e-5
> > >
> > > ld_seed = -1
> > >
> > > I am using the amber99sb forcefield for tip3p, so I believe the 1.0 nm
> > > cutoffs to be correct?
> > >
> > > I have tried a couple different values for the number of insertions,
> and
> > > for some frames different values sometimes give non-inf results, but
> for
> > > the most part it does not seem to make a difference.
> > >
> > > 1 ns is short, I agree, but since the value of  (which I take to be
> > the
> > > excess chemical potential I am after) immediately goes to inf when the
> > > first mu=inf appears, extending does not make sense to me? Is the
> > chemical
> > > potential reported elsewhere as well?
> > >
> > > Thanks
> > > /PK
> > >
> > > 2016-08-16 12:35 GMT+02:00 João M. Damas <jmda...@itqb.unl.pt>:
> > >
> > > > Yes, all water atoms can't be with coordinates 0,0,0. I don't know
> how
> > > did
> > > > that even work... Weird.
> > > >
> > > > 1 ns is very short time scale. Also, how many insertions are you
> trying
> > > per
> > > > frame? That could also help improve the sampling.
> > > >
> > > > The inf values are normal as it just means that the water is too
> > > structured
> > > > and it's hard to insert a new water from the sampling point of view.
> > > >
> > > > Can you post the .mdp you used for the tpi?
> > > >

Re: [gmx-users] TPI and chemical potential

[João M . Damas]

Well, 5 insertions per frame, doesn't look bad. 1 ns should not be an
issue.

Well, actually that value normally starts at inf and should go to the
equilibrium  as you increase sampling. But to be inf after 5
inserts, it does sound weird.

How did you build your box of water? Is it equilibrated at that temperature
(298 K)?
Please make make that the water molecule to be inserted has the correct
geometrical coordinates and that it is centered at 0,0,0.

João

On Tue, Aug 16, 2016 at 12:45 PM, Gmx QA <gmxquesti...@gmail.com> wrote:

> Hi Joao
>
> Thank you for your reply. My mdp-file is pasted below:
>
> integrator  = tpi
> emtol = 1000.0
> emstep  = 0.01
> nsteps= 5
>
> nstlist = 1
> cutoff-scheme   = group
> ns_type = grid
> coulombtype = pme
> rcoulomb= 1.0
> rvdw= 1.0
> pbc = xyz
> nstxtcout = 5000
>
> ; Temperature coupling is on
> tcoupl = V-rescale
> tc-grps  = system
> tau_t  = 0.1
> ref_t= 298
>
> ; Pressure coupling is on
> pcoupl  = no
> pcoupltype  = isotropic
> tau_p   = 2.0
> ref_p   = 1.0
> compressibility = 4.5e-5
>
> ld_seed = -1
>
> I am using the amber99sb forcefield for tip3p, so I believe the 1.0 nm
> cutoffs to be correct?
>
> I have tried a couple different values for the number of insertions, and
> for some frames different values sometimes give non-inf results, but for
> the most part it does not seem to make a difference.
>
> 1 ns is short, I agree, but since the value of  (which I take to be the
> excess chemical potential I am after) immediately goes to inf when the
> first mu=inf appears, extending does not make sense to me? Is the chemical
> potential reported elsewhere as well?
>
> Thanks
> /PK
>
> 2016-08-16 12:35 GMT+02:00 João M. Damas <jmda...@itqb.unl.pt>:
>
> > Yes, all water atoms can't be with coordinates 0,0,0. I don't know how
> did
> > that even work... Weird.
> >
> > 1 ns is very short time scale. Also, how many insertions are you trying
> per
> > frame? That could also help improve the sampling.
> >
> > The inf values are normal as it just means that the water is too
> structured
> > and it's hard to insert a new water from the sampling point of view.
> >
> > Can you post the .mdp you used for the tpi?
> >
> > João
> >
> > On Tue, Aug 16, 2016 at 9:52 AM, Gmx QA <gmxquesti...@gmail.com> wrote:
> >
> > > Please - anyone?
> > >
> > > I gathered from the mail-list that maybe the entire molecule (water in
> > this
> > > case) should be centered on origo (rather than having all atoms at
> > (0,0,0),
> > > but this gives me only a lot of inf for the chemical potential.
> > >
> > > How can I calculate the excess chemical potential of water using TPI in
> > > gromacs?
> > >
> > >
> > >
> > > 2016-08-15 13:31 GMT+02:00 Gmx QA <gmxquesti...@gmail.com>:
> > >
> > > > Dear list
> > > >
> > > > I am trying to teach myself how the test particle method for excess
> > > > chemical potential calculations work. To this end, I created a small
> > > system
> > > > of about 900 water molecules (TIP3p), and simulated for 1 ns.
> > > >
> > > > I then set up files for inserting an extra water molecule to
> calculate
> > > mu,
> > > > the chemical potential.
> > > >
> > > > The end of my tpi_start.gro looks like this:
> > > > 
> > > >   884SOL OW 2650   2.466   0.788   2.747 -0.5599 -0.0387  0.0570
> > > >   884SOLHW1 2651   2.529   0.835   2.802  0.0024 -0.9901  0.2261
> > > >   884SOLHW2 2652   2.506   0.703   2.732 -1.4472 -0.3598 -0.5022
> > > >   885SOL OW 2653   0.000   0.000   0.000  0.  0.  0.
> > > >   885SOLHW1 2654   0.000   0.000   0.000  0.  0.  0.
> > > >   885SOLHW2 2655   0.000   0.000   0.000  0.  0.  0.
> > > >3.01188   3.01188   3.01188
> > > >
> > > > So I think this last water molecule is the one to be inserted. The
> > > > topology was also updated accordingly.
> > > >
> > > > I then made a rerun like this:
> > > >
> > > > $ gmx mdrun -v -deffnm tpi -rerun md.xtc
> > > >
> > > > And the output is a series of lines like

Re: [gmx-users] TPI and chemical potential

[João M . Damas]

Yes, all water atoms can't be with coordinates 0,0,0. I don't know how did
that even work... Weird.

1 ns is very short time scale. Also, how many insertions are you trying per
frame? That could also help improve the sampling.

The inf values are normal as it just means that the water is too structured
and it's hard to insert a new water from the sampling point of view.

Can you post the .mdp you used for the tpi?

João

On Tue, Aug 16, 2016 at 9:52 AM, Gmx QA <gmxquesti...@gmail.com> wrote:

> Please - anyone?
>
> I gathered from the mail-list that maybe the entire molecule (water in this
> case) should be centered on origo (rather than having all atoms at (0,0,0),
> but this gives me only a lot of inf for the chemical potential.
>
> How can I calculate the excess chemical potential of water using TPI in
> gromacs?
>
>
>
> 2016-08-15 13:31 GMT+02:00 Gmx QA <gmxquesti...@gmail.com>:
>
> > Dear list
> >
> > I am trying to teach myself how the test particle method for excess
> > chemical potential calculations work. To this end, I created a small
> system
> > of about 900 water molecules (TIP3p), and simulated for 1 ns.
> >
> > I then set up files for inserting an extra water molecule to calculate
> mu,
> > the chemical potential.
> >
> > The end of my tpi_start.gro looks like this:
> > 
> >   884SOL OW 2650   2.466   0.788   2.747 -0.5599 -0.0387  0.0570
> >   884SOLHW1 2651   2.529   0.835   2.802  0.0024 -0.9901  0.2261
> >   884SOLHW2 2652   2.506   0.703   2.732 -1.4472 -0.3598 -0.5022
> >   885SOL OW 2653   0.000   0.000   0.000  0.  0.  0.
> >   885SOLHW1 2654   0.000   0.000   0.000  0.  0.  0.
> >   885SOLHW2 2655   0.000   0.000   0.000  0.  0.  0.
> >3.01188   3.01188   3.01188
> >
> > So I think this last water molecule is the one to be inserted. The
> > topology was also updated accordingly.
> >
> > I then made a rerun like this:
> >
> > $ gmx mdrun -v -deffnm tpi -rerun md.xtc
> >
> > And the output is a series of lines like this:
> >
> > Reading frame 180 time  900.000   mu  8.924e+00   7.240e+00
> > mu  7.671e+00   7.242e+00
> > mu  6.987e+00   7.241e+00
> > mu  7.010e+00   7.239e+00
> > mu  7.691e+00   7.241e+00
> > mu  7.439e+00   7.242e+00
> > mu  6.757e+00   7.240e+00
> > mu  8.114e+00   7.243e+00
> > mu  7.173e+00   7.243e+00
> > mu  8.768e+00   7.249e+00
> > Reading frame 190 time  950.000   mu  7.799e+00   7.252e+00
> > mu  9.284e+00   7.259e+00
> > mu  8.103e+00   7.262e+00
> > mu  7.835e+00   7.265e+00
> > mu  7.321e+00   7.265e+00
> > mu  7.576e+00   7.267e+00
> > mu  9.348e+00   7.274e+00
> > mu  7.021e+00   7.272e+00
> > mu  7.162e+00   7.272e+00
> > mu  7.695e+00   7.274e+00
> > Reading frame 200 time 1000.000   mu  7.104e+00   7.273e+00
> >
> > Now, is  here the average computed chemical potential? What is the
> TPI
> > energy distribution being reported in the tpi.xvg-file?
> >
> > I tried to google for the chemical potential of water and according to
> > e.g. [1] (page 13) it should be around -23.5 kJ/mol. I would really
> > appreciate if someone could comment on this, as I need to understand it
> > before moving on to more relevant (for me) systems….
> >
> > Thanks
> > /PK
> >
> >
> >
> >
> >
> > [1] Chemical potential of liquids and mixtures via Adaptive Resolution
> ...
> > <https://www.google.se/url?sa=t=j==s=web;
> cd=21=0ahUKEwj-7-2gqMPOAhVFWiwKHdp4DYY4FBAWCBww
> AA=https%3A%2F%2Fopus4.kobv.de%2Fopus4-zib%2Ffiles%
> 2F5097%2FZIB-Report_14-25.pdf=AFQjCNECRk9dif8TGxKJeeztHV6T_
> FmVuw=-vsjUB9HRdlcnt4vyKWcbw>
> >
> --
> Gromacs Users mailing list
>
> * Please search the archive at http://www.gromacs.org/
> Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Creating topology for Cu-containing enzyme,

[João M . Damas]

Hi Francesca,

Please contact me directly.

Best,
João

On Fri, Aug 12, 2016 at 8:23 AM, Francesca Lønstad Bleken <
francescal.ble...@sintef.no> wrote:

> Hi,
>
> Thank you Joao, Justin and Marlon for your answers.
>
> Joao, I have been looking at your article the last days as it explains
> very well what you have done, particularly in the Supplementary info, so
> I am very happy that you answered this thread. Would it be possible for me
> to look at your specbond.dat, .rtp and .itp files so that I better can
> ensure that I am doing things the right way?
> Your system is very similar to mine, so I think I would learn a lot from
> looking at your setup. I hope this is not an inappropriate request, I will
> of course acknowledge you help if this work comes to a publication.
>
> Best regards,
> Francesca
>
>
>
> Date: Thu, 11 Aug 2016 15:40:30 +0100
>
> From: Jo?o M. Damas >
>
> To: Discussion list for GROMACS users >
>
> Subject: Re: [gmx-users] Creating topology for Cu-containing enzyme,
>
> GROMOS96 force field.
>
> Message-ID:
>
> 

Re: [gmx-users] Creating topology for Cu-containing enzyme, GROMOS96 force field.

[João M . Damas]

Hi Francesca,

For previous works on copper proteins (
http://pubs.acs.org/doi/abs/10.1021/ct500196e), I have used specbond.dat as
Marlon suggested for coppers bound to the protein. For coppers bound to a
co-factor, I would assume you are building an .itp for the co-factor, so I
would include them directly on that .itp file.

Best,
João

On Wed, Aug 10, 2016 at 8:26 PM, Francesca Lønstad Bleken <
francescal.ble...@sintef.no> wrote:

I am interested in a metalloenzyme with Cu and I have found several studies
> in the literature on systems similar to mine using GROMACS and the Gromos
> force field. I see that GROMOS contains parameters for Cu, and I intend to
> keep the Cu-protein distances for the ligand atoms fixated during MD (as I
> see most of the previous papers have done). However, I do not understand
> how to prepare the topology for the cofactors with Cu, and none of the
> papers discuss this. pdb2gmx does not recognize it and the PRODRG server
> suggested in the excellent tutorial on protein-ligand system does not
> recognize Cu.
> Do you have a suggestion for how to proceed with creating the topology
> including Cu (in one case) and Cu-containing (another case) co-factors?
> Direction towards tutorials that I might have missed are also appreciated.
>
> Kind regards,
> Francesca
> --
> Gromacs Users mailing list
>
> * Please search the archive at http://www.gromacs.org/Support
> /Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
​
-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] GMXSCRIPT: Simple checkpointed Python scripting framework for Gromacs

[João M . Damas]

There is already a similar project going on for a long time:
https://orbeckst.github.io/GromacsWrapper/

Cheers,
João

On Wed, May 4, 2016 at 3:12 AM, Pedro Lacerda <pslacerda+...@gmail.com>
wrote:

> Installation is now working. The upload script was broken.
>
> 2016-05-03 21:50 GMT-03:00 Pedro Lacerda <pslacerda+...@gmail.com>:
>
> > Hi Gromacs users,
> >
> > I just started to develop a scripting framework for Gromacs, it makes
> some
> > assumptions about the directory structure and command parameters. You
> > cannot prepare or run two different systems in the same directory and
> > always pass the -deffnm option to mdrun.
> >
> > It is very nice!
> >
> > Its main goal is to easy the reproduction of simulation protocols,
> > canonical steps used to perform and analyze a simulation. The commands
> are
> > stored in very readable and structured Python file that requires no
> > programming knowledge except syntax. Of course you can always extend it
> > with code as you need.
> >
> > As a bonus it maintain in the .gmx/ directory a checkpoint file that skip
> > previously successful commands if started again. Also there is no need to
> > source GMXRC in common cases.
> >
> > https://github.com/pslacerda/gmx
> >
> > Please make comments, suggestions and critics about GMXSCRIPT. The next
> > feature would be an option to generate a file that allows to reproduce a
> > simulation in any linux computer with Gromacs installed.
> >
> > (apologies for my poor English!)
> >
> > Best regards,
> > Pedro Lacerda
> >
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] why .xtc not generated in 5.1.2?

[João M . Damas]

Please see:
http://manual.gromacs.org/documentation/5.1.2/user-guide/mdp-options.html#output-control

In particular, with nstxout set to 0, the .trr will not be written. See
nstxout-compressed.

Best,
João

On Thu, Mar 3, 2016 at 4:14 PM, Mark Abraham <mark.j.abra...@gmail.com>
wrote:

> Hi,
>
> A tpr file produced from that mdp cannot have written an xtc file with any
> version of GROMACS. You have always needed to use the appropriate mdp file
> options to write a compressed trajectory file.
>
> Mark
>
> On Thu, 3 Mar 2016 15:23 Albert <mailmd2...@gmail.com> wrote:
>
> > Hello:
> >
> > I am using the following md.mdp file for MD production in Gromacs-5.1.2:
> >
> > integrator  = md
> > dt  = 0.002
> > nsteps  = 5000
> > nstlog  = 1
> > nstxout = 0
> > nstvout = 0
> > nstfout = 0
> > nstcalcenergy   = 1000
> > nstenergy   = 1000
> >
> >
> > However, it doesn't generate either .xtc or .trr trajectory file. In my
> > Gromacs-5.0.7 it generate the .xtc trajectory.. I only need the .xtc
> > file and I don't want the .trr trajectory. I am just wondering how shall
> > we configure it in 5.1.2 correctly?
> >
> > Thank you very much
> > --
> > Gromacs Users mailing list
> >
> > * Please search the archive at
> > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> > send a mail to gmx-users-requ...@gromacs.org.
> >
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] REGRESSIONTESTS-5.1.tar.gz

[João M . Damas]

Maybe try this one instead:

https://github.com/gromacs/regressiontests/archive/release-5-1.zip

Cheers,
João

On Sat, Feb 20, 2016 at 6:27 AM, ikrormi rungsung <ikrorm...@gmail.com>
wrote:

> Hi,
>
> I couldn't download REGRESSIONTESTS-5.1.tar.gz from this
> sitegerrit.gromacs.org/download/regressiontests-5.1.tar.gz. Please let me
> know if there is any other sites to get this file.
>
>
>
> *Ikrormi Rungsung*
> *PhD student,*
> *Centre for Bioinformatics,**Pondicherry University, India*
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] supervised MD in Gromacs?

[João M . Damas]

Dear Albert,

Unfortunately, the methods section of some papers does not reflect every
detail of what was done to achieve the results. In the particular case of
computational papers, this means the use of scripting (or even hacking) to
assist a more wide-spread code (like GROMACS). That being said, I do not
know what was done in those papers.

I have not read the papers, but these "supervised" techniques seem fairly
similar to the milestoning ones. Maybe find an alternative there?

Best,
João

On Tue, Dec 8, 2015 at 1:31 PM, Albert <mailmd2...@gmail.com> wrote:

> Thanks a lot for comments.
>
> May I ask what kind of Gromacs utilities should be involved? For sure,
> Gromacs definitely could do this so called "supervised MD", since one of
> the work was claimed done in Gromacs.
>
> Albert
>
>
>
>
> On 12/08/2015 01:45 PM, Vitaly V. Chaban wrote:
>
>> The only thing you need is to arrange the existing gromacs utilities into
>> a
>> script. Python, Perl, Bash languages do this very well.
>>
>>
>> P.S. It is not very honest of the algorithm authors to call it
>> *unconstrained*  while they simply disregard motions that they do not
>> like.
>>
>>
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] GMXLIB does not induce residuetype.dat

[João M . Damas]

The definition seems fine. In the pdb2gmx standard output, you should check
that directory is the one being opened.

If it is, please do a "ls ${GMXLIB}" and check the output, if the file is
there (and not inside the ff directory). Even though I am guessing this is
just a typo problem, and you are using "residuestype.dat" while the file is
"residuetypes.dat".

João

On Sat, Oct 3, 2015 at 4:55 AM, Barnett, James W <jbarn...@tulane.edu>
wrote:

> On Thu, 2015-10-01 at 20:21 +, Ebert Maximilian wrote:
> > Dear list,
> >
> > I have my own force field working folder so I cloned the entire top
> folder to
> > no mess with the original files. I added residues to the residue type
> file to
> > add my residues to the protein group. My FF is included due to the GMXLIB
> > environmental variable but my modified residuestype.dat not. Any idea
> why?
>
> Can you give an example of how it is not included? Is there a specific
> GROMACS
> command that is not finding it, or is it something else?
>
> --
> James “Wes” Barnett, Ph.D. Candidate
> Louisiana Board of Regents Fellow
>
> Chemical and Biomolecular Engineering
> Tulane University
> 341-B Lindy Boggs Center for Energy and Biotechnology
> 6823 St. Charles Ave
> New Orleans, Louisiana 70118-5674
> jbarn...@tulane.edu
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] GMXLIB does not induce residuetype.dat

[João M . Damas]

How are you defining the GMXLIB variable in your script? Please give us
some more information (inputs and outputs) for us to be able to help you.

João

On Thu, Oct 1, 2015 at 9:21 PM, Ebert Maximilian <m.eb...@umontreal.ca>
wrote:

> Dear list,
>
> I have my own force field working folder so I cloned the entire top folder
> to no mess with the original files. I added residues to the residue type
> file to add my residues to the protein group. My FF is included due to the
> GMXLIB environmental variable but my modified residuestype.dat not. Any
> idea why?
>
> Thanks
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Using TIP4P(2005) with GROMOS-53a6

[João M . Damas]

Furthermore, G53a6 (even with SPC) is problematic for helices in proteins.
I would advise you to use the more recent G54a7.

João

On Mon, Sep 14, 2015 at 3:11 PM, Justin Lemkul <jalem...@vt.edu> wrote:

>
>
> On 9/14/15 10:05 AM, Pallavi Banerjee wrote:
>
>> Thanks for your reply, Micholas.
>> Are you sure about that? 'Cause I have found papers that talk about having
>> used other water models with gromos. One such is sort of a motivation for
>> the work I am doing :
>>
>> http://mb.uni-paderborn.de/fileadmin/thet/Publikationen/Veroeffentlichungen/Hydrogel-1.pdf
>>
>>
> AFAIK, no one has examined whether or not GROMOS + TIP4P is valid.  The
> water model is part of the force field, and without examining the force
> field in very well controlled simulations, I would absolutely not dive into
> simulations with water models for which the force field was not
> parametrized.
>
> A quick look at the paper suggests: "The results for OPLS-AA + SPC/E are
> in fair agreement with the experimental results" and even "Note that the
> two force field combinations that predict the correct conformations at 280
> and 360 K are not recommended by their developers. The OPLS force field was
> developed for TIP4P water and G53A6 for SPC water."
>
> Just because an application study arrived at a desirable result *does not*
> mean that the underlying physical model is valid.  You could be getting the
> "right" answer for the wrong reasons.
>
> The combination of OPLS-AA + SPC/E has been studied and found to give
> hydration free energies of amino acid analogs that are in better agreement
> than OPLS/AA + TIP*P models, and SPC/E seems to be a good choice for
> several force fields.  But this is not a choice to be made lightly, and
> just because something is published with a certain combination does not
> make it right.
>
> -Justin
>
> --
> ==
>
> 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
>
> jalem...@outerbanks.umaryland.edu | (410) 706-7441
> http://mackerell.umaryland.edu/~jalemkul
>
> ==
>
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Cyclic peptide by using specbond.dat

[João M . Damas]

--
> Program pdb2gmx, VERSION 5.0.2
> Source code file:
> /build/buildd/gromacs-5.0.2/src/gromacs/gmxpreprocess/pdb2top.cpp, line:
> 1091
>
> *Fatal error:*
> *There is a dangling bond at at least one of the terminal ends. Fix your
> coordinate file, add a new terminal database entry (.tdb), or select the
> proper existing terminal entry.*
> *For more information and tips for troubleshooting, please check the
> GROMACS*
> *website at http://www.gromacs.org/Documentation/Errors
> <http://www.gromacs.org/Documentation/Errors>*
>
>
>
> i hope someone can guide me how excactly the specbond.dat option can use
>
> Ragards,
> Nikhil Maroli
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
> send a mail to gmx-users-requ...@gromacs.org.
>



-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Gromos 53a6, .mdp parameters for reaction field

[João M . Damas]

  = semiisotropic
   ref-p= 1.0  1.0
   tau-p   = 1.0  1.0
   compressibility = 4.5e-5   4.5e-5
  
  
   constraints  = all-bonds
   constraint-algorithm = Lincs
  
  
   gen_vel= yes
   gen_temp= 353
   gen_seed= -1
  
  
   Since the initial structures are the same, I think my parameters for
   reaction field one has problem. I have also tried shorter time steps
   (even
   0.5 fs) and also started from different initial structures but the
   problem
   still exist.
  
   I searched the mailing list but I could not find my answer completely.
   Please let me know if you have any idea about parameters or if you
 have
   any
   .mdp file for reaction field (Gromos 53a6).
  
   Cheers
   Mohsen
   --
   *Rewards work better than punishment ...*
   --
   Gromacs Users mailing list
  
   * Please search the archive at
   http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
   send a mail to gmx-users-requ...@gromacs.org.
  --
  Gromacs Users mailing list
 
  * Please search the archive at
  http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send
  a mail to gmx-users-requ...@gromacs.org.
 
 
 
 
  --
  Rewards work better than punishment ...
 --
 Gromacs Users mailing list

 * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Reference of the algorithm gromos in g_cluster

[João M . Damas]

It's on the second paragraph of the Experimental Section. The entire
paragraph.

Note: the middle of cluster from g_cluster is not the same as the method's
center of cluster.

Best,
João

On Fri, May 1, 2015 at 8:27 AM, Antonio De Nicola adenic...@unisa.it
wrote:

 I used the tool g_cluster of gromacs (4.5.1) to obtain clusters from my
 simulations. As option of g_cluster, you can chose the cluster algorithm
 gromos.

 gromos: use algorithm as described in Daura et al. (Angew. Chem. Int. Ed.
 1999, 38, pp 236-240). Count number of neighbors using cut-off, take
 structure
 with largest number of neighbors with all its neighbors as cluster and
 eliminate it from the pool of clusters. Repeat for remaining structures in
 pool.

 The reference of Daura seems not correct. In such paper  I did not found
 information or description about how the algorithm works.
 Someone has a correct reference or can help me to find it ?

 best,
 Antonio
 --
 Gromacs Users mailing list

 * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] g_cluster (gromos method) creates clusters with members having RMSD greater than the cutoff to the cluster middle

[João M . Damas]

 clusters when I use a
 cutoff of 0.275 nm.

 I understand that some of the members in a cluster can have a pairwise
 RMSD greater than the cutoff, but I thought that the middle of the
 cluster should have an RMSD less than the cutoff to all cluster members.

 Can anybody help me figure out what I am missing?

 Thank you,
 Chris.

 --
 Gromacs Users mailing list

 * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.
 --
 Gromacs Users mailing list

 * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Inconsistency in gmx sasa/g_sas buried SASA?

[João M . Damas]

The formula, following your notation, should be (A+B-AB)/2. The value
you're obtaining is the buried area of protein plus the buried area of the
ligand, hence you need to divide it by two.

The remaining differences from the approach [total-area(ligand) -
exposed-area(ligand)] could be due the probe, which probes differently in
each approach.

If there are still inconsistencies, please let us know.

Best,
João

On Wed, Mar 4, 2015 at 8:48 PM, Leandro Bortot leandro@gmail.com
wrote:

 Dear users,

  I'm trying to calculate how much of a given ligand surface area is
 buried upon binding to a protein.
  I did it before for two proteins by doing three separate calls of gmx
 sasa, each for the surface and output groups System and System of files
 containing protein A, protein B and the AB complex. Then, I used to
 calculate the buried area by doing sasa_A + sasa_B - sasa_AB. However, I
 found some strange values with a protein-ligand system. Can you please
 point me to what I'm doing wrong?


  If I follow the previously stated protocol with pdb files of the
 complex, isolated ligand and isolated receptor, I end with the following
 values for the SASAs: 85.8060, 8.288 and 86.4280 nm^2, respectively. By
 doing the A+B-AB calculation, I get a buried area of 8.9100 nm^2, which
 is actually more than the whole isolated ligand.
  On the other hand, by using the -surface and -output groups System
 and Other, I have the value of 2.970 nm^2 of exposed area for the ligand
 in the complex, which corresponds to a buried area of 5.3180 nm^2, 64% of
 the ligand, which seems reasonable according to visual inspection.

  Why are the values calculated by the two approaches not consistent?
  My first thought was that gmx sasa was not seeing the whole ligand
 in the complex structure, hence the very small increment in the complex
 SASA in comparison with the isolated receptor. However, the results for
 using different -surface and -output groups doesn't agree with that.
  I have the same results with GROMACS 4.6.7 with slightly different
 numerical values, which I assume is due to the changes in the values of
 vdwradii.dat. I get  100% are buried by doing the A+B-AB calculation and
 around 60% when I use System and Other in g_sas.

  I tried using .gro files created from the .pdb by editconf, but
 nothing changed. I cannot afford to generate the tprs because I'm trying to
 use GROMACS to analyse a large number of complexes which came from a
 virtual screening essay.
  The .pdb files are typical, there is nothing strange in them. At least
 as much as I can tell.


  Here are the commands I used, for clarity.

  gmx sasa -f complex.pdb -s complex.pdb -nopbc -o sasa_complex.xvg
 -surface System -output System -xvg none -probe 0.14 -ndots 24
  gmx sasa -f ligand.pdb -s ligand.pdb -nopbc -o sasa_ligand.xvg
 -surface System -output System -xvg none -probe 0.14 -ndots 24
  gmx sasa -f receptor.pdb -s receptor.pdb -nopbc -o
 sasa_receptor.xvg -surface System -output System -xvg none -probe 0.14
 -ndots 24
  gmx sasa -f complex.pdb -s complex.pdb -nopbc -o
 sasa_difference.xvg -surface System -output Other -xvg none -probe 0.14
 -ndots 24


  Any help is greatly appreciated.

 Thank you for your attention,
 Leandro.
 --
 Gromacs Users mailing list

 * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] How to exclude atoms within the same molecule from an rdf.

[João M . Damas]

It's fairly simple: generate a .tpr file with a nrexcl big enough to
exclude self-counts and give it to g_rdf through the -s flag.

João

On Thu, Nov 6, 2014 at 8:42 PM, Stella Nickerson stella.nicker...@gmail.com
 wrote:

 I'm simulating a mixture of molecules (call them Molecules A, B, and C).
 The rdf between A and B and between A and C both look fine, but the one
 between A and A is crazy-looking. I assume this is because it's comparing
 atoms within the same molecule. I can't figure out how to exclude atoms in
 the same molecule from the rdf.

 Thanks,

 Stella
 --
 Gromacs Users mailing list

 * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] numerical matrix from xpm file

[João M . Damas]

://lists.gromacs.org/mailman/listinfo/gmx-users
 Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
 Please don't post (un)subscribe requests to the list. Use the
 www interface or send it to gmx-users-requ...@gromacs.org.
 Can't post? Read http://www.gromacs.org/Support/Mailing_Lists




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] TPI calculation in desired coordinates

[João M . Damas]

Hello Kim,

1. Yes, if you choose the cavity location and radius to be inside the water
slab.

2. the molecule to be inserted and cavity location are two distinct things.
The molecule to be inserted should be found on the .tpr supplied to mdrun
-rerun. The molecule should be centered at 0, 0, 0 because what the tpic
code does while inserting the molecule is to shift the molecule's
position to the inside the cavity you provided by summing a vector
equivalent to the cavity location you supplied (plus a random bit to give a
random location inside the cavity). If the molecule to be inserted is not
centered at 0, 0, 0, it may not be getting inserted where you want it to be
inserted. For Neon, it's trivial to make it centered at 0, 0, 0. ;-)

3. the cavity location, unlike the molecule to be inserted, is provided in
the trajectory. There isn't, up to my knowledge, any tool to do this. So
you have to manually edit the original trajectory (keep the original
though). For each frame, you'll have to insert a final line which will have
the coordinates for the cavity location. You probably will have to convert
your trajectory from binary formats to ASCII formats in order to do that
(extra tip: you can construct a script to give different cavity locations
inside the water slab for each frame).

I hope this helps.

João

On Wed, Oct 8, 2014 at 2:49 AM, Kim Q Hwan kim.qh...@gmail.com wrote:

 Dear all,

 I have simulate confined water between two solid crystals with infinite
 XY-periodic dimension. Now I want to calculate the chemical potential of
 the Neon atom in confined water. I think integrator=tpi option is not
 appropriate due to the two solids, so I am using integrator=tpic option.

 I have questions.

 1. Is integrator=tpic option appropriate option?
 2. GROMACS manual says: The molecule to be inserted should be centered at
 0,0,0”
  Following this manual, should I center the location of the cavity where
 Neon atom will be inserted to 0, 0, 0? What will happen if the location of
 the cavity is not 0, 0, 0?
 3. tpic reads the cavity location from the trajectory. But my simulation
 result surely doesn’t contains Neon atom. Is there any script or g_ utility
 including coordinate of the Neon atom to the .trr file?

 Thank you.
 --
 Kim Q Hwan
 Center of Nano-Liquid
 Department of Physics  Astronomy
 Seoul National University
 Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

 --
 Gromacs Users mailing list

 * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Why should I repeat my simulation?

[João M . Damas]

Some care must be taken with the use of the term replica, due to the
amount of replica-exchange schemes around. The replicate simulations
being talked about here do not imply exchange schemes and different
hamiltonians. Just to make things clearer.

João

On Sun, Oct 5, 2014 at 4:15 PM, massimo sandal deviceran...@gmail.com
wrote:

 On 5 Oct 2014 04:18, Justin Lemkul jalem...@vt.edu wrote:
 
 
 
  On 10/4/14 5:15 PM, fatemeh ramezani wrote:
 
  Dear gmx-users
 
  I performed a MD simulation with gromacs software and after sending my
 results to a journal, referee said
 
  Simulations needs to
  be repeated with different initial velocity (seed) to make sure that the
  results are not simulation artifacts.It is needed to ensure that the
 simulation represents true dynamics
  of the system.
  It is really need to I repeat my simulation (that is very time-consuming
 process) or you can help me to providea compelling reason for not
 repeating.
 
 
  The reviewer is right.  A single simulation is generally insufficient to
 provide convincing evidence of any behavior, unless it is exceptionally
 long and shows, for instance, reversible behavior.  In reality, no
 simulation is probably ever truly converged.  That is why it is standard
 practice to conduct multiple simulations, exactly as the reviewer says.
 One would never perform a single biological assay and claim it to be
 exactly correct, why should one simulation be the exact answer?  Perhaps
 your one simulation would end up being the outlier in a data set.
 
  -Justin
 

 Agree with Justin. At least three replicas should be done. Note also that
 comparing different simulations can tell you more interesting things about
 your system. It's always not only necessary but enriching.

 M.

  --
  ==
 
  Justin A. Lemkul, Ph.D.
  Ruth L. Kirschstein NRSA Postdoctoral Fellow
 
  Department of Pharmaceutical Sciences
  School of Pharmacy
  Health Sciences Facility II, Room 601
  University of Maryland, Baltimore
  20 Penn St.
  Baltimore, MD 21201
 
  jalem...@outerbanks.umaryland.edu | (410) 706-7441
  http://mackerell.umaryland.edu/~jalemkul
 
  ==
 
  --
  Gromacs Users mailing list
 
  * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.
 --
 Gromacs Users mailing list

 * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] TIGER2 implementation in GROMACS

[João M . Damas]

I guess you'll have to become a NAMD person ;-)

On Tue, Sep 23, 2014 at 2:22 PM, João Henriques 
joao.henriques.32...@gmail.com wrote:

 Ok, I see what you mean. Thanks anyway.

 Best regards,
 João

 On Tue, Sep 23, 2014 at 1:49 PM, Mark Abraham mark.j.abra...@gmail.com
 wrote:

  Hi,
 
  I don't know of anyone with such plans. It wouldn't be hard for the right
  person, but that goes for dozens of things such a person could do... :-)
 
  Mark
 
  On Tue, Sep 23, 2014 at 1:46 PM, João Henriques 
  joao.henriques.32...@gmail.com wrote:
 
   Dear all,
  
   Short and fast: I'm interested in using/testing the TIGER2*** method,
   currently implemented in NAMD, but I'm what you would call a GROMACS
   person. Are there any plans to implement it for GROMACS in the near
   future? Is this something that has been discussed among the developers
 at
   some point?
  
   This might come in handy for quite a few other people besides me, thus
 my
   inquiry.
  
   *** Citing the paper: TIGER2 is a next-generation REMD method that
  offers
   more efficient sampling compared to the original REMD method by
 reducing
   the number of replicas required to span a given temperature range.
 DOI:
   10.1016/j.cpc.2010.09.011
  
   Best regards,
   João
   --
   Gromacs Users mailing list
  
   * Please search the archive at
   http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
   send a mail to gmx-users-requ...@gromacs.org.
  
  --
  Gromacs Users mailing list
 
  * Please search the archive at
  http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
  send a mail to gmx-users-requ...@gromacs.org.
 
 --
 Gromacs Users mailing list

 * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] g_sas

[João M . Damas]

 mailing list
  
   * Please search the archive at http://www.gromacs.org/
   Support/Mailing_Lists/GMX-Users_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-users or
   send a mail to gmx-users-requ...@gromacs.org.
  
 
 
  --
  Rajat Desikan (Ph.D Scholar)
  Prof. K. Ganapathy Ayappa's Lab (no 13),
  Dept. of Chemical Engineering,
  Indian Institute of Science, Bangalore
  --
  Gromacs Users mailing list
 
  * Please search the archive at
  http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
  send a mail to gmx-users-requ...@gromacs.org.
 
 --
 Gromacs Users mailing list

 * Please search the archive at
 http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] -inf potential with TPIC

[João M . Damas]

Interesting... Does it also happen on the mu or only on the mu? I ask
this because the mu, unlike the mu, has the volume in it (as per the
Widom insertion equations for the isothermic-isobaric ensemble). If the
-inf is only on the mu, I'd suggest checking the volume along the
trajectory (using g_energy, for example, or check the .xvg file from the
-tpi flag, which already has the volume, I think). Check the post-processed
trajectory that you feed mdrun -rerun, as your trajectory-processing script
for TPIC may be doing something strange to the box size.

I recognize that the single/double-precision is intriguing, if indeed the
problem is the volume.

João

On Fri, Jun 13, 2014 at 11:10 PM, Rafael I. Silverman y de la Vega 
rsilv...@ucsc.edu wrote:

 Hi João,
 I dont think its an excessive number of unfavorable insertions. The mu
 getting output with double precision are
 Reading frame  40 time 1770.000   mu -6.570e+01 mu -7.654e+01
 Reading frame  50 time 1775.000   mu -4.985e+01 mu -7.609e+01
 Reading frame  60 time 1780.000   mu -7.010e+01 mu -7.571e+01
 Reading frame  70 time 1785.000   mu -5.669e+01 mu -7.540e+01
 Reading frame  80 time 1790.000   mu -4.749e+01 mu -7.511e+01
 Reading frame  90 time 1795.000   mu -7.355e+01 mu -7.590e+01

 to give a fairly representative sample. So, no, they arent near 100, and
 are negative... And the issue seems to happen with later insertions, not
 the first few... One run I just did, only the very last average mu was
 -inf, (not even the mu for that frame, just the average mu after that
 frame) which really seems to imply some sort of overflow problem

 Reading frame 180 time 1790.000   mu -1.284e+02 mu -1.153e+02
 Reading frame 190 time 1795.000   mu -7.920e+01 mu   -inf
 (not the same run as above, this was run in single precision)


 On Thu, Jun 12, 2014 at 7:06 AM, João M. Damas jmda...@itqb.unl.pt
 wrote:

  Hello Rafael,
 
  High energies (energy differences) are not discarded. When summing them
  through the exponential of their negative, they contribute very little to
  the final sum (lower energies dominate the sum). Hence, they are
  discarded.
 
  The -inf value on the mu standard error output is normal because,
 unlike
  the -tpi output, there is no ternary operator checking if the sum of
  exponentials is equal to zero (when it is, the log of zero gives you the
  inf value).
 
  The change to the double precision not giving you the -inf also makes
  sense, because the sum of exponentials, which on single-precision was
 zero,
  can now be non-zero due to the higher number of decimal places on
  double-precision. I am guessing with double-precision you are getting
 very
  high positive numbers (energies) for the mu, around 1000 maybe?
 
  My interpretation is that it is hard to find a favorable place to
 insert
  the water molecule in that cavity, at least with a few frames. I am
  guessing that with more and more frames, that may change, which is
 natural.
 
  I hope this has helped.
 
  Cheers,
  João
 
 
 
  On Thu, Jun 12, 2014 at 10:45 AM, Justin Lemkul jalem...@vt.edu wrote:
 
  
  
   On 6/11/14, 8:55 PM, Rafael I. Silverman y de la Vega wrote:
  
   I mistyped amber, when I should have typed charmm, amber is totally
   uninvolved in  my calculations. I used the script from
   http://www.gromacs.org/Downloads/User_contributions/Other_software
  titled
   charmm2gromacs. The output looked fine after running it.
  
   And, I doubt its the cofactor,  just ran the insertion with double
   precision mdrun, it gave reasonable looking results. There seems to be
   some
   sort of issue with unreasonable interaction energies not being
 discarded
   properly.
  
  
   It's entirely possible that there's something wrong with the tpic code;
   you can certainly file a bug report on Redmine with input files to
   reproduce it.
  
  
   -Justin
  
  
   On Tue, Jun 10, 2014 at 3:41 PM, Justin Lemkul jalem...@vt.edu
 wrote:
  
  
  
   On 6/10/14, 6:14 PM, Rafael I. Silverman y de la Vega wrote:
  
I meant that I only changed to cofactor to gromacs chamm27 format,
 not
   amber format. I used charmm27 for the apoprotein as well as the
   cofactor.
  
  
What script did you use?  I don't understand why Amber99SB is
  involved
   here, so I don't know exactly what you were doing to create the
  topology.
 It may not end up being useful information, but it's important to
   establish the validity of the underlying physical model.
  
  
   -Justin
  
  
On Tue, Jun 10, 2014 at 3:09 PM, Justin Lemkul jalem...@vt.edu
  wrote:
  
  
  
   On 6/10/14, 6:04 PM, Rafael I. Silverman y de la Vega wrote:
  
 you think it was the cofactor model?
  
  
  
 If you're using a CHARMM-parametrized cofactor with an Amber99SB
  
   protein,
   I'd say the simulations are wholly unreliable.  It's certainly the
 #1
   likely cause for nonsensical results.  If you want to get to the
 root
   of
   the issue, you need to start

Re: [gmx-users] -inf potential with TPIC

[João M . Damas]

 have no experience with TPIC, but if you post
 more

 detailed
 information about what you're doing and which Gromacs version
 you're
 using,
 you're more likely to get some suggestions.

 -Justin

 --
 ==

 Justin A. Lemkul, Ph.D.
 Ruth L. Kirschstein NRSA Postdoctoral Fellow

 Department of Pharmaceutical Sciences
 School of Pharmacy
 Health Sciences Facility II, Room 601
 University of Maryland, Baltimore
 20 Penn St.
 Baltimore, MD 21201

 jalem...@outerbanks.umaryland.edu | (410) 706-7441
 http://mackerell.umaryland.edu/~jalemkul

 ==
 --
 Gromacs Users mailing list

 * Please search the archive at http://www.gromacs.org/
 Support/Mailing_Lists/GMX-Users_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-users
 or
 send a mail to gmx-users-requ...@gromacs.org.




 --

  ==


 Justin A. Lemkul, Ph.D.
 Ruth L. Kirschstein NRSA Postdoctoral Fellow

 Department of Pharmaceutical Sciences
 School of Pharmacy
 Health Sciences Facility II, Room 601
 University of Maryland, Baltimore
 20 Penn St.
 Baltimore, MD 21201

 jalem...@outerbanks.umaryland.edu | (410) 706-7441
 http://mackerell.umaryland.edu/~jalemkul

 ==
 --
 Gromacs Users mailing list

 * Please search the archive at http://www.gromacs.org/
 Support/Mailing_Lists/GMX-Users_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-users
 or
 send a mail to gmx-users-requ...@gromacs.org.


   --

 ==

 Justin A. Lemkul, Ph.D.
 Ruth L. Kirschstein NRSA Postdoctoral Fellow

 Department of Pharmaceutical Sciences
 School of Pharmacy
 Health Sciences Facility II, Room 601
 University of Maryland, Baltimore
 20 Penn St.
 Baltimore, MD 21201

 jalem...@outerbanks.umaryland.edu | (410) 706-7441
 http://mackerell.umaryland.edu/~jalemkul

 ==
 --
 Gromacs Users mailing list

 * Please search the archive at http://www.gromacs.org/
 Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.


  --
 ==

 Justin A. Lemkul, Ph.D.
 Ruth L. Kirschstein NRSA Postdoctoral Fellow

 Department of Pharmaceutical Sciences
 School of Pharmacy
 Health Sciences Facility II, Room 601
 University of Maryland, Baltimore
 20 Penn St.
 Baltimore, MD 21201

 jalem...@outerbanks.umaryland.edu | (410) 706-7441
 http://mackerell.umaryland.edu/~jalemkul

 ==
 --
 Gromacs Users mailing list

 * Please search the archive at http://www.gromacs.org/
 Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.


 --
 ==

 Justin A. Lemkul, Ph.D.
 Ruth L. Kirschstein NRSA Postdoctoral Fellow

 Department of Pharmaceutical Sciences
 School of Pharmacy
 Health Sciences Facility II, Room 601
 University of Maryland, Baltimore
 20 Penn St.
 Baltimore, MD 21201

 jalem...@outerbanks.umaryland.edu | (410) 706-7441
 http://mackerell.umaryland.edu/~jalemkul

 ==
 --
 Gromacs Users mailing list

 * Please search the archive at http://www.gromacs.org/
 Support/Mailing_Lists/GMX-Users_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-users or
 send a mail to gmx-users-requ...@gromacs.org.




-- 
João M. Damas
PhD Student
Protein Modelling Group
ITQB-UNL, Oeiras, Portugal
Tel:+351-214469613
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_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-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] g_sas: unable to reproduce data from original article of the DCLM (Eisenhaber1995)

[João M . Damas]

Sorry, I shouldn't have embedded the plot. Here goes a link to it:

https://dl.dropboxusercontent.com/u/384/plot_fixed_vs_nonfixed_g_sas.png


On Wed, Mar 5, 2014 at 2:27 AM, João M. Damas jmda...@itqb.unl.pt wrote:

 Thanks to Teemu, we found that the -pbc yes results is not a bug after
 all (my bad). It is solved here: http://redmine.gromacs.org/issues/1449.
 The final results are in Attached Table 4.

 To conclude, going back to the -nopbc bug found, the following plot is a
 real case example of the difference one can see between a fixed and a
 non-fixed g_sas run. I plot the contact area [there are several ways to
 calculate this, I show one of them] between a ligand and a protein along
 simulation time. Negative contact areas and the spikes were the puzzling
 results I mentioned in the beginning of this thread.

 [image: Inline image 1]

 I would like to thanks David and Teemu for their help on this matter.

 Best,
 João

 --
 Attached Table 4
 met  - method used, anl=analytical method, num=numerical method (DCLM)
 dots - number of points used for the numerical method
 src  - source of the data, paper=Eisenhaber1995, ASC=ASC software,
g463{sp,fx}=g_sas of GMX4.6.3 {single precision,fix 
 3199https://gerrit.gromacs.org/#/c/3199/
 }

 pbc  - PBC flag for g_sas, yes=-pbc, no=-nopbc
 Areas are in square angstrom
  ==
   met  dots src  pbc  4PTI  3FXN  1TIM
 ==
   anl paper3973.80   6943.80  20002.80
   anl   ASC3973.81   6943.80  20002.80

   num   122   paper3961.40   6968.30  19970.90
   num   122 ASC3961.44   6968.33  19970.90
   num   122  g463sp  yes   3957.81   6955.99  20004.20

   num   122  g463sp   no   4169.21   7731.63  24080.20
num   122  g463fx  yes   3957.81   6955.99  20004.20

   num   122  g463fx   no   3957.81   6955.99  20004.20

   num   362   paper3971.80   6933.40  19997.10
   num   362 ASC3971.79   6933.37  19997.10
num   362  g463sp  yes   3969.92   6936.20  20016.70

   num   362  g463sp   no   4195.02   7704.70  24132.10
   num   362  g463fx  yes   3969.92   6936.20  20016.70

   num   362  g463fx   no   3969.92   6936.20  20016.70

   num   642   paper3967.90   6944.40  19998.70
   num   642 ASC3967.78   6944.37  19998.70
   num   642  g463sp  yes   3966.21   6941.26  20013.40
   num   642  g463sp   no   4188.63   7701.99  24119.00
   num   642  g463fx  yes   3966.21   6941.26  20013.40
   num   642  g463fx   no   3966.21   6941.26  20013.40


   num  1002   paper3974.10   6939.10  20012.20
   num  1002 ASC3974.07   6939.12  20012.20
num  1002  g463sp  yes   3973.51   6939.81  20027.50
   num  1002  g463sp   no   4193.60   7700.78  24143.10
   num  1002  g463fx  yes   3973.51   6939.81  20027.50
   num  1002  g463fx   no   3973.51   6939.81  20027.50


   num  1472   paper3975.70   6943.30  19997.00
   num  1472 ASC3975.70   6943.35  19996.90
   num  1472  g463sp  yes   3975.88   6943.96  20012.40

   num  1472  g463sp   no   4198.08   7709.30  24123.30
num  1472  g463fx  yes   3975.88   6943.96  20012.40

   num  1472  g463fx   no   3975.88   6943.96  20012.40
 ==


 On Tue, Mar 4, 2014 at 4:05 PM, João M. Damas jmda...@itqb.unl.pt wrote:

 Done: http://redmine.gromacs.org/issues/1449

 João


 On Tue, Mar 4, 2014 at 6:56 AM, David van der Spoel sp...@xray.bmc.uu.se
  wrote:

 On 2014-03-04 04:39, João M. Damas wrote:

 Hello Teemu,

 Thank you! I am glad the GROMACS team is concerned about this particular
 problem.
 And I am sorry for my late reply.

 For the sake of conciseness, so we do not get lost in the data, I am
 only
 showing the single precision results (we may bring double precision
 later
 on again). Also, since GROMACS 4.0.4 is flawed in the -pbc flag, as
 Teemu
 said, I also excluded it from these results (it is not going to get
 corrected anyway).

 I compiled a GROMACS version 4.6.3 with the fix presented in
 https://gerrit.gromacs.org/#/c/3199/ (in single precision).

 I repeated the tests and the results are presented in Attached Table 3.

 - the fix brings the -nopbc results close (within 1 square
 angstrom) to

 the ones obtained by ASC, except for 1TIM where the difference is
 within
 10-20 square angstrom. Maybe 1TIM has a difficult shape, because
 ASC also
 had the largest difference between numerical DCLM and the
 analytical method
 in this protein.
 - the -pbc yes results though, do not change (which is normal,

 considering the flag is working in this version and the fix is
 inside a
 conditional expression that depends on the -pbc flag). It continues
 to
 baffle me why this is happening. If the molecule is inside the box
 and far
 from the edges (again, a test using a .gro created

Re: [gmx-users] g_sas: unable to reproduce data from original article of the DCLM (Eisenhaber1995)

[João M . Damas]

Done: http://redmine.gromacs.org/issues/1449

João


On Tue, Mar 4, 2014 at 6:56 AM, David van der Spoel sp...@xray.bmc.uu.sewrote:

 On 2014-03-04 04:39, João M. Damas wrote:

 Hello Teemu,

 Thank you! I am glad the GROMACS team is concerned about this particular
 problem.
 And I am sorry for my late reply.

 For the sake of conciseness, so we do not get lost in the data, I am only
 showing the single precision results (we may bring double precision later
 on again). Also, since GROMACS 4.0.4 is flawed in the -pbc flag, as Teemu
 said, I also excluded it from these results (it is not going to get
 corrected anyway).

 I compiled a GROMACS version 4.6.3 with the fix presented in
 https://gerrit.gromacs.org/#/c/3199/ (in single precision).

 I repeated the tests and the results are presented in Attached Table 3.

 - the fix brings the -nopbc results close (within 1 square angstrom)
 to

 the ones obtained by ASC, except for 1TIM where the difference is
 within
 10-20 square angstrom. Maybe 1TIM has a difficult shape, because ASC
 also
 had the largest difference between numerical DCLM and the analytical
 method
 in this protein.
 - the -pbc yes results though, do not change (which is normal,

 considering the flag is working in this version and the fix is inside
 a
 conditional expression that depends on the -pbc flag). It continues to
 baffle me why this is happening. If the molecule is inside the box
 and far
 from the edges (again, a test using a .gro created by editconf -d 5
 gave
 the same exact table as Attached Table 3), I see no reason why these
 results should be different...

 So, I think Bug #1445 http://redmine.gromacs.org/issues/1445 is indeed

 solved, but we still need to solve an unknown bug with -pbc yes. Should
 I
 open a new bug related to this in the redmine?


 In short, yes. If the protein is in the center of the box with no periodic
 contacts the result should be the same as without pbc.


 I can perform more tests, if anyone has more ideas.

 Best,
 João

 --
 Attached Table 3
 met  - method used, anl=analytical method, num=numerical method (DCLM)
 dots - number of points used for the numerical method
 src  - source of the data, paper=Eisenhaber1995, ASC=ASC software,
 g463{sp,fx}=g_sas of GMX4.6.3 {single precision,fix
 3199https://gerrit.gromacs.org/#/c/3199/

 }
 pbc  - PBC flag for g_sas, yes=-pbc, no=-nopbc
 Areas are in square angstrom
 ==
met  dots src  pbc  4PTI  3FXN  1TIM
 ==
anl paper3973.80   6943.80  20002.80
anl   ASC3973.81   6943.80  20002.80

num   122   paper3961.40   6968.30  19970.90
num   122 ASC3961.44   6968.33  19970.90
num   122  g463sp  yes   3825.86   6257.83  19867.90
num   122  g463sp   no   4169.21   7731.63  24080.20
num   122  g463fx  yes   3825.86   6257.83  19867.90
num   122  g463fx   no   3957.81   6955.99  20004.20

num   362   paper3971.80   6933.40  19997.10
num   362 ASC3971.79   6933.37  19997.10
num   362  g463sp  yes   3838.35   6248.43  19886.80
num   362  g463sp   no   4195.02   7704.70  24132.10
num   362  g463fx  yes   3838.35   6248.43  19886.80
num   362  g463fx   no   3969.92   6936.20  20016.70

num   642   paper3967.90   6944.40  19998.70
num   642 ASC3967.78   6944.37  19998.70
num   642  g463sp  yes   3831.64   6255.64  19882.70
num   642  g463sp   no   4188.63   7701.99  24119.40
num   642  g463fx  yes   3831.64   6255.64  19882.70
num   642  g463fx   no   3966.21   6941.26  20013.60

num  1002   paper3974.10   6939.10  20012.20
num  1002 ASC3974.07   6939.12  20012.20
num  1002  g463sp  yes   3840.58   6250.14  19897.40
num  1002  g463sp   no   4193.60   7700.64  24143.10
num  1002  g463fx  yes   3840.58   6250.14  19897.40
num  1002  g463fx   no   3973.51   6939.68  20027.50

num  1472   paper3975.70   6943.30  19997.00
num  1472 ASC3975.70   6943.35  19996.90
num  1472  g463sp  yes   3841.69   6256.92  19882.80
num  1472  g463sp   no   4198.08   7709.30  24123.30
num  1472  g463fx  yes   3841.69   6256.92  19882.80
num  1472  g463fx   no   3975.88   6943.96  20012.40
 ==




 On Fri, Feb 28, 2014 at 4:49 AM, Teemu Murtola teemu.murt...@gmail.com
 wrote:

  Hi,

 On Thu, Feb 27, 2014 at 4:09 PM, Teemu Murtola teemu.murt...@gmail.com

 wrote:


  I'll post additional information once I have had time to test more
 cases.


 I have now created http://redmine.gromacs.org/issues/1445 to track the
 issue, and uploaded a fix to Gerrit: https://gerrit.gromacs.org/#/
 c/3199/

 .

 My current set of tests is here: https://gerrit.gromacs.org/#/c/3200

[gmx-users] g_sas: unable to reproduce data from original article of the DCLM (Eisenhaber1995)

[João M . Damas]

Dear all,

I have been having some puzzling results when using g_sas to analyze some
trajectories, so I have decided to go back to basics.

As described in the documentation, g_sas implements the double cubic
lattice method (DCLM) originally presented in Eisenhaber1995 (doi:
10.1002/jcc.540160303 http://dx.doi.org/10.1002/jcc.540160303). Table I
of that article shows a test case of three proteins (PDB code: 4PTI, 3FXN
and 1TIM), where the DCLM (numerical method) at different point densities
is compared against an analytic method (also by Eisenhaber, citation 30).

My question was: can g_sas reproduce the areas reported in Table I of
Eisenhaber1995?

First of all, I went on to reproduce the reported areas with the software
originally developed by Eisenhaber, which has both the analytical and
numerical (DCLM) methods implemented - ASC software. As it can be seen in
Attached Table (see below), running ASC provided results very similar (to
the tenths of square angstrom), if not equal, to the reported ones. Besides
assessing the reported areas, I now have a software which allows me to
benchmark other cases.

The next step was answering my question. For that, I had to make sure g_sas
was performing the same calculation as ASC software:

   - Both ASC and g_sas took the same input structures (only using the ATOM
   records). In the case of g_sas, I had to build a .tpr file for the -s flag
   of g_sas, which was done using pdb2gmx+grompp. Like with the ASC, the g_sas
   calculation was done using only the heavy atoms (using the Protein-H group
   for calculation and output groups).
   - The radii used also had to be the same for both ASC and g_sas. g_sas
   is still using the vdwradii.dat, so I created a new vdwradii.dat file with
   the EisenbergMcLachlan radii that are used in the ASC calculations (both
   mine and the reported ones). The radii were correctly attributed to the
   atoms, as checked in the g_sas.log file outputted by the debug mode.
   - In both cases the probe radius was 1.4 angstroms (0.14 nm as per g_sas
   input).

The area calculations were then performed using g_sas (number of points
used were provided using the -ndots flag). Originally, I used GROMACS
4.0.4, but afterwards I also performed the calculations using GROMACS
4.6.3. Results are presented in Attached Table (see below).

   - GROMACS 4.0.4 g_sas DCLM overestimates the area by about 5, 10 and 20%
   for 4PTI, 3FXN and 1TIM, respectively, in relation to ASC DCLM. This is
   also the same overestimation of the areas obtained through an analytical
   method, since ASC DCLM gives a good estimation of the analytical ones,
   unlike g_sas.
   - On the other hand, GROMACS 4.6.3 g_sas DCLM underestimates the area by
   about 3, 10 and 0.5% for 4PTI, 3FXN and 1TIM, respectively, in relation to
   ASC DCLM. I have checked that this different behavior appeared from the
   4.0.X to the 4.5.X versions. This is odd since I have searched the release
   notes for g_sas and I haven't found any change in this tool... Maybe this
   is a clue to what is going on?
   - From my understanding, DCLM implemented on ASC or on g_sas shouldn't
   give different results. Moreover, even if there could be some differences
   when using a low number of points (due some factor of randomness I may not
   be aware), this difference should have already vanished when using more
   than 1000 points per atom. Take note that increasing the number of points
   in g_sas does not give areas nearer the analytical results (hence, more
   dots may not mean more accuracy, maybe this is the reason 24 is the default
   number...). Can anyone point me out on some mistake I may be doing? Maybe
   there is a factor that I may be disregarding...

I have some data which point out that these differences (errors?) may lead
to very large errors when calculating properties like buried/contact areas,
specially if the buried/contact areas have different magnitudes from the
molecule's areas. But this may be the theme of a another/follow-up e-mail
when I get ASC working on my trajectories.

Best regards,
João M. Damas

--
Attached Table
met  - method used, anl=analytical method, num=numerical method (DCLM)
dots - number of points used for the numerical method
src  - source of the data, paper=Eisenhaber1995, ASC=ASC software,
gmx404=g_sas of GMX4.0.4,
   gmx463=g_sas of GMX4.6.3
Areas are in square angstroms
==
  met  dots src  4PTI  3FXN  1TIM
==
  anl paper   3973.80   6943.80  20002.80
  anl   ASC   3973.81   6943.80  20002.80

  num   122   paper   3961.40   6968.30  19970.90
  num   122 ASC   3961.44   6968.33  19970.90
  num   122  gmx404   4165.31   7727.73  24110.10
  num   122  gmx463   3825.86   6257.83  19867.90

  num   362   paper   3971.80   6933.40  19997.10
  num   362 ASC   3971.79   6933.37  19997.10
  num   362  gmx404   4192.12

Re: [gmx-users] g_sas: unable to reproduce data from original article of the DCLM (Eisenhaber1995)

[João M . Damas]

  g404dp   no   4197.79   7709.92  24153.90
  num  1472  g463sp  yes   3841.69   6256.92  19882.80
  num  1472  g463sp   no   4198.08   7709.30  24123.30
  num  1472  g463dp  yes   3842.52   6259.11  19882.70
  num  1472  g463dp   no   4198.54   7708.29  24123.50
==


On Sat, Feb 22, 2014 at 9:13 PM, David van der Spoel
sp...@xray.bmc.uu.sewrote:

 On 2014-02-22 18:34, João M. Damas wrote:

 Dear all,

 I have been having some puzzling results when using g_sas to analyze some
 trajectories, so I have decided to go back to basics.

 As described in the documentation, g_sas implements the double cubic
 lattice method (DCLM) originally presented in Eisenhaber1995 (doi:
 10.1002/jcc.540160303 http://dx.doi.org/10.1002/jcc.540160303). Table I

 of that article shows a test case of three proteins (PDB code: 4PTI, 3FXN
 and 1TIM), where the DCLM (numerical method) at different point densities
 is compared against an analytic method (also by Eisenhaber, citation 30).

 My question was: can g_sas reproduce the areas reported in Table I of
 Eisenhaber1995?

 First of all, I went on to reproduce the reported areas with the software
 originally developed by Eisenhaber, which has both the analytical and
 numerical (DCLM) methods implemented - ASC software. As it can be seen in
 Attached Table (see below), running ASC provided results very similar (to
 the tenths of square angstrom), if not equal, to the reported ones.
 Besides
 assessing the reported areas, I now have a software which allows me to
 benchmark other cases.

 The next step was answering my question. For that, I had to make sure
 g_sas
 was performing the same calculation as ASC software:

 - Both ASC and g_sas took the same input structures (only using the
 ATOM

 records). In the case of g_sas, I had to build a .tpr file for the -s
 flag
 of g_sas, which was done using pdb2gmx+grompp. Like with the ASC, the
 g_sas
 calculation was done using only the heavy atoms (using the Protein-H
 group
 for calculation and output groups).
 - The radii used also had to be the same for both ASC and g_sas. g_sas

 is still using the vdwradii.dat, so I created a new vdwradii.dat file
 with
 the EisenbergMcLachlan radii that are used in the ASC calculations
 (both
 mine and the reported ones). The radii were correctly attributed to
 the
 atoms, as checked in the g_sas.log file outputted by the debug mode.
 - In both cases the probe radius was 1.4 angstroms (0.14 nm as per
 g_sas

 input).

 The area calculations were then performed using g_sas (number of points
 used were provided using the -ndots flag). Originally, I used GROMACS
 4.0.4, but afterwards I also performed the calculations using GROMACS
 4.6.3. Results are presented in Attached Table (see below).

 - GROMACS 4.0.4 g_sas DCLM overestimates the area by about 5, 10 and
 20%

 for 4PTI, 3FXN and 1TIM, respectively, in relation to ASC DCLM. This
 is
 also the same overestimation of the areas obtained through an
 analytical
 method, since ASC DCLM gives a good estimation of the analytical ones,
 unlike g_sas.
 - On the other hand, GROMACS 4.6.3 g_sas DCLM underestimates the area
 by

 about 3, 10 and 0.5% for 4PTI, 3FXN and 1TIM, respectively, in
 relation to
 ASC DCLM. I have checked that this different behavior appeared from
 the
 4.0.X to the 4.5.X versions. This is odd since I have searched the
 release
 notes for g_sas and I haven't found any change in this tool... Maybe
 this
 is a clue to what is going on?
 - From my understanding, DCLM implemented on ASC or on g_sas shouldn't

 give different results. Moreover, even if there could be some
 differences
 when using a low number of points (due some factor of randomness I
 may not
 be aware), this difference should have already vanished when using
 more
 than 1000 points per atom. Take note that increasing the number of
 points
 in g_sas does not give areas nearer the analytical results (hence,
 more
 dots may not mean more accuracy, maybe this is the reason 24 is the
 default
 number...). Can anyone point me out on some mistake I may be doing?
 Maybe
 there is a factor that I may be disregarding...

 I have some data which point out that these differences (errors?) may lead
 to very large errors when calculating properties like buried/contact
 areas,
 specially if the buried/contact areas have different magnitudes from the
 molecule's areas. But this may be the theme of a another/follow-up e-mail
 when I get ASC working on my trajectories.

 Best regards,
 João M. Damas

 --
 Attached Table
 met  - method used, anl=analytical method, num=numerical method (DCLM)
 dots - number of points used for the numerical method
 src  - source of the data, paper=Eisenhaber1995, ASC=ASC software,
 gmx404=g_sas of GMX4.0.4,
 gmx463=g_sas of GMX4.6.3
 Areas are in square angstroms