Re: [gmx-users] REMD: NPT being +-Infinity or NaN

[Justin A. Lemkul]

杜波 wrote:

dear teacher,
when i do remd  in the  npt ensemble.

REMD: NPT -replex 4000
dt= 0.0001

step 172000, will finish Sat Dec 31 18:44:12 2011

---
Program mdrun_mpi_4.5.5, VERSION 4.5.5
Source code file: nsgrid.c, line: 549

Range checking error:
Explanation: During neighborsearching, we assign each particle to a grid
based on its coordinates. If your system contains collisions or parameter
errors that give particles very high velocities you might end up with some
coordinates being +-Infinity or NaN (not-a-number). Obviously, we cannot
put these on a grid, so this is usually where we detect those errors.
Make sure your system is properly energy-minimized and that the potential
energy seems reasonable before trying again.

how could  i do except using the small dt ? 



Your system is not stable, as is often the case with NPT REMD at high 
temperature.

http://www.gromacs.org/Documentation/Terminology/Blowing_Up

-Justin

--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


--
gmx-users mailing listgmx-users@gromacs.org
http://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

[gmx-users] REMD: NPT being +-Infinity or NaN

[杜波]

dear teacher,
when i do remd  in the  npt ensemble.

REMD: NPT -replex 4000
dt= 0.0001

step 172000, will finish Sat Dec 31 18:44:12 2011

---
Program mdrun_mpi_4.5.5, VERSION 4.5.5
Source code file: nsgrid.c, line: 549

Range checking error:
Explanation: During neighborsearching, we assign each particle to a grid
based on its coordinates. If your system contains collisions or parameter
errors that give particles very high velocities you might end up with some
coordinates being +-Infinity or NaN (not-a-number). Obviously, we cannot
put these on a grid, so this is usually where we detect those errors.
Make sure your system is properly energy-minimized and that the potential
energy seems reasonable before trying again.

how could  i do except using the small dt ?

thanks!
Bo Du
Department of Polymer Science and Engineering,
School of Chemical Engineering and technology,
Tianjin University, Weijin Road 92, Nankai District 300072,
Tianjin City P. R. China
Tel/Fax: +86-22-27404303 ; +8613820062885
E-mail: 2008d...@gmail.com ; dubo2...@tju.edu.cn
-- 
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] Re: gmx-users Dipole

[HAO JIANG]

Is the total dipole moment stored in the energy file of Gromacs 3.3 correct?

Thanks.

Hao


-Original Message- 
From: David van der Spoel

Sent: Sunday, November 27, 2011 9:36 AM
To: Discussion list for GROMACS users
Subject: Re: [gmx-users] Re: gmx-users Dipole

On 11/27/11 3:26 PM, Dr. Vitaly V. Chaban wrote:


Dear All,

Is there a way to let GROMACS to calculate and write the total dipole 
moment on-the-fly?


I realize that g_dipoles can be used to calculate the total dipole moment 
using a stored trajectory. However, for a large system it is not very 
feasible to write the trajectory at a frequency good enough for spectra 
analysis.


Thanks.


I don't think such way exists, unless you insert the dipole
calculation subroutine into the main code. All gromacs analysis tools
imply postprocessing of the generated trajectories. In certain cases
(e.g. when velocities or forces should be analyzed), this is not
perfect, of course.


This is  stored in the energy file still, but THE NUMBERS ARE INCORRECT
since gromacs 4.0.
See http://redmine.gromacs.org/issues/620

--
David.

David van der Spoel, PhD, Professor of Biology
Dept. of Cell and Molecular Biology, Uppsala University.
Husargatan 3, Box 596,  75124 Uppsala, Sweden
phone: 46 18 471 4205 fax: 46 18 511 755
sp...@xray.bmc.uu.se sp...@gromacs.org   http://folding.bmc.uu.se

--
gmx-users mailing listgmx-users@gromacs.org
http://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

--
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] Pme on gpu performance

[Szilárd Páll]

Hi,

4.6 will support only CUDA.

OpenCL GPU implementations have yet match CUDA; on CPU it would hardly
match the performance of the hand-tuned SSE kernels, moreover, CPU &
GPU algorithms are not the same.

--
Szilárd



On Sun, Nov 27, 2011 at 11:25 PM, Alexey Shvetsov
 wrote:
> Hi!
>
> Will it use CUDA or OpenCL? Second one will be more common since it will
> work with wider range of platfroms (cpu, gpu, fcpga)
>
> Szilárd Páll писал 27.11.2011 23:50:
>>
>> Native acceleration = not relying on external libraries. ;)
>>
>> --
>> Szilárd
>>
>>
>>
>> On Sun, Nov 27, 2011 at 9:33 PM, Peter C. Lai  wrote:
>>>
>>> Random hijack:
>>>
>>> Will the CUDA acceleration support CMAP or will it still be limited to
>>> the limitations of OpenMM that it currently has?
>>>
>>> On 2011-11-27 12:10:47PM -0600, Szilárd Páll wrote:

 Hi Andrzej,

 GROMACS 4.6 is work in progress, it will have native CUDA acceleration
 with multi-GPU support along a few other improvements. You can expect
 a speedup in the ballpark of 3x. We will soon have the code available
 for testing.

 I'm a little skeptical about the 5x of ACEMD. What setting did you
 use? AFAIR they were using large time-steps without contraints in
 their benchmarks.

 Cheers,
 --
 Szilárd



 On Thu, Nov 24, 2011 at 9:53 AM, Andrzej Rzepiela
  wrote:
 > Dears,
 >
 > I would like to ask what performance improvement is expected for
 > future
 > releases (e.g. 4.6) for PME calculations on gpu cards. Last week I
 > sent
 > benchmark results for dhfr to the list, which show no performance gain
 > when
 > the newest versions of tesla cards vs intel xeon R are used (more or
 > less in
 > agreement of what is presented on the gromacs website). However, for
 > the
 > same system  simulations with different gpu code, acemd,  on a very
 > similar
 > machine can be about 5 times faster, as benchmarked recently by my
 > colleagues, suggesting that performance of gromacs may soon improve.
 > is that
 > correct ?
 >
 >
 > Andrzej
 > --
 > gmx-users mailing list    gmx-users@gromacs.org
 > http://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 thewww
 > interface
 > or send it to gmx-users-requ...@gromacs.org.
 > Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
 >
 --
 gmx-users mailing list    gmx-users@gromacs.org
 http://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
>>>
>>> --
>>> ==
>>> Peter C. Lai                    | University of Alabama-Birmingham
>>> Programmer/Analyst              | KAUL 752A
>>> Genetics, Div. of Research      | 705 South 20th Street
>>> p...@uab.edu                     | Birmingham AL 35294-4461
>>> (205) 690-0808                        |
>>> ==
>>>
>>> --
>>> gmx-users mailing list    gmx-users@gromacs.org
>>> http://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
>>>
>
> --
> Best Regards,
> Alexey 'Alexxy' Shvetsov
> Petersburg Nuclear Physics Institute, Russia
> Department of Molecular and Radiation Biophysics
> Gentoo Team Ru
> Gentoo Linux Dev
> mailto:alexx...@gmail.com
> mailto:ale...@gentoo.org
> mailto:ale...@omrb.pnpi.spb.ru
> --
> gmx-users mailing list    gmx-users@gromacs.org
> http://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
>
--
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] Pme on gpu performance

[Alexey Shvetsov]

Hi!

Will it use CUDA or OpenCL? Second one will be more common since it 
will work with wider range of platfroms (cpu, gpu, fcpga)


Szilárd Páll писал 27.11.2011 23:50:

Native acceleration = not relying on external libraries. ;)

--
Szilárd



On Sun, Nov 27, 2011 at 9:33 PM, Peter C. Lai  wrote:

Random hijack:

Will the CUDA acceleration support CMAP or will it still be limited 
to

the limitations of OpenMM that it currently has?

On 2011-11-27 12:10:47PM -0600, Szilárd Páll wrote:

Hi Andrzej,

GROMACS 4.6 is work in progress, it will have native CUDA 
acceleration
with multi-GPU support along a few other improvements. You can 
expect
a speedup in the ballpark of 3x. We will soon have the code 
available

for testing.

I'm a little skeptical about the 5x of ACEMD. What setting did you
use? AFAIR they were using large time-steps without contraints in
their benchmarks.

Cheers,
--
Szilárd



On Thu, Nov 24, 2011 at 9:53 AM, Andrzej Rzepiela
 wrote:
> Dears,
>
> I would like to ask what performance improvement is expected for 
future
> releases (e.g. 4.6) for PME calculations on gpu cards. Last week 
I sent
> benchmark results for dhfr to the list, which show no performance 
gain when
> the newest versions of tesla cards vs intel xeon R are used (more 
or less in
> agreement of what is presented on the gromacs website). However, 
for the
> same system  simulations with different gpu code, acemd,  on a 
very similar
> machine can be about 5 times faster, as benchmarked recently by 
my
> colleagues, suggesting that performance of gromacs may soon 
improve. is that

> correct ?
>
>
> Andrzej
> --
> gmx-users mailing list    gmx-users@gromacs.org
> http://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 thewww 
interface

> or send it to gmx-users-requ...@gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
--
gmx-users mailing list    gmx-users@gromacs.org
http://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


