Re: [gmx-users] QMMM with GROMACS and DFTB3

[dgfd dgdfg]

http://wwwuser.gwdg.de/~ggroenh/qmmm.html  
or
8.13.1 ORCA and Gromacs chapter
in orca4 manual.

What will be the speed of calculation?
-- 
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] Umbrella sampling: window distance - harmonic force constant

[Hermann, Johannes]

Dear All, dear Justin,

I am playing around with my umbrella sampling setup and I was looking at 
your paper which you linked in your umbrella sampling tutorial 
("Assessing the Stability of Alzheimer’s Amyloid Protofibrils Using 
Molecular Dynamics").
Up to a distance of 2nm you use a 0.1nm spacing, beyond a 0.2nm spacing. 
Which harmonic force constant pull_coord1_k do you use for the 0.1nm 
spacing? In comparison to the 0.2nm spacing, where pull_coord1_k=1000.
Is there a general rule of thumb between window distance and force 
constant? Or is it always try and error while checking the histograms?

Thank you very much.

All the best

Johannes

--
__
*Technische Universität München*
*Johannes Hermann, M.Sc.*
Lehrstuhl für Bioverfahrenstechnik
Boltzmannstr. 15
D-85748 Garching
Tel: +49 8928915730
Fax: +49 8928915714

Email: j.herm...@lrz.tum.de
http://www.biovt.mw.tum.de/

--
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] Box shape changing from rectangle to parallelogram at NVT

[Marlon Sidore]

Hello,

I am trying to set up a DAFT approach for membrane segments using MARTINI (
http://www.cgmartini.nl/index.php/329-the-daft-approach-to-membrane-protein-assembly)
and I've made simulation boxes as small as in the original paper.
However, I'm not sure if everything is fine or not: the shape of the box
changes from a rectangle to a parallelogram (see pictures).
Since I've never seen that, I'm wondering if that's a problem - boundary
conditions don't seem problematic (no holes when vizualizing them with
VMD), but still I doubt.

I am linking to my drive since eduroam won't let me use another image
hosting site:
https://drive.google.com/open?id=1PKtivk4lSygMgWey-N5PGhwGZ3JQJJw_

Best regards,

Marlon Sidore


PhD Student
Laboratoire d'Ingénierie des Systèmes Macromoléculaire (LISM)
CNRS - UMR7255
31, Chemin Joseph Aiguier
13402 cedex 20 Marseille
France
-- 
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] What's new in GROMACS 2018? - a BioExcel webinar

[Mark Abraham]

Hi all,

Just a quick reminder that our webinar about GROMACS 2018 is on shortly -
please register and join me to hear more!

Mark

On Mon, Mar 26, 2018 at 3:26 PM Rossen Apostolov  wrote:

> Hi again,
>
> We just realized there was a mistake on the website, and the *webinar is
> scheduled for 13:00 BST (UK) / 14:00 CEST time.*
>
> The GoToWebinar platform, where you register, has the correct time.
>
> Rossen
>
>
> On 2018-03-26 11:25, Rossen Apostolov wrote:
> >
> > Dear GROMACS users,
> >
> > BioExcel CoE (https://bioexcel.eu) is organizing *tomorrow from 14:00
> > GMT (15:00 CEST) *a webinar on the features, hardware support and
> > various enhancements in the latest 2018 major release. At the end of
> > the presentation, Mark Abraham, the GROMACS development manager, will
> > answer your questions regarding the release.
> >
> > You can register here:
> >
> https://bioexcel.eu/webinar-gromacs-2018-overview-of-the-new-features-and-capabilities-2018-03-27/
> >
> > Note that we have a limit of 100 attendees and there are already over
> > 50 registrants.
> >
> > Rossen
> >
>
> --
> 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.

[gmx-users] gmx mindist error

[João Henriques]

Dear users and developers,

I am trying to use gmx mindist to calculate the minimum distance between
periodic images but I get the following error:

Fatal error:
pbc = no is not supported by g_mindist

This is the command I am running:

gmx_mpi mindist -f output.xtc -s structure.pdb -od -pi -pbc

Now, I have to admit that the .xtc file I'm using is generated by ACEMD and
not mdrun, but I used gmx dump to check it and everything looks sane. The
cuboid box sizes are clearly specified and I don't understand what the
problem is...

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?

Thank you for your attention,
Best regards,
J
-- 
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 Henriques]

"Is gmx mindist reading the box vector lengths from the structure file
instead?" ---> That would make no sense, since NPT simulations have varying
box sizes. Silly question, sorry. Still, I would really appreciate if
anyone could help me solving this issue.

J

On Tue, Mar 27, 2018 at 3:59 PM, João Henriques <
joao.m.a.henriq...@gmail.com> wrote:

> Dear users and developers,
>
> I am trying to use gmx mindist to calculate the minimum distance between
> periodic images but I get the following error:
>
> Fatal error:
> pbc = no is not supported by g_mindist
>
> This is the command I am running:
>
> gmx_mpi mindist -f output.xtc -s structure.pdb -od -pi -pbc
>
> Now, I have to admit that the .xtc file I'm using is generated by ACEMD
> and not mdrun, but I used gmx dump to check it and everything looks sane.
> The cuboid box sizes are clearly specified and I don't understand what the
> problem is...
>
> 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?
>
> Thank you for your attention,
> Best regards,
> J
>
-- 
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

[Justin Lemkul]

On 3/27/18 9:59 AM, João Henriques wrote:

Dear users and developers,

I am trying to use gmx mindist to calculate the minimum distance between
periodic images but I get the following error:

Fatal error:
pbc = no is not supported by g_mindist

This is the command I am running:

gmx_mpi mindist -f output.xtc -s structure.pdb -od -pi -pbc

Now, I have to admit that the .xtc file I'm using is generated by ACEMD and
not mdrun, but I used gmx dump to check it and everything looks sane. The
cuboid box sizes are clearly specified and I don't understand what the
problem is...

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.

[gmx-users] Excessive and gradually increasing memory usage with OpenCL

[Albert Mao]

Hello!

I'm trying to run molecular dynamics on a fairly large system
containing approximately 25 atoms. The simulation runs well for
about 10 steps and then gets killed by the queueing engine due to
exceeding the swap space usage limit. The compute node I'm using has
12 cores in two sockets, three GPUs, and 8 GB of memory. I'm using
GROMACS 2018 and allowing mdrun to delegate the workload
automatically, resulting in three thread-MPI ranks each with one GPU
and four OpenMP threads. The queueing engine reports the following
usage:

TERM_SWAP: job killed after reaching LSF swap usage limit.
Exited with exit code 131.
Resource usage summary:
CPU time   :  50123.00 sec.
Max Memory :  4671 MB
Max Swap   : 30020 MB
Max Processes  : 5
Max Threads:35

Even though it's a large system, by my rough estimate, the simulation
should not need much more than 0.5 gigabytes of memory; 4.6 GB seems
like too much and 30 GB is completely ridiculous.
Indeed, running the system on a similar node without GPUs is working
well (but slowly), consuming about 0.65 GB and 2 GB of swap.

I also don't understand why 35 threads got created.

Could there be a memory leak somewhere in the OpenCL code? Any
suggestions on preventing this memory usage expansion would be greatly
appreciated.

I've included relevant output from mdrun with system and configuration
information at the end of this message. I'm using OpenCL despite
having Nvidia GPUs because of a sad problem where building with CUDA
support fails due to the C compiler being "too new".

Thanks!
-Albert Mao

GROMACS:  gmx mdrun, version 2018
Executable:   /data/albertmaolab/software/gromacs/bin/gmx
Data prefix:  /data/albertmaolab/software/gromacs
Command line:

  gmx mdrun -v -pforce 1 -s blah.tpr -deffnm blah -cpi blah.cpt

