Re: [AMBER] MMPBSA TrajError

From: Ahmed Ayoub <atayoub.ualberta.ca>
Date: Tue, 4 Mar 2014 13:58:58 -0700

Hi Dan,

Thanks for your reply. The command you gave to me returns this:






*Warning: AMBERHOME [/pmshare/amber/amber12-20120918] differs from expected
[/nfs/r510-1/pmshare/amber/amber12_ibm_gnu-20140206]. No changes
will be made until this is fixedVersion is reported as <version>.<patches
applied> AmberTools version 13.22 Amber version 12.21*

As to the warning, I guess I shouldn't worry about it as I always define
the environmental variable AMBERHOME in the job script.
Do you this the solution is just to update it?

Ahmed


On Tue, Mar 4, 2014 at 1:00 PM, <amber-request.ambermd.org> wrote:

> Send AMBER mailing list submissions to
> amber.ambermd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.ambermd.org/mailman/listinfo/amber
> or, via email, send a message with subject or body 'help' to
> amber-request.ambermd.org
>
> You can reach the person managing the list at
> amber-owner.ambermd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AMBER digest..."
>
>
> AMBER Mailing List Digest
>
> Today's Topics:
>
> 1. Re: pmemd.cuda segfaults (pavel.banas.upol.cz)
> 2. Re: pmemd.cuda segfaults (Ross Walker)
> 3. MMPBSA TrajError (Ahmed Ayoub)
> 4. Re: MMPBSA TrajError (Daniel Roe)
> 5. Re: amber trajectory to gromacs trajectory conversion (Daniel Roe)
> 6. mass (Zahra Khatti)
> 7. question about mmpbsa result (. mirage)
> 8. Re: pmemd.cuda segfaults (pavel.banas.upol.cz)
> 9. deprotonated histidine parameters (Ahmet y?ld?r?m)
> 10. calculate charge and spin multiplicity (Arunima Shilpi)
> 11. Re: calculate charge and spin multiplicity (David A Case)
> 12. Re: question about mmpbsa result (Jason Swails)
> 13. Re: deprotonated histidine parameters (Jason Swails)
> 14. Re: deprotonated histidine parameters (Gmail2)
> 15. Re: deprotonated histidine parameters (Jason Swails)
> 16. Pmf-plane to plane restrain (Rasha Alqus)
> 17. non-bonded parameters for ferric iron and ferrous iron
> (Jean-Paul Becker)
> 18. Re: deprotonated histidine parameters (Gmail2)
> 19. Re: pmemd.CUDA.mpi micro-second long simulation (psu4.uic.edu)
> 20. Re: pmemd.CUDA.mpi micro-second long simulation (Ross Walker)
> 21. Re: deprotonated histidine parameters (David A Case)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 03 Mar 2014 21:44:24 +0100 (CET)
> From: <pavel.banas.upol.cz>
> Subject: Re: [AMBER] pmemd.cuda segfaults
> To: "AMBER Mailing List" <amber.ambermd.org>
> Message-ID: <Eyt.aACh.1{YUNGPdOc6.1J5Ece.seznam.cz>
> Content-Type: text/plain; charset="utf-8"
>
>
> Dear all,
>
> Thanks for all comments and suggestions. In order to simplify things, I
> will
> put all my answers together.
>
> ?
>
> > Are these 'Titan' cards or Titan-Black cards?
>
> ?
>
> Actually don?t know exactly. Nvidia-smi says just ?GeForce GTX TITAN? and I
> can?t get anything conclusive from lspci, but assuming the core frequency
> mentioned in AMBER output 0.88 GHz, this would speak for TITAN-black. I
> will
> check it, but not before tomorrow as this is remote machine.
>
> ?
>
> > I think that not many of us are building pmemd.cuda with Intel?
> > compilers. Compared to using GCC, there is no performance gain to be?
> > expected. And since Intel compilers are not exactly known for
> equivalent?
> > behavior among different releases, it might very well be that you had?
> > bad luck in your combination of things. Did you really try CUDA toolkit?
> > 5.0 together with older Intel compilers?
>
> ?
>
> No, we just tested older compiler with toolkit 5.5 and older toolkit with
> new compiler. If we do not have titans-black cards, we will definitely
> check
> gcc and after that even the combination of older toolkit and intel
> compiler.
>
> ?
>
> > .Pavel: If you know how to use gdb/idb, you can add the "-g" flag to the
> > pmemd compiler defined in config.h (to add debugging symbols) and then
> > use idb/gdb to get the stack trace of the resulting core dump. That
> > should at least tell us where the segfault is occurring.
>
> ?
>
> We indeed compiled the code with ?-g? and used gdb, attached you can find
> two of error messages.
>
> ?
>
> Anyway, many thanks to all of you. I will definitely check, whether we have
> titans or titan-black cards and if titans, we will try to use gnu compilers
> and let you know.
>
> Thank you very much,
>
> Pavel
>
> --
> Pavel Ban??
> pavel.banas.upol.cz
> Department of Physical Chemistry,
> Palacky University Olomouc
> Czech Republic
>
>
>
> ---------- P?vodn? zpr?va ----------
> Od: Ross Walker <ross.rosswalker.co.uk>
> Komu: AMBER Mailing List <amber.ambermd.org>
> Datum: 3. 3. 2014 18:07:31
> P?edm?t: Re: [AMBER] pmemd.cuda segfaults
>
> "Forget the debugging. It is a hardware issue for sure.
>
> Main thing to know is if these are Titan or Titan-Black. If they are
> Titan-Black then all bets are off. Titan-Black are currently not supported
> due to the fact the cards give incorrect results. A bug is filed with
> NVIDIA. Until it is fixed they will remain unusable.
>
> All the best
> Ross
>
>
>
>
> On 3/3/14, 9:01 AM, "Jason Swails" <jason.swails.gmail.com> wrote:
>
> >On Mon, 2014-03-03 at 17:44 +0100, Jan-Philip Gehrcke wrote:
> >> Hello Pavel,
> >>
> >> I think that not many of us are building pmemd.cuda with Intel
> >> compilers.
> >
> >FWIW, I always use this combination on my machine with a GTX 680 and an
> >AMD 6-core processor; mainly out of habit. I've never seen any
> >problems.
> >
> >.Pavel: If you know how to use gdb/idb, you can add the "-g" flag to the
> >pmemd compiler defined in config.h (to add debugging symbols) and then
> >use idb/gdb to get the stack trace of the resulting core dump. That
> >should at least tell us where the segfault is occurring.
> >
> >HTH,
> >Jason
> >
> >--
> >Jason M. Swails
> >BioMaPS,
> >Rutgers University
> >Postdoctoral Researcher
> >
> >
> >_______________________________________________
> >AMBER mailing list
> >AMBER.ambermd.org
> >http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber"
> -------------- next part --------------
> # RUN 1
>
> banas.v01:~/test/test4$ gdb --args pmemd.cuda -O -i NVT.in -o
> production1_GPU0.out -p test1.top -c production0.restart -x
> production1_GPU0.traj -r production1_GPU0.restart
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from
> /usr/local/programs/common/amber/amber12-pl21-at13-pl22/arch/x86_64-intel_13.1.0.146-cuda_5.5-debug/amber12/bin/pmemd.cuda...done.
> (gdb) run
> Starting program:
> /usr/local/programs/common/amber/amber12-pl21-at13-pl22/arch/x86_64-intel_13.1.0.146-cuda_5.5-debug/amber12/bin/pmemd.cuda
> -O -i NVT.in -o production1_GPU0.out -p test1.top -c production0.restart -x
> production1_GPU0.traj -r production1_GPU0.restart
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffed594700 (LWP 3074)]
> version_line NVRM version: NVIDIA UNIX x86_64 Kernel Module 331.38 Wed
> Jan 8 19:32:30 PST 2014
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000000 in ?? ()
> (gdb) backtrace
> #0 0x0000000000000000 in ?? ()
> #1 0x00007fffed9f821a in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #2 0x00007fffed9156aa in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #3 0x00007fffed9fc229 in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #4 0x00007fffed9fc3e2 in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #5 0x00007fffed9158af in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #6 0x00007fffed905eba in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #7 0x00007fffed8f1e2f in cuCtxSynchronize () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #8 0x00007ffff0e9fc99 in ?? () from
> /usr/local/programs/cuda/cuda-5.5/cuda/lib64/libcudart.so.5.5
> #9 0x00007ffff0ec1509 in cudaThreadSynchronize () from
> /usr/local/programs/cuda/cuda-5.5/cuda/lib64/libcudart.so.5.5
> #10 0x000000000055ecb8 in gpu_calculate_kinetic_energy_ ()
> #11 0x000000000049cf3c in runmd_mod_mp_runmd_ ()
> #12 0x00000000004db2e1 in MAIN__ ()
>
> # RUN 2
>
> banas.v01:~/test/test4$ gdb --args pmemd.cuda -O -i NVT.in -o
> production1_GPU0.out -p test1.top -c production0.restart -x
> production1_GPU0.traj -r production1_GPU0.restart
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from
> /usr/local/programs/common/amber/amber12-pl21-at13-pl22/arch/x86_64-intel_13.1.0.146-cuda_5.5-debug/amber12/bin/pmemd.cuda...done.
> (gdb) run
> Starting program:
> /usr/local/programs/common/amber/amber12-pl21-at13-pl22/arch/x86_64-intel_13.1.0.146-cuda_5.5-debug/amber12/bin/pmemd.cuda
> -O -i NVT.in -o production1_GPU0.out -p test1.top -c production0.restart -x
> production1_GPU0.traj -r production1_GPU0.restart
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffed594700 (LWP 3147)]
> version_line NVRM version: NVIDIA UNIX x86_64 Kernel Module 331.38 Wed
> Jan 8 19:32:30 PST 2014
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fffed9cf9d6 in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> (gdb) backtrace
> #0 0x00007fffed9cf9d6 in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #1 0x00007fffed9d501f in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #2 0x00007fffed9ed57c in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #3 0x00007fffed907c25 in ?? () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #4 0x00007fffed8e401c in cuLaunchKernel () from
> /usr/local/programs/cuda/driver-331.38/usr/lib/libcuda.so
> #5 0x00007ffff0ea4108 in ?? () from
> /usr/local/programs/cuda/cuda-5.5/cuda/lib64/libcudart.so.5.5
> #6 0x00007ffff0ec2bbd in cudaLaunch () from
> /usr/local/programs/cuda/cuda-5.5/cuda/lib64/libcudart.so.5.5
> #7 0x000000000058ba67 in cudaError (anonymous
> namespace)::cudaLaunch<char>(char*) ()
> #8 0x000000000058b12a in __device_stub__Z18kNLSkinTest_kernelv() ()
> #9 0x000000000058b135 in kNLSkinTest_kernel() ()
> #10 0x000000000058ad66 in kNLSkinTest ()
> #11 0x0000000000556091 in gpu_skin_test_ ()
> #12 0x000000000049da3f in runmd_mod_mp_runmd_ ()
> #13 0x00000000004db2e1 in MAIN__ ()
>
> ------------------------------
>
> Message: 2
> Date: Mon, 03 Mar 2014 13:43:45 -0800
> From: Ross Walker <ross.rosswalker.co.uk>
> Subject: Re: [AMBER] pmemd.cuda segfaults
> To: AMBER Mailing List <amber.ambermd.org>
> Message-ID: <CF3A35F6.3BCA0%ross.rosswalker.co.uk>
> Content-Type: text/plain; charset="ISO-8859-2"
>
> Hi Pavel,
>
> I guarantee you this is a hardware issue. It is either that they are
> Titan-Black cards or they are faulty Titan cards. It could also be an
> overheating issue, that case you showed is not ducted - way to check that
> is to pull all but one of the GPUs and see if it works. It could be a
> motherboard issue but I doubt it if the machine is working properly and
> CPU runs don't randomly crash.
>
> FYI this is what you should see in mdout for Titan
>
> |------------------- GPU DEVICE INFO --------------------
> |
> | CUDA Capable Devices Detected: 1
> | CUDA Device ID in use: 0
> | CUDA Device Name: GeForce GTX TITAN
> | CUDA Device Global Mem Size: 6143 MB
> | CUDA Device Num Multiprocessors: 14
> | CUDA Device Core Freq: 0.88 GHz
> |
> |--------------------------------------------------------
>
>
> and for Titan-Black
>
> |------------------- GPU DEVICE INFO --------------------
> |
> | CUDA Capable Devices Detected: 1
> | CUDA Device ID in use: 0
> | CUDA Device Name: GeForce GTX TITAN Black
> | CUDA Device Global Mem Size: 6143 MB
> | CUDA Device Num Multiprocessors: 15
> | CUDA Device Core Freq: 0.98 GHz
> |
> |--------------------------------------------------------
>
>
> To test things build AMBER with GCC and CUDA5.0 (we recommend 5.0 since
> 5.5 and 6.0 are about a 5 to 8% performance regression), download the
> following:
>
> https://dl.dropboxusercontent.com/u/708185/GPU_Validation_Test.tar.gz
>
> then
>
> export AMBERHOME=/path_to_amber12
> tar xvzf GPU_Validation_Test.tar.gz
> cd GPU_Validation_Test
> ./run_test_4gpu.x
>
> Let it run until it completes - about 5 hours and then let us know what
> the 4 log files that you get contain.
>
> All the best
> Ross
>
>
>
> On 3/3/14, 12:44 PM, "pavel.banas.upol.cz" <pavel.banas.upol.cz> wrote:
>
> >
> >Dear all,
> >
> >Thanks for all comments and suggestions. In order to simplify things, I
> >will
> >put all my answers together.
> >
> >
> >
> >> Are these 'Titan' cards or Titan-Black cards?
> >
> >
> >
> >Actually don't know exactly. Nvidia-smi says just 'GeForce GTX TITAN' and
> >I
> >can't get anything conclusive from lspci, but assuming the core frequency
> >mentioned in AMBER output 0.88 GHz, this would speak for TITAN-black. I
> >will
> >check it, but not before tomorrow as this is remote machine.
> >
> >
> >
> >> I think that not many of us are building pmemd.cuda with Intel
> > > compilers. Compared to using GCC, there is no performance gain to be
> > > expected. And since Intel compilers are not exactly known for
> >equivalent
> > > behavior among different releases, it might very well be that you had
> > > bad luck in your combination of things. Did you really try CUDA
> >toolkit
> > > 5.0 together with older Intel compilers?
> >
> >
> >
> >No, we just tested older compiler with toolkit 5.5 and older toolkit with
> >new compiler. If we do not have titans-black cards, we will definitely
> >check
> >gcc and after that even the combination of older toolkit and intel
> >compiler.
> >
> >
> >
> >> .Pavel: If you know how to use gdb/idb, you can add the "-g" flag to the
> >> pmemd compiler defined in config.h (to add debugging symbols) and then
> >> use idb/gdb to get the stack trace of the resulting core dump. That
> >> should at least tell us where the segfault is occurring.
> >
> >
> >
> >We indeed compiled the code with "-g" and used gdb, attached you can find
> >two of error messages.
> >
> >
> >
> >Anyway, many thanks to all of you. I will definitely check, whether we
> >have
> >titans or titan-black cards and if titans, we will try to use gnu
> >compilers
> >and let you know.
> >
> >Thank you very much,
> >
> >Pavel
> >
> >--
> >Pavel Ban??
> >pavel.banas.upol.cz
> >Department of Physical Chemistry,
> >Palacky University Olomouc
> >Czech Republic
> >
> >
> >
> >---------- P?vodn? zpr?va ----------
> >Od: Ross Walker <ross.rosswalker.co.uk>
> >Komu: AMBER Mailing List <amber.ambermd.org>
> >Datum: 3. 3. 2014 18:07:31
> >P?edm?t: Re: [AMBER] pmemd.cuda segfaults
> >
> >"Forget the debugging. It is a hardware issue for sure.
> >
> >Main thing to know is if these are Titan or Titan-Black. If they are
> >Titan-Black then all bets are off. Titan-Black are currently not supported
> >due to the fact the cards give incorrect results. A bug is filed with
> >NVIDIA. Until it is fixed they will remain unusable.
> >
> >All the best
> >Ross
> >
> >
> >
> >
> >On 3/3/14, 9:01 AM, "Jason Swails" <jason.swails.gmail.com> wrote:
> >
> >>On Mon, 2014-03-03 at 17:44 +0100, Jan-Philip Gehrcke wrote:
> >>> Hello Pavel,
> >>>
> >>> I think that not many of us are building pmemd.cuda with Intel
> >>> compilers.
> >>
> >>FWIW, I always use this combination on my machine with a GTX 680 and an
> >>AMD 6-core processor; mainly out of habit. I've never seen any
> >>problems.
> >>
> >>.Pavel: If you know how to use gdb/idb, you can add the "-g" flag to the
> >>pmemd compiler defined in config.h (to add debugging symbols) and then
> >>use idb/gdb to get the stack trace of the resulting core dump. That
> >>should at least tell us where the segfault is occurring.
> >>
> >>HTH,
> >>Jason
> >>
> >>--
> >>Jason M. Swails
> >>BioMaPS,
> >>Rutgers University
> >>Postdoctoral Researcher
> >>
> >>
> >>_______________________________________________
> >>AMBER mailing list
> >>AMBER.ambermd.org
> >>http://lists.ambermd.org/mailman/listinfo/amber
> >
> >
> >
> >_______________________________________________
> >AMBER mailing list
> >AMBER.ambermd.org
> >http://lists.ambermd.org/mailman/listinfo/amber
> "=_________________________
> >______________________
> >AMBER mailing list
> >AMBER.ambermd.org
> >http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 3 Mar 2014 16:08:31 -0700
> From: Ahmed Ayoub <atayoub.ualberta.ca>
> Subject: [AMBER] MMPBSA TrajError
> To: amber.ambermd.org
> Message-ID:
> <
> CAB8KURuE1sxP1-qkX50T4LNL4-cTqE1E3NERDMQnYAA_5kgpyg.mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Dear Amber Developers,
>
> I have been trying to submit an MMPBSA parallel job. The job works
> perfectly fine on AmberTools 12 perfectly fine. But on AmberTools 13 it
> keeps giving me this error although the trajectory files are fine:
>
> TrajError: start frame (1) > total frames (0)
> Error occured on rank 0.
> Exiting. All files have been retained.
> --------------------------------------------------------------------------
> MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
> with errorcode 1.
>
> NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
> You may or may not see output from other processes, depending on
> exactly when Open MPI kills them.
>
> Could any one help?
> --
> Ahmed Taha Ayoub
> PhD Student, Theoretical and Computational Chemistry
> W4-54, Department of Chemistry
> 11227 Saskatchewan Drive
> University of Alberta
> Edmonton, Alberta T6G 2G2
> Canada
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 3 Mar 2014 16:16:02 -0700
> From: Daniel Roe <daniel.r.roe.gmail.com>
> Subject: Re: [AMBER] MMPBSA TrajError
> To: AMBER Mailing List <amber.ambermd.org>
> Message-ID:
> <
> CAAC0qOa7JmvvMCOzU5EvhA4SXRVtX-ccbVfUjHr2SjbjsSEZjw.mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> Do you have the latest version of AmberTools? You can check with
> './update_amber -v' in $AMBERHOME. The output should read:
>
> AmberTools version 13.23
>
> -Dan
>
>
>
> On Mon, Mar 3, 2014 at 4:08 PM, Ahmed Ayoub <atayoub.ualberta.ca> wrote:
>
> > Dear Amber Developers,
> >
> > I have been trying to submit an MMPBSA parallel job. The job works
> > perfectly fine on AmberTools 12 perfectly fine. But on AmberTools 13 it
> > keeps giving me this error although the trajectory files are fine:
> >
> > TrajError: start frame (1) > total frames (0)
> > Error occured on rank 0.
> > Exiting. All files have been retained.
> >
> --------------------------------------------------------------------------
> > MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
> > with errorcode 1.
> >
> > NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
> > You may or may not see output from other processes, depending on
> > exactly when Open MPI kills them.
> >
> > Could any one help?
> > --
> > Ahmed Taha Ayoub
> > PhD Student, Theoretical and Computational Chemistry
> > W4-54, Department of Chemistry
> > 11227 Saskatchewan Drive
> > University of Alberta
> > Edmonton, Alberta T6G 2G2
> > Canada
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
> >
>
>
>
> --
> -------------------------
> Daniel R. Roe, PhD
> Department of Medicinal Chemistry
> University of Utah
> 30 South 2000 East, Room 201
> Salt Lake City, UT 84112-5820
> http://home.chpc.utah.edu/~cheatham/
> (801) 587-9652
> (801) 585-6208 (Fax)
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 3 Mar 2014 16:28:14 -0700
> From: Daniel Roe <daniel.r.roe.gmail.com>
> Subject: Re: [AMBER] amber trajectory to gromacs trajectory conversion
> To: AMBER Mailing List <amber.ambermd.org>
> Message-ID:
> <CAAC0qOb_g4hqSf9heToru6c1AbhL5EDN=
> U-q_Vb20+gGeKseTQ.mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> You can convert from Amber trajectory formats to Gromacs trr with cpptraj:
>
> trajin amber.crd
> trajout gromacs.trr
>
> However, I would like to point out that you can do hydrogen bond lifetime
> analysis using cpptraj using the hbond command with the 'series' keyword,
> followed by the lifetime command, e.g. to analyze solute hydrogen bond
> lifetimes over 5-frame time windows:
>
> hbond H1 series .N,H,C,O
> run
> runanalysis lifetime H1[solutehb] out life.5.dat window 5
>
> See the AmberTools manual for more details. Hope this helps,
>
> -Dan
>
>
>
> On Sat, Mar 1, 2014 at 11:55 PM, Sohag Biswas <cy13p1001.iith.ac.in>
> wrote:
>
> > dear amber users,
> > I need your helps. I want to calculate hydrogen bond lifetime. For that i
> > need to convert amber trajectory to gromacs trajectory. Can anybody tell
> me
> > how to convert from amber to gromacs. It will be very helpful to me.
> > Thanks.
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
> >
>
>
>
> --
> -------------------------
> Daniel R. Roe, PhD
> Department of Medicinal Chemistry
> University of Utah
> 30 South 2000 East, Room 201
> Salt Lake City, UT 84112-5820
> http://home.chpc.utah.edu/~cheatham/
> (801) 587-9652
> (801) 585-6208 (Fax)
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 23 Feb 2014 20:47:18 +0000 (GMT)
> From: Zahra Khatti <khatti_za.yahoo.com>
> Subject: [AMBER] mass
> To: "AMBER.ambermd.org" <AMBER.ambermd.org>
> Message-ID:
> <1393188438.26950.YahooMailNeo.web28705.mail.ir2.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> Dear amberist
>
> I couldn't find the second parameter of mass in frcmod.file in ambertools
> manual.
> MASS
> H? 1.008???????? 0.161 ?? what is this?
>
> best regards. ????????????
> ????????????
>
> ?
> Z. Khatti, Ph.D student of Physical Chemistry,
>
> Department of Chemistry, Iran University of Science & Technology,Tehran,
> Iran?
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 4 Mar 2014 06:47:55 +0000
> From: ". mirage" <m.o.m.live.fr>
> Subject: [AMBER] question about mmpbsa result
> To: "amber.ambermd.org" <amber.ambermd.org>
> Message-ID: <DUB119-W157D6BD38A66541EBB9B8DB98E0.phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi amber user'sI do mmpbsa calculations after molecular dynamics for
> inclusion of (1;2 or 3)B-cyclodextrin with: a-one ester with 20 Carbon
> b-one of the same ester C20 with a double bond between C10-C11
> My results are: 1- I confirmed with cpptraj that the second ester is less
> flexible 2- the first ester is more stable ( more negative deltaG) I seek
> explanation3- The first ester has the best polar contribution
> (Electrostatic) = DeltaE.elect + DeltaG.pb and the second has the best
> apolaire contribution (hydrophobic) = DeltaE.vdw + DeltaG.nonpolar???? Why
> Thank's for all reponse
>
> ------------------------------
>
> Message: 8
> Date: Tue, 04 Mar 2014 09:10:51 +0100 (CET)
> From: <pavel.banas.upol.cz>
> Subject: Re: [AMBER] pmemd.cuda segfaults
> To: "AMBER Mailing List" <amber.ambermd.org>
> Message-ID: <Fey.aACp.29GWfeHzjEw.1J5OgB.seznam.cz>
> Content-Type: text/plain; charset=utf-8
>
> Hi Ross,
> thank you very much. Actually I have not seen nvidia-smi or amber output
> for
> titan-black card until now. So now it is clear that we have titan cards,
> not
> titan-black. Tomorrow we will be able to compile amber with gcc (as our
> admin has vacacy today), run all tests and I will let you know.
> thanks a lot,
>
> Pavel
>
>
> --
> Pavel Ban??
> pavel.banas.upol.cz
> Department of Physical Chemistry,
> Palacky University Olomouc
> Czech Republic
>
>
>
> ---------- P?vodn? zpr?va ----------
> Od: Ross Walker <ross.rosswalker.co.uk>
> Komu: AMBER Mailing List <amber.ambermd.org>
> Datum: 3. 3. 2014 22:50:31
> P?edm?t: Re: [AMBER] pmemd.cuda segfaults
>
> "Hi Pavel,
>
> I guarantee you this is a hardware issue. It is either that they are
> Titan-Black cards or they are faulty Titan cards. It could also be an
> overheating issue, that case you showed is not ducted - way to check that
> is to pull all but one of the GPUs and see if it works. It could be a
> motherboard issue but I doubt it if the machine is working properly and
> CPU runs don't randomly crash.
>
> FYI this is what you should see in mdout for Titan
>
> |------------------- GPU DEVICE INFO --------------------
> |
> | CUDA Capable Devices Detected: 1
> | CUDA Device ID in use: 0
> | CUDA Device Name: GeForce GTX TITAN
> | CUDA Device Global Mem Size: 6143 MB
> | CUDA Device Num Multiprocessors: 14
> | CUDA Device Core Freq: 0.88 GHz
> |
> |--------------------------------------------------------
>
>
> and for Titan-Black
>
> |------------------- GPU DEVICE INFO --------------------
> |
> | CUDA Capable Devices Detected: 1
> | CUDA Device ID in use: 0
> | CUDA Device Name: GeForce GTX TITAN Black
> | CUDA Device Global Mem Size: 6143 MB
> | CUDA Device Num Multiprocessors: 15
> | CUDA Device Core Freq: 0.98 GHz
> |
> |--------------------------------------------------------
>
>
> To test things build AMBER with GCC and CUDA5.0 (we recommend 5.0 since
> 5.5 and 6.0 are about a 5 to 8% performance regression), download the
> following:
>
> https://dl.dropboxusercontent.com/u/708185/GPU_Validation_Test.tar.gz
>
> then
>
> export AMBERHOME=/path_to_amber12
> tar xvzf GPU_Validation_Test.tar.gz
> cd GPU_Validation_Test
> ./run_test_4gpu.x
>
> Let it run until it completes - about 5 hours and then let us know what
> the 4 log files that you get contain.
>
> All the best
> Ross
>
>
>
> On 3/3/14, 12:44 PM, "pavel.banas.upol.cz" <pavel.banas.upol.cz> wrote:
>
> >
> >Dear all,
> >
> >Thanks for all comments and suggestions. In order to simplify things, I
> >will
> >put all my answers together.
> >
> >
> >
> >> Are these 'Titan' cards or Titan-Black cards?
> >
> >
> >
> >Actually don't know exactly. Nvidia-smi says just 'GeForce GTX TITAN' and
> >I
> >can't get anything conclusive from lspci, but assuming the core frequency
> >mentioned in AMBER output 0.88 GHz, this would speak for TITAN-black. I
> >will
> >check it, but not before tomorrow as this is remote machine.
> >
> >
> >
> >> I think that not many of us are building pmemd.cuda with Intel
> > > compilers. Compared to using GCC, there is no performance gain to be
> > > expected. And since Intel compilers are not exactly known for
> >equivalent
> > > behavior among different releases, it might very well be that you had
> > > bad luck in your combination of things. Did you really try CUDA
> >toolkit
> > > 5.0 together with older Intel compilers?
> >
> >
> >
> >No, we just tested older compiler with toolkit 5.5 and older toolkit with
> >new compiler. If we do not have titans-black cards, we will definitely
> >check
> >gcc and after that even the combination of older toolkit and intel
> >compiler.
> >
> >
> >
> >> .Pavel: If you know how to use gdb/idb, you can add the "-g" flag to the
> >> pmemd compiler defined in config.h (to add debugging symbols) and then
> >> use idb/gdb to get the stack trace of the resulting core dump. That
> >> should at least tell us where the segfault is occurring.
> >
> >
> >
> >We indeed compiled the code with "-g" and used gdb, attached you can find
> >two of error messages.
> >
> >
> >
> >Anyway, many thanks to all of you. I will definitely check, whether we
> >have
> >titans or titan-black cards and if titans, we will try to use gnu
> >compilers
> >and let you know.
> >
> >Thank you very much,
> >
> >Pavel
> >
> >--
> >Pavel Ban??
> >pavel.banas.upol.cz
> >Department of Physical Chemistry,
> >Palacky University Olomouc
> >Czech Republic
> >
> >
> >
> >---------- P?vodn? zpr?va ----------
> >Od: Ross Walker <ross.rosswalker.co.uk>
> >Komu: AMBER Mailing List <amber.ambermd.org>
> >Datum: 3. 3. 2014 18:07:31
> >P?edm?t: Re: [AMBER] pmemd.cuda segfaults
> >
> >"Forget the debugging. It is a hardware issue for sure.
> >
> >Main thing to know is if these are Titan or Titan-Black. If they are
> >Titan-Black then all bets are off. Titan-Black are currently not supported
> >due to the fact the cards give incorrect results. A bug is filed with
> >NVIDIA. Until it is fixed they will remain unusable.
> >
> >All the best
> >Ross
> >
> >
> >
> >
> >On 3/3/14, 9:01 AM, "Jason Swails" <jason.swails.gmail.com> wrote:
> >
> >>On Mon, 2014-03-03 at 17:44 +0100, Jan-Philip Gehrcke wrote:
> >>> Hello Pavel,
> >>>
> >>> I think that not many of us are building pmemd.cuda with Intel
> >>> compilers.
> >>
> >>FWIW, I always use this combination on my machine with a GTX 680 and an
> >>AMD 6-core processor; mainly out of habit. I've never seen any
> >>problems.
> >>
> >>.Pavel: If you know how to use gdb/idb, you can add the "-g" flag to the
> >>pmemd compiler defined in config.h (to add debugging symbols) and then
> >>use idb/gdb to get the stack trace of the resulting core dump. That
> >>should at least tell us where the segfault is occurring.
> >>
> >>HTH,
> >>Jason
> >>
> >>--
> >>Jason M. Swails
> >>BioMaPS,
> >>Rutgers University
> >>Postdoctoral Researcher
> >>
> >>
> >>_______________________________________________
> >>AMBER mailing list
> >>AMBER.ambermd.org
> >>http://lists.ambermd.org/mailman/listinfo/amber
> >
> >
> >
> >_______________________________________________
> >AMBER mailing list
> >AMBER.ambermd.org
> >http://lists.ambermd.org/mailman/listinfo/amber
> "=_________________________
> >______________________
> >AMBER mailing list
> >AMBER.ambermd.org
> >http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber"
>
> ------------------------------
>
> Message: 9
> Date: Tue, 4 Mar 2014 11:12:11 +0200
> From: Ahmet y?ld?r?m <ahmedo047.gmail.com>
> Subject: [AMBER] deprotonated histidine parameters
> To: amber.ambermd.org
> Message-ID:
> <CAKVtM2tXpqkF6zJ5mjqh0zQJ-JT5oaM=qezba5E=
> 6TAtbZh5kQ.mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-9
>
> Dear users,
>
> How can I get/find the Amber force field parameters for the deprotonated
> histidine?
>
> Thanks in advance
>
> --
> Ahmet Y?ld?r?m
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 4 Mar 2014 16:47:43 +0530
> From: Arunima Shilpi <writetoash28.gmail.com>
> Subject: [AMBER] calculate charge and spin multiplicity
> To: amber.ambermd.org
> Message-ID:
> <
> CAM90emYRGSy+4fMo618GJpKysikaTwKqFeo73-VbPceVRHe+MA.mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Dear Sir
>
> I have ligand molecule for which I am required to calculate charge and spin
> multiplicity. As I am trying to run antechamber its showing error.
>
> antechamber -i DRG_h.pdb -fi pdb -o DRG.mol2 -fo mol2 -c bcc -s 2
>
> Here is my ligand molecule
>
> HETATM 7193 C1 DRG 1 27.871 -19.015 31.805 1.00 0.00
> C
> HETATM 7194 C2 DRG 1 29.053 -18.343 31.453 1.00 0.00
> C
> HETATM 7195 C3 DRG 1 30.144 -19.040 30.907 1.00 0.00
> C
> HETATM 7196 C4 DRG 1 30.063 -20.436 30.758 1.00 0.00
> C
> HETATM 7197 C5 DRG 1 28.890 -21.111 31.139 1.00 0.00
> C
> HETATM 7198 C6 DRG 1 27.771 -20.406 31.627 1.00 0.00
> C
> HETATM 7199 C7 DRG 1 26.493 -21.057 31.924 1.00 0.00
> C
> HETATM 7200 C8 DRG 1 26.209 -22.370 31.830 1.00 0.00
> C
> HETATM 7201 C9 DRG 1 24.869 -22.904 32.122 1.00 0.00
> C
> HETATM 7202 O1 DRG 1 24.672 -24.112 32.230 1.00 0.00
> O
> HETATM 7203 C10 DRG 1 23.702 -21.946 32.378 1.00 0.00
> C
> HETATM 7204 O2 DRG 1 23.292 -21.275 31.189 1.00 0.00
> O
> HETATM 7205 C11 DRG 1 22.363 -20.196 31.378 1.00 0.00
> C
> HETATM 7206 C12 DRG 1 21.470 -20.267 32.639 1.00 0.00
> C
> HETATM 7207 C13 DRG 1 20.416 -19.133 32.699 1.00 0.00
> C
> HETATM 7208 C14 DRG 1 21.123 -17.760 32.578 1.00 0.00
> C
> HETATM 7209 C15 DRG 1 22.060 -17.642 31.357 1.00 0.00
> C
> HETATM 7210 C16 DRG 1 23.055 -18.818 31.223 1.00 0.00
> C
> HETATM 7211 O3 DRG 1 24.016 -18.604 32.230 1.00 0.00
> O
> HETATM 7212 O4 DRG 1 21.272 -17.543 30.196 1.00 0.00
> O
> HETATM 7213 C17 DRG 1 19.663 -19.144 34.055 1.00 0.00
> C
> HETATM 7214 O5 DRG 1 20.271 -19.544 35.077 1.00 0.00
> O1-
> HETATM 7215 O6 DRG 1 18.479 -18.741 34.060 1.00 0.00
> O1-
> HETATM 7216 O7 DRG 1 19.532 -19.253 31.571 1.00 0.00
> O
> HETATM 7217 C18 DRG 1 18.594 -20.337 31.543 1.00 0.00
> C
> HETATM 7218 C19 DRG 1 18.489 -20.927 30.130 1.00 0.00
> C
> HETATM 7219 O8 DRG 1 17.817 -21.943 29.962 1.00 0.00
> O
> HETATM 7220 C20 DRG 1 19.234 -20.278 29.040 1.00 0.00
> C
> HETATM 7221 C21 DRG 1 19.402 -20.831 27.824 1.00 0.00
> C
> HETATM 7222 C22 DRG 1 20.242 -20.225 26.777 1.00 0.00
> C
> HETATM 7223 C23 DRG 1 21.281 -19.325 27.114 1.00 0.00
> C
> HETATM 7224 C24 DRG 1 22.079 -18.744 26.118 1.00 0.00
> C
> HETATM 7225 C25 DRG 1 21.852 -19.063 24.770 1.00 0.00
> C
> HETATM 7226 C26 DRG 1 20.803 -19.939 24.409 1.00 0.00
> C
> HETATM 7227 C27 DRG 1 19.999 -20.513 25.416 1.00 0.00
> C
> HETATM 7228 O9 DRG 1 20.569 -20.244 23.095 1.00 0.00
> O
> HETATM 7229 O10 DRG 1 22.671 -18.521 23.830 1.00 0.00
> O
> HETATM 7230 O11 DRG 1 31.100 -21.143 30.231 1.00 0.00
> O
> HETATM 7231 O12 DRG 1 31.244 -18.343 30.503 1.00 0.00
> O
> HETATM 0 HC52 DRG 1 29.257 -22.081 31.505 1.00 0.00
> H new HETATM 0 H10C DRG 1 24.133 -21.599 33.329 1.00 0.00
> H new
> HETATM 0 HC8 DRG 1 27.004 -23.066 31.525 1.00 0.00
> H new
> TER 7232 DRG 1
>
> Here is the error detail
> Total number of electrons: 261; net charge: 0
> INFO: Number of electrons is odd: 261
> Please check the total charge (-nc flag) and spin multiplicity (-m
> flag)
>
> Error: cannot run "/home/sabnam/amber12/bin/sqm -O -i sqm.in -o sqm.out"
> of
> bcc() in charge.c properly, exit
>
> I request to kindly guide me in calculating the charge and spin
> multiplicity and debuging the error associated with antechamber.
>
> Regards
>
> Arunima
>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 4 Mar 2014 07:59:01 -0500
> From: David A Case <case.biomaps.rutgers.edu>
> Subject: Re: [AMBER] calculate charge and spin multiplicity
> To: AMBER Mailing List <amber.ambermd.org>, writetoash28.gmail.com
> Message-ID: <20140304125901.GC26163.biomaps.rutgers.edu>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Mar 04, 2014, Arunima Shilpi wrote:
> >
> > I have ligand molecule for which I am required to calculate charge and
> spin
> > multiplicity. As I am trying to run antechamber its showing error.
> >
> > antechamber -i DRG_h.pdb -fi pdb -o DRG.mol2 -fo mol2 -c bcc -s 2
>
> Your question has already been answered twice on the reflector, e.g.
>
> http://archive.ambermd.org/201403/0002.html
>
> Please be sure you are receiving posts, and check your spam filters.
>
> Short answer: you need to have all hydrogens in your input file.
>
> ...dac
>
>
>
>
> ------------------------------
>
> Message: 12
> Date: Tue, 04 Mar 2014 08:10:30 -0500
> From: Jason Swails <jason.swails.gmail.com>
> Subject: Re: [AMBER] question about mmpbsa result
> To: amber.ambermd.org
> Message-ID: <1393938630.12682.2.camel.heroes-out.rutgers.edu>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, 2014-03-04 at 06:47 +0000, . mirage wrote:
> > The first ester has the best polar contribution (Electrostatic) =
> > DeltaE.elect + DeltaG.pb and the second has the best apolaire
> > contribution (hydrophobic) = DeltaE.vdw + DeltaG.nonpolar???? Why
>
> Because that's what the force field says for the ensemble of
> conformations you analyzed.
>
> If you want a more detailed explanation than that you will need to look
> at the local environment of each ester and the interactions it's forming
> and develop an explanation based on the functional form of the Amber
> potential.
>
> Good luck,
> Jason
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Tue, 04 Mar 2014 08:17:39 -0500
> From: Jason Swails <jason.swails.gmail.com>
> Subject: Re: [AMBER] deprotonated histidine parameters
> To: amber.ambermd.org
> Message-ID: <1393939059.12682.7.camel.heroes-out.rutgers.edu>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, 2014-03-04 at 11:12 +0200, Ahmet y?ld?r?m wrote:
> > Dear users,
> >
> > How can I get/find the Amber force field parameters for the deprotonated
> > histidine?
>
> Histidine has 3 major protonation states at biological pHs.
> Single-protonated at the delta- or epsilon- positions and
> double-protonated (protonated at both). The first two states are
> neutral, the third is positively charged.
>
> You have to change the residue name of HIS to HIE or HID for epsilon- or
> delta-protonated histidine, respectively (HIS is interpreted as HIE).
> To get the double-protonated form, change the residue name to HIP.
>
> A fully deprotonated histidine (no protons on either Ne or Nd) would
> need to be parametrized (mainly just the charge derivation). See
> http://ambermd.org/tutorials/advanced/tutorial1_orig/ for example. Note
> that this is a _highly_ unusual form of histidine that would only be
> present at extremely high pHs (I've never seen the pKa value for the
> second imidazole H since it rarely [ever??] comes off).
>
> HTH,
> Jason
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
>
>
>
>
> ------------------------------
>
> Message: 14
> Date: Tue, 4 Mar 2014 18:42:02 +0200
> From: Gmail2 <ahmedo047.gmail.com>
> Subject: Re: [AMBER] deprotonated histidine parameters
> To: AMBER Mailing List <amber.ambermd.org>
> Message-ID: <AF1FB552-3ADE-4DEA-A0F5-DF0DCF6A7AFE.gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Dear Dr. Jason,
>
> In my structure, a zinc is connected to the nitrogens of three histidines
> and a water. The structure should be simulated with Zn bound to three
> deprotonated (negative) histidines and a water. I am wondering what is the
> default net charge of histidine in Amber?
>
> Ahmet Y?ld?r?m
>
>
> 4 Mar 2014 tarihinde 15:17 saatinde, Jason Swails <jason.swails.gmail.com>
> ?unlar? yazd?:
>
> >> On Tue, 2014-03-04 at 11:12 +0200, Ahmet y?ld?r?m wrote:
> >> Dear users,
> >>
> >> How can I get/find the Amber force field parameters for the deprotonated
> >> histidine?
> >
> > Histidine has 3 major protonation states at biological pHs.
> > Single-protonated at the delta- or epsilon- positions and
> > double-protonated (protonated at both). The first two states are
> > neutral, the third is positively charged.
> >
> > You have to change the residue name of HIS to HIE or HID for epsilon- or
> > delta-protonated histidine, respectively (HIS is interpreted as HIE).
> > To get the double-protonated form, change the residue name to HIP.
> >
> > A fully deprotonated histidine (no protons on either Ne or Nd) would
> > need to be parametrized (mainly just the charge derivation). See
> > http://ambermd.org/tutorials/advanced/tutorial1_orig/ for example. Note
> > that this is a _highly_ unusual form of histidine that would only be
> > present at extremely high pHs (I've never seen the pKa value for the
> > second imidazole H since it rarely [ever??] comes off).
> >
> > HTH,
> > Jason
> >
> > --
> > Jason M. Swails
> > BioMaPS,
> > Rutgers University
> > Postdoctoral Researcher
> >
> >
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
> ------------------------------
>
> Message: 15
> Date: Tue, 04 Mar 2014 11:51:05 -0500
> From: Jason Swails <jason.swails.gmail.com>
> Subject: Re: [AMBER] deprotonated histidine parameters
> To: amber.ambermd.org
> Message-ID: <1393951865.12682.24.camel.heroes-out.rutgers.edu>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, 2014-03-04 at 18:42 +0200, Gmail2 wrote:
> > Dear Dr. Jason,
> >
> > In my structure, a zinc is connected to the nitrogens of three
> > histidines and a water. The structure should be simulated with Zn
> > bound to three deprotonated (negative) histidines and a water. I am
> > wondering what is the default net charge of histidine in Amber?
>
> The answer was in my last reply as well as advice for how to deal with
> your system. You will need to derive charges and force field parameters
> for your metal center. You can use R.E.D. to do this or MCPB. I also
> suggest working through the tutorial I provided to see how to create
> custom residues.
>
> Parametrizing your compound will likely take a fairly long time.
>
> Good luck,
> Jason
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
>
>
>
>
> ------------------------------
>
> Message: 16
> Date: Tue, 4 Mar 2014 17:03:19 +0000
> From: Rasha Alqus <rasha.alqus.manchester.ac.uk>
> Subject: [AMBER] Pmf-plane to plane restrain
> To: AMBER Mailing List <amber.ambermd.org>
> Message-ID:
> <91194318CCF0994BA21082AE31EB74EC01928008.MBXP14.ds.man.ac.uk>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Dear Amber usrers,
>
> I am trying to perform PMF calculation for my system using two restrain
> the distance restrain and plane -plane restrain. I have done minimization
> using these restrain and in the output file it read two restrains, but the
> energy showed that NMR restrain for bond only. I have also tried plane to
> point restrain and it showed that bond and plane to point in NMR restrain
> is used.
> I am applying the plane-plane restrain in order to prevent structure b to
> move all over structure A in z direction, when i set distance restrain only
> B structure dose not stay above A at specific distance (z) and location
> it move around A sheet in z direction.
>
> what is the problem with second restrain highlighted in red, is the angle
> set right, any other suggestion might be useful please .
>
> I am using sander in amber 12.
>
> The input file for the restrain is
>
>
> Disance restrian at 11.0 A
> &rst
> iat=-1, -1,
> igr1=531,556,561,560,535,534,
> igr2=1095,1096,1097,1098,1099,1100,1101,1102,1103,1104,1105,1106,
> r1=0, r2=11.0, r3=11.0, r4=99,
> rk2=20.0, rk3=20.0,
> /
> &rst
> iat=1096,1097,1099,1100,560,531,556,561,
> r1=-180.0, r2=0.0, r3=0.0, r4=180.0,
> rk2=20, rk3=20,
> /
>
>
> note;
> plane one atomes are:1096,1097,1099,1100
> plane two atoms are: 560,531,556,561,
> Regards
> Rasha
>
>
>
> ------------------------------
>
> Message: 17
> Date: Tue, 04 Mar 2014 18:08:48 +0100
> From: Jean-Paul Becker <jpb.q4md-forcefieldtools.org>
> Subject: [AMBER] non-bonded parameters for ferric iron and ferrous
> iron
> To: amber.ambermd.org
> Message-ID: <20140304180848.22992bmjh2uzpg2o.horde1.u-picardie.fr>
> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
> format="flowed"
>
> Dear Amber users,
>
> I searched the bibbliography for non-bonded parameters for
> a five-coordinate ferric iron.
>
> There are the well known values coming from D.A. Giammona's PhD
> thesis (1.2 and 0.05)
> that were once in the Amber contrib but removed recently.
> These values are said to be appropriate for a six-coordinate iron though.
>
> In the supporting information of Shahrokh et al. (J. Comput. Chem.
> 33:119-133,2012)
> one can find three sets of non-bonded parameters either for ferrous iron or
> ferric iron in different environment:
> 1.8 0.01
> 1.3 0.002
> 1.3 0.01
> but reading the paper, the method used to derive these parameters does
> not appear clearly.
>
> In Shahrokh et al., a reference leads to Moore et al.
> (Biochemistry 49:9011-9019,1010) where one can read:
> "The van der Waals parameters for the heme iron atom were manually assigne
> Rii
> and epsii values of 1.3 and 0.01, respectively."...
>
> I am wondering where to look for published and trustworthy non-bonded
> parameteres suitable
> to ferric iron in a five-coordinate environment.
> My question is also more general and applies to ferrous and ferric
> iron in five-coodinate
> and six-coordinates environmants as well.
> Any suggestion would be deeply appreciated.
>
> Cheers.
> JPB.
>
> --
> Jean-Paul Becker
> Equipe THERA
> Laboratoire des Glucides
> FRE 3517
> 1 rue des Louvels
> 80036 Amiens Cedex
> France
>
>
>
>
> ------------------------------
>
> Message: 18
> Date: Tue, 4 Mar 2014 19:11:18 +0200
> From: Gmail2 <ahmedo047.gmail.com>
> Subject: Re: [AMBER] deprotonated histidine parameters
> To: AMBER Mailing List <amber.ambermd.org>
> Message-ID: <13D77A59-F914-4A91-941C-5D1ADF44D187.gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Sorry. HIS is HIE in Amber. And It is neutral.
>
> Ahmet Y?ld?r?m
>
>
> 4 Mar 2014 tarihinde 18:51 saatinde, Jason Swails <jason.swails.gmail.com>
> ?unlar? yazd?:
>
> >> On Tue, 2014-03-04 at 18:42 +0200, Gmail2 wrote:
> >> Dear Dr. Jason,
> >>
> >> In my structure, a zinc is connected to the nitrogens of three
> >> histidines and a water. The structure should be simulated with Zn
> >> bound to three deprotonated (negative) histidines and a water. I am
> >> wondering what is the default net charge of histidine in Amber?
> >
> > The answer was in my last reply as well as advice for how to deal with
> > your system. You will need to derive charges and force field parameters
> > for your metal center. You can use R.E.D. to do this or MCPB. I also
> > suggest working through the tutorial I provided to see how to create
> > custom residues.
> >
> > Parametrizing your compound will likely take a fairly long time.
> >
> > Good luck,
> > Jason
> >
> > --
> > Jason M. Swails
> > BioMaPS,
> > Rutgers University
> > Postdoctoral Researcher
> >
> >
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
> ------------------------------
>
> Message: 19
> Date: Tue, 4 Mar 2014 12:40:14 -0600
> From: psu4.uic.edu
> Subject: Re: [AMBER] pmemd.CUDA.mpi micro-second long simulation
> To: AMBER Mailing List <amber.ambermd.org>
> Message-ID:
> <
> CAEcFrgU4SE4R4_oGmH2h47QNgHWtBNRv3CeXopOk+H5r3-GdZQ.mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Dear Professor Walker and Simmerling,
>
> Thanks for your kind comments.
>
> Regarding the NANs issue, it means the system energy blows up during
> simulations. You mention in this
> post<http://archive.ambermd.org/201103/0431.html>
> (http://archive.ambermd.org/201103/0431.html) that " In my opinion this is
> a better option than using langevin for the entire simulation as all of the
> issues with simulation problems, NANs seen on the GPUs etc arise from
> running long ntt=3 simulations.I would even typically run NPT (if I thought
> my system would change shape) *using ntt=1* once the system is
> equilibrated." Our experience using pmemd.CUDA.mpi together with langevin
> suggests NANs are not uncommon in couple hundreds nano second simulations.
> That is why we follow your advice for ntt = 1 and NTP in pmemd.CUDA.mpi
> for long simulations.
>
> "For example you could run the protein itself for 500ns or so and
> extract geometries every 20ns or so and use these as the seed structures
> for the binding simulations." In this example, my understanding is to run
> 500ns simulation, and extract 25 seed structures. Followingly, use these
> 25 seed structures to start another 25 simulations?
>
> Cheers,
> Henry
>
>
> On Mon, Feb 24, 2014 at 9:26 AM, Ross Walker <ross.rosswalker.co.uk>
> wrote:
>
> > Hi Henry,
> >
> > Please see my answers inline below.
> >
> >
> >
> > On 2/23/14, 10:58 PM, "psu4.uic.edu" <psu4.uic.edu> wrote:
> >
> > >Dear Amber community,
> > >
> > >
> > >
> > > It will be interesting to see a non-guided drug molecule could find
> its
> > >protein target binding site(s) and/or allosteric sites if we can run
> > >several micro-second long simulations using pmemd.CUDA.mpi , similar to
> > >this study.
> > >
> > >
> > >
> > >http://pubs.acs.org/doi/abs/10.1021/ja202726y
> > >
> > >
> > >
> > > Unfortunately there are not too many method details reported in the
> > >manuscript to follow up. We are taking some other long simulation
> > >examples
> > >in the Amber community and other D.E. Shaw plus P.E. Vande's
> > >publications. The proposed settings are below. Wonder if the
> community
> > >could kindly offer some comments?
> > >
> >
> > There is no reason why this should not work. Note the performance / way
> it
> > works would I suspect bt very dependent on the concentration of drug
> > molecules in the system. Also note that you'll likely want to run
> multiple
> > simulations ideally from independent initial equilibrium geometries for
> > better sampling. For example you could run the protein itself for 500ns
> or
> > so and extract geometries every 20ns or so and use these as the seed
> > structures for the binding simulations.
> >
> > Note I'm not entirely sure what these simulations ultimately give you -
> > they are perhaps useful for identifying alosteric sites or potential
> > intermediates in the binding process. They don't however, give you free
> > energy or timescale information so be aware of that. They can be used to
> > make nice movies though. :)
> >
> > >
> > >
> > >a. Force field: ff12SB. It seems to provide good protein stability in
> > >Professor Case's studies.
> > >
> > >
> > >
> > >http://archive.ambermd.org/201211/0363.html
> > >
> > >
> >
> > This is a probably a good choice yes. Note you also need parameters for
> > the ligand. GAFF is probably the reasonable (only?) choice for this
> unless
> > you parameterize each ligand manually. Note since charge is likely very
> > important here you probably want to take the time to do a multi
> > conformational resp fit on each ligand rather than relying on AM1-BCC.
> >
> > >
> > >b. pmemd.CUDA.mpi precision model: SPFP
> >
> > Should be good - and has the advantage of being deterministic. So you
> > could always rerun the simulation with a lower value of NTWX if you want
> > more 'resolution' in the trajectory file.
> >
> >
> > >c. solvent: TIP3 water in an 10A octahedron truncated water box
> >
> > Probably good although some people prefer TIP4PEW.
> >
> > >
> > >d. Minimization:
> > >
> > >
> > >
> > >&cntrl
> > >
> > > imin = 1,
> > >
> > > ntx = 1,
> > >
> > > maxcyc = 2000,
> > >
> > > ntmin = 2,
> > >
> > > ntpr = 100,
> > >
> > > ntf = 1,
> > >
> > > ntc = 1,
> > >
> > > ntb = 1,
> > >
> > > cut = 8.0,
> > >
> > > &end
> > >
> >
> > Seems ok but use the CPU code for the minimization since it more robust
> > when it comes to initially strained structures (or use the CUDA SPDP or
> > DPDP precision models).
> >
> > >
> > >
> > >e. Equi 1
> > >
> > >
> > >
> > >&cntrl
> > >
> > > imin = 0,
> > >
> > > irest = 0,
> > >
> > > ntx = 1,
> > >
> > > ntb = 1,
> > >
> > > cut = 8.0,
> > >
> > > ntr = 1,
> > >
> > > ntc = 2,
> > >
> > > ntf = 2,
> > >
> > > tempi = 0.0,
> > >
> > > temp0 = 310.0,
> > >
> > > ntt = 3,
> > >
> > > gamma_ln = 2.0,
> > >
> > > nstlim = 50000,
> > >
> > > dt = 0.002,
> > >
> > > ntpr = 1000,
> > >
> > > ntwx = 25000,
> > >
> > > ntwr = 25000,
> > >
> > > restraint_wt = 10.0,
> > >
> > > restraintmask = '${protein-ligand-mask}',
> > >
> > > iwrap = 1,
> > >
> > > ioutfm =1,
> > >
> > > ig = -1,
> > >
> > > &end
> >
> >
> > Seems reasonable to me - note you want to switch to constant pressure as
> > soon as possible to prevent vacuum bubbles so you might want to heat to
> > just 100K or so before finishing the heating with NPT.
> >
> >
> > >f. NPT equilibration ntt =3
> > >
> > >&cntrl
> > >
> > > imin = 0,
> > >
> > > irest = 1,
> > >
> > > ntx = 5,
> > >
> > > ntb = 2,
> > >
> > > ntp = 1,
> > >
> > > pres0 = 1.0,
> > >
> > > taup = 2.0,
> > >
> > > cut = 8,
> > >
> > > ntr = 0,
> > >
> > > ntc = 2,
> > >
> > > ntf = 2,
> > >
> > > temp0 = 310.0,
> > >
> > > tempi = 310.0,
> > >
> > > ntt = 3,
> > >
> > > gamma_ln = 2.0,
> > >
> > > nstlim = 50000,
> > >
> > > dt = 0.002,
> > >
> > > ntpr = 1000,
> > >
> > > ntwx = 25000,
> > >
> > > ntwr = 25000,
> > >
> > > iwrap = 1,
> > >
> > > ioutfm =1,
> > >
> > > ig = -1,
> > >
> > > &end
> >
> > Also looks good - run this for long enough to make sure the density
> > equilibrates.
> >
> > >g. NPT production run: the same as "equi 2" but change to ntt=1, taup
> =10
> > >to avoid the NANs issue.
> >
> > What's the NAN issue? - I wasn't aware of a problem with ntt=3 and NTP.
> >
> > One thing to note though is that you are probably best using langevin
> > thermostat for production run for better diffusion BUT note that the
> value
> > of gamma_ln essentially acts as a viscosity - the higher it is the more
> > viscous the system effectively is. Thus you may find there are optimum
> > values of gamma_ln so you might want to play around with a few
> simulations
> > run with different gamma_ln values and see if there is a difference.
> >
> > Note if you switch to AMBER 14 in a few months when it is released you
> can
> > use the montecarlo barostat which willgive you NPT performance similar to
> > NVT/NVE and across two GPUs you will get significantly better scaling if
> > the motherboard supports peer to peer over PCI-E 3.0.
> >
> > All the best
> > Ross
> >
> > /\
> > \/
> > |\oss Walker
> >
> > ---------------------------------------------------------
> > | Associate Research Professor |
> > | San Diego Supercomputer Center |
> > | Adjunct Associate Professor |
> > | Dept. of Chemistry and Biochemistry |
> > | University of California San Diego |
> > | NVIDIA Fellow |
> > | http://www.rosswalker.co.uk | http://www.wmd-lab.org |
> > | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> > ---------------------------------------------------------
> >
> > Note: Electronic Mail is not secure, has no guarantee of delivery, may
> not
> > be read every day, and should not be used for urgent or sensitive issues.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
> >
>
>
>
> --
>
> Pin-Chih Su (Henry Su)
>
> Ph.D. canditate
>
> Center for Pharmaceutical Biotechnology (MC 870)
>
> College of Pharmacy, University of Illinois at Chicago
>
> 900 South Ashland Avenue, Room 1052
>
> Chicago, IL 60607-7173
>
> office 312-996-5388
>
> fax 312-413-9303
>
>
> ------------------------------
>
> Message: 20
> Date: Tue, 04 Mar 2014 10:49:14 -0800
> From: Ross Walker <ross.rosswalker.co.uk>
> Subject: Re: [AMBER] pmemd.CUDA.mpi micro-second long simulation
> To: AMBER Mailing List <amber.ambermd.org>
> Message-ID: <CF3B5FC1.3BD58%ross.rosswalker.co.uk>
> Content-Type: text/plain; charset="US-ASCII"
>
> Hi Henry,
>
> That post is ancient. We've almost entirely rewritten the code since then.
> That's referring to bugs (issues with the random number generator) that
> should have long been eradicated from the latest patched version of AMBER
> 12.
>
> All the best
> Ross
>
>
>
> On 3/4/14, 10:40 AM, "psu4.uic.edu" <psu4.uic.edu> wrote:
>
> >Dear Professor Walker and Simmerling,
> >
> > Thanks for your kind comments.
> >
> > Regarding the NANs issue, it means the system energy blows up during
> >simulations. You mention in this
> >post<http://archive.ambermd.org/201103/0431.html>
> >(http://archive.ambermd.org/201103/0431.html) that " In my opinion this
> is
> >a better option than using langevin for the entire simulation as all of
> >the
> >issues with simulation problems, NANs seen on the GPUs etc arise from
> >running long ntt=3 simulations.I would even typically run NPT (if I
> >thought
> >my system would change shape) *using ntt=1* once the system is
> >equilibrated." Our experience using pmemd.CUDA.mpi together with
> >langevin
> >suggests NANs are not uncommon in couple hundreds nano second simulations.
> > That is why we follow your advice for ntt = 1 and NTP in pmemd.CUDA.mpi
> >for long simulations.
> >
> > "For example you could run the protein itself for 500ns or so and
> >extract geometries every 20ns or so and use these as the seed structures
> >for the binding simulations." In this example, my understanding is to
> >run
> >500ns simulation, and extract 25 seed structures. Followingly, use these
> >25 seed structures to start another 25 simulations?
> >
> > Cheers,
> > Henry
> >
> >
> >On Mon, Feb 24, 2014 at 9:26 AM, Ross Walker <ross.rosswalker.co.uk>
> >wrote:
> >
> >> Hi Henry,
> >>
> >> Please see my answers inline below.
> >>
> >>
> >>
> >> On 2/23/14, 10:58 PM, "psu4.uic.edu" <psu4.uic.edu> wrote:
> >>
> >> >Dear Amber community,
> >> >
> >> >
> >> >
> >> > It will be interesting to see a non-guided drug molecule could find
> >>its
> >> >protein target binding site(s) and/or allosteric sites if we can run
> >> >several micro-second long simulations using pmemd.CUDA.mpi , similar to
> >> >this study.
> >> >
> >> >
> >> >
> >> >http://pubs.acs.org/doi/abs/10.1021/ja202726y
> >> >
> >> >
> >> >
> >> > Unfortunately there are not too many method details reported in the
> >> >manuscript to follow up. We are taking some other long simulation
> >> >examples
> >> >in the Amber community and other D.E. Shaw plus P.E. Vande's
> >> >publications. The proposed settings are below. Wonder if the
> >>community
> >> >could kindly offer some comments?
> >> >
> >>
> >> There is no reason why this should not work. Note the performance / way
> >>it
> >> works would I suspect bt very dependent on the concentration of drug
> >> molecules in the system. Also note that you'll likely want to run
> >>multiple
> >> simulations ideally from independent initial equilibrium geometries for
> >> better sampling. For example you could run the protein itself for 500ns
> >>or
> >> so and extract geometries every 20ns or so and use these as the seed
> >> structures for the binding simulations.
> >>
> >> Note I'm not entirely sure what these simulations ultimately give you -
> >> they are perhaps useful for identifying alosteric sites or potential
> >> intermediates in the binding process. They don't however, give you free
> >> energy or timescale information so be aware of that. They can be used to
> >> make nice movies though. :)
> >>
> >> >
> >> >
> >> >a. Force field: ff12SB. It seems to provide good protein stability in
> >> >Professor Case's studies.
> >> >
> >> >
> >> >
> >> >http://archive.ambermd.org/201211/0363.html
> >> >
> >> >
> >>
> >> This is a probably a good choice yes. Note you also need parameters for
> >> the ligand. GAFF is probably the reasonable (only?) choice for this
> >>unless
> >> you parameterize each ligand manually. Note since charge is likely very
> >> important here you probably want to take the time to do a multi
> >> conformational resp fit on each ligand rather than relying on AM1-BCC.
> >>
> >> >
> >> >b. pmemd.CUDA.mpi precision model: SPFP
> >>
> >> Should be good - and has the advantage of being deterministic. So you
> >> could always rerun the simulation with a lower value of NTWX if you want
> >> more 'resolution' in the trajectory file.
> >>
> >>
> >> >c. solvent: TIP3 water in an 10A octahedron truncated water box
> >>
> >> Probably good although some people prefer TIP4PEW.
> >>
> >> >
> >> >d. Minimization:
> >> >
> >> >
> >> >
> >> >&cntrl
> >> >
> >> > imin = 1,
> >> >
> >> > ntx = 1,
> >> >
> >> > maxcyc = 2000,
> >> >
> >> > ntmin = 2,
> >> >
> >> > ntpr = 100,
> >> >
> >> > ntf = 1,
> >> >
> >> > ntc = 1,
> >> >
> >> > ntb = 1,
> >> >
> >> > cut = 8.0,
> >> >
> >> > &end
> >> >
> >>
> >> Seems ok but use the CPU code for the minimization since it more robust
> >> when it comes to initially strained structures (or use the CUDA SPDP or
> >> DPDP precision models).
> >>
> >> >
> >> >
> >> >e. Equi 1
> >> >
> >> >
> >> >
> >> >&cntrl
> >> >
> >> > imin = 0,
> >> >
> >> > irest = 0,
> >> >
> >> > ntx = 1,
> >> >
> >> > ntb = 1,
> >> >
> >> > cut = 8.0,
> >> >
> >> > ntr = 1,
> >> >
> >> > ntc = 2,
> >> >
> >> > ntf = 2,
> >> >
> >> > tempi = 0.0,
> >> >
> >> > temp0 = 310.0,
> >> >
> >> > ntt = 3,
> >> >
> >> > gamma_ln = 2.0,
> >> >
> >> > nstlim = 50000,
> >> >
> >> > dt = 0.002,
> >> >
> >> > ntpr = 1000,
> >> >
> >> > ntwx = 25000,
> >> >
> >> > ntwr = 25000,
> >> >
> >> > restraint_wt = 10.0,
> >> >
> >> > restraintmask = '${protein-ligand-mask}',
> >> >
> >> > iwrap = 1,
> >> >
> >> > ioutfm =1,
> >> >
> >> > ig = -1,
> >> >
> >> > &end
> >>
> >>
> >> Seems reasonable to me - note you want to switch to constant pressure as
> >> soon as possible to prevent vacuum bubbles so you might want to heat to
> >> just 100K or so before finishing the heating with NPT.
> >>
> >>
> >> >f. NPT equilibration ntt =3
> >> >
> >> >&cntrl
> >> >
> >> > imin = 0,
> >> >
> >> > irest = 1,
> >> >
> >> > ntx = 5,
> >> >
> >> > ntb = 2,
> >> >
> >> > ntp = 1,
> >> >
> >> > pres0 = 1.0,
> >> >
> >> > taup = 2.0,
> >> >
> >> > cut = 8,
> >> >
> >> > ntr = 0,
> >> >
> >> > ntc = 2,
> >> >
> >> > ntf = 2,
> >> >
> >> > temp0 = 310.0,
> >> >
> >> > tempi = 310.0,
> >> >
> >> > ntt = 3,
> >> >
> >> > gamma_ln = 2.0,
> >> >
> >> > nstlim = 50000,
> >> >
> >> > dt = 0.002,
> >> >
> >> > ntpr = 1000,
> >> >
> >> > ntwx = 25000,
> >> >
> >> > ntwr = 25000,
> >> >
> >> > iwrap = 1,
> >> >
> >> > ioutfm =1,
> >> >
> >> > ig = -1,
> >> >
> >> > &end
> >>
> >> Also looks good - run this for long enough to make sure the density
> >> equilibrates.
> >>
> >> >g. NPT production run: the same as "equi 2" but change to ntt=1, taup
> >>=10
> >> >to avoid the NANs issue.
> >>
> >> What's the NAN issue? - I wasn't aware of a problem with ntt=3 and NTP.
> >>
> >> One thing to note though is that you are probably best using langevin
> >> thermostat for production run for better diffusion BUT note that the
> >>value
> >> of gamma_ln essentially acts as a viscosity - the higher it is the more
> >> viscous the system effectively is. Thus you may find there are optimum
> >> values of gamma_ln so you might want to play around with a few
> >>simulations
> >> run with different gamma_ln values and see if there is a difference.
> >>
> >> Note if you switch to AMBER 14 in a few months when it is released you
> >>can
> >> use the montecarlo barostat which willgive you NPT performance similar
> >>to
> >> NVT/NVE and across two GPUs you will get significantly better scaling if
> >> the motherboard supports peer to peer over PCI-E 3.0.
> >>
> >> All the best
> >> Ross
> >>
> >> /\
> >> \/
> >> |\oss Walker
> >>
> >> ---------------------------------------------------------
> >> | Associate Research Professor |
> >> | San Diego Supercomputer Center |
> >> | Adjunct Associate Professor |
> >> | Dept. of Chemistry and Biochemistry |
> >> | University of California San Diego |
> >> | NVIDIA Fellow |
> >> | http://www.rosswalker.co.uk | http://www.wmd-lab.org |
> >> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> >> ---------------------------------------------------------
> >>
> >> Note: Electronic Mail is not secure, has no guarantee of delivery, may
> >>not
> >> be read every day, and should not be used for urgent or sensitive
> >>issues.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> AMBER mailing list
> >> AMBER.ambermd.org
> >> http://lists.ambermd.org/mailman/listinfo/amber
> >>
> >
> >
> >
> >--
> >
> >Pin-Chih Su (Henry Su)
> >
> >Ph.D. canditate
> >
> >Center for Pharmaceutical Biotechnology (MC 870)
> >
> >College of Pharmacy, University of Illinois at Chicago
> >
> >900 South Ashland Avenue, Room 1052
> >
> >Chicago, IL 60607-7173
> >
> >office 312-996-5388
> >
> >fax 312-413-9303
> >_______________________________________________
> >AMBER mailing list
> >AMBER.ambermd.org
> >http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
>
>
> ------------------------------
>
> Message: 21
> Date: Tue, 4 Mar 2014 13:58:19 -0500
> From: David A Case <case.biomaps.rutgers.edu>
> Subject: Re: [AMBER] deprotonated histidine parameters
> To: AMBER Mailing List <amber.ambermd.org>
> Message-ID: <20140304185819.GB28014.biomaps.rutgers.edu>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Mar 04, 2014, Gmail2 wrote:
> >
> > In my structure, a zinc is connected to the nitrogens of three
> > histidines and a water. The structure should be simulated with Zn bound
> > to three deprotonated (negative) histidines and a water.
>
> Please be aware that what you are proposing goes against a lot of "received
> wisdom", which holds that histidines bound to zinc should be neutral.
> Certainly having *three* deprotonated histidines would be most
> questionable.
>
> There are plenty of zinc protein experts who can chime in here: both on the
> general question, and on whether there are any experimental determinations
> of
> a histidine pKa bound to a zinc ion.
>
> You probably don't need to do a bunch of new parameterizations: there is
> plenty of published work on how to model MMP-like active sites with Amber:
>
> Lin & Wang, JCTC 6: 1852, 2010
> Peters et al, JCTC 6: 2935, 2010
>
> A google search on "zinc protein amber parameters" will yield yet more
> info.
>
> ...good luck....dac
>
>
>
>
> ------------------------------
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
>
> End of AMBER Digest, Vol 783, Issue 1
> *************************************
>
>


-- 
Ahmed Taha Ayoub
PhD Student, Theoretical and Computational Chemistry
W4-54, Department of Chemistry
11227 Saskatchewan Drive
University of Alberta
Edmonton, Alberta T6G 2G2
Canada
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Mar 04 2014 - 13:00:02 PST
Custom Search