--
==
Peter C. Lai                    | University of Alabama-Birmingham
Programmer/Analyst              | KAUL 752A
Genetics, Div. of Research      | 705 South 20th Street
p...@uab.edu                     | Birmingham AL 35294-4461
(205) 690-0808                        |
==

--
gmx-users mailing list    gmx-users@gromacs.org
http://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



--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru
--
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] Reg : Protein-ligand complex using Amber force field

[Justin A. Lemkul]

Rohit Farmer wrote:

Dear GMX user,

Can anyone suggest how to use simulated a protein-ligand complex using 
AMBER force field in GROMACS.




Though the force field is different, the workflow is the same as:

http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin/gmx-tutorials/complex/index.html

And one thing more in another simulation i am trying to find out the 
difference in protein complex interaction by mutating one residue. Right 
now I am using simple procedure to perform simulation on the wild type 
and the mutant complex. Is there any specific procedure which I can use 
to record any significant difference in the complex just by the mutation 
of one residue.




Conducting meaningful analysis implies you have some hypothesis to test and have 
some biochemical knowledge of the system.  There is no magic wand to wave to 
parse out the answer.  Some metrics may give you a general idea (RMSD, RMSF, 
etc) but without a much more focused approach, you'll be stuck in the weeds.


-Justin

--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


--
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] Pme on gpu performance

[Peter C. Lai]

Oh cool. Looking forward to it then!

On 2011-11-27 02:50:43PM -0600, Szilárd Páll wrote:
> Native acceleration = not relying on external libraries. ;)
> 
> --
> Szilárd
> 
> 
> 
> On Sun, Nov 27, 2011 at 9:33 PM, Peter C. Lai  wrote:
> > Random hijack:
> >
> > Will the CUDA acceleration support CMAP or will it still be limited to
> > the limitations of OpenMM that it currently has?
> >
> > On 2011-11-27 12:10:47PM -0600, Szilárd Páll wrote:
> >> Hi Andrzej,
> >>
> >> GROMACS 4.6 is work in progress, it will have native CUDA acceleration
> >> with multi-GPU support along a few other improvements. You can expect
> >> a speedup in the ballpark of 3x. We will soon have the code available
> >> for testing.
> >>
> >> I'm a little skeptical about the 5x of ACEMD. What setting did you
> >> use? AFAIR they were using large time-steps without contraints in
> >> their benchmarks.
> >>
> >> Cheers,
> >> --
> >> Szilárd
> >>
> >>
> >>
> >> On Thu, Nov 24, 2011 at 9:53 AM, Andrzej Rzepiela
> >>  wrote:
> >> > Dears,
> >> >
> >> > I would like to ask what performance improvement is expected for future
> >> > releases (e.g. 4.6) for PME calculations on gpu cards. Last week I sent
> >> > benchmark results for dhfr to the list, which show no performance gain 
> >> > when
> >> > the newest versions of tesla cards vs intel xeon R are used (more or 
> >> > less in
> >> > agreement of what is presented on the gromacs website). However, for the
> >> > same system  simulations with different gpu code, acemd,  on a very 
> >> > similar
> >> > machine can be about 5 times faster, as benchmarked recently by my
> >> > colleagues, suggesting that performance of gromacs may soon improve. is 
> >> > that
> >> > correct ?
> >> >
> >> >
> >> > Andrzej
> >> > --
> >> > gmx-users mailing list    gmx-users@gromacs.org
> >> > http://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 thewww 
> >> > interface
> >> > or send it to gmx-users-requ...@gromacs.org.
> >> > Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >> >
> >> --
> >> gmx-users mailing list    gmx-users@gromacs.org
> >> http://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
> >
> > --
> > ==
> > Peter C. Lai                    | University of Alabama-Birmingham
> > Programmer/Analyst              | KAUL 752A
> > Genetics, Div. of Research      | 705 South 20th Street
> > p...@uab.edu                     | Birmingham AL 35294-4461
> > (205) 690-0808                        |
> > ==
> >
> > --
> > gmx-users mailing list    gmx-users@gromacs.org
> > http://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
> >
> -- 
> gmx-users mailing listgmx-users@gromacs.org
> http://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

-- 
==
Peter C. Lai| University of Alabama-Birmingham
Programmer/Analyst  | KAUL 752A
Genetics, Div. of Research  | 705 South 20th Street
p...@uab.edu| Birmingham AL 35294-4461
(205) 690-0808  |
==

-- 
gmx-users mailing listgmx-users@gromacs.org
http://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

[gmx-users] Reg : Protein-ligand complex using Amber force field

[Rohit Farmer]

Dear GMX user,

Can anyone suggest how to use simulated a protein-ligand complex using 
AMBER force field in GROMACS.


And one thing more in another simulation i am trying to find out the 
difference in protein complex interaction by mutating one residue. Right 
now I am using simple procedure to perform simulation on the wild type 
and the mutant complex. Is there any specific procedure which I can use 
to record any significant difference in the complex just by the mutation 
of one residue.


Many thanks

Rohit
--
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] Pme on gpu performance

[Szilárd Páll]

Native acceleration = not relying on external libraries. ;)

--
Szilárd



On Sun, Nov 27, 2011 at 9:33 PM, Peter C. Lai  wrote:
> Random hijack:
>
> Will the CUDA acceleration support CMAP or will it still be limited to
> the limitations of OpenMM that it currently has?
>
> On 2011-11-27 12:10:47PM -0600, Szilárd Páll wrote:
>> Hi Andrzej,
>>
>> GROMACS 4.6 is work in progress, it will have native CUDA acceleration
>> with multi-GPU support along a few other improvements. You can expect
>> a speedup in the ballpark of 3x. We will soon have the code available
>> for testing.
>>
>> I'm a little skeptical about the 5x of ACEMD. What setting did you
>> use? AFAIR they were using large time-steps without contraints in
>> their benchmarks.
>>
>> Cheers,
>> --
>> Szilárd
>>
>>
>>
>> On Thu, Nov 24, 2011 at 9:53 AM, Andrzej Rzepiela
>>  wrote:
>> > Dears,
>> >
>> > I would like to ask what performance improvement is expected for future
>> > releases (e.g. 4.6) for PME calculations on gpu cards. Last week I sent
>> > benchmark results for dhfr to the list, which show no performance gain when
>> > the newest versions of tesla cards vs intel xeon R are used (more or less 
>> > in
>> > agreement of what is presented on the gromacs website). However, for the
>> > same system  simulations with different gpu code, acemd,  on a very similar
>> > machine can be about 5 times faster, as benchmarked recently by my
>> > colleagues, suggesting that performance of gromacs may soon improve. is 
>> > that
>> > correct ?
>> >
>> >
>> > Andrzej
>> > --
>> > gmx-users mailing list    gmx-users@gromacs.org
>> > http://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 thewww interface
>> > or send it to gmx-users-requ...@gromacs.org.
>> > Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> >
>> --
>> gmx-users mailing list    gmx-users@gromacs.org
>> http://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
>
> --
> ==
> Peter C. Lai                    | University of Alabama-Birmingham
> Programmer/Analyst              | KAUL 752A
> Genetics, Div. of Research      | 705 South 20th Street
> p...@uab.edu                     | Birmingham AL 35294-4461
> (205) 690-0808                        |
> ==
>
> --
> gmx-users mailing list    gmx-users@gromacs.org
> http://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
>
--
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] Pme on gpu performance

[Peter C. Lai]

Random hijack:

Will the CUDA acceleration support CMAP or will it still be limited to
the limitations of OpenMM that it currently has?

On 2011-11-27 12:10:47PM -0600, Szilárd Páll wrote:
> Hi Andrzej,
> 
> GROMACS 4.6 is work in progress, it will have native CUDA acceleration
> with multi-GPU support along a few other improvements. You can expect
> a speedup in the ballpark of 3x. We will soon have the code available
> for testing.
> 
> I'm a little skeptical about the 5x of ACEMD. What setting did you
> use? AFAIR they were using large time-steps without contraints in
> their benchmarks.
> 
> Cheers,
> --
> Szilárd
> 
> 
> 
> On Thu, Nov 24, 2011 at 9:53 AM, Andrzej Rzepiela
>  wrote:
> > Dears,
> >
> > I would like to ask what performance improvement is expected for future
> > releases (e.g. 4.6) for PME calculations on gpu cards. Last week I sent
> > benchmark results for dhfr to the list, which show no performance gain when
> > the newest versions of tesla cards vs intel xeon R are used (more or less in
> > agreement of what is presented on the gromacs website). However, for the
> > same system  simulations with different gpu code, acemd,  on a very similar
> > machine can be about 5 times faster, as benchmarked recently by my
> > colleagues, suggesting that performance of gromacs may soon improve. is that
> > correct ?
> >
> >
> > Andrzej
> > --
> > gmx-users mailing list    gmx-users@gromacs.org
> > http://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 thewww interface
> > or send it to gmx-users-requ...@gromacs.org.
> > Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
> -- 
> gmx-users mailing listgmx-users@gromacs.org
> http://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

-- 
==
Peter C. Lai| University of Alabama-Birmingham
Programmer/Analyst  | KAUL 752A
Genetics, Div. of Research  | 705 South 20th Street
p...@uab.edu| Birmingham AL 35294-4461
(205) 690-0808  |
==

-- 
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] Pme on gpu performance