GROMACS version:2018
Precision:  single
Memory model:   64 bit
MPI library:thread_mpi
OpenMP support: enabled (GMX_OPENMP_MAX_THREADS = 64)
GPU support:OpenCL
SIMD instructions:  SSE4.1
FFT library:fftw-3.2.1
RDTSCP usage:   disabled
TNG support:enabled
Hwloc support:  hwloc-1.5.0
Tracing support:disabled
Built on:   2018-02-22 07:25:43
Built by:   ah...@eris1pm01.research.partners.org [CMAKE]
Build OS/arch:  Linux 2.6.32-431.29.2.el6.x86_64 x86_64
Build CPU vendor:   Intel
Build CPU brand:Common KVM processor
Build CPU family:   15   Model: 6   Stepping: 1
Build CPU features: aes apic clfsh cmov cx8 cx16 intel lahf mmx msr
nonstop_tsc pcid pclmuldq pdpe1gb popcnt pse sse2 sse3 sse4.1 sse4.2
ssse3
C compiler: /data/albertmaolab/software/gcc/bin/gcc GNU 7.3.0
C compiler flags:-msse4.1 -O3 -DNDEBUG -funroll-all-loops
-fexcess-precision=fast
C++ compiler:   /data/albertmaolab/software/gcc/bin/g++ GNU 7.3.0
C++ compiler flags:  -msse4.1-std=c++11   -O3 -DNDEBUG
-funroll-all-loops -fexcess-precision=fast
OpenCL include dir: /apps/lib-osver/cuda/8.0.61/include
OpenCL library: /apps/lib-osver/cuda/8.0.61/lib64/libOpenCL.so
OpenCL version: 1.2

Running on 1 node with total 12 cores, 12 logical cores, 3 compatible GPUs
Hardware detected:
  CPU info:
Vendor: Intel
Brand:  Intel(R) Xeon(R) CPU   X5675  @ 3.07GHz
Family: 6   Model: 44   Stepping: 2
Features: aes apic clfsh cmov cx8 cx16 htt intel lahf mmx msr
nonstop_tsc pcid pclmuldq pdcm pdpe1gb popcnt pse rdtscp sse2 sse3
sse4.1 sse4.2 ssse3
  Hardware topology: Full, with devices
Sockets, cores, and logical processors:
  Socket  0: [   0] [   2] [   4] [   6] [   8] [  10]
  Socket  1: [   1] [   3] [   5] [   7] [   9] [  11]
Numa nodes:
  Node  0 (25759080448 bytes mem):   0   2   4   6   8  10
  Node  1 (25769799680 bytes mem):   1   3   5   7   9  11
  Latency:
   0 1
 0  1.00  2.00
 1  2.00  1.00
Caches:
  L1: 32768 bytes, linesize 64 bytes, assoc. 8, shared 1 ways
  L2: 262144 bytes, linesize 64 bytes, assoc. 8, shared 1 ways
  L3: 12582912 bytes, linesize 64 bytes, assoc. 16, shared 6 ways
PCI devices:
  :04:00.0  Id: 8086:10c9  Class: 0x0200  Numa: -1
  :04:00.1  Id: 8086:10c9  Class: 0x0200  Numa: -1
  :05:00.0  Id: 15b3:6746  Class: 0x0280  Numa: -1
  :06:00.0  Id: 10de:06d2  Class: 0x0302  Numa: -1
  :01:03.0  Id: 1002:515e  Class: 0x0300  Numa: -1
  :00:1f.2  Id: 8086:3a20  Class: 0x0101  Numa: -1
  :00:1f.5  Id: 8086:3a26  Class: 0x0101  Numa: -1
  :14:00.0  Id: 10de:06d2  Class: 0x0302  Numa: -1
  :11:00.0  Id: 10de:06d2  Class: 0x0302  Numa: -1
  GPU info:
Number of GPUs detected: 3
#0: name: Tesla M2070, vendor: NVIDIA Corporation, device version:
OpenCL 1.1 CUDA, stat: compatible
#1: name: Tesla M2070, vendor: NVIDIA Corporation, device version:
OpenCL 1.1 CUDA, stat: compatible
#2: name: Tesla M2070, vendor: NVIDIA Corporation, device 

Re: [gmx-users] gmx mindist error

[João Henriques]

Thanks Justin, I was really trying to avoid making a tpr file, because my
ACEMD uses the Amber format. I sort of hoped gmx mindist could figure it
out from the box components present in the xtc file. In principle, couldn't
it be done by using that info alone? Just curious.

J

On Tue, Mar 27, 2018 at 4:04 PM, Justin Lemkul  wrote:

>
>
> On 3/27/18 9:59 AM, João Henriques wrote:
>
>> Dear users and developers,
>>
>> I am trying to use gmx mindist to calculate the minimum distance between
>> periodic images but I get the following error:
>>
>> Fatal error:
>> pbc = no is not supported by g_mindist
>>
>> This is the command I am running:
>>
>> gmx_mpi mindist -f output.xtc -s structure.pdb -od -pi -pbc
>>
>> Now, I have to admit that the .xtc file I'm using is generated by ACEMD
>> and
>> not mdrun, but I used gmx dump to check it and everything looks sane. The
>> cuboid box sizes are clearly specified and I don't understand what the
>> problem is...
>>
>> 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.

Re: [gmx-users] Excessive and gradually increasing memory usage with OpenCL

[Mark Abraham]

Hi,

There's too little information for us to guess where the problem could be -
mdrun could be leaking memory, or it could be an issue where the
driver/runtime are also doing it.

Since you're using a version of gcc you compiled/installed yourself, do
yourself a favour and get a version that's supported by the CUDA you have
(or update it also). The native CUDA  performance will far outstrip the
OpenCL one.


Mark

On Tue, Mar 27, 2018 at 4:10 PM Albert Mao  wrote:

> Hello!
>
> I'm trying to run molecular dynamics on a fairly large system
> containing approximately 25 atoms. The simulation runs well for
> about 10 steps and then gets killed by the queueing engine due to
> exceeding the swap space usage limit. The compute node I'm using has
> 12 cores in two sockets, three GPUs, and 8 GB of memory. I'm using
> GROMACS 2018 and allowing mdrun to delegate the workload
> automatically, resulting in three thread-MPI ranks each with one GPU
> and four OpenMP threads. The queueing engine reports the following
> usage:
>
> TERM_SWAP: job killed after reaching LSF swap usage limit.
> Exited with exit code 131.
> Resource usage summary:
> CPU time   :  50123.00 sec.
> Max Memory :  4671 MB
> Max Swap   : 30020 MB
> Max Processes  : 5
> Max Threads:35
>
> Even though it's a large system, by my rough estimate, the simulation
> should not need much more than 0.5 gigabytes of memory; 4.6 GB seems
> like too much and 30 GB is completely ridiculous.
> Indeed, running the system on a similar node without GPUs is working
> well (but slowly), consuming about 0.65 GB and 2 GB of swap.
>
> I also don't understand why 35 threads got created.
>
> Could there be a memory leak somewhere in the OpenCL code? Any
> suggestions on preventing this memory usage expansion would be greatly
> appreciated.
>
> I've included relevant output from mdrun with system and configuration
> information at the end of this message. I'm using OpenCL despite
> having Nvidia GPUs because of a sad problem where building with CUDA
> support fails due to the C compiler being "too new".
>
> Thanks!
> -Albert Mao
>
> GROMACS:  gmx mdrun, version 2018
> Executable:   /data/albertmaolab/software/gromacs/bin/gmx
> Data prefix:  /data/albertmaolab/software/gromacs
> Command line:
>
>   gmx mdrun -v -pforce 1 -s blah.tpr -deffnm blah -cpi blah.cpt
>
> GROMACS version:2018
> Precision:  single
> Memory model:   64 bit
> MPI library:thread_mpi
> OpenMP support: enabled (GMX_OPENMP_MAX_THREADS = 64)
> GPU support:OpenCL
> SIMD instructions:  SSE4.1
> FFT library:fftw-3.2.1
> RDTSCP usage:   disabled
> TNG support:enabled
> Hwloc support:  hwloc-1.5.0
> Tracing support:disabled
> Built on:   2018-02-22 07:25:43
> Built by:   ah...@eris1pm01.research.partners.org [CMAKE]
> Build OS/arch:  Linux 2.6.32-431.29.2.el6.x86_64 x86_64
> Build CPU vendor:   Intel
> Build CPU brand:Common KVM processor
> Build CPU family:   15   Model: 6   Stepping: 1
> Build CPU features: aes apic clfsh cmov cx8 cx16 intel lahf mmx msr
> nonstop_tsc pcid pclmuldq pdpe1gb popcnt pse sse2 sse3 sse4.1 sse4.2
> ssse3
> C compiler: /data/albertmaolab/software/gcc/bin/gcc GNU 7.3.0
> C compiler flags:-msse4.1 -O3 -DNDEBUG -funroll-all-loops
> -fexcess-precision=fast
> C++ compiler:   /data/albertmaolab/software/gcc/bin/g++ GNU 7.3.0
> C++ compiler flags:  -msse4.1-std=c++11   -O3 -DNDEBUG
> -funroll-all-loops -fexcess-precision=fast
> OpenCL include dir: /apps/lib-osver/cuda/8.0.61/include
> OpenCL library: /apps/lib-osver/cuda/8.0.61/lib64/libOpenCL.so
> OpenCL version: 1.2
>
> Running on 1 node with total 12 cores, 12 logical cores, 3 compatible GPUs
> Hardware detected:
>   CPU info:
> Vendor: Intel
> Brand:  Intel(R) Xeon(R) CPU   X5675  @ 3.07GHz
> Family: 6   Model: 44   Stepping: 2
> Features: aes apic clfsh cmov cx8 cx16 htt intel lahf mmx msr
> nonstop_tsc pcid pclmuldq pdcm pdpe1gb popcnt pse rdtscp sse2 sse3
> sse4.1 sse4.2 ssse3
>   Hardware topology: Full, with devices
> Sockets, cores, and logical processors:
>   Socket  0: [   0] [   2] [   4] [   6] [   8] [  10]
>   Socket  1: [   1] [   3] [   5] [   7] [   9] [  11]
> Numa nodes:
>   Node  0 (25759080448 bytes mem):   0   2   4   6   8  10
>   Node  1 (25769799680 bytes mem):   1   3   5   7   9  11
>   Latency:
>0 1
>  0  1.00  2.00
>  1  2.00  1.00
> Caches:
>   L1: 32768 bytes, linesize 64 bytes, assoc. 8, shared 1 ways
>   L2: 262144 bytes, linesize 64 bytes, assoc. 8, shared 1 ways
>   L3: 12582912 bytes, linesize 64 bytes, assoc. 16, shared 6 ways
> PCI devices:
>   :04:00.0  Id: 8086:10c9  Class: 0x0200  Numa: -1
>   :04:00.1  Id: 8086:10c9  Class: 0x0200  Numa: -1
>   :05:00.0  Id: 15b3:6746  Class: 0x0280  Numa

Re: [gmx-users] QMMM with GROMACS and DFTB3

[S M Bargeen Turzo]

Thanks. I found in the ORCA manual(8.14.1) that ORCA can only be interfaced
with 4.0.4 up to version 4.5.5 of GROMACS and nothing is mentioned about
2016 and/or 2018.
​​When you ask about the speed of calculation, I am not exactly sure what
you mean by that. If you are asking how big my system is, then it contains
about 13870 atoms, it is a protein and a small molecule. Interested to find
reaction pathway through QM/MM optimization(geometry opt, transition state
opt).


On Tue, Mar 27, 2018 at 5:20 AM, <
gromacs.org_gmx-users-requ...@maillist.sys.kth.se> wrote:

> Send gromacs.org_gmx-users mailing list submissions to
> gromacs.org_gmx-users@maillist.sys.kth.se
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users
> or, via email, send a message with subject or body 'help' to
> gromacs.org_gmx-users-requ...@maillist.sys.kth.se
>
> You can reach the person managing the list at
> gromacs.org_gmx-users-ow...@maillist.sys.kth.se
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gromacs.org_gmx-users digest..."
>
>
> Today's Topics:
>
>1. Re: Confusions about rlist>=rcoulomb and rlist>=rvdw in the
>   mdp options in Gromacs 2016 (or 2018) user guide?? (Szil?rd P?ll)
>2. Re: cudaMallocHost filed: unknown error (Szil?rd P?ll)
>3. QMMM with GROMACS and DFTB3 (S M Bargeen Turzo)
>4. Re: QMMM with GROMACS and DFTB3 (dgfd dgdfg)
>5. Umbrella sampling: window distance - harmonic force constant
>   (Hermann, Johannes)
>6. Box shape changing from rectangle to parallelogram at NVT
>   (Marlon Sidore)
>
>
> --
>
> Message: 1
> Date: Mon, 26 Mar 2018 15:27:03 +0200
> From: Szil?rd P?ll 
> To: Discussion list for GROMACS users 
> Cc: Discussion list for GROMACS users
> 
> Subject: Re: [gmx-users] Confusions about rlist>=rcoulomb and
> rlist>=rvdw in the mdp options in Gromacs 2016 (or 2018) user
> guide??
> Message-ID:
>  5ojbmzx...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> rlist >= rcoulomb / rvdw is the correct one, the list cutoff has to be
> at least as long as the longest of the interaction cut-offs.
> --
> Szil?rd
>
>
> On Mon, Mar 26, 2018 at 1:05 PM, huolei peng 
> wrote:
> > In the user guide of Gromacs 2016 (or 2018), it shows " rlist>=rcoulomb "
> >  or "rlist>=rvdw" in several places (see the links below), which are in
> > contrast to those in version of 5.15.  Are those changes due to typos?
> > Thanks.
> >
> >
> > http://manual.gromacs.org/documentation/2016-current/
> user-guide/mdp-options.html
> >
> > http://manual.gromacs.org/documentation/current/user-
> guide/mdp-options.html
> >
> > http://manual.gromacs.org/documentation/5.1-current/
> user-guide/mdp-options.html
> >
> >
> >
> > Best,
> >
> > Peng
> > --
> > 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.
>
>
> --
>
> Message: 2
> Date: Mon, 26 Mar 2018 15:29:35 +0200
> From: Szil?rd P?ll 
> To: Discussion list for GROMACS users 
> Subject: Re: [gmx-users] cudaMallocHost filed: unknown error
> Message-ID:
>  gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> As a side-note, your mdrun invocation does not seem suitable for GPU
> accelerated runs, you'd most likely be better of running fewer ranks.
> --
> Szil?rd
>
>
> On Fri, Mar 23, 2018 at 9:26 PM, Christopher Neale
>  wrote:
> > Hello,
> >
> > I am running gromacs 5.1.2 on single nodes where the run is set to use
> 32 cores and 4 GPUs. The run command is:
> >
> > mpirun -np 32 gmx_mpi mdrun -deffnm MD -maxh $maxh -dd 4 4 2 -npme 0
> -gpu_id  -ntomp 1 -notunepme
> >
> > Some of my runs die with this error:
> > cudaMallocHost of size 1024128 bytes failed: unknown error
> >
> > Below is the relevant part of the .log file. Searching the internet
> didn't turn up any solutions. I'll contact sysadmins if you think this is
> likely some problem with the hardware or rogue jobs. In my testing, a
> collection of 24 jobs had 6 die with this same error message (including the
> "1024128 bytes" and "pmalloc_cuda.cu, line: 70"). All on different nodes,
> and all those node next took repeat jobs that run fine. When the error
> occured, it was always right at the start of the run.
> >
> >
> > Thank you for your help,
> > Chris.
> >
> >
> >
> > Command line:
> >   gmx_mpi mdrun -deffnm MD -maxh 0.9 -dd 4 4 2 -npme 0 -gpu_id
>  -ntomp 1 -notunepme
> >
> >
> > Number of logical cores

Re: [gmx-users] gmx mindist error

[Mark Abraham]

Hi,

The box sizes say nothing about whether the boundary is fully or partially
periodic, or screw, or not.

Mark

On Tue, Mar 27, 2018, 16:13 João Henriques 
wrote:

> Thanks Justin, I was really trying to avoid making a tpr file, because my
> ACEMD uses the Amber format. I sort of hoped gmx mindist could figure it
> out from the box components present in the xtc file. In principle, couldn't
> it be done by using that info alone? Just curious.
>
> J
>
> On Tue, Mar 27, 2018 at 4:04 PM, Justin Lemkul  wrote:
>
> >
> >
> > On 3/27/18 9:59 AM, João Henriques wrote:
> >
> >> Dear users and developers,
> >>
> >> I am trying to use gmx mindist to calculate the minimum distance between
> >> periodic images but I get the following error:
> >>
> >> Fatal error:
> >> pbc = no is not supported by g_mindist
> >>
> >> This is the command I am running:
> >>
> >> gmx_mpi mindist -f output.xtc -s structure.pdb -od -pi -pbc
> >>
> >> Now, I have to admit that the .xtc file I'm using is generated by ACEMD
> >> and
> >> not mdrun, but I used gmx dump to check it and everything looks sane.
> The
> >> cuboid box sizes are clearly specified and I don't understand what the
> >> problem is...
> >>
> >> 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.

Re: [gmx-users] QMMM with GROMACS and DFTB3

[dgfd dgdfg]

Im am also starting to perform QM/MM in GROMACS for dyes in ground and excited 
states in supramolecules, but didn't decided yet what QM package (MOPAC, ORCA 
or GAMESS-US) will be. But aware of calculation speed of DFT QM in 
non-empirical methods for average-size molecules I suppose that needed for MD 
number of steps (~10^6) willl be completely unaccesible. If ORCA will work with 
latest GROMACS I shall inform.
-- 
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 Henriques]

I see, I didn't consider that. I was strictly thinking about the geometry
of the box.

Anyway, with some tricks I managed to build a tpr and am now able to
calculate the mindist to the periodic image.

Thanks!
J

On 18:19, Tue, Mar 27, 2018 Mark Abraham  wrote:

> Hi,
>
> The box sizes say nothing about whether the boundary is fully or partially
> periodic, or screw, or not.
>
> Mark
>
> On Tue, Mar 27, 2018, 16:13 João Henriques 
> wrote:
>
> > Thanks Justin, I was really trying to avoid making a tpr file, because my
> > ACEMD uses the Amber format. I sort of hoped gmx mindist could figure it
> > out from the box components present in the xtc file. In principle,
> couldn't
> > it be done by using that info alone? Just curious.
> >
> > J
> >
> > On Tue, Mar 27, 2018 at 4:04 PM, Justin Lemkul  wrote:
> >
> > >
> > >
> > > On 3/27/18 9:59 AM, João Henriques wrote:
> > >
> > >> Dear users and developers,
> > >>
> > >> I am trying to use gmx mindist to calculate the minimum distance
> between
> > >> periodic images but I get the following error:
> > >>
> > >> Fatal error:
> > >> pbc = no is not supported by g_mindist
> > >>
> > >> This is the command I am running:
> > >>
> > >> gmx_mpi mindist -f output.xtc -s structure.pdb -od -pi -pbc
> > >>
> > >> Now, I have to admit that the .xtc file I'm using is generated by
> ACEMD
> > >> and
> > >> not mdrun, but I used gmx dump to check it and everything looks sane.
> > The
> > >> cuboid box sizes are clearly specified and I don't understand what the
> > >> problem is...
> > >>
> > >> 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.

[gmx-users] Number of Xeon cores per GTX 1080Ti

[Jochen Hub]

Dear Gromacs community, dear Mark,

Mark showed in the webinar today that having more than 8 Xeon E5-26XXv4 
cores does not help when using a GTX 1080Ti and PME on the GPU.


Unfortunately, there were no data points between 4 and 8 CPU cores, 
hence it was not clear at which #cores the performance actually levels 
off. With a GTX 1080 (not Ti) I once found that having more than 5 Xeon 
cores does not help, if not having UB potentials, but I don't have a 
1080Ti at hand to test for that.


So my questions are:

- At which number of E5-26XXv4 cores does the performance for common 
systems level off with a 1080Ti for your test system (GLIC)?


- Does the answer depend strongly on the mdp settings (in particular on 
the LJ cutoff)?


This would help us a lot when choosing the appropriate CPU for a 1080Ti.

Many thanks for any suggestions,
Jochen

--
---
Dr. Jochen Hub
Computational Molecular Biophysics Group
Institute for Microbiology and Genetics
Georg-August-University of Göttingen
Justus-von-Liebig-Weg 11, 37077 Göttingen, Germany.
Phone: +49-551-39-14189
http://cmb.bio.uni-goettingen.de/
---
--
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] QMMM with GROMACS and DFTB3

[dgfd dgdfg]

It seems that ORCA compatible with latest GROMACS if I correctly understand 
meaning of "//". Look in  CMakeCache.txt file in the installer.

//QM package for QM/MM. Pick one of: none, gaussian, mopac, gamess,
// orca
GMX_QMMM_PROGRAM:STRING=None


-- 
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

[Mark Abraham]

Hi,

I have no idea how ACEMD works, but one can certainly imagine an MD package
that hard codes the assumption of a cubic box with normal 3D periodicity.
But there's nothing intrinsic to the file format that implies any
periodicity to a box. That's either a convention, or given by other
information from the user.

Mark

On Tue, Mar 27, 2018, 18:26 João Henriques 
wrote:

> I see, I didn't consider that. I was strictly thinking about the geometry
> of the box.
>
> Anyway, with some tricks I managed to build a tpr and am now able to
> calculate the mindist to the periodic image.
>
> Thanks!
> J
>
> On 18:19, Tue, Mar 27, 2018 Mark Abraham  wrote:
>
> > Hi,
> >
> > The box sizes say nothing about whether the boundary is fully or
> partially
> > periodic, or screw, or not.
> >
> > Mark
> >
> > On Tue, Mar 27, 2018, 16:13 João Henriques  >
> > wrote:
> >
> > > Thanks Justin, I was really trying to avoid making a tpr file, because
> my
> > > ACEMD uses the Amber format. I sort of hoped gmx mindist could figure
> it
> > > out from the box components present in the xtc file. In principle,
> > couldn't
> > > it be done by using that info alone? Just curious.
> > >
> > > J
> > >
> > > On Tue, Mar 27, 2018 at 4:04 PM, Justin Lemkul 
> wrote:
> > >
> > > >
> > > >
> > > > On 3/27/18 9:59 AM, João Henriques wrote:
> > > >
> > > >> Dear users and developers,
> > > >>
> > > >> I am trying to use gmx mindist to calculate the minimum distance
> > between
> > > >> periodic images but I get the following error:
> > > >>
> > > >> Fatal error:
> > > >> pbc = no is not supported by g_mindist
> > > >>
> > > >> This is the command I am running:
> > > >>
> > > >> gmx_mpi mindist -f output.xtc -s structure.pdb -od -pi -pbc
> > > >>
> > > >> Now, I have to admit that the .xtc file I'm using is generated by
> > ACEMD
> > > >> and
> > > >> not mdrun, but I used gmx dump to check it and everything looks
> sane.
> > > The
> > > >> cuboid box sizes are clearly specified and I don't understand what
> the
> > > >> problem is...
> > > >>
> > > >> 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/mailm

[gmx-users] 'constraints' directive and water

[Alex]

Hi all,

Some of my simulations run with a time step of 2 fs and 'constraints' 
set to 'none'. Everything runs perfectly fine, but with such a time 
step, do you usually set constraints to 'h-bonds'? I know I should be 
looking at literature for this, but just wanted to get a basic idea on 
whether people do this.


Thanks,

Alex

--
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] 'constraints' directive and water

[Justin Lemkul]

On 3/27/18 3:10 PM, Alex wrote:

Hi all,

Some of my simulations run with a time step of 2 fs and 'constraints' 
set to 'none'. Everything runs perfectly fine, but with such a time 
step, do you usually set constraints to 'h-bonds'? I know I should be 
looking at literature for this, but just wanted to get a basic idea on 
whether people do this.




Normally constraining bonds to H is required to get stable integration 
with dt = 2 fs. Water is a different matter; it is held rigid with 
SETTLE and is not under the influence of the "constraints" keyword.