[Szilárd Páll]

Hi Andrzej,

GROMACS 4.6 is work in progress, it will have native CUDA acceleration
with multi-GPU support along a few other improvements. You can expect
a speedup in the ballpark of 3x. We will soon have the code available
for testing.

I'm a little skeptical about the 5x of ACEMD. What setting did you
use? AFAIR they were using large time-steps without contraints in
their benchmarks.

Cheers,
--
Szilárd



On Thu, Nov 24, 2011 at 9:53 AM, Andrzej Rzepiela
 wrote:
> Dears,
>
> I would like to ask what performance improvement is expected for future
> releases (e.g. 4.6) for PME calculations on gpu cards. Last week I sent
> benchmark results for dhfr to the list, which show no performance gain when
> the newest versions of tesla cards vs intel xeon R are used (more or less in
> agreement of what is presented on the gromacs website). However, for the
> same system  simulations with different gpu code, acemd,  on a very similar
> machine can be about 5 times faster, as benchmarked recently by my
> colleagues, suggesting that performance of gromacs may soon improve. is that
> correct ?
>
>
> Andrzej
> --
> gmx-users mailing list    gmx-users@gromacs.org
> http://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 thewww interface
> or send it to gmx-users-requ...@gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
--
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] gromacs 4.5.3 and GCC 4.1.x

[Szilárd Páll]

Hi,

I don't remember any incident related to tools crashing, but I do
recall a problem which initially was attributed to a known gcc 4.1 bug
(http://redmine.gromacs.org/issues/431), but it turned out to be a GB
bug.

However, knowing that there is such a nasty bug in gcc 4.1, we thought
it's better to discourage this compiler version.

Moreover, with gcc 4.1 you are wasting a serious amount of performance
compared to 4.5 or 4.6.

Cheers,
--
Szilárd



On Thu, Nov 24, 2011 at 12:58 AM, Justin A. Lemkul  wrote:
>
>
> Efrat Exlrod wrote:
>>
>> Hi,
>>
>>
>> I want to install standard gromacs 4.5.5 on a new linux machine, prior to
>> installing GPU accelerated gromacs. Looking at the installation instructions
>> I see you recommend not to use GCC 4.1.x series of compilers.
>>
>>
>> A year ago I have installed gromacs 4.5.3 and I don't recall seeing the
>> recommendation of not using the GCC 4.1.x compilers. The gcc version of
>
> The warning about the gcc compilers has been on the website for several
> years.
>
>> the computer on which I installed is:
>> /usr/bin/gcc -v ==> /u/gcc version 4.1.2 20080704 (Red Hat 4.1.2-51).
>>
>>
>> Is there also a problem with gromacs 4.5.3 and GCC 4.1.x? Was I supposed
>> to have trouble installing or running?
>>
>
> As I recall, the bug was in gcc and it led to various random failures of
> different tools.  Perhaps others with more knowledge of the compilers
> themselves can comment.  Upgrading gcc is a good idea; the 4.1.x is quite
> outdated.
>
>> Is it possible I was able to compile and run but I can't rely on the
>> results I got?
>>
>
> Possible.  More likely you would get random instability rather than some
> hidden inaccuracy.
>
> -Justin
>
>>
>> Thanks, Efrat
>
> --
> 
>
> Justin A. Lemkul
> Ph.D. Candidate
> ICTAS Doctoral Scholar
> MILES-IGERT Trainee
> Department of Biochemistry
> Virginia Tech
> Blacksburg, VA
> jalemkul[at]vt.edu | (540) 231-9080
> http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
>
> 
> --
> gmx-users mailing list    gmx-users@gromacs.org
> http://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
>
--
gmx-users mailing listgmx-users@gromacs.org
http://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

[gmx-users] Add ligand molecules in a lipid bilayer

[parto haghighi]

Dear Dr.Abraham,
Thanks a lot for your response.

I have another question. Should I add several molecules in DMPC together or
I should add them one by one?
Best regard
Parto
-- 
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] Re: gmx-users Dipole

[David van der Spoel]

On 11/27/11 3:26 PM, Dr. Vitaly V. Chaban wrote:


Dear All,

Is there a way to let GROMACS to calculate and write the total dipole moment 
on-the-fly?

I realize that g_dipoles can be used to calculate the total dipole moment using 
a stored trajectory. However, for a large system it is not very feasible to 
write the trajectory at a frequency good enough for spectra analysis.

Thanks.


I don't think such way exists, unless you insert the dipole
calculation subroutine into the main code. All gromacs analysis tools
imply postprocessing of the generated trajectories. In certain cases
(e.g. when velocities or forces should be analyzed), this is not
perfect, of course.

This is  stored in the energy file still, but THE NUMBERS ARE INCORRECT 
since gromacs 4.0.

See http://redmine.gromacs.org/issues/620

--
David.

David van der Spoel, PhD, Professor of Biology
Dept. of Cell and Molecular Biology, Uppsala University.
Husargatan 3, Box 596,  75124 Uppsala, Sweden
phone:  46 18 471 4205  fax: 46 18 511 755
sp...@xray.bmc.uu.sesp...@gromacs.org   http://folding.bmc.uu.se

--
gmx-users mailing listgmx-users@gromacs.org
http://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

[gmx-users] Re: gmx-users Digest, Vol 91, Issue 191

[Dr. Vitaly V. Chaban]

>
> Dear All,
>
> Is there a way to let GROMACS to calculate and write the total dipole moment 
> on-the-fly?
>
> I realize that g_dipoles can be used to calculate the total dipole moment 
> using a stored trajectory. However, for a large system it is not very 
> feasible to write the trajectory at a frequency good enough for spectra 
> analysis.
>
> Thanks.

I don't think such way exists, unless you insert the dipole
calculation subroutine into the main code. All gromacs analysis tools
imply postprocessing of the generated trajectories. In certain cases
(e.g. when velocities or forces should be analyzed), this is not
perfect, of course.

-- 
Dr. Vitaly V. Chaban, 430 Hutchison Hall, Chem. Dept.
Univ. Rochester, Rochester, New York 14627-0216
THE UNITED STATES OF AMERICA
-- 
gmx-users mailing listgmx-users@gromacs.org
http://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

[gmx-users] diffusion of the water at the micelle surface

[chris . neale]

Well, the positive way of looking at this is that it appears that  
nobody has ever done it before. If somebody has done it (in charmm for  
instance) then you might be able to convert the format of your .xtc  
and use their tools to analyze it.


Good luck,
Chris.

-- original message --

Thank you very much for your reply. Indeed I have read several papers  
where the diffusion of water at the membrane surface have been  
computed. Since the diffusion of the interfacial water is an useful  
properties to examine the micelle/surface irregularities, I would hope  
that this option exist in gromacs. Unfortunately, it is not the case,  
so i will try your suggestions .


Stephane


--

Message: 6
Date: Sat, 26 Nov 2011 10:17:10 -0500
From: chris.neale at utoronto.ca
Subject: [gmx-users] diffusion of the water at the micelle surface
To: gmx-users at gromacs.org
Message-ID: <2026101710.bbl5wl376s04ccww at webmail.utoronto.ca>
Content-Type: text/plain;   charset=ISO-8859-1; DelSp="Yes";
format="flowed"

When people do this for lipid bilayers, they compute depth-dependent
diffusion profiles (often diffusion is computed separately for lateral
diffusion and diffusion along the bilayer normal). Sounds like you
might do something similar. I doubt that the standard gromacs tools
will do this for you. If you don't hear from anybody about how to do
this, then I'd suggest that you simply use g_dist to get the
time-dependent distance for each water molecule and then use g_traj to
output the coordinates of each water molecule and then script it
yourself after reading one of the papers where people compute
depth-dependent diffusion profiles for a lipid bilayer.

Chris.

-- original message --

I would like to compute the translational diffusion around the micelle
surface. I know that I can select the water molecules at x distance of the
micelle surface with g_select (right ?) but how to use this file generated
by g_select to compute de diffusion, since the index and/or the number of
water will change with the simulation time .



Thank you for your response



--
gmx-users mailing listgmx-users@gromacs.org
http://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

[gmx-users] diffusion of the water at the micelle surface

[ABEL Stephane 175950]

Hi Chris,  Druz

Thank you very much for your reply. Indeed I have read several papers where the 
diffusion of water at the membrane surface have been computed. Since the 
diffusion of the interfacial water is an useful properties to examine the 
micelle/surface irregularities, I would hope that this option exist in gromacs. 
Unfortunately, it is not the case, so i will try your suggestions .

Stephane


--

Message: 6
Date: Sat, 26 Nov 2011 10:17:10 -0500
From: chris.ne...@utoronto.ca
Subject: [gmx-users] diffusion of the water at the micelle surface
To: gmx-users@gromacs.org
Message-ID: <2026101710.bbl5wl376s04c...@webmail.utoronto.ca>
Content-Type: text/plain;   charset=ISO-8859-1; DelSp="Yes";
format="flowed"

When people do this for lipid bilayers, they compute depth-dependent
diffusion profiles (often diffusion is computed separately for lateral
diffusion and diffusion along the bilayer normal). Sounds like you
might do something similar. I doubt that the standard gromacs tools
will do this for you. If you don't hear from anybody about how to do
this, then I'd suggest that you simply use g_dist to get the
time-dependent distance for each water molecule and then use g_traj to
output the coordinates of each water molecule and then script it
yourself after reading one of the papers where people compute
depth-dependent diffusion profiles for a lipid bilayer.

Chris.

-- original message --

I would like to compute the translational diffusion around the micelle
surface. I know that I can select the water molecules at x distance of the
micelle surface with g_select (right ?) but how to use this file generated
by g_select to compute de diffusion, since the index and/or the number of
water will change with the simulation time .



Thank you for your response



Stephane



--

Message: 7
Date: Sat, 26 Nov 2011 23:22:59 +0800
From: lina 
Subject: Re: [gmx-users] diffusion of the water at the micelle surface
To: Discussion list for GROMACS users 
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

On Sat, Nov 26, 2011 at 11:17 PM,   wrote:
> When people do this for lipid bilayers, they compute depth-dependent
> diffusion profiles (often diffusion is computed separately for lateral
> diffusion and diffusion along the bilayer normal). Sounds like you might do
> something similar. I doubt that the standard gromacs tools will do this for
> you. If you don't hear from anybody about how to do this, then I'd suggest
> that you simply use g_dist to get the time-dependent distance for each water
> molecule and then use g_traj to output the coordinates of each water
> molecule and then script it yourself after reading one of the papers where
> people compute depth-dependent diffusion profiles for a lipid bilayer.
>
> Chris.
>
> -- original message --
>
> I would like to compute the translational diffusion around the micelle
> surface. I know that I can select the water molecules at x distance of the
> micelle surface with g_select (right ?) but how to use this file generated
> by g_select to compute de diffusion, since the index and/or the number of
> water will change with the simulation time .

You may try g_density, choose different time interval.

>
>
>
> Thank you for your response
>
>
>
> Stephane
>
> --
> gmx-users mailing list ? ?gmx-users@gromacs.org
> http://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 thewww interface
> or send it to gmx-users-requ...@gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>

--
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] Add ligand molecules in a lipid bilayer

[Mark Abraham]

On 27/11/2011 7:23 PM, parto haghighi wrote:

Dear gmx_users,

I am working on lipid/drug molecule system.
I could make the ligand topology by PRODRG and get DMPC.itp from 
http://moose.bio.ucalgary.ca/index.php?page=Structures_and_Topologies.


To add ligand molecule I first changed its coordinate by:
editconf -f drg.gro -o drg_newbox.gro -c -box  6.17600   6.17600   5.5

then add drg_newbox.gro to my bilayer by:
cat drg_newbox.gro dmpc_whole.gro > system.gro


Updating the number of atoms and shifting the box line, of course...



How can I add 6 ligand molecules in lipid bilayer symmetrically at 
each side of membrane?


Suitable use of editconf options to do translations, or maybe genconf 
can achieve this.



What is gromacs command to add molecules in bilayer (except editconf)?


There is none.

Mark
--
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] to gro or not to gro

[David van der Spoel]

Back to square one! The point you are missing is that 4.172 A is not
equal to 0.417 nm and  pdb2gmx does it without any warning.



You have a point. It is not possible to change the file formats without 
creating great havoc as I'm sure you understand, but a warning that 
precision is lost in pdb2gmx, editconf, trjconv is a good idea. We 
should not make *any* presumptions about what the user wants to do 
(although it is hard).


I've created redmine issue 846 to remind us of this problem.

http://redmine.gromacs.org/issues/846


--
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:  +46184714205.
sp...@xray.bmc.uu.sehttp://folding.bmc.uu.se
--
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] to gro or not to gro

[Igor Druz]

On Sun, Nov 27, 2011 at 11:26 AM, Mark Abraham wrote:

>  On 27/11/2011 10:15 PM, Igor Druz wrote:
>
> write to gro in angstroms, read from gro in angstroms, convert into nm in
> grompp.
>
>
> What are you trying to communicate with this hypothetical workflow?
>
> Historical file formats imply particular units and are often limited to a
> particular precision. Nothing should or will be done to change this.
> Eventually file formats will be flexible enough to specify arbitrary
> precision in arbitrary units, but that day is not here yet. Even when we
> get there, workmen will still have to know about their tools work in order
> to use them.
>
> I still haven't seen any evidence beyond Igor's assertion that there's a
> problem worth a warning, so I'm going to regard that issue as closed.
>
> Mark
>
>
>
> On Sun, Nov 27, 2011 at 10:41 AM, Tsjerk Wassenaar wrote:
>
>> Hi Igor,
>>
>> Please do read the manual. The GRO file format is a fixed-width format
>> with %8.3f for coordinates, velocities and forces. Changing the format
>> to %9.4f will break everything written in fortran. And, yes, people
>> still use fortran. So which point did I miss? :)
>>
>> Cheers,
>>
>> Tsjerk
>>
>> Back to square one! The point you are missing is that 4.172 A is not
equal to 0.417 nm and  pdb2gmx does it without any warning.


>> On Sun, Nov 27, 2011 at 11:38 AM, Igor Druz  wrote:
>> > You are missing the point. Quoting my response to David:
>> >
>> > I appreciate the history of the matter, but it would save a lot of
>> headache
>> > to store coordinates in angstroms in gro files, i.e., not to omit "2" in
>> > 4.172 A in the pdb file by converting it to 0.417 nm in the gro file.
>> What
>> > is the point in dropping useful "2" by introducing useless "0"?
>> >
>> > On Sun, Nov 27, 2011 at 10:30 AM, Tsjerk Wassenaar 
>> > wrote:
>> >>
>> >> My my. Why is it a fault to adhere to ISO units (nm) over non-standard
>> >> (A)? It's a choice, but a choice is not faulty. The consequences may
>> >> be undesirable. But shouldn't a user, certainly a computation
>> >> scientist, understand the file formats, as an experimentalist should
>> >> know its solvent? And know the consequences of using one over another?
>> >> Mark is correct to state that a picometer uncertainty at the start has
>> >> no consequences for molecular dynamics simulations. For single point
>> >> eneriges they will have. But no one ever forced anyone to use GRO
>> >> rather than PDB format. That's the choice the researcher makes. And,
>> >> at least in my tutorial, that difference between GRO and PDB format is
>> >> stressed. The choice to use standard units is historical, and lies
>> >> decades back in time. Could we now change it to A, because a 'faulty'
>> >> choice was made?
>> >>
>> >> I'm terribly sorry that you need to do a lot of work again, Igor. But
>> >> you can't shove the blame in another's shoes. You overlooked
>> >> something, lead by presumptions about standardization in units and
>> >> file formats. May I wonder why you only found out now, after all the
>> >> work has been done? This difference would have showed up with the
>> >> first test, right? But again, it's not us against you, and I'm sorry
>> >> you have to go through this. Trust me, most of us have had such
>> >> moments, although with a different aspect.
>> >>
>> >> Best,
>> >>
>> >> Tsjerk
>> >>
>> >> On Sun, Nov 27, 2011 at 11:03 AM, Igor Druz 
>> wrote:
>> >> > You can put whichever spin you like into what is said, but there is a
>> >> > clear
>> >> > (and unnecessary) fault with the way coordinates are stored in gro
>> files
>> >> > when made from pdb using pdb2gmx.
>> >> >
>> >> > On Sun, Nov 27, 2011 at 12:39 AM, Mark Abraham <
>> mark.abra...@anu.edu.au>
>> >> > wrote:
>> >> >>
>> >> >> On 27/11/2011 5:07 AM, Igor Druz wrote:
>> >> >>
>> >> >> On Sat, Nov 26, 2011 at 5:35 PM,  wrote
>> >> >>>
>> >> >>> 1. why repeat the calculations? If you're talking about simulations
>> >> >>> then
>> >> >>> there is no need to repeat them due to this. You will get different
>> >> >>> answers
>> >> >>> with the same starting coordinates if you simply change the initial
>> >> >>> velocities. If you're talking about instantaneous energy
>> calculations
>> >> >>> then I
>> >> >>> suppose you might need to redo it, but they should be very quick,
>> >> >>> right?
>> >> >>>
>> >> >>
>> >> >> The calculations must be repeated. You are making irrelevant
>> >> >> assumptions
>> >> >> without knowing what the calculations are for.
>> >> >>
>> >> >> You asserted that there should have been a warning without
>> explaining
>> >> >> why
>> >> >> this loss of precision was material. Chris knew that many uses of
>> >> >> pdb2gmx
>> >> >> change the atomic configuration considerably, e.g. new hydrogen
>> >> >> positions,
>> >> >> building termini, etc. so that any change of precision of
>> coordinates
>> >> >> is not
>> >> >> a big deal, and even less important once a simulation has run
>> >> >> afterwards. If
>> >> >> you

Re: [gmx-users] g_rdf -com

[David van der Spoel]

On 2011-11-27 12:27, mohammad agha wrote:

Dear Prof.

I have a question about g_rdf.
I have a box consists of 500 surfactants that make 10 micelle. I want to
compute rdf for surfactant relative to the center of mass of micelle.
When I do g_rdf, the program ask me 2 groups that the first one is COM,
but it is COM of molecules that I defined in index file.
If I select the surfactant molecules as the first group for COM, this
means the COM of micelle or just surfactants?
If it select just COM of surfactants, then what do I do for selection of
COM of micelle?
Please help me.