-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.

Re: [gmx-users] Umbrella sampling: window distance - harmonic force constant

[Justin Lemkul]

On 3/27/18 4:44 AM, Hermann, Johannes wrote:

Dear All, dear Justin,

I am playing around with my umbrella sampling setup and I was looking 
at your paper which you linked in your umbrella sampling tutorial 
("Assessing the Stability of Alzheimer’s Amyloid Protofibrils Using 
Molecular Dynamics").
Up to a distance of 2nm you use a 0.1nm spacing, beyond a 0.2nm 
spacing. Which harmonic force constant pull_coord1_k do you use for 
the 0.1nm spacing? In comparison to the 0.2nm spacing, where 
pull_coord1_k=1000.
Is there a general rule of thumb between window distance and force 
constant? Or is it always try and error while checking the histograms?


You can set the value of k based on experimental methods or somewhat ad 
hoc, but then yes, you have to check overlap. I don't know of any useful 
way of trying to predict how the intermolecular forces in the system 
will respond in such a way that you can exactly say a priori how to set 
up the windows.


-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.

Re: [gmx-users] 'constraints' directive and water

[Alex]

That was always my default impression, but from looking into e.g. 
tip4p.itp i somehow got the idea that water _is_ affected by 'constraints'.


Yes, whenever I have hydrogens in the system (aside from water), I 
always set 'h-bonds', which, if you recall my old 'meh' regarding 
constraints, suggests that I have accepted your view for computational 
efficiency. :)  This certainly answers my question, thank you.


Alex


On 3/27/2018 1:11 PM, Justin Lemkul wrote:



On 3/27/18 3:10 PM, Alex wrote:

Hi all,

Some of my simulations run with a time step of 2 fs and 'constraints' 
set to 'none'. Everything runs perfectly fine, but with such a time 
step, do you usually set constraints to 'h-bonds'? I know I should be 
looking at literature for this, but just wanted to get a basic idea 
on whether people do this.




Normally constraining bonds to H is required to get stable integration 
with dt = 2 fs. Water is a different matter; it is held rigid with 
SETTLE and is not under the influence of the "constraints" keyword.


-Justin



--
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] 'constraints' directive and water

[Justin Lemkul]

On 3/27/18 3:18 PM, Alex wrote:
That was always my default impression, but from looking into e.g. 
tip4p.itp i somehow got the idea that water _is_ affected by 
'constraints'.




In case this is confusing for anyone else, let me explain:

There is a difference between [settles] and [constraints]. [settles] are 
always on unless you use "define = -DFLEXIBLE" in the .mdp file. When 
"constraints = none" is specified, the only explicit bond constraints 
(that are not SETTLE) that get used are those listed in [constraints] 
directives. So, while SETTLE is a constraint method, it's not subject to 
the "constraints" keyword in the same way.


-Justin

Yes, whenever I have hydrogens in the system (aside from water), I 
always set 'h-bonds', which, if you recall my old 'meh' regarding 
constraints, suggests that I have accepted your view for computational 
efficiency. :)  This certainly answers my question, thank you.


Alex


On 3/27/2018 1:11 PM, Justin Lemkul wrote:



On 3/27/18 3:10 PM, Alex wrote:

Hi all,

Some of my simulations run with a time step of 2 fs and 
'constraints' set to 'none'. Everything runs perfectly fine, but 
with such a time step, do you usually set constraints to 'h-bonds'? 
I know I should be looking at literature for this, but just wanted 
to get a basic idea on whether people do this.




Normally constraining bonds to H is required to get stable 
integration with dt = 2 fs. Water is a different matter; it is held 
rigid with SETTLE and is not under the influence of the "constraints" 
keyword.


-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.

Re: [gmx-users] 'constraints' directive and water

[Alex]

My idea about SETTLE probably comes from misunderstanding of the fact 
that I do not have FLEXIBLE defined anywhere and the following excerpt 
from tip4.itp:


#ifndef FLEXIBLE
[ settles ]
; OW    funct   doh    dhh
1   1   0.09572    0.15139
#else
[ bonds ]
; i    j    funct    length    force.c.
1    2    1    0.09572    502416.0 0.09572    502416.0
1    3    1    0.09572    502416.0 0.09572    502416.0


On 3/27/2018 1:18 PM, Alex wrote:
That was always my default impression, but from looking into e.g. 
tip4p.itp i somehow got the idea that water _is_ affected by 
'constraints'.


Yes, whenever I have hydrogens in the system (aside from water), I 
always set 'h-bonds', which, if you recall my old 'meh' regarding 
constraints, suggests that I have accepted your view for computational 
efficiency. :)  This certainly answers my question, thank you.


Alex


On 3/27/2018 1:11 PM, Justin Lemkul wrote:



On 3/27/18 3:10 PM, Alex wrote:

Hi all,

Some of my simulations run with a time step of 2 fs and 
'constraints' set to 'none'. Everything runs perfectly fine, but 
with such a time step, do you usually set constraints to 'h-bonds'? 
I know I should be looking at literature for this, but just wanted 
to get a basic idea on whether people do this.




Normally constraining bonds to H is required to get stable 
integration with dt = 2 fs. Water is a different matter; it is held 
rigid with SETTLE and is not under the influence of the "constraints" 
keyword.


-Justin





--
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] 'constraints' directive and water

[Alex]

Yes, perfect. From my previous post, you can see that I simply got 
confused by the syntax of definitions.


Thanks a bunch.

Alex


On 3/27/2018 1:21 PM, Justin Lemkul wrote:



On 3/27/18 3:18 PM, Alex wrote:
That was always my default impression, but from looking into e.g. 
tip4p.itp i somehow got the idea that water _is_ affected by 
'constraints'.




In case this is confusing for anyone else, let me explain:

There is a difference between [settles] and [constraints]. [settles] 
are always on unless you use "define = -DFLEXIBLE" in the .mdp file. 
When "constraints = none" is specified, the only explicit bond 
constraints (that are not SETTLE) that get used are those listed in 
[constraints] directives. So, while SETTLE is a constraint method, 
it's not subject to the "constraints" keyword in the same way.


-Justin

Yes, whenever I have hydrogens in the system (aside from water), I 
always set 'h-bonds', which, if you recall my old 'meh' regarding 
constraints, suggests that I have accepted your view for 
computational efficiency. :)  This certainly answers my question, 
thank you.


Alex


On 3/27/2018 1:11 PM, Justin Lemkul wrote:



On 3/27/18 3:10 PM, Alex wrote:

Hi all,

Some of my simulations run with a time step of 2 fs and 
'constraints' set to 'none'. Everything runs perfectly fine, but 
with such a time step, do you usually set constraints to 'h-bonds'? 
I know I should be looking at literature for this, but just wanted 
to get a basic idea on whether people do this.




Normally constraining bonds to H is required to get stable 
integration with dt = 2 fs. Water is a different matter; it is held 
rigid with SETTLE and is not under the influence of the 
"constraints" keyword.


-Justin







--
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] 'constraints' directive and water

[Justin Lemkul]

Yeah, the distinction between "ifndef" and "ifdef" can easily be missed :)

-Justin

On 3/27/18 3:26 PM, Alex wrote:
Yes, perfect. From my previous post, you can see that I simply got 
confused by the syntax of definitions.


Thanks a bunch.

Alex


On 3/27/2018 1:21 PM, Justin Lemkul wrote:



On 3/27/18 3:18 PM, Alex wrote:
That was always my default impression, but from looking into e.g. 
tip4p.itp i somehow got the idea that water _is_ affected by 
'constraints'.




In case this is confusing for anyone else, let me explain:

There is a difference between [settles] and [constraints]. [settles] 
are always on unless you use "define = -DFLEXIBLE" in the .mdp file. 
When "constraints = none" is specified, the only explicit bond 
constraints (that are not SETTLE) that get used are those listed in 
[constraints] directives. So, while SETTLE is a constraint method, 
it's not subject to the "constraints" keyword in the same way.


-Justin