Best Regards
Sara


you first have to define which surfactants belong together before g_rdf 
can do this - make an appropriate index file, maybe g_clustsize can help.


--
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:  +46184714205.
sp...@xray.bmc.uu.sehttp://folding.bmc.uu.se
--
gmx-users mailing listgmx-users@gromacs.org
http://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

[gmx-users] g_rdf -com

[mohammad agha]

Dear Prof.

I have a question about g_rdf.
I have a box consists of 500 surfactants that make 10 micelle. I want to 
compute rdf for surfactant relative to the center of mass of micelle.
When I do g_rdf, the program ask me 2 groups that the first one is COM, but it 
is COM of molecules that I defined in index file.
If I select the surfactant molecules as the first group for COM, this means the 
COM of micelle or just surfactants?
If it select just COM of surfactants, then what do I do for selection of COM of 
micelle?
Please help me.

Best Regards
Sara
-- 
gmx-users mailing listgmx-users@gromacs.org
http://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

Re: [gmx-users] to gro or not to gro

[Mark Abraham]

On 27/11/2011 10:15 PM, Igor Druz wrote:
write to gro in angstroms, read from gro in angstroms, convert into nm 
in grompp.


What are you trying to communicate with this hypothetical workflow?

Historical file formats imply particular units and are often limited to 
a particular precision. Nothing should or will be done to change this. 
Eventually file formats will be flexible enough to specify arbitrary 
precision in arbitrary units, but that day is not here yet. Even when we 
get there, workmen will still have to know about their tools work in 
order to use them.


I still haven't seen any evidence beyond Igor's assertion that there's a 
problem worth a warning, so I'm going to regard that issue as closed.


Mark



On Sun, Nov 27, 2011 at 10:41 AM, Tsjerk Wassenaar > wrote:


Hi Igor,

Please do read the manual. The GRO file format is a fixed-width format
with %8.3f for coordinates, velocities and forces. Changing the format
to %9.4f will break everything written in fortran. And, yes, people
still use fortran. So which point did I miss? :)

Cheers,

Tsjerk


On Sun, Nov 27, 2011 at 11:38 AM, Igor Druz mailto:idruz...@gmail.com>> wrote:
> You are missing the point. Quoting my response to David:
>
> I appreciate the history of the matter, but it would save a lot
of headache
> to store coordinates in angstroms in gro files, i.e., not to
omit "2" in
> 4.172 A in the pdb file by converting it to 0.417 nm in the gro
file. What
> is the point in dropping useful "2" by introducing useless "0"?
>
> On Sun, Nov 27, 2011 at 10:30 AM, Tsjerk Wassenaar
mailto:tsje...@gmail.com>>
> wrote:
>>
>> My my. Why is it a fault to adhere to ISO units (nm) over
non-standard
>> (A)? It's a choice, but a choice is not faulty. The
consequences may
>> be undesirable. But shouldn't a user, certainly a computation
>> scientist, understand the file formats, as an experimentalist
should
>> know its solvent? And know the consequences of using one over
another?
>> Mark is correct to state that a picometer uncertainty at the
start has
>> no consequences for molecular dynamics simulations. For single
point
>> eneriges they will have. But no one ever forced anyone to use GRO
>> rather than PDB format. That's the choice the researcher makes.
And,
>> at least in my tutorial, that difference between GRO and PDB
format is
>> stressed. The choice to use standard units is historical, and lies
>> decades back in time. Could we now change it to A, because a
'faulty'
>> choice was made?
>>
>> I'm terribly sorry that you need to do a lot of work again,
Igor. But
>> you can't shove the blame in another's shoes. You overlooked
>> something, lead by presumptions about standardization in units and
>> file formats. May I wonder why you only found out now, after
all the
>> work has been done? This difference would have showed up with the
>> first test, right? But again, it's not us against you, and I'm
sorry
>> you have to go through this. Trust me, most of us have had such
>> moments, although with a different aspect.
>>
>> Best,
>>
>> Tsjerk
>>
>> On Sun, Nov 27, 2011 at 11:03 AM, Igor Druz mailto:idruz...@gmail.com>> wrote:
>> > You can put whichever spin you like into what is said,
but there is a
>> > clear
>> > (and unnecessary) fault with the way coordinates are stored
in gro files
>> > when made from pdb using pdb2gmx.
>> >
>> > On Sun, Nov 27, 2011 at 12:39 AM, Mark Abraham
mailto:mark.abra...@anu.edu.au>>
>> > wrote:
>> >>
>> >> On 27/11/2011 5:07 AM, Igor Druz wrote:
>> >>
>> >> On Sat, Nov 26, 2011 at 5:35 PM, mailto:chris.ne...@utoronto.ca>> wrote
>> >>>
>> >>> 1. why repeat the calculations? If you're talking about
simulations
>> >>> then
>> >>> there is no need to repeat them due to this. You will get
different
>> >>> answers
>> >>> with the same starting coordinates if you simply change the
initial
>> >>> velocities. If you're talking about instantaneous energy
calculations
>> >>> then I
>> >>> suppose you might need to redo it, but they should be very
quick,
>> >>> right?
>> >>>
>> >>
>> >> The calculations must be repeated. You are making irrelevant
>> >> assumptions
>> >> without knowing what the calculations are for.
>> >>
>> >> You asserted that there should have been a warning without
explaining
>> >> why
>> >> this loss of precision was material. Chris knew that many
uses of
>> >> pdb2gmx
>> >> change the atomic configuration considerably, e.g. new hydrogen
>> >> positions,
>> >> building termini, etc. so that any change of precision of
coordinates
>> >> is not
>> >> a big deal,

Re: [gmx-users] to gro or not to gro

[David van der Spoel]

On 2011-11-27 12:15, Igor Druz wrote:

write to gro in angstroms, read from gro in angstroms, convert into nm
in grompp.

once more you don't have to use gro, use g96 if precision is important. 
if we'd introduce a gro format in angstrom it couldn't be called .gro 
anyway since that would confuse tons of programs using it.




On Sun, Nov 27, 2011 at 10:41 AM, Tsjerk Wassenaar mailto:tsje...@gmail.com>> wrote:

Hi Igor,

Please do read the manual. The GRO file format is a fixed-width format
with %8.3f for coordinates, velocities and forces. Changing the format
to %9.4f will break everything written in fortran. And, yes, people
still use fortran. So which point did I miss? :)

Cheers,

Tsjerk


On Sun, Nov 27, 2011 at 11:38 AM, Igor Druz mailto:idruz...@gmail.com>> wrote:
 > You are missing the point. Quoting my response to David:
 >
 > I appreciate the history of the matter, but it would save a lot
of headache
 > to store coordinates in angstroms in gro files, i.e., not to omit
"2" in
 > 4.172 A in the pdb file by converting it to 0.417 nm in the gro
file. What
 > is the point in dropping useful "2" by introducing useless "0"?
 >
 > On Sun, Nov 27, 2011 at 10:30 AM, Tsjerk Wassenaar
mailto:tsje...@gmail.com>>
 > wrote:
 >>
 >> My my. Why is it a fault to adhere to ISO units (nm) over
non-standard
 >> (A)? It's a choice, but a choice is not faulty. The consequences may
 >> be undesirable. But shouldn't a user, certainly a computation
 >> scientist, understand the file formats, as an experimentalist should
 >> know its solvent? And know the consequences of using one over
another?
 >> Mark is correct to state that a picometer uncertainty at the
start has
 >> no consequences for molecular dynamics simulations. For single point
 >> eneriges they will have. But no one ever forced anyone to use GRO
 >> rather than PDB format. That's the choice the researcher makes. And,
 >> at least in my tutorial, that difference between GRO and PDB
format is
 >> stressed. The choice to use standard units is historical, and lies
 >> decades back in time. Could we now change it to A, because a
'faulty'
 >> choice was made?
 >>
 >> I'm terribly sorry that you need to do a lot of work again,
Igor. But
 >> you can't shove the blame in another's shoes. You overlooked
 >> something, lead by presumptions about standardization in units and
 >> file formats. May I wonder why you only found out now, after all the
 >> work has been done? This difference would have showed up with the
 >> first test, right? But again, it's not us against you, and I'm sorry
 >> you have to go through this. Trust me, most of us have had such
 >> moments, although with a different aspect.
 >>
 >> Best,
 >>
 >> Tsjerk
 >>
 >> On Sun, Nov 27, 2011 at 11:03 AM, Igor Druz mailto:idruz...@gmail.com>> wrote:
 >> > You can put whichever spin you like into what is said,
but there is a
 >> > clear
 >> > (and unnecessary) fault with the way coordinates are stored in
gro files
 >> > when made from pdb using pdb2gmx.
 >> >
 >> > On Sun, Nov 27, 2011 at 12:39 AM, Mark Abraham
mailto:mark.abra...@anu.edu.au>>
 >> > wrote:
 >> >>
 >> >> On 27/11/2011 5:07 AM, Igor Druz wrote:
 >> >>
 >> >> On Sat, Nov 26, 2011 at 5:35 PM, mailto:chris.ne...@utoronto.ca>> wrote
 >> >>>
 >> >>> 1. why repeat the calculations? If you're talking about
simulations
 >> >>> then
 >> >>> there is no need to repeat them due to this. You will get
different
 >> >>> answers
 >> >>> with the same starting coordinates if you simply change the
initial
 >> >>> velocities. If you're talking about instantaneous energy
calculations
 >> >>> then I
 >> >>> suppose you might need to redo it, but they should be very
quick,
 >> >>> right?
 >> >>>
 >> >>
 >> >> The calculations must be repeated. You are making irrelevant
 >> >> assumptions
 >> >> without knowing what the calculations are for.
 >> >>
 >> >> You asserted that there should have been a warning without
explaining
 >> >> why
 >> >> this loss of precision was material. Chris knew that many uses of
 >> >> pdb2gmx
 >> >> change the atomic configuration considerably, e.g. new hydrogen
 >> >> positions,
 >> >> building termini, etc. so that any change of precision of
coordinates
 >> >> is not
 >> >> a big deal, and even less important once a simulation has run
 >> >> afterwards. If
 >> >> you want to engage in constructive dialogue, please explain
why the
 >> >> loss of
 >> >> precision was material, in order to clarify the reason for
your request
 >> >> for
 >> >> a warning message. If you wish to blow off steam, please do it
 

Re: [gmx-users] to gro or not to gro

[Igor Druz]

write to gro in angstroms, read from gro in angstroms, convert into nm in
grompp.

On Sun, Nov 27, 2011 at 10:41 AM, Tsjerk Wassenaar wrote:

> Hi Igor,
>
> Please do read the manual. The GRO file format is a fixed-width format
> with %8.3f for coordinates, velocities and forces. Changing the format
> to %9.4f will break everything written in fortran. And, yes, people
> still use fortran. So which point did I miss? :)
>
> Cheers,
>
> Tsjerk
>
>
> On Sun, Nov 27, 2011 at 11:38 AM, Igor Druz  wrote:
> > You are missing the point. Quoting my response to David:
> >
> > I appreciate the history of the matter, but it would save a lot of
> headache
> > to store coordinates in angstroms in gro files, i.e., not to omit "2" in
> > 4.172 A in the pdb file by converting it to 0.417 nm in the gro file.
> What
> > is the point in dropping useful "2" by introducing useless "0"?
> >
> > On Sun, Nov 27, 2011 at 10:30 AM, Tsjerk Wassenaar 
> > wrote:
> >>
> >> My my. Why is it a fault to adhere to ISO units (nm) over non-standard
> >> (A)? It's a choice, but a choice is not faulty. The consequences may
> >> be undesirable. But shouldn't a user, certainly a computation
> >> scientist, understand the file formats, as an experimentalist should
> >> know its solvent? And know the consequences of using one over another?
> >> Mark is correct to state that a picometer uncertainty at the start has
> >> no consequences for molecular dynamics simulations. For single point
> >> eneriges they will have. But no one ever forced anyone to use GRO
> >> rather than PDB format. That's the choice the researcher makes. And,
> >> at least in my tutorial, that difference between GRO and PDB format is
> >> stressed. The choice to use standard units is historical, and lies
> >> decades back in time. Could we now change it to A, because a 'faulty'
> >> choice was made?
> >>
> >> I'm terribly sorry that you need to do a lot of work again, Igor. But
> >> you can't shove the blame in another's shoes. You overlooked
> >> something, lead by presumptions about standardization in units and
> >> file formats. May I wonder why you only found out now, after all the
> >> work has been done? This difference would have showed up with the
> >> first test, right? But again, it's not us against you, and I'm sorry
> >> you have to go through this. Trust me, most of us have had such
> >> moments, although with a different aspect.
> >>
> >> Best,
> >>
> >> Tsjerk
> >>
> >> On Sun, Nov 27, 2011 at 11:03 AM, Igor Druz  wrote:
> >> > You can put whichever spin you like into what is said, but there is a
> >> > clear
> >> > (and unnecessary) fault with the way coordinates are stored in gro
> files
> >> > when made from pdb using pdb2gmx.
> >> >
> >> > On Sun, Nov 27, 2011 at 12:39 AM, Mark Abraham <
> mark.abra...@anu.edu.au>
> >> > wrote:
> >> >>
> >> >> On 27/11/2011 5:07 AM, Igor Druz wrote:
> >> >>
> >> >> On Sat, Nov 26, 2011 at 5:35 PM,  wrote
> >> >>>
> >> >>> 1. why repeat the calculations? If you're talking about simulations
> >> >>> then
> >> >>> there is no need to repeat them due to this. You will get different
> >> >>> answers
> >> >>> with the same starting coordinates if you simply change the initial
> >> >>> velocities. If you're talking about instantaneous energy
> calculations
> >> >>> then I
> >> >>> suppose you might need to redo it, but they should be very quick,
> >> >>> right?
> >> >>>
> >> >>
> >> >> The calculations must be repeated. You are making irrelevant
> >> >> assumptions
> >> >> without knowing what the calculations are for.
> >> >>
> >> >> You asserted that there should have been a warning without explaining
> >> >> why
> >> >> this loss of precision was material. Chris knew that many uses of
> >> >> pdb2gmx
> >> >> change the atomic configuration considerably, e.g. new hydrogen
> >> >> positions,
> >> >> building termini, etc. so that any change of precision of coordinates
> >> >> is not
> >> >> a big deal, and even less important once a simulation has run
> >> >> afterwards. If
> >> >> you want to engage in constructive dialogue, please explain why the
> >> >> loss of
> >> >> precision was material, in order to clarify the reason for your
> request
> >> >> for
> >> >> a warning message. If you wish to blow off steam, please do it
> >> >> elsewhere.
> >> >>
> >> >>
> >> >>>
> >> >>> 2. The .gro files do not carry useless zeroes. you have it
> >> >>> backwards...
> >> >>> the gro files end up with fewer digits.
> >> >>>
> >> >>
> >> >> 0.417 or 4.172. Shall I continue? I know which one I prefer.
> >> >>
> >> >>>
> >> >>> 3. it's a little annoying to find out that you already knew the
> >> >>> answer.
> >> >>> Why not state that at the outset? Unless I misunderstand this point,
> >> >>> this
> >> >>> will mark the end of my comments since holding back information on
> >> >>> purpose
> >> >>> just wastes people's time.
> >> >>>
> >> >>
> >> >> Check my 1st e-mail, please. It is NOT asking for clarification. It
> is
> >> >> requesting an exp

Re: [gmx-users] to gro or not to gro

[Tsjerk Wassenaar]

Hi Igor,

Please do read the manual. The GRO file format is a fixed-width format
with %8.3f for coordinates, velocities and forces. Changing the format
to %9.4f will break everything written in fortran. And, yes, people
still use fortran. So which point did I miss? :)

Cheers,

Tsjerk


On Sun, Nov 27, 2011 at 11:38 AM, Igor Druz  wrote:
> You are missing the point. Quoting my response to David:
>
> I appreciate the history of the matter, but it would save a lot of headache
> to store coordinates in angstroms in gro files, i.e., not to omit "2" in
> 4.172 A in the pdb file by converting it to 0.417 nm in the gro file. What
> is the point in dropping useful "2" by introducing useless "0"?
>
> On Sun, Nov 27, 2011 at 10:30 AM, Tsjerk Wassenaar 
> wrote:
>>
>> My my. Why is it a fault to adhere to ISO units (nm) over non-standard
>> (A)? It's a choice, but a choice is not faulty. The consequences may
>> be undesirable. But shouldn't a user, certainly a computation
>> scientist, understand the file formats, as an experimentalist should
>> know its solvent? And know the consequences of using one over another?
>> Mark is correct to state that a picometer uncertainty at the start has
>> no consequences for molecular dynamics simulations. For single point
>> eneriges they will have. But no one ever forced anyone to use GRO
>> rather than PDB format. That's the choice the researcher makes. And,
>> at least in my tutorial, that difference between GRO and PDB format is
>> stressed. The choice to use standard units is historical, and lies
>> decades back in time. Could we now change it to A, because a 'faulty'
>> choice was made?
>>
>> I'm terribly sorry that you need to do a lot of work again, Igor. But
>> you can't shove the blame in another's shoes. You overlooked
>> something, lead by presumptions about standardization in units and
>> file formats. May I wonder why you only found out now, after all the
>> work has been done? This difference would have showed up with the
>> first test, right? But again, it's not us against you, and I'm sorry
>> you have to go through this. Trust me, most of us have had such
>> moments, although with a different aspect.
>>
>> Best,
>>
>> Tsjerk
>>
>> On Sun, Nov 27, 2011 at 11:03 AM, Igor Druz  wrote:
>> > You can put whichever spin you like into what is said, but there is a
>> > clear
>> > (and unnecessary) fault with the way coordinates are stored in gro files
>> > when made from pdb using pdb2gmx.
>> >
>> > On Sun, Nov 27, 2011 at 12:39 AM, Mark Abraham 
>> > wrote:
>> >>
>> >> On 27/11/2011 5:07 AM, Igor Druz wrote:
>> >>
>> >> On Sat, Nov 26, 2011 at 5:35 PM,  wrote
>> >>>
>> >>> 1. why repeat the calculations? If you're talking about simulations
>> >>> then
>> >>> there is no need to repeat them due to this. You will get different
>> >>> answers
>> >>> with the same starting coordinates if you simply change the initial
>> >>> velocities. If you're talking about instantaneous energy calculations
>> >>> then I
>> >>> suppose you might need to redo it, but they should be very quick,
>> >>> right?
>> >>>
>> >>
>> >> The calculations must be repeated. You are making irrelevant
>> >> assumptions
>> >> without knowing what the calculations are for.
>> >>
>> >> You asserted that there should have been a warning without explaining
>> >> why
>> >> this loss of precision was material. Chris knew that many uses of
>> >> pdb2gmx
>> >> change the atomic configuration considerably, e.g. new hydrogen
>> >> positions,
>> >> building termini, etc. so that any change of precision of coordinates
>> >> is not
>> >> a big deal, and even less important once a simulation has run
>> >> afterwards. If
>> >> you want to engage in constructive dialogue, please explain why the
>> >> loss of
>> >> precision was material, in order to clarify the reason for your request
>> >> for
>> >> a warning message. If you wish to blow off steam, please do it
>> >> elsewhere.
>> >>
>> >>
>> >>>
>> >>> 2. The .gro files do not carry useless zeroes. you have it
>> >>> backwards...
>> >>> the gro files end up with fewer digits.
>> >>>
>> >>
>> >> 0.417 or 4.172. Shall I continue? I know which one I prefer.
>> >>
>> >>>
>> >>> 3. it's a little annoying to find out that you already knew the
>> >>> answer.
>> >>> Why not state that at the outset? Unless I misunderstand this point,
>> >>> this
>> >>> will mark the end of my comments since holding back information on
>> >>> purpose
>> >>> just wastes people's time.
>> >>>
>> >>
>> >> Check my 1st e-mail, please. It is NOT asking for clarification. It is
>> >> requesting an explicit warning message.
>> >>
>> >> There's nothing to warn about. You thought that "switching from
>> >> Angstrom
>> >> to nanometers" was significant somehow, and then assumed that different
>> >> file
>> >> formats would definitely contain identical information, and didn't
>> >> check
>> >> their contents.
>> >>
>> >> Mark
>> >>
>> >>
>> >>>
>> >>> Chris.
>> >>>
>> >>> -- original message --
>> >>>
>> >>