Yes, whenever I have hydrogens in the system (aside from water), I 
always set 'h-bonds', which, if you recall my old 'meh' regarding 
constraints, suggests that I have accepted your view for 
computational efficiency. :)  This certainly answers my question, 
thank you.


Alex


On 3/27/2018 1:11 PM, Justin Lemkul wrote:



On 3/27/18 3:10 PM, Alex wrote:

Hi all,

Some of my simulations run with a time step of 2 fs and 
'constraints' set to 'none'. Everything runs perfectly fine, but 
with such a time step, do you usually set constraints to 
'h-bonds'? I know I should be looking at literature for this, but 
just wanted to get a basic idea on whether people do this.




Normally constraining bonds to H is required to get stable 
integration with dt = 2 fs. Water is a different matter; it is held 
rigid with SETTLE and is not under the influence of the 
"constraints" keyword.


-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.

Re: [gmx-users] 'constraints' directive and water

[Alex]

I never ever used either, but I totally agree that sarcasm was warranted. :)

Alex


On 3/27/2018 1:28 PM, Justin Lemkul wrote:


Yeah, the distinction between "ifndef" and "ifdef" can easily be 
missed :)


-Justin

On 3/27/18 3:26 PM, Alex wrote:
Yes, perfect. From my previous post, you can see that I simply got 
confused by the syntax of definitions.


Thanks a bunch.

Alex


On 3/27/2018 1:21 PM, Justin Lemkul wrote:



On 3/27/18 3:18 PM, Alex wrote:
That was always my default impression, but from looking into e.g. 
tip4p.itp i somehow got the idea that water _is_ affected by 
'constraints'.




In case this is confusing for anyone else, let me explain:

There is a difference between [settles] and [constraints]. [settles] 
are always on unless you use "define = -DFLEXIBLE" in the .mdp file. 
When "constraints = none" is specified, the only explicit bond 
constraints (that are not SETTLE) that get used are those listed in 
[constraints] directives. So, while SETTLE is a constraint method, 
it's not subject to the "constraints" keyword in the same way.


-Justin

Yes, whenever I have hydrogens in the system (aside from water), I 
always set 'h-bonds', which, if you recall my old 'meh' regarding 
constraints, suggests that I have accepted your view for 
computational efficiency. :) This certainly answers my question, 
thank you.


Alex


On 3/27/2018 1:11 PM, Justin Lemkul wrote:



On 3/27/18 3:10 PM, Alex wrote:

Hi all,

Some of my simulations run with a time step of 2 fs and 
'constraints' set to 'none'. Everything runs perfectly fine, but 
with such a time step, do you usually set constraints to 
'h-bonds'? I know I should be looking at literature for this, but 
just wanted to get a basic idea on whether people do this.




Normally constraining bonds to H is required to get stable 
integration with dt = 2 fs. Water is a different matter; it is 
held rigid with SETTLE and is not under the influence of the 
"constraints" keyword.


-Justin











--
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] 'constraints' directive and water

[Justin Lemkul]

I'm not trying to unnecessarily extend the thread or be sarcastic - it's 
worth clarifying the situation for others and point out that you *did* 
use one of those conditions, perhaps without knowing it.


#ifndef FLEXIBLE means "if you did not define FLEXIBLE, then use SETTLE" 
and you did precisely that - by not using "define = -DFLEXIBLE," you 
satisfied the condition. That's the default behavior because all of the 
force fields built into GROMACS were parametrized for use with a rigid 
water model, so we sort of take that decision out of the hands of the user.


-Justin

On 3/27/18 3:31 PM, Alex wrote:
I never ever used either, but I totally agree that sarcasm was 
warranted. :)


Alex


On 3/27/2018 1:28 PM, Justin Lemkul wrote:


Yeah, the distinction between "ifndef" and "ifdef" can easily be 
missed :)


-Justin

On 3/27/18 3:26 PM, Alex wrote:
Yes, perfect. From my previous post, you can see that I simply got 
confused by the syntax of definitions.


Thanks a bunch.

Alex


On 3/27/2018 1:21 PM, Justin Lemkul wrote:



On 3/27/18 3:18 PM, Alex wrote:
That was always my default impression, but from looking into e.g. 
tip4p.itp i somehow got the idea that water _is_ affected by 
'constraints'.




In case this is confusing for anyone else, let me explain:

There is a difference between [settles] and [constraints]. 
[settles] are always on unless you use "define = -DFLEXIBLE" in the 
.mdp file. When "constraints = none" is specified, the only 
explicit bond constraints (that are not SETTLE) that get used are 
those listed in [constraints] directives. So, while SETTLE is a 
constraint method, it's not subject to the "constraints" keyword in 
the same way.


-Justin

Yes, whenever I have hydrogens in the system (aside from water), I 
always set 'h-bonds', which, if you recall my old 'meh' regarding 
constraints, suggests that I have accepted your view for 
computational efficiency. :) This certainly answers my question, 
thank you.


Alex


On 3/27/2018 1:11 PM, Justin Lemkul wrote:



On 3/27/18 3:10 PM, Alex wrote:

Hi all,

Some of my simulations run with a time step of 2 fs and 
'constraints' set to 'none'. Everything runs perfectly fine, but 
with such a time step, do you usually set constraints to 
'h-bonds'? I know I should be looking at literature for this, 
but just wanted to get a basic idea on whether people do this.




Normally constraining bonds to H is required to get stable 
integration with dt = 2 fs. Water is a different matter; it is 
held rigid with SETTLE and is not under the influence of the 
"constraints" keyword.


-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.

Re: [gmx-users] 'constraints' directive and water

[Mark Abraham]

I amended some of the docs to clarify.

https://gerrit.gromacs.org/#/c/7728/

Mark

On Tue, Mar 27, 2018 at 9:35 PM Justin Lemkul  wrote:

>
> I'm not trying to unnecessarily extend the thread or be sarcastic - it's
> worth clarifying the situation for others and point out that you *did*
> use one of those conditions, perhaps without knowing it.
>
> #ifndef FLEXIBLE means "if you did not define FLEXIBLE, then use SETTLE"
> and you did precisely that - by not using "define = -DFLEXIBLE," you
> satisfied the condition. That's the default behavior because all of the
> force fields built into GROMACS were parametrized for use with a rigid
> water model, so we sort of take that decision out of the hands of the user.
>
> -Justin
>
> On 3/27/18 3:31 PM, Alex wrote:
> > I never ever used either, but I totally agree that sarcasm was
> > warranted. :)
> >
> > Alex
> >
> >
> > On 3/27/2018 1:28 PM, Justin Lemkul wrote:
> >>
> >> Yeah, the distinction between "ifndef" and "ifdef" can easily be
> >> missed :)
> >>
> >> -Justin
> >>
> >> On 3/27/18 3:26 PM, Alex wrote:
> >>> Yes, perfect. From my previous post, you can see that I simply got
> >>> confused by the syntax of definitions.
> >>>
> >>> Thanks a bunch.
> >>>
> >>> Alex
> >>>
> >>>
> >>> On 3/27/2018 1:21 PM, Justin Lemkul wrote:
> 
> 
>  On 3/27/18 3:18 PM, Alex wrote:
> > That was always my default impression, but from looking into e.g.
> > tip4p.itp i somehow got the idea that water _is_ affected by
> > 'constraints'.
> >
> 
>  In case this is confusing for anyone else, let me explain:
> 
>  There is a difference between [settles] and [constraints].
>  [settles] are always on unless you use "define = -DFLEXIBLE" in the
>  .mdp file. When "constraints = none" is specified, the only
>  explicit bond constraints (that are not SETTLE) that get used are
>  those listed in [constraints] directives. So, while SETTLE is a
>  constraint method, it's not subject to the "constraints" keyword in
>  the same way.
> 
>  -Justin
> 
> > Yes, whenever I have hydrogens in the system (aside from water), I
> > always set 'h-bonds', which, if you recall my old 'meh' regarding
> > constraints, suggests that I have accepted your view for
> > computational efficiency. :) This certainly answers my question,
> > thank you.
> >
> > Alex
> >
> >
> > On 3/27/2018 1:11 PM, Justin Lemkul wrote:
> >>
> >>
> >> On 3/27/18 3:10 PM, Alex wrote:
> >>> Hi all,
> >>>
> >>> Some of my simulations run with a time step of 2 fs and
> >>> 'constraints' set to 'none'. Everything runs perfectly fine, but
> >>> with such a time step, do you usually set constraints to
> >>> 'h-bonds'? I know I should be looking at literature for this,
> >>> but just wanted to get a basic idea on whether people do this.
> >>>
> >>
> >> Normally constraining bonds to H is required to get stable
> >> integration with dt = 2 fs. Water is a different matter; it is
> >> held rigid with SETTLE and is not under the influence of the
> >> "constraints" keyword.
> >>
> >> -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.