Re: [gmx-users] to gro or not to gro

[Igor Druz]

You are missing the point. Quoting my response to David:

I appreciate the history of the matter, but it would save a lot of headache
to store coordinates in angstroms in gro files, i.e., not to omit "2" in
4.172 A in the pdb file by converting it to 0.417 nm in the gro file. What
is the point in dropping useful "2" by introducing useless "0"?


On Sun, Nov 27, 2011 at 10:30 AM, Tsjerk Wassenaar wrote:

> My my. Why is it a fault to adhere to ISO units (nm) over non-standard
> (A)? It's a choice, but a choice is not faulty. The consequences may
> be undesirable. But shouldn't a user, certainly a computation
> scientist, understand the file formats, as an experimentalist should
> know its solvent? And know the consequences of using one over another?
> Mark is correct to state that a picometer uncertainty at the start has
> no consequences for molecular dynamics simulations. For single point
> eneriges they will have. But no one ever forced anyone to use GRO
> rather than PDB format. That's the choice the researcher makes. And,
> at least in my tutorial, that difference between GRO and PDB format is
> stressed. The choice to use standard units is historical, and lies
> decades back in time. Could we now change it to A, because a 'faulty'
> choice was made?
>
> I'm terribly sorry that you need to do a lot of work again, Igor. But
> you can't shove the blame in another's shoes. You overlooked
> something, lead by presumptions about standardization in units and
> file formats. May I wonder why you only found out now, after all the
> work has been done? This difference would have showed up with the
> first test, right? But again, it's not us against you, and I'm sorry
> you have to go through this. Trust me, most of us have had such
> moments, although with a different aspect.
>
> Best,
>
> Tsjerk
>
> On Sun, Nov 27, 2011 at 11:03 AM, Igor Druz  wrote:
> > You can put whichever spin you like into what is said, but there is a
> clear
> > (and unnecessary) fault with the way coordinates are stored in gro files
> > when made from pdb using pdb2gmx.
> >
> > On Sun, Nov 27, 2011 at 12:39 AM, Mark Abraham 
> > wrote:
> >>
> >> On 27/11/2011 5:07 AM, Igor Druz wrote:
> >>
> >> On Sat, Nov 26, 2011 at 5:35 PM,  wrote
> >>>
> >>> 1. why repeat the calculations? If you're talking about simulations
> then
> >>> there is no need to repeat them due to this. You will get different
> answers
> >>> with the same starting coordinates if you simply change the initial
> >>> velocities. If you're talking about instantaneous energy calculations
> then I
> >>> suppose you might need to redo it, but they should be very quick,
> right?
> >>>
> >>
> >> The calculations must be repeated. You are making irrelevant assumptions
> >> without knowing what the calculations are for.
> >>
> >> You asserted that there should have been a warning without explaining
> why
> >> this loss of precision was material. Chris knew that many uses of
> pdb2gmx
> >> change the atomic configuration considerably, e.g. new hydrogen
> positions,
> >> building termini, etc. so that any change of precision of coordinates
> is not
> >> a big deal, and even less important once a simulation has run
> afterwards. If
> >> you want to engage in constructive dialogue, please explain why the
> loss of
> >> precision was material, in order to clarify the reason for your request
> for
> >> a warning message. If you wish to blow off steam, please do it
> elsewhere.
> >>
> >>
> >>>
> >>> 2. The .gro files do not carry useless zeroes. you have it backwards...
> >>> the gro files end up with fewer digits.
> >>>
> >>
> >> 0.417 or 4.172. Shall I continue? I know which one I prefer.
> >>
> >>>
> >>> 3. it's a little annoying to find out that you already knew the answer.
> >>> Why not state that at the outset? Unless I misunderstand this point,
> this
> >>> will mark the end of my comments since holding back information on
> purpose
> >>> just wastes people's time.
> >>>
> >>
> >> Check my 1st e-mail, please. It is NOT asking for clarification. It is
> >> requesting an explicit warning message.
> >>
> >> There's nothing to warn about. You thought that "switching from Angstrom
> >> to nanometers" was significant somehow, and then assumed that different
> file
> >> formats would definitely contain identical information, and didn't check
> >> their contents.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Chris.
> >>>
> >>> -- original message --
> >>>
> >>> I already knew the reason. But I had to find this out hard way. Now
> >>> facing
> >>> a dreading prospect of repeating tons of calculations!  Hence the
> request
> >>> for the "bad for the health" sign. Btw, gromacs issues a lot of
> warnings,
> >>> but not this one :D
> >>>
> >>> What a bright idea to switch from angstroms to nanometers! Now the gro
> >>> files carry a lot of useless zeros.
> >>>
> >>>
> >>> --
> >>> gmx-users mailing listgmx-users@gromacs.org
> >>> http://lists.gromacs.org/mailman/listinfo/gmx-users
> >>> Please searc

Re: [gmx-users] to gro or not to gro

[Tsjerk Wassenaar]

My my. Why is it a fault to adhere to ISO units (nm) over non-standard
(A)? It's a choice, but a choice is not faulty. The consequences may
be undesirable. But shouldn't a user, certainly a computation
scientist, understand the file formats, as an experimentalist should
know its solvent? And know the consequences of using one over another?
Mark is correct to state that a picometer uncertainty at the start has
no consequences for molecular dynamics simulations. For single point
eneriges they will have. But no one ever forced anyone to use GRO
rather than PDB format. That's the choice the researcher makes. And,
at least in my tutorial, that difference between GRO and PDB format is
stressed. The choice to use standard units is historical, and lies
decades back in time. Could we now change it to A, because a 'faulty'
choice was made?

I'm terribly sorry that you need to do a lot of work again, Igor. But
you can't shove the blame in another's shoes. You overlooked
something, lead by presumptions about standardization in units and
file formats. May I wonder why you only found out now, after all the
work has been done? This difference would have showed up with the
first test, right? But again, it's not us against you, and I'm sorry
you have to go through this. Trust me, most of us have had such
moments, although with a different aspect.

Best,

Tsjerk

On Sun, Nov 27, 2011 at 11:03 AM, Igor Druz  wrote:
> You can put whichever spin you like into what is said, but there is a clear
> (and unnecessary) fault with the way coordinates are stored in gro files
> when made from pdb using pdb2gmx.
>
> On Sun, Nov 27, 2011 at 12:39 AM, Mark Abraham 
> wrote:
>>
>> On 27/11/2011 5:07 AM, Igor Druz wrote:
>>
>> On Sat, Nov 26, 2011 at 5:35 PM,  wrote
>>>
>>> 1. why repeat the calculations? If you're talking about simulations then
>>> there is no need to repeat them due to this. You will get different answers
>>> with the same starting coordinates if you simply change the initial
>>> velocities. If you're talking about instantaneous energy calculations then I
>>> suppose you might need to redo it, but they should be very quick, right?
>>>
>>
>> The calculations must be repeated. You are making irrelevant assumptions
>> without knowing what the calculations are for.
>>
>> You asserted that there should have been a warning without explaining why
>> this loss of precision was material. Chris knew that many uses of pdb2gmx
>> change the atomic configuration considerably, e.g. new hydrogen positions,
>> building termini, etc. so that any change of precision of coordinates is not
>> a big deal, and even less important once a simulation has run afterwards. If
>> you want to engage in constructive dialogue, please explain why the loss of
>> precision was material, in order to clarify the reason for your request for
>> a warning message. If you wish to blow off steam, please do it elsewhere.
>>
>>
>>>
>>> 2. The .gro files do not carry useless zeroes. you have it backwards...
>>> the gro files end up with fewer digits.
>>>
>>
>> 0.417 or 4.172. Shall I continue? I know which one I prefer.
>>
>>>
>>> 3. it's a little annoying to find out that you already knew the answer.
>>> Why not state that at the outset? Unless I misunderstand this point, this
>>> will mark the end of my comments since holding back information on purpose
>>> just wastes people's time.
>>>
>>
>> Check my 1st e-mail, please. It is NOT asking for clarification. It is
>> requesting an explicit warning message.
>>
>> There's nothing to warn about. You thought that "switching from Angstrom
>> to nanometers" was significant somehow, and then assumed that different file
>> formats would definitely contain identical information, and didn't check
>> their contents.
>>
>> Mark
>>
>>
>>>
>>> Chris.
>>>
>>> -- original message --
>>>
>>> I already knew the reason. But I had to find this out hard way. Now
>>> facing
>>> a dreading prospect of repeating tons of calculations!  Hence the request
>>> for the "bad for the health" sign. Btw, gromacs issues a lot of warnings,
>>> but not this one :D
>>>
>>> What a bright idea to switch from angstroms to nanometers! Now the gro
>>> files carry a lot of useless zeros.
>>>
>>>
>>> --
>>> gmx-users mailing list    gmx-users@gromacs.org
>>> http://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 thewww
>>> interface or send it to gmx-users-requ...@gromacs.org.
>>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>>
>>
>>
>>
>> --
>> gmx-users mailing list    gmx-users@gromacs.org
>> http://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.
>> Ca

Re: [gmx-users] to gro or not to gro

[Igor Druz]

You can put whichever spin you like into what is said, but there is a clear
(and unnecessary) fault with the way coordinates are stored in gro files
when made from pdb using pdb2gmx.

On Sun, Nov 27, 2011 at 12:39 AM, Mark Abraham wrote:

>  On 27/11/2011 5:07 AM, Igor Druz wrote:
>
> On Sat, Nov 26, 2011 at 5:35 PM,  wrote
>
>> 1. why repeat the calculations? If you're talking about simulations then
>> there is no need to repeat them due to this. You will get different answers
>> with the same starting coordinates if you simply change the initial
>> velocities. If you're talking about instantaneous energy calculations then
>> I suppose you might need to redo it, but they should be very quick, right?
>>
>>
>  The calculations must be repeated. You are making irrelevant assumptions
> without knowing what the calculations are for.
>
>
> You asserted that there should have been a warning without explaining why
> this loss of precision was material. Chris knew that many uses of pdb2gmx
> change the atomic configuration considerably, e.g. new hydrogen positions,
> building termini, etc. so that any change of precision of coordinates is
> not a big deal, and even less important once a simulation has run
> afterwards. If you want to engage in constructive dialogue, please explain
> why the loss of precision was material, in order to clarify the reason for
> your request for a warning message. If you wish to blow off steam, please
> do it elsewhere.
>
>
>
>
>> 2. The .gro files do not carry useless zeroes. you have it backwards...
>> the gro files end up with fewer digits.
>>
>>
>  0.417 or 4.172. Shall I continue? I know which one I prefer.
>
>
>> 3. it's a little annoying to find out that you already knew the answer.
>> Why not state that at the outset? Unless I misunderstand this point, this
>> will mark the end of my comments since holding back information on purpose
>> just wastes people's time.
>>
>>
>  Check my 1st e-mail, please. It is NOT asking for clarification. It is
> requesting an explicit warning message.
>
>
> There's nothing to warn about. You thought that "switching from Angstrom
> to nanometers" was significant somehow, and then assumed that different
> file formats would definitely contain identical information, and didn't
> check their contents.
>
> Mark
>
>
>
>
>> Chris.
>>
>> -- original message --
>>
>> I already knew the reason. But I had to find this out hard way. Now facing
>> a dreading prospect of repeating tons of calculations!  Hence the request
>> for the "bad for the health" sign. Btw, gromacs issues a lot of warnings,
>> but not this one :D
>>
>> What a bright idea to switch from angstroms to nanometers! Now the gro
>> files carry a lot of useless zeros.
>>
>>
>> --
>> gmx-users mailing listgmx-users@gromacs.org
>> http://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 thewww
>> interface or send it to gmx-users-requ...@gromacs.org.
>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>
>
>
>
>
> --
> gmx-users mailing listgmx-users@gromacs.org
> http://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
>
-- 
gmx-users mailing listgmx-users@gromacs.org
http://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

[gmx-users] how to set files for free energy caculation?

[zhongjin]

Dear GMX users,
  Recently, I want to caculate the free energy for K+->NA+ in bulk with 
GMX4.5.4 using charmm 27 force field.  I change ion.itp
[ moleculetype ]
; molname nrexcl
K  1
[ atoms ]
; id at type    res nr  residu name at name  cg nr   charge   
1 POT    1 K K  1   1   
 
to
 
[ moleculetype ]
; molname nrexcl
K  1
[ atoms ]
; id at type    res nr  residu name at name  cg nr   charge   mass 
typeB    chargeB  massB
1 POT    1 K K  1   1 39.102000  SOD    1   
22.989770 
#ifdef POSRES_K
[ position_restraints ]
;  i funct   fcx    fcy    fcz
   1    1    100    100 100
#endif
 
and include it into .top file.
 
And I set .mdp file
; Free energy control stuff
free-energy  = yes
init-lambda  = 0.0
delta-lambda = 0
foreign_lambda   = 0.05
sc-alpha = 0.5
sc-power = 1.0
sc-sigma = 0.3
nstdhdl  = 10
separate-dhdl-file   = yes
dhdl-derivatives = yes
dh_hist_size = 0
dh_hist_spacing  = 0.1
couple-moltype   = K
couple-lambda0   = vdw-q
couple-lambda1   = vdw-q
couple-intramol  = no
 
however when I do EM, there are two warnings and stop.
WARNING 1 [file min.mdp, line 329]:
  The lambda=0 and lambda=1 states for coupling are identical
Generated 28 of the 28 non-bonded parameter combinations
Generating 1-4 interactions: fudge = 1
Generated 28 of the 28 1-4 parameter combinations
WARNING 2 [file ion.itp, line 22]:
  Some parameters for bonded interaction involving perturbed atoms are
  specified explicitly in state A, but not B - copying A to B
Excluding 3 bonded neighbours molecule type 'gra'
Excluding 2 bonded neighbours molecule type 'SOL'
Excluding 1 bonded neighbours molecule type 'K'
Coupling 1 copies of molecule type 'K'
NOTE 1 [file topol.top, line 16]:
  System has non-zero total charge: 1.00e+00
  

Analysing residue names:
There are: 1  Other residues
There are:   531  Water residues
There are: 1    Ion residues
Analysing residues not classified as Protein/DNA/RNA/Water and splitting into 
groups...
Analysing residues not classified as Protein/DNA/RNA/Water and splitting into 
groups...
Number of degrees of freedom in T-Coupling group rest is 3660.00
Largest charge group radii for Van der Waals: 0.040, 0.040 nm
Largest charge group radii for Coulomb:   0.079, 0.079 nm
Calculating fourier grid dimensions for X Y Z
Using a fourier grid of 20x20x30, spacing 0.115 0.115 0.115
Estimate for the relative computational load of the PME mesh part: 0.36
This run will generate roughly 22 Mb of data
There was 1 note
There were 2 warnings
---
Program grompp, VERSION 4.5.4
Source code file: grompp.c, line: 1582
Fatal error:
Too many warnings (2), grompp terminated.
If you are sure all warnings are harmless, use the -maxwarn option.
For more information and tips for troubleshooting, please check the GROMACS
website at http://www.gromacs.org/Documentation/Errors
---
"Your Proposal is Accepted" (Men In Black)
 
It seems that 
[ moleculetype ]
; molname nrexcl
K  1
[ atoms ]
; id at type    res nr  residu name at name  cg nr   charge   mass 
typeB    chargeB  massB
1 POT    1 K K  1   1 39.102000  SOD    1   
22.989770 
do not take effect.
 
Thanks in advance!
 
Zhongjin He-- 
gmx-users mailing listgmx-users@gromacs.org
http://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

[gmx-users] Add ligand molecules in a lipid bilayer

[parto haghighi]

Dear gmx_users,

I am working on lipid/drug molecule system.
I could make the ligand topology by PRODRG and get DMPC.itp from
http://moose.bio.ucalgary.ca/index.php?page=Structures_and_Topologies.

To add ligand molecule I first changed its coordinate by:
editconf -f drg.gro -o drg_newbox.gro -c -box  6.17600   6.17600   5.5

then add drg_newbox.gro to my bilayer by:
cat drg_newbox.gro dmpc_whole.gro > system.gro

How can I add 6 ligand molecules in lipid bilayer symmetrically at each
side of membrane?
What is gromacs command to add molecules in bilayer (except editconf)?

Thanks a lot in advance.
Parto
-- 
gmx-users mailing listgmx-users@gromacs.org
http://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