Re: [gmx-users] gmx mindist error

[Mark Abraham]

Hi,

Looking at the code, if your PDB file had suitable CRYST1 fields then you
would not have needed a .tpr. I improved the docs a bit at
https://gerrit.gromacs.org/#/c/7729/

Mark

On Tue, Mar 27, 2018 at 8:58 PM Mark Abraham 
wrote:

> Hi,
>
> I have no idea how ACEMD works, but one can certainly imagine an MD
> package that hard codes the assumption of a cubic box with normal 3D
> periodicity. But there's nothing intrinsic to the file format that implies
> any periodicity to a box. That's either a convention, or given by other
> information from the user.
>
> Mark
>
> On Tue, Mar 27, 2018, 18:26 João Henriques 
> wrote:
>
>> I see, I didn't consider that. I was strictly thinking about the geometry
>> of the box.
>>
>> Anyway, with some tricks I managed to build a tpr and am now able to
>> calculate the mindist to the periodic image.
>>
>> Thanks!
>> J
>>
>> On 18:19, Tue, Mar 27, 2018 Mark Abraham 
>> wrote:
>>
>> > Hi,
>> >
>> > The box sizes say nothing about whether the boundary is fully or
>> partially
>> > periodic, or screw, or not.
>> >
>> > Mark
>> >
>> > On Tue, Mar 27, 2018, 16:13 João Henriques <
>> joao.m.a.henriq...@gmail.com>
>> > wrote:
>> >
>> > > Thanks Justin, I was really trying to avoid making a tpr file,
>> because my
>> > > ACEMD uses the Amber format. I sort of hoped gmx mindist could figure
>> it
>> > > out from the box components present in the xtc file. In principle,
>> > couldn't
>> > > it be done by using that info alone? Just curious.
>> > >
>> > > J
>> > >
>> > > On Tue, Mar 27, 2018 at 4:04 PM, Justin Lemkul 
>> wrote:
>> > >
>> > > >
>> > > >
>> > > > On 3/27/18 9:59 AM, João Henriques wrote:
>> > > >
>> > > >> Dear users and developers,
>> > > >>
>> > > >> I am trying to use gmx mindist to calculate the minimum distance
>> > between
>> > > >> periodic images but I get the following error:
>> > > >>
>> > > >> Fatal error:
>> > > >> pbc = no is not supported by g_mindist
>> > > >>
>> > > >> This is the command I am running:
>> > > >>
>> > > >> gmx_mpi mindist -f output.xtc -s structure.pdb -od -pi -pbc
>> > > >>
>> > > >> Now, I have to admit that the .xtc file I'm using is generated by
>> > ACEMD
>> > > >> and
>> > > >> not mdrun, but I used gmx dump to check it and everything looks
>> sane.
>> > > The
>> > > >> cuboid box sizes are clearly specified and I don't understand what
>> the
>> > > >> problem is...
>> > > >>
>> > > >> 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

Re: [gmx-users] Excessive and gradually increasing memory usage with OpenCL

[Szilárd Páll]

Hi,

This is an issue I noticed recently, but I thought it was only
affecting some use-cases (or some runtimes). However, it seems it's a
broader problem. It is under investigation, but for now it seems that
eliminate it (or strongly diminish its effects) by turning off
GPU-side task timing. You can do that by setting the
GMX_DISABLE_GPU_TIMING environment variable.

Note that this is workaround that may turn out to not be a complete
solution, please report back if you've done longer runs.

Regarding the thread count, the MPI and CUDA runtimes can spawn
threads, GROMACS certainly used 3x 4 threads in your case. Note that
you will likely get better performance by using 6 ranks x 2 threads
(both because this avoids ranks spanning across sockets and it allows
GPU task/transfer overlap).

Cheers,
--
Szilárd


On Tue, Mar 27, 2018 at 4:09 PM, Albert Mao  wrote:
> Hello!
>
> I'm trying to run molecular dynamics on a fairly large system
> containing approximately 25 atoms. The simulation runs well for
> about 10 steps and then gets killed by the queueing engine due to
> exceeding the swap space usage limit. The compute node I'm using has
> 12 cores in two sockets, three GPUs, and 8 GB of memory. I'm using
> GROMACS 2018 and allowing mdrun to delegate the workload
> automatically, resulting in three thread-MPI ranks each with one GPU
> and four OpenMP threads. The queueing engine reports the following
> usage:
>
> TERM_SWAP: job killed after reaching LSF swap usage limit.
> Exited with exit code 131.
> Resource usage summary:
> CPU time   :  50123.00 sec.
> Max Memory :  4671 MB
> Max Swap   : 30020 MB
> Max Processes  : 5
> Max Threads:35
>
> Even though it's a large system, by my rough estimate, the simulation
> should not need much more than 0.5 gigabytes of memory; 4.6 GB seems
> like too much and 30 GB is completely ridiculous.
> Indeed, running the system on a similar node without GPUs is working
> well (but slowly), consuming about 0.65 GB and 2 GB of swap.
>
> I also don't understand why 35 threads got created.
>
> Could there be a memory leak somewhere in the OpenCL code? Any
> suggestions on preventing this memory usage expansion would be greatly
> appreciated.
>
> I've included relevant output from mdrun with system and configuration
> information at the end of this message. I'm using OpenCL despite
> having Nvidia GPUs because of a sad problem where building with CUDA
> support fails due to the C compiler being "too new".
>
> Thanks!
> -Albert Mao
>
> GROMACS:  gmx mdrun, version 2018
> Executable:   /data/albertmaolab/software/gromacs/bin/gmx
> Data prefix:  /data/albertmaolab/software/gromacs
> Command line:
>
>   gmx mdrun -v -pforce 1 -s blah.tpr -deffnm blah -cpi blah.cpt
>
> GROMACS version:2018
> Precision:  single
> Memory model:   64 bit
> MPI library:thread_mpi
> OpenMP support: enabled (GMX_OPENMP_MAX_THREADS = 64)
> GPU support:OpenCL
> SIMD instructions:  SSE4.1
> FFT library:fftw-3.2.1
> RDTSCP usage:   disabled
> TNG support:enabled
> Hwloc support:  hwloc-1.5.0
> Tracing support:disabled
> Built on:   2018-02-22 07:25:43
> Built by:   ah...@eris1pm01.research.partners.org [CMAKE]
> Build OS/arch:  Linux 2.6.32-431.29.2.el6.x86_64 x86_64
> Build CPU vendor:   Intel
> Build CPU brand:Common KVM processor
> Build CPU family:   15   Model: 6   Stepping: 1
> Build CPU features: aes apic clfsh cmov cx8 cx16 intel lahf mmx msr
> nonstop_tsc pcid pclmuldq pdpe1gb popcnt pse sse2 sse3 sse4.1 sse4.2
> ssse3
> C compiler: /data/albertmaolab/software/gcc/bin/gcc GNU 7.3.0
> C compiler flags:-msse4.1 -O3 -DNDEBUG -funroll-all-loops
> -fexcess-precision=fast
> C++ compiler:   /data/albertmaolab/software/gcc/bin/g++ GNU 7.3.0
> C++ compiler flags:  -msse4.1-std=c++11   -O3 -DNDEBUG
> -funroll-all-loops -fexcess-precision=fast
> OpenCL include dir: /apps/lib-osver/cuda/8.0.61/include
> OpenCL library: /apps/lib-osver/cuda/8.0.61/lib64/libOpenCL.so
> OpenCL version: 1.2
>
> Running on 1 node with total 12 cores, 12 logical cores, 3 compatible GPUs
> Hardware detected:
>   CPU info:
> Vendor: Intel
> Brand:  Intel(R) Xeon(R) CPU   X5675  @ 3.07GHz
> Family: 6   Model: 44   Stepping: 2
> Features: aes apic clfsh cmov cx8 cx16 htt intel lahf mmx msr
> nonstop_tsc pcid pclmuldq pdcm pdpe1gb popcnt pse rdtscp sse2 sse3
> sse4.1 sse4.2 ssse3
>   Hardware topology: Full, with devices
> Sockets, cores, and logical processors:
>   Socket  0: [   0] [   2] [   4] [   6] [   8] [  10]
>   Socket  1: [   1] [   3] [   5] [   7] [   9] [  11]
> Numa nodes:
>   Node  0 (25759080448 bytes mem):   0   2   4   6   8  10
>   Node  1 (25769799680 bytes mem):   1   3   5   7   9  11
>   Latency:
>0 1
>  0  1.00  2.00
>  1  2.00  1.00
> Caches:
>   

Re: [gmx-users] gmx mindist error

[João Henriques]

Yes, I understand what you and Justin refer to. Until your first email I
completely forgot to consider that certain simulations require variations
to the normal 3D periodicity, and thus my ramble about the box vectors. It
makes perfect sense now.

Also, thank you suggesting the alternative using the PDB, really
appreciated. It can certainly make things easier in this particular case.

Best regards,
J

On Tue, Mar 27, 2018 at 9:48 PM, Mark Abraham 
wrote:

> Hi,
>
> Looking at the code, if your PDB file had suitable CRYST1 fields then you
> would not have needed a .tpr. I improved the docs a bit at
> https://gerrit.gromacs.org/#/c/7729/
>
> Mark
>
> On Tue, Mar 27, 2018 at 8:58 PM Mark Abraham 
> wrote:
>
> > Hi,
> >
> > I have no idea how ACEMD works, but one can certainly imagine an MD
> > package that hard codes the assumption of a cubic box with normal 3D
> > periodicity. But there's nothing intrinsic to the file format that
> implies
> > any periodicity to a box. That's either a convention, or given by other
> > information from the user.
> >
> > Mark
> >
> > On Tue, Mar 27, 2018, 18:26 João Henriques  >
> > wrote:
> >
> >> I see, I didn't consider that. I was strictly thinking about the
> geometry
> >> of the box.
> >>
> >> Anyway, with some tricks I managed to build a tpr and am now able to
> >> calculate the mindist to the periodic image.
> >>
> >> Thanks!
> >> J
> >>
> >> On 18:19, Tue, Mar 27, 2018 Mark Abraham 
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > The box sizes say nothing about whether the boundary is fully or
> >> partially
> >> > periodic, or screw, or not.
> >> >
> >> > Mark
> >> >
> >> > On Tue, Mar 27, 2018, 16:13 João Henriques <
> >> joao.m.a.henriq...@gmail.com>
> >> > wrote:
> >> >
> >> > > Thanks Justin, I was really trying to avoid making a tpr file,
> >> because my
> >> > > ACEMD uses the Amber format. I sort of hoped gmx mindist could
> figure
> >> it
> >> > > out from the box components present in the xtc file. In principle,
> >> > couldn't
> >> > > it be done by using that info alone? Just curious.
> >> > >
> >> > > J
> >> > >
> >> > > On Tue, Mar 27, 2018 at 4:04 PM, Justin Lemkul 
> >> wrote:
> >> > >
> >> > > >
> >> > > >
> >> > > > On 3/27/18 9:59 AM, João Henriques wrote:
> >> > > >
> >> > > >> Dear users and developers,
> >> > > >>
> >> > > >> I am trying to use gmx mindist to calculate the minimum distance
> >> > between
> >> > > >> periodic images but I get the following error:
> >> > > >>
> >> > > >> Fatal error:
> >> > > >> pbc = no is not supported by g_mindist
> >> > > >>
> >> > > >> This is the command I am running:
> >> > > >>
> >> > > >> gmx_mpi mindist -f output.xtc -s structure.pdb -od -pi -pbc
> >> > > >>
> >> > > >> Now, I have to admit that the .xtc file I'm using is generated by
> >> > ACEMD
> >> > > >> and
> >> > > >> not mdrun, but I used gmx dump to check it and everything looks
> >> sane.
> >> > > The
> >> > > >> cuboid box sizes are clearly specified and I don't understand
> what
> >> the
> >> > > >> problem is...
> >> > > >>
> >> > > >> 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
> >> > 

Re: [gmx-users] Number of Xeon cores per GTX 1080Ti

[Mark Abraham]

Hi,

On Tue, Mar 27, 2018 at 6:43 PM Jochen Hub  wrote:

> Dear Gromacs community, dear Mark,
>
> Mark showed in the webinar today that having more than 8 Xeon E5-26XXv4
> cores does not help when using a GTX 1080Ti and PME on the GPU.
>

... for that particular simulation system.


> Unfortunately, there were no data points between 4 and 8 CPU cores,
> hence it was not clear at which #cores the performance actually levels
> off. With a GTX 1080 (not Ti) I once found that having more than 5 Xeon
> cores does not help, if not having UB potentials, but I don't have a
> 1080Ti at hand to test for that.
>

Those data points may not have been run. Szilard might have the data - this
was GLIC 2fs comparing 1080 with 1080Ti from the recent plots he shared.


> So my questions are:
>
> - At which number of E5-26XXv4 cores does the performance for common
> systems level off with a 1080Ti for your test system (GLIC)?
>
> - Does the answer depend strongly on the mdp settings (in particular on
> the LJ cutoff)?
>

Longer LJ cutoff (e.g. from different forcefields) will certainly require
more non-bonded work, so then fewer CPU cores would be needed to do the
remaining non-offloaded work. However any sweet spot for a particular .tpr
would be highly dependent on other effects, such as the ratio of solvent
(which typically has less LJ and simpler update) to solute, or the density
of dihedral or U-B interactions. And doing pulling or FEP is very different
again. The sweet spot for the next project will be elsewhere, sadly.

This would help us a lot when choosing the appropriate CPU for a 1080Ti.
>
> Many thanks for any suggestions,
> Jochen
>
> --
> ---
> Dr. Jochen Hub
> Computational Molecular Biophysics Group
> Institute for Microbiology and Genetics
> Georg-August-University of Göttingen
> Justus-von-Liebig-Weg 11, 37077 Göttingen, Germany
> 
> .
> Phone: +49-551-39-14189 <+49%20551%203914189>
> http://cmb.bio.uni-goettingen.de/
> ---
> --
> 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.

[gmx-users] mdrun on single node with GPU

[Myunggi Yi]

Dear users,

I am running simulation with gromacs 2018.1 version
on a computer with quad core and 1 gpu.

I used to use the following command to run simulations.

gmx mdrun -deffnm md


However, this time I've got the following message.

---
Program: gmx mdrun, version 2018.1
Source file: src/gromacs/taskassignment/resourcedivision.cpp (line 224)

Fatal error:
When using GPUs, setting the number of OpenMP threads without specifying the
number of ranks can lead to conflicting demands. Please specify the number
of
thread-MPI ranks as well (option -ntmpi).

For more information and tips for troubleshooting, please check the GROMACS
website at http://www.gromacs.org/Documentation/Errors
---


Can anyone help?


Thank you for any help in advance.


Myunggi Yi
-- 
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] RMSD values consideration

[SHYANTANI MAITI]

Dear all,
After using this command for computation of rmsd of backbone of protein
protein complex consisting of three proteins :
/home/locuz/apps/gromacs/5.1/bin/gmx_mpi rms -f md_0_1.trr -s md_0_1.tpr
The rmsd is drastically increasing from 1 to 6 nm and after that it again
decreases to 1nm. can I use this result for my analysis? Is the rmsd
correctly obtained?
-- 
Best regards,
*Shyantani Maiti*
-- 
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.