Custom Search
-- Regards Yip Yew Mun Graduate, Masters Chemistry and Biological Chemistry School of Physical and Mathematical Sciences Nanyang Technological University ------------------------------ Message: 4 Date: Sun, 23 Feb 2014 20:52:09 -0500 From: Jason Swails <jason.swails.gmail.com> Subject: Re: [AMBER] SMD Problem: r4 and r4a values are not read from the restraint file To: AMBER Mailing List <amber.ambermd.org> Message-ID: <16D22600-F63E-411D-9E24-97FE68A3883C.gmail.com> Content-Type: text/plain; charset=us-ascii > On Feb 23, 2014, at 2:33 PM, "Ali M. Naserian-Nik" <naseriannik.gmail.com> > wrote: > > Dear Jason, > > Thank you. But you can see that the method described for obtaining > constant > force pulling - via Amber - has been suggested by Dr. Dan Roe and Dr. > Adrian Roitberg in the Amber mail list. Oh of course. A linear potential yields a constant force. Man, I need to think things out more. Good luck, Jason -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ------------------------------ Message: 5 Date: Mon, 24 Feb 2014 04:37:02 +0000 From: "de Waal, Parker" <Parker.DeWaal.vai.org> Subject: [AMBER] New bonds in PyMol? To: "amber.ambermd.org" <amber.ambermd.org> Message-ID: <974700F6B71AA04897B9105CC7E1AAFA704459.VAIEXMB01.vai.org> Content-Type: text/plain; charset="iso-8859-1" Hi Everyone, When visualizing my simulation in pymol I noticed that a new bond seems to form between two carbons in my ligand not present in the tleap output (paramaterized as cc and cd). Interestingly when I view the same pdb snapshot in UCSF Chimera or VMD the bond is not present. While I don't believe this bond is real, as it isn't present in the original geometry optimized .mol2, params .frcmod or library fille, I'm wondering if anyone has experienced this before. Attached to this email are snapshots of the tleap output (vis.png) as well as a point about 70 ns into my production run (prod.png). Additionally I've attached the .mol2 just in case I've missed something. Any input would be greatly appreciated. Best, Parker -------------- next part -------------- A non-text attachment was scrubbed... Name: vis.png Type: image/png Size: 145957 bytes Desc: vis.png Url : http://lists.ambermd.org/mailman/private/amber/attachments/20140224/6e7834ff/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: prod.png Type: image/png Size: 81714 bytes Desc: prod.png Url : http://lists.ambermd.org/mailman/private/amber/attachments/20140224/6e7834ff/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: SCH.mol2 Type: application/octet-stream Size: 4857 bytes Desc: SCH.mol2 Url : http://lists.ambermd.org/mailman/private/amber/attachments/20140224/6e7834ff/attachment-0001.obj ------------------------------ Message: 6 Date: Mon, 24 Feb 2014 00:32:44 -0500 From: Yi Shang <mirandaisbest.gmail.com> Subject: Re: [AMBER] using chamber to convert psf generated by VMD To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CA+sW6w-zVv0w_Ars757SV3UfPGYv-yxy8M6q7EOXGizcHH33uQ.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Jason, I re-generated the system psf using charmm. It still did not work, but now the problem is somewhat different. My system has protein, cholesterol, POPC, water and ions. For each component, conversion from psf to AMBER was successful. Two-components-system that has non-water component and water also worked. But any other combination (protein+cholesterol, etc. ) failed due to either segmentation fault or "topology file ends without finding all atom types", which does not make sense. I was wondering if chamber is indeed capable of converting a system containing more than one non-water components. Thanks! On Fri, Feb 14, 2014 at 11:24 AM, Jason Swails <jason.swails.gmail.com>wrote: > On Fri, 2014-02-14 at 11:15 -0500, Yi Shang wrote: > > Hi there, > > I was trying to prepare AMBER simulation with charmm ff. > > I built the system .psf file using VMD, but then I am stuck trying to > > convert .psf to AMBER topology using chamber. > > This is a known limitation of chamber (at least known to my experience). > As a general rule, I think it's safe to assume that only CHARMM PSFs > will work with chamber (i.e., not XPLOR or VMD-generated PSFs). > > > > > To narrow down the problem, I did the following testing: > > > > A. I built a toy system containing only several ions. I got the > > following > > error: > > > > $ chamber -top top_all36_combine.rtf -param par_all36_combine.prm -psf > > ion.psf -crd ion.pdb -nocmap > > > > | ***************************************************** > > | * CHAMBER: Charmm psf to AMBER prmtop convertor * > > | * * > > | * v1.0 * > > | * * > > | * Written by: * > > | * Mark J. Williamson * > > | * Michael F. Crowley * > > | * Ross C. Walker * > > | * * > > | ***************************************************** > > > > forrtl: severe (64): input conversion error, unit 20, file XXXX/ion.psf > > Image PC Routine Line > Source > > > > libintlc.so.5 00007F1D7D5BBA7A Unknown Unknown > Unknown > > libintlc.so.5 00007F1D7D5BA576 Unknown Unknown > Unknown > > libifcore.so.5 00007F1D7E59680C Unknown Unknown > Unknown > > libifcore.so.5 00007F1D7E508DB2 Unknown Unknown > Unknown > > libifcore.so.5 00007F1D7E508256 Unknown Unknown > Unknown > > libifcore.so.5 00007F1D7E544400 Unknown Unknown > Unknown > > chamber 000000000042EA6A Unknown Unknown > Unknown > > chamber 0000000000401A6C Unknown Unknown > Unknown > > chamber 000000000040134C Unknown Unknown > Unknown > > libc.so.6 00007F1D7D01ECDD Unknown Unknown > Unknown > > chamber 0000000000401249 Unknown Unknown > Unknown > > > > > > B. I used .psf and .pdb from VMD online tutorial (psf generated using > VMD). > > I got exactly the same error message as test A. > > $ chamber -top top_all36_combine.rtf -param par_all36_combine.prm -psf > > kcsav.psf -crd kcsav.pdb -nocmap > > > > C. I used .psf and .pdb downloaded from charmm-gui website. These files > > worked fine and I get prmtop and inpcrd generated. > > $ chamber -top top_all36_combine.rtf -param par_all36_combine.prm -psf > > step4_lipid.psf -crd step4_lipid.pdb -nocmap > > > > It seems to be the problem of reading VMD outputs, but the error message > > from chamber is not enough for me to locate the problem. I was wondering > if > > anyone had the same issue before. > > > > Please find the inputs I used here (2MB in size, not allowed to be > attached > > here): > > https://dl.dropboxusercontent.com/u/76890735/chamber.tar.gz > > > > Thank you in advance! > > > > > > On Fri, Feb 14, 2014 at 12:02 AM, Yi Shang <mirandaisbest.gmail.com> > wrote: > > > > > Hi there, > > > I was trying to prepare AMBER simulation with charmm ff. > > > I built the system .psf file using VMD, but then I am stuck trying to > > > convert .psf to AMBER topology using chamber. > > > > > > To narrow down the problem, I did the following testing: > > > > > > A. I built a toy system containing only several ions. I got the > following > > > error: > > > > > > $ chamber -top top_all36_combine.rtf -param par_all36_combine.prm -psf > > > ion.psf -crd ion.pdb -nocmap > > > > > > | ***************************************************** > > > | * CHAMBER: Charmm psf to AMBER prmtop convertor * > > > | * * > > > | * v1.0 * > > > | * * > > > | * Written by: * > > > | * Mark J. Williamson * > > > | * Michael F. Crowley * > > > | * Ross C. Walker * > > > | * * > > > | ***************************************************** > > > > > > forrtl: severe (64): input conversion error, unit 20, file > > > XXXX/ion.psf > > > Image PC Routine Line > Source > > > > > > libintlc.so.5 00007F1D7D5BBA7A Unknown Unknown > Unknown > > > libintlc.so.5 00007F1D7D5BA576 Unknown Unknown > Unknown > > > libifcore.so.5 00007F1D7E59680C Unknown Unknown > Unknown > > > libifcore.so.5 00007F1D7E508DB2 Unknown Unknown > Unknown > > > libifcore.so.5 00007F1D7E508256 Unknown Unknown > Unknown > > > libifcore.so.5 00007F1D7E544400 Unknown Unknown > Unknown > > > chamber 000000000042EA6A Unknown Unknown > Unknown > > > chamber 0000000000401A6C Unknown Unknown > Unknown > > > chamber 000000000040134C Unknown Unknown > Unknown > > > libc.so.6 00007F1D7D01ECDD Unknown Unknown > Unknown > > > chamber 0000000000401249 Unknown Unknown > Unknown > > > > > This is a result of trying to read a string into an integer variable, or > something of that nature. Since none of the read() statements are > error-protected, hunting down which read caused the error might be > laborious. One thing you can try is to build without optimization and > with debug symbols and hope it gives a more reasonable traceback. > > If you do get VMD PSFs to work, we would greatly appreciate a patch or > some type of recipe to get it working. > > Good luck! > Jason > > -- > Jason M. Swails > BioMaPS, > Rutgers University > Postdoctoral Researcher > > > _______________________________________________ > AMBER mailing list > AMBER.ambermd.org > http://lists.ambermd.org/mailman/listinfo/amber > -- Yi Shang, Ph.D. postdoctoral research associate Icahn School of Medicine at Mount Sinai ------------------------------ Message: 7 Date: Mon, 24 Feb 2014 00:58:42 -0600 From: psu4.uic.edu Subject: [AMBER] pmemd.CUDA.mpi micro-second long simulation To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CAEcFrgWT0wAhZnw8u9feG7s3vA9q9BUy86j-p9u7siQUqq06Yw.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 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? a. Force field: ff12SB. It seems to provide good protein stability in Professor Case's studies. http://archive.ambermd.org/201211/0363.html b. pmemd.CUDA.mpi precision model: SPFP c. solvent: TIP3 water in an 10A octahedron truncated water box d. Minimization: &cntrl imin = 1, ntx = 1, maxcyc = 2000, ntmin = 2, ntpr = 100, ntf = 1, ntc = 1, ntb = 1, cut = 8.0, &end 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 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 g. NPT production run: the same as "equi 2" but change to ntt=1, taup =10 to avoid the NANs issue. Many thanks, Henry ------------------------------ Message: 8 Date: Mon, 24 Feb 2014 16:01:20 +0800 (CST) From: Sun <sunbintyy.163.com> Subject: [AMBER] pbsa calculation using sander To: amber.ambermd.org Message-ID: <43425149.1866d.14462e99a41.Coremail.sunbintyy.163.com> Content-Type: text/plain; charset=GBK Dear all, I want to use sander ( Amber 12 ) to calculate the solvation free energy of a protein-ligand comolex. Here is command-line I typed : sander -O -i pb.in -c x.crd -p x.top -r rest -o pb.out The input file ( pb.in ) is like this : --------------------------------------------- &cntrl nsnb=99999, dec_verbose=0, ipb=2, ntb=0, cut=999.0, imin=5, igb=10, / &pb istrng=100.0, maxitn=1000, fillratio=4.0, radiopt=1, / -------------------------------------------- The calculation is aborted and the error message ? the last two lines of the output file ) is : -------------------------------------------- | Flags: MPI PBSA currently doesn't work with MPI inside SANDER. --------------------------------------------- What does the error message mean ? How should I modify the input file to successfully conduct the calculation ? Thanks very much ! -Sun ------------------------------ Message: 9 Date: Mon, 24 Feb 2014 15:31:46 +0700 From: setyanto md <stwahyudi.md.gmail.com> Subject: [AMBER] asking about pmemd and GTX 660 Ti compatibility To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CAM2h4ewYKOe+XRUQD=W2wHVMh1ARX9Tvb1tKn=Jg+=OJgbUJ0Q.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Dear Amber User and developer, I have 2 question: first: I just read in AMBER 12 Manual, in page 248, sub 7.7.7 Considerations for Maximizing GPU Performance, point 4. It is said : 4. Avoid using the NTP ensemble (NTB=2) when it is not required. Performance will generally be NVE~NVT>NPT. I just to make sure that to term "avoid" doesn't mean prohibited. So I can still make simulation with NPT ensemble. It right ? second: My Lab will buy GTX 660 Ti, with 1344 cuda core. Does the GPU accelerated MD in AMBER support this hardware ? thank you very much Setyanto TW Institut Teknologi Bandung ------------------------------ Message: 10 Date: Mon, 24 Feb 2014 14:41:49 +0530 From: Robin Jain <robinjain.chem.gmail.com> Subject: [AMBER] request for help in analysis To: amber.ambermd.org Message-ID: <CA+QHj+=52K95v97ntX0VXv7CWQ4LbNfCiUck-+RVBJp+oF-i8w.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Dear all amber users, I am doing MD of a organic molecule in methanol and i have a 10 ns trajectory file. Now i want to calculate rotational reorientation time (ps) and translational diffusion coefficient for that organic molecule. Please help me in this regard. -- Robin Jain ------------------------------ Message: 11 Date: Mon, 24 Feb 2014 14:42:04 +0530 From: Arun Kumar Somavarapu <arunks.imtech.res.in> Subject: [AMBER] using ff99SB forcefiled to a complex where ligand charge is from Glycam_04 To: Amber <amber.ambermd.org> Message-ID: <d3ce68fab4efa7d677d94f2456f64493.imtech.res.in> Content-Type: text/plain; charset=UTF-8 Dear Sir I have a protein and a pseudo oligosaccharide complex. I used Red server and GLYCAM_04 forcefield to generate charges for oligosaccharide, now to generate topology files(prmtop and inpcrd) for complex can i use ff99SB forcefield? Thanking you. Regards -- Arun Kumar Somavarapu Project Fellow, Dr. Pawan Gupta Lab, Protein Science and Engineering Dept, Institute of Microbial Tecnology, Sec 39-A, Chandigarh - 160036. ------------------------------ Message: 12 Date: Mon, 24 Feb 2014 10:31:26 +0100 From: FyD <fyd.q4md-forcefieldtools.org> Subject: Re: [AMBER] PME with cutoff = 0 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <20140224103126.i2jpdno5mo8o8sgw.webmail.u-picardie.fr> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Dear Robert, > The cutoff value of "0.d0" in pmemd for a pme run is equivalent to > requesting that the default values be used - probably 8.0 angstrom, > if memory serves, assuming igb 0 for a pme simulation. Yes - this corresponds to what I get... I compare MD simulations (with PME) with cut = 12 vs cut = 0 the obtained results are very similar. This means 'cut = O' does not do what I want; I wonder if crashing is not better than generating data in this case... > PME does strange things at small-ish cutoff, but does not allow 0 > (in the sense that it says "oh, you wanted 8"), and I presume later > catches and disallows cut < 0. In my experience, reducing the > direct space cut below roughly 7.0 angstrom causes unacceptable > error limits unless you increase grid density for reciprocal space > (there is basically a balancing act between reciprocal and direct > space in terms of what is necessary to keep error acceptable). And > if you think long cutoffs are expensive, play around a bit with > greatly increasing nfft1,2,3 in a large system :-}. So all I am > really answering here is why pmemd ran - it basically ignored you... ok > I would have to read the paper done with amber 4.1 to have a clue > what they were really up to, See http://pubs.acs.org/doi/full/10.1021/jp9717655 - It is written: "The heat of vaporization is computed from the average intermolecular interaction energy Eint via dHvap = -Eint + RT For molecules that do not have an internal nonbonded interaction beyond 1?4 (e.g., the chloromethanes), Eint is calculated straightforwardly as the sum of EELEC and ENONB in the SANDER output, divided by the number of molecules in the system. For all other molecules, EELEC and ENONB also contain contributions from intramolecular nonbonded interactions. To correct for these, we performed a short simulation with the nonbonded cutoff radius set to zero. Due to the residue-based cutoff in AMBER, EELEC and ENONB now accumulate only the intraresidue nonbonded interactions that can be subtracted from the total to yield the intermolecular portion needed for the calculation of dHvap." > but pmemd is designed to always use either > pme or generalized Born, so resurrecting an old copy of sander may > be your best bet.. I use PME & would like to continue to use PME. Resurrecting an old copy of sander? uff... Does it means this is not possible to carefully study/check solvent boxes with Amber nowadays? thank you, regards, Francois Dear Ross, > Both sander and pmemd almost certainly make assumptions about the cutoff. > Since the days of AMBER 4.1 there have been huge changes in the way the > pairlist is built etc. I can understand that ;-) > For example the code use to just rebuild the > pairlist at set intervals. These days it is smart and only rebuilds it > when an atom has moved more than the distance skinnb such that the > pairlist cutoff is really cut+skinnb. Thus reducing cut to zero probably > messes up logic in this part of the code. There are likely other issues as > well, like divisions by zero inside the code that determines the Ewald > coefficient etc. My understanding is that division by zero should always be checked. > The fact one code crashes and the other doesn't is likely > just dependent on where they hit the first problem. From what you show it > looks like pmemd just hangs while sander crashes with an error - both > could be considered a crash. pmemd does not hang; see above. > Anyway, to cut a long story short neither code officially supports a value > of cut=0 for PME runs and it is something that isn't tested. It may be > possible to run the simulation in GB in sander by setting igb=6 - this > will run a gas phase simulation. I doubt there is anyway to run a periodic > simulation with a cutoff of 0. If you really want to then your options are > likely see if you can find a PRE-PME copy of sander (such as AMBER 4.1) or > (sander-classic from AMBER 6 perhaps?) or crack open the debugger and see > if you can trace through the use of the cutoff value and find out where > the problems are occurring. This may just be a case of going down the > rabbit hole though. sander-classic from AMBER 6: do you think this is possible to get sander-classic from AMBER 6 compiled using 4.4 GNU compiler? Does it means this is not possible to carefully study/check solvent boxes with Amber nowadays? See http://pubs.acs.org/doi/full/10.1021/jp9717655 > Sorry I can't offer much more help than that. - Note you could also try > cut=0.001 and see if that works. There is almost certainly a 1.0d0/cut^2 > somewhere in the code and this might work around that and still give you > what you want from the simulation. I am testing... thank you, regards, Francois > On 2/23/14, 9:19 AM, "FyD" <fyd.q4md-forcefieldtools.org> wrote: > >> Dear All, >> >> I ran amber10/sander.MPI with PME + cutoff = 0 -> sander crashes >> amber12/sander.MPI with PME + cutoff = 0 -> sander crashes >> (compiled with intel13 + mkl) >> amber12/pmemd.MPI with PME + cutoff = 0 -> pmemd does not crash... >> >> Printed output: printing stops in section 4: >> >> -------------------------------------------------------------------------- >> 4. RESULTS >> -------------------------------------------------------------------------- >> >> | # of SOLUTE degrees of freedom (RNDFP): 24936. >> | # of SOLVENT degrees of freedom (RNDFS): 0. >> | NDFMIN = 24933. NUM_NOSHAKE = 0 CORRECTED RNDFP = 24933. >> | TOTAL # of degrees of freedom (RNDF) = 24933. >> >> -> nothing else is printed... >> >> In Fox & Kollman J.Phys.Chem.B 1998, 102, 8070, MD simulation with >> cutoff = 0 is reported & Sander from Amber 4.1 was used. >> >> Why does sander crash, while pmemd does not crash in this case? >> (with the same input & cut = 12, sander does not crash) >> >> thank you, regards, >> Francois >> >> >> >> # Cst pressure simulation with cutoff = 0 Angs; 300 K short >> $PARAL -np $NPROC $EXE -O -i md-cstpres0.in \ >> -o md-cstpres0b.out \ >> -p $mol.parm7 \ >> -c md-cstvol.rst7 \ >> -r md-cstpres0b.rst7 \ >> -x md-cstpres0b.mdcrd >> >> my test input below: >> >> cst pressure MD, nstlim*dt psec, PME with cutoff >> &cntrl >> nmropt = 0, ioutfm = 1, iwrap = 0, >> ntx = 1, irest = 0, ntrx = 1, ntxo = 1, >> ntpr = 100, ntwr = 1000, ntwx = 500, >> ntave = 0, ntwv = 0, ntwe = 0, >> ntf = 2, ntb = 2, >> ntc = 2, tol = 0.00001, >> dielc = 1, ipol = 0, >> cut = 0, ig = 71277, comp = 52.5, >> ibelly = 0, ntr = 0, igb = 0, >> imin = 0, nstlim = 5000, >> nscm = 1000, t = 0.0, dt = 0.002, >> temp0 = 300, tempi = 300, >> ntt = 1, tautp = 0.2, vlimit = 20, >> ntp = 1, pres0 = 1.0, taup = 0.2, >> &end ------------------------------ Message: 13 Date: Mon, 24 Feb 2014 09:45:58 +0000 From: "Mele N." <nm10g13.soton.ac.uk> Subject: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be accomplished To: Amber <amber.ambermd.org> Message-ID: <5729F3D82873334E960C2D13696DB0BB016F8F85.SRV00047.soton.ac.uk> Content-Type: text/plain; charset="iso-8859-1" Hi everyone, I am trying to equilibrate a box of mixture water DMSO/Water created thanks to packmol software. During the equilibration step I get this error: vlimit exceeded for step 0; vmax = 128.9242 Coordinate resetting (SHAKE) cannot be accomplished, deviation is too large NITER, NIT, LL, I and J are : 0 1 35579 45871 45873 Note: This is usually a symptom of some deeper problem with the energetics of the system. My input file was: Equilibration &cntrl imin=0, irest=0, ntx=1, nstlim=100, dt=0.002, ntc=2, ntf=2, ntb=2, ntp=1, taup=2.0, ntpr=1, ntwx=1, ntwr=1, ntt=3, gamma_ln=2.0, temp0=300.0,iwrap=1, / And my minimization input file was: minimization &cntrl imin=1, maxcyc=5000, ncyc=2500, cut=10.0, ntb=1, ntc=1, ntf=1, ntpr=10, / Minimization steps worked without any problems. Thanks in advance for help, Regards, ------------------------------ Message: 14 Date: Mon, 24 Feb 2014 10:57:18 +0100 From: Karl Kirschner <k.n.kirschner.gmail.com> Subject: Re: [AMBER] using ff99SB forcefiled to a complex where ligand charge is from Glycam_04 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CAF=D-bxGz2-tWhcsToaHX7P17wBw6AsEK7EUTLeWzTqcxpNCXw.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi, If you have a pure oligosaccharides that is composed of residue found within Glycam04 and does not contain any unusual linkages to the protein (e.g. it is a nonbonded complex), then you should use the Glycam parameter set for the carbohydrates and the ff99SB for the protein. The partial atomic charges for carbohydrates and those for the amino acids were developed using different protocols, making them only balanced with their respective force field (e.g. aliphatic hydrorgens are treated different, plus the force fields use different scee and scnb scaling factors, which Amber12 supports easily). Furthermore, you should try to use the more recent version of Glycam06. Now if you have a ligand that is a mix between carbohydrates and amino acids, or other nonstandard residues, then the problem becomes much more difficult. In this case, you should develop parameters that are optimized for use with Glycam. This can be very difficult to do and will likely involve assigning new atom types. Once this is done then you can use your optimized parameters with Glycam for the ligand, and the ff99SB for the protein. A nonideal way would be to borrow parameters from another force field (e.g. gaff, parm99SB), convert the parameter's atom types to be compatible with Glycam, and then verify that they reproduce some target observable (e.g. QM torsion curves). Alternatively, you can develop partial atomic charges that are compatible with the gaff force field, and use a gaff/parm99SB combination and hope that it properly captures that ligand's conformational and energetic behavior. Best regards, Karl On Mon, Feb 24, 2014 at 10:12 AM, Arun Kumar Somavarapu < arunks.imtech.res.in> wrote: > > > Dear Sir > > I have a protein and a pseudo oligosaccharide complex. I used Red server > and GLYCAM_04 forcefield to generate charges for oligosaccharide, now to > generate topology files(prmtop and inpcrd) for complex can i use ff99SB > forcefield? > > Thanking you. > > Regards > > -- > Arun Kumar Somavarapu > Project Fellow, > Dr. Pawan Gupta Lab, > Protein Science and Engineering Dept, > Institute of Microbial Tecnology, > Sec 39-A, Chandigarh - 160036. > > _______________________________________________ > AMBER mailing list > AMBER.ambermd.org > http://lists.ambermd.org/mailman/listinfo/amber > ------------------------------ Message: 15 Date: Mon, 24 Feb 2014 15:50:09 +0530 From: Arun Kumar Somavarapu <arunks.imtech.res.in> Subject: Re: [AMBER] using ff99SB forcefiled to a complex where ligand charge is from Glycam_04 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <f5442d3759117ea766b95ccc193a8e30.imtech.res.in> Content-Type: text/plain; charset=UTF-8 Hello Sir, Mine is a docked complex, the ligand is bonded through H-bonds. i have generated charges for ligand by Glycam ff. while generating topology files for complex, i used source leaprc.GLYCAM_04 source leaprc.gaff source leaprc.ff99SB and generated topology files successfully. is it right way to perform. is it considering Glycam ff here? On 2014-02-24 15:27, Karl Kirschner wrote: > Hi, > > If you have a pure oligosaccharides that is composed of residue found > within Glycam04 and does not contain any unusual linkages to the protein > (e.g. it is a nonbonded complex), then you should use the Glycam parameter > set for the carbohydrates and the ff99SB for the protein. The partial > atomic charges for carbohydrates and those for the amino acids were > developed using different protocols, making them only balanced with their > respective force field (e.g. aliphatic hydrorgens are treated different, > plus the force fields use different scee and scnb scaling factors, which > Amber12 supports easily). Furthermore, you should try to use the more > recent version of Glycam06. > > Now if you have a ligand that is a mix between carbohydrates and amino > acids, or other nonstandard residues, then the problem becomes much more > difficult. In this case, you should develop parameters that are optimized > for use with Glycam. This can be very difficult to do and will likely > involve assigning new atom types. Once this is done then you can use your > optimized parameters with Glycam for the ligand, and the ff99SB for the > protein. > > A nonideal way would be to borrow parameters from another force field > (e.g. gaff, parm99SB), convert the parameter's atom types to be compatible > with Glycam, and then verify that they reproduce some target observable > (e.g. QM torsion curves). Alternatively, you can develop partial atomic > charges that are compatible with the gaff force field, and use a > gaff/parm99SB combination and hope that it properly captures that ligand's > conformational and energetic behavior. > > Best regards, > Karl > > On Mon, Feb 24, 2014 at 10:12 AM, Arun Kumar Somavarapu < > arunks.imtech.res.in> wrote: > >> Dear Sir I have a protein and a pseudo oligosaccharide complex. I used >> Red server and GLYCAM_04 forcefield to generate charges for >> oligosaccharide, now to generate topology files(prmtop and inpcrd) for >> complex can i use ff99SB forcefield? Thanking you. Regards -- Arun Kumar >> Somavarapu Project Fellow, Dr. Pawan Gupta Lab, Protein Science and >> Engineering Dept, Institute of Microbial Tecnology, Sec 39-A, >> Chandigarh - 160036. _______________________________________________ >> AMBER mailing list AMBER.ambermd.org >> http://lists.ambermd.org/mailman/listinfo/amber [1] > > _______________________________________________ > AMBER mailing list > AMBER.ambermd.org > http://lists.ambermd.org/mailman/listinfo/amber [1] -- Arun Kumar Somavarapu Project Fellow, Dr. Pawan Gupta Lab, Protein Science and Engineering Dept, Institute of Microbial Tecnology, Sec 39-A, Chandigarh - 160036. Links: ------ [1] http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 16 Date: Mon, 24 Feb 2014 11:49:54 +0100 From: FyD <fyd.q4md-forcefieldtools.org> Subject: Re: [AMBER] using ff99SB forcefiled to a complex where ligand charge is from Glycam_04 To: Amber <amber.ambermd.org> Message-ID: <20140224114954.8zl9gxaq9cs0wo88.webmail.u-picardie.fr> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Dear Arun, > I have a protein and a pseudo oligosaccharide complex. I used Red server > and GLYCAM_04 forcefield to generate charges for oligosaccharide, now to > generate topology files(prmtop and inpcrd) for complex can i use ff99SB > forcefield? If you use R.E.D. Server Dev./R.E.D. Python a LEaP script is generated in: Data-R.E.D.Server/Data-Default-Proj see leaprc.ff13q4mdfft from this leaprc.ff13q4mdfft you can load your PDB file; see: # Let's load the PDB file # Web site: http://ambermd.org/doc6/html/AMBER-sh-5.9.html#sh-5.9.44 # VAR = loadPdb Your-PDB-file.ent you can load extra-FF etc... regards, Francois ------------------------------ Message: 17 Date: Mon, 24 Feb 2014 12:01:26 +0100 From: De?k Robert <kokumetto.gmail.com> Subject: [AMBER] GTX670 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CAEYkJNWrk7M4ZnoZkHntyCVuDOM3Jj0j3gNGMczHap5ULnkABg.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Dear Amber users, Recently we bought 2 GTX 670 DC mini ( http://www.asus.com/Graphics_Cards/GTX670DCMOC2GD5/) but with both of them I experienced the same error message after random run time. The message is: *cudaMemcpy GpuBuffer::Download failed unspecified launch failure* With exactly the same input files and input settings there are no error messages using a GTX TITAN or a TESLA card. I have tried the GTX 670 cards in the other machine, and also a TITAN card in this server, but the error is related to GTX 670 cards, independently from the server. My question is, this type of error message means hardware failure? These are my input parameters: &cntrl imin = 0, irest = 0, ntx = 1, ntb = 2, pres0 = 1.0, ntp = 1, taup = 2.0, cut = 11.0, ntr = 0, ntc = 2, ntf = 2, tempi = 300.0, temp0 = 300.0, ntt = 3, gamma_ln = 0.1, nstlim = 100000000, dt = 0.002, ntpr = 1000, ntwx = 1000, ntwr = 1000, ig=1, nscm=1000 / Thanks, Robert ------------------------------ Message: 18 Date: Mon, 24 Feb 2014 11:31:18 +0000 From: almarques <almarques.itqb.unl.pt> Subject: [AMBER] MMPBSA.py error To: AMBER Mailing List <amber.ambermd.org> Message-ID: <9d65287bfc10ed25c1c0a40b3a5a3123.itqb.unl.pt> Content-Type: text/plain; charset=UTF-8; format=flowed Hi, I have bee trying to run the mmpbsa.py for alanine scanning mutagenesis but I always get this error: Loading and checking parameter files for compatibility... PrmtopError: Couldn't predict mask from topology files! Your ligand residues must be sequential in your complex. There are likely problems with your topology files if this is not the case. My input is: sample input file for running alanine scanning &general startframe=3000, endframe=5000, interval=1000, verbose=1, ligand_mask=':1-200,806,810', receptor_mask=':201-401,402-603,604-805,807,808,809,811,812,813', / &pb inp=1, radiopt=0, exdi=80, indi=3.0, cavity_surften=0.00542, cavity_offset=-1.008, fillratio=4, scale=2.0, linit=1000, istrng=0.100, / &alanine_scanning / I have four chains, each with a Mn atom and a water molecule bound to the metal. One of the chains (with its metak and water) is the ligand. The command that I am using is: $AMBERHOME/bin/MMPBSA.py -O -i mmpbsaAS2.in -cp com_wt.top -rp recCFH_wt.top -lp ligB_wt.top -y 10ns_noH2O.mdcrd -mc 2Bcomp.top -ml 2Blig.top -mr recCFH_wt.top & Am I missing something? Could you help me please? Thanks, Alexandra ------------------------------ Message: 19 Date: Mon, 24 Feb 2014 07:43:51 -0500 From: David A Case <case.biomaps.rutgers.edu> Subject: Re: [AMBER] New bonds in PyMol? To: AMBER Mailing List <amber.ambermd.org> Message-ID: <20140224124351.GB58335.biomaps.rutgers.edu> Content-Type: text/plain; charset=us-ascii On Mon, Feb 24, 2014, de Waal, Parker wrote: > > When visualizing my simulation in pymol I noticed that a new bond seems > to form between two carbons in my ligand not present in the tleap output > (paramaterized as cc and cd). Interestingly when I view the same pdb > snapshot in UCSF Chimera or VMD the bond is not present. Depending on what sort of input you give it, visualization programs can make lots of different decisions about whether or not to show a bond between two atoms. The default is often to use some pretty arbitrary distance criterion. It's is generally not enough to say "I used pymol, or VMD...". What is shown on the screen also depends on the type of file you use as input. If you haven't yet done so, use the printBonds command in parmed.py to determine which bonds are actually contained in the prmtop file. What is in the prmtop file is what is really used by sander or pmemd. ...dac ------------------------------ Message: 20 Date: Mon, 24 Feb 2014 07:47:09 -0500 From: David A Case <case.biomaps.rutgers.edu> Subject: Re: [AMBER] pbsa calculation using sander To: AMBER Mailing List <amber.ambermd.org> Message-ID: <20140224124709.GC58335.biomaps.rutgers.edu> Content-Type: text/plain; charset=us-ascii On Mon, Feb 24, 2014, Sun wrote: > | Flags: MPI > PBSA currently doesn't work with MPI inside SANDER. > > What does the error message mean ? How should I modify the input file to > successfully conduct the calculation ? As Amber error messages go, this one is pretty clear(!). For the calculation you want, you have to use sander (not sander.MPI) as the program doing the calculation. It's not the input file but the command line that you need to change. ....dac ------------------------------ Message: 21 Date: Mon, 24 Feb 2014 07:50:53 -0500 From: David A Case <case.biomaps.rutgers.edu> Subject: Re: [AMBER] using ff99SB forcefiled to a complex where ligand charge is from Glycam_04 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <20140224125053.GD58335.biomaps.rutgers.edu> Content-Type: text/plain; charset=us-ascii On Mon, Feb 24, 2014, Karl Kirschner wrote: > > If you have a pure oligosaccharides that is composed of residue found > within Glycam04 and does not contain any unusual linkages to the protein > (e.g. it is a nonbonded complex), then you should use the Glycam parameter > set for the carbohydrates and the ff99SB for the protein. Just a minor update: we recommend using the ff12SB force field for the protein. This is also compatible with Glycam, but has improved torsion parameters for the protein part, and generally should give better results. ....dac ------------------------------ Message: 22 Date: Mon, 24 Feb 2014 13:52:45 +0100 From: FyD <fyd.q4md-forcefieldtools.org> Subject: Re: [AMBER] PME with cutoff = 0 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <20140224135245.43khemrfwgcgokco.webmail.u-picardie.fr> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Ross, > Sorry I can't offer much more help than that. - Note you could also try > cut=0.001 and see if that works. There is almost certainly a 1.0d0/cut^2 > somewhere in the code and this might work around that and still give you > what you want from the simulation. I tested sander12 with cut = 0.1, same type of crash; so this is not a problem of division by zero... see below the end of the sander output. regards, Francois -------------------------------------------------------------------------------- 4. RESULTS -------------------------------------------------------------------------------- | # of SOLUTE degrees of freedom (RNDFP): 24936. | # of SOLVENT degrees of freedom (RNDFS): 0. | NDFMIN = 24933. NUM_NOSHAKE = 0 CORRECTED RNDFP = 24933. | TOTAL # of degrees of freedom (RNDF) = 24933. --------------------------------------------------- APPROXIMATING switch and d/dx switch using CUBIC SPLINE INTERPOLATION using 5000.0 points per unit in tabled values TESTING RELATIVE ERROR over r ranging from 0.0 to cutoff | CHECK switch(x): max rel err = 0.2738E-14 at 2.422500 | CHECK d/dx switch(x): max rel err = 0.8987E-11 at 2.875760 --------------------------------------------------- | Local SIZE OF NONBOND LIST = 25 | TOTAL SIZE OF NONBOND LIST = 123 ---> crash > > On 2/23/14, 9:19 AM, "FyD" <fyd.q4md-forcefieldtools.org> wrote: > >> Dear All, >> >> I ran amber10/sander.MPI with PME + cutoff = 0 -> sander crashes >> amber12/sander.MPI with PME + cutoff = 0 -> sander crashes >> (compiled with intel13 + mkl) >> amber12/pmemd.MPI with PME + cutoff = 0 -> pmemd does not crash... >> >> Printed output: printing stops in section 4: >> >> -------------------------------------------------------------------------- >> ------ >> 4. RESULTS >> -------------------------------------------------------------------------- >> ------ >> >> | # of SOLUTE degrees of freedom (RNDFP): 24936. >> | # of SOLVENT degrees of freedom (RNDFS): 0. >> | NDFMIN = 24933. NUM_NOSHAKE = 0 CORRECTED RNDFP = >> 24933. >> | TOTAL # of degrees of freedom (RNDF) = 24933. >> >> -> nothing else is printed... >> >> In Fox & Kollman J.Phys.Chem.B 1998, 102, 8070, MD simulation with >> cutoff = 0 is reported & Sander from Amber 4.1 was used. >> >> Why does sander crash, while pmemd does not crash in this case? >> (with the same input & cut = 12, sander does not crash) >> >> thank you, regards, >> Francois >> >> >> >> # Cst pressure simulation with cutoff = 0 Angs; 300 K short >> $PARAL -np $NPROC $EXE -O -i md-cstpres0.in \ >> -o md-cstpres0b.out \ >> -p $mol.parm7 \ >> -c md-cstvol.rst7 \ >> -r md-cstpres0b.rst7 \ >> -x md-cstpres0b.mdcrd >> >> my test input below: >> >> cst pressure MD, nstlim*dt psec, PME with cutoff >> &cntrl >> nmropt = 0, ioutfm = 1, iwrap = 0, >> ntx = 1, irest = 0, ntrx = 1, ntxo = 1, >> ntpr = 100, ntwr = 1000, ntwx = 500, >> ntave = 0, ntwv = 0, ntwe = 0, >> ntf = 2, ntb = 2, >> ntc = 2, tol = 0.00001, >> dielc = 1, ipol = 0, >> cut = 0, ig = 71277, comp = 52.5, >> ibelly = 0, ntr = 0, igb = 0, >> imin = 0, nstlim = 5000, >> nscm = 1000, t = 0.0, dt = 0.002, >> temp0 = 300, tempi = 300, >> ntt = 1, tautp = 0.2, vlimit = 20, >> ntp = 1, pres0 = 1.0, taup = 0.2, >> &end ------------------------------ Message: 23 Date: Mon, 24 Feb 2014 07:54:50 -0500 From: David A Case <case.biomaps.rutgers.edu> Subject: Re: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be accomplished To: AMBER Mailing List <amber.ambermd.org> Message-ID: <20140224125450.GE58335.biomaps.rutgers.edu> Content-Type: text/plain; charset=us-ascii On Mon, Feb 24, 2014, Mele N. wrote: > > I am trying to equilibrate a box of mixture water DMSO/Water created > thanks to packmol software. During the equilibration step I get this > error: > > vlimit exceeded for step 0; vmax = 128.9242 > > Equilibration > &cntrl > imin=0, irest=0, ntx=1, > nstlim=100, dt=0.002, > ntc=2, ntf=2, > ntb=2, ntp=1, taup=2.0, > ntpr=1, ntwx=1, ntwr=1, > ntt=3, gamma_ln=2.0, > temp0=300.0,iwrap=1, > / Equilibrate first with ntb=1,npt=0, then move to ntb=2,ntp=1. Also, for some systems, doing a bit of equilibration with dt=0.001, before moving to dt=0.002 sometimes helps. The fact that you get the error at step 0 is odd. It might be good to re-do the minimization step with SHAKE turned on. Generally, you want the minimization and MD steps to use identical parameters. ...dac ------------------------------ Message: 24 Date: Mon, 24 Feb 2014 20:58:43 +0800 (CST) From: Sun <sunbintyy.163.com> Subject: Re: [AMBER] pbsa calculation using sander To: "AMBER Mailing List" <amber.ambermd.org> Message-ID: <1632453e.1e800.14463f9def8.Coremail.sunbintyy.163.com> Content-Type: text/plain; charset=GBK Hi dac, Thanks for your kindly reply, but I actually did NOT use sander.MPI. the program I used was JUST sander. -Sun At 2014-02-24 20:47:09,"David A Case" <case.biomaps.rutgers.edu> wrote: >On Mon, Feb 24, 2014, Sun wrote: > >> | Flags: MPI >> PBSA currently doesn't work with MPI inside SANDER. >> >> What does the error message mean ? How should I modify the input file to >> successfully conduct the calculation ? > >As Amber error messages go, this one is pretty clear(!). For the >calculation >you want, you have to use sander (not sander.MPI) as the program doing the >calculation. It's not the input file but the command line that you need to >change. > >....dac > > >_______________________________________________ >AMBER mailing list >AMBER.ambermd.org >http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 25 Date: Mon, 24 Feb 2014 08:07:49 -0500 From: Jason Swails <jason.swails.gmail.com> Subject: Re: [AMBER] asking about pmemd and GTX 660 Ti compatibility To: amber.ambermd.org Message-ID: <1393247269.13429.56.camel.heroes-out.rutgers.edu> Content-Type: text/plain; charset="UTF-8" On Mon, 2014-02-24 at 15:31 +0700, setyanto md wrote: > Dear Amber User and developer, > > I have 2 question: > > first: > I just read in AMBER 12 Manual, in page 248, sub 7.7.7 Considerations for > Maximizing GPU Performance, point 4. > It is said : > 4. Avoid using the NTP ensemble (NTB=2) when it is not required. > Performance will generally be NVE~NVT>NPT. > > I just to make sure that to term "avoid" doesn't mean prohibited. So I can > still make simulation with NPT ensemble. It right ? Correct, it is not prohibited. In fact, the upcoming Amber 14 release will feature a Monte Carlo barostat that has performance close to that of NVT and NVE _and_ samples rigorously from the isobaric-isothermal ensemble. > second: > My Lab will buy GTX 660 Ti, with 1344 cuda core. Does the GPU accelerated > MD in AMBER support this hardware ? It will run, if that's what you're asking. It hasn't been explicitly tested as far as I know, but it should work in principle. HTH, Jason -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ------------------------------ Message: 26 Date: Mon, 24 Feb 2014 18:38:28 +0530 From: Arun Kumar Somavarapu <arunks.imtech.res.in> Subject: Re: [AMBER] using ff99SB forcefiled to a complex where ligand charge is from Glycam_04 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <5d689fe25e139f6ac0899349f3fd4463.imtech.res.in> Content-Type: text/plain; charset=UTF-8 Thank you Sir. I am in little bit confuse, i have ligand bound to protein whose charge is defined through Glycam ff, now do i have to source GLYCAM_06 ff also along with ff12SB. Regards On 2014-02-24 18:20, David A Case wrote: > On Mon, Feb 24, 2014, Karl Kirschner wrote: > >> If you have a pure oligosaccharides that is composed of residue found >> within Glycam04 and does not contain any unusual linkages to the protein >> (e.g. it is a nonbonded complex), then you should use the Glycam >> parameter set for the carbohydrates and the ff99SB for the protein. > > Just a minor update: we recommend using the ff12SB force field for the > protein. This is also compatible with Glycam, but has improved torsion > parameters for the protein part, and generally should give better results. > > ....dac > > _______________________________________________ > AMBER mailing list > AMBER.ambermd.org > http://lists.ambermd.org/mailman/listinfo/amber [1] -- Arun Kumar Somavarapu Project Fellow, Dr. Pawan Gupta Lab, Protein Science and Engineering Dept, Institute of Microbial Tecnology, Sec 39-A, Chandigarh - 160036. Links: ------ [1] http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 27 Date: Mon, 24 Feb 2014 08:11:13 -0500 From: Jason Swails <jason.swails.gmail.com> Subject: Re: [AMBER] pbsa calculation using sander To: amber.ambermd.org Message-ID: <1393247473.13429.59.camel.heroes-out.rutgers.edu> Content-Type: text/plain; charset="UTF-8" On Mon, 2014-02-24 at 20:58 +0800, Sun wrote: > Hi dac, > > > Thanks for your kindly reply, but I actually did NOT use sander.MPI. > the program I used was JUST sander. Then Amber was not compiled 'properly'. It's certainly possible to have a sander executable that is _really_ sander.MPI, but this would indicate a non-standard compilation procedure. I suggest recompiling, following the instructions in the first chapter of the AmberTools manual. Without knowing exactly what you did it's impossible to provide any more help. HTH, Jason -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ------------------------------ Message: 28 Date: Mon, 24 Feb 2014 13:11:09 +0000 From: "de Waal, Parker" <Parker.DeWaal.vai.org> Subject: Re: [AMBER] New bonds in PyMol? To: AMBER Mailing List <amber.ambermd.org> Message-ID: <974700F6B71AA04897B9105CC7E1AAFA704510.VAIEXMB01.vai.org> Content-Type: text/plain; charset="us-ascii" Hi Dac, Thank you for the advice. I confirmed that the prmtop file does not contain a bond between the carbons with parmed.py (thankfully). Cheers, Parker ________________________________________ From: David A Case [case.biomaps.rutgers.edu] Sent: Monday, February 24, 2014 7:43 AM To: AMBER Mailing List Subject: Re: [AMBER] New bonds in PyMol? On Mon, Feb 24, 2014, de Waal, Parker wrote: > > When visualizing my simulation in pymol I noticed that a new bond seems > to form between two carbons in my ligand not present in the tleap output > (paramaterized as cc and cd). Interestingly when I view the same pdb > snapshot in UCSF Chimera or VMD the bond is not present. Depending on what sort of input you give it, visualization programs can make lots of different decisions about whether or not to show a bond between two atoms. The default is often to use some pretty arbitrary distance criterion. It's is generally not enough to say "I used pymol, or VMD...". What is shown on the screen also depends on the type of file you use as input. If you haven't yet done so, use the printBonds command in http://scanmail.trustwave.com/?c=129&d=kL6L0x4Ao_79TfGWyE7sEf2Ye6LP9S9RIqVaCRuMmw&u=http%3a%2f%2fparmed%2epy to determine which bonds are actually contained in the prmtop file. What is in the prmtop file is what is really used by sander or pmemd. ...dac _______________________________________________ AMBER mailing list AMBER.ambermd.org http://scanmail.trustwave.com/?c=129&d=kL6L0x4Ao_79TfGWyE7sEf2Ye6LP9S9RIqNeCRWPnw&u=http%3a%2f%2flists%2eambermd%2eorg%2fmailman%2flistinfo%2famber ------------------------------ Message: 29 Date: Mon, 24 Feb 2014 08:13:31 -0500 From: Jason Swails <jason.swails.gmail.com> Subject: Re: [AMBER] MMPBSA.py error To: amber.ambermd.org Message-ID: <1393247611.13429.61.camel.heroes-out.rutgers.edu> Content-Type: text/plain; charset="UTF-8" On Mon, 2014-02-24 at 11:31 +0000, almarques wrote: > Hi, > > I have bee trying to run the mmpbsa.py for alanine scanning mutagenesis > but I always get this error: > > Loading and checking parameter files for compatibility... > PrmtopError: Couldn't predict mask from topology files! > Your ligand residues must be sequential in your complex. > There are likely problems with your topology files if this is not the > case. > > My input is: > > sample input file for running alanine scanning > &general > startframe=3000, endframe=5000, interval=1000, > verbose=1, > ligand_mask=':1-200,806,810', > receptor_mask=':201-401,402-603,604-805,807,808,809,811,812,813', Consider simplifying your receptor mask to ':201-805,807-809,811-813' Also, it would help to know what version of AmberTools you are using. -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ------------------------------ Message: 30 Date: Mon, 24 Feb 2014 18:51:27 +0530 From: Arun Kumar Somavarapu <arunks.imtech.res.in> Subject: Re: [AMBER] MMPBSA binding energy for all frames To: AMBER Mailing List <amber.ambermd.org> Message-ID: <88021e83cab5f20ac2a782bbe0954251.imtech.res.in> Content-Type: text/plain; charset=UTF-8 Thank you Dr. Vlad. As i have done my simulation with amber 11 i want to calculate binding energy with MMPBSA from Ambertools1.5, is there any way to calculate binding energy to all frames as like -eo option in new MMPBSA. Regards On 2014-02-21 18:11, Vlad Cojocaru wrote: > We and others did lots of tests with different MMPBSA parameters and the > result is that parameters can influence the dG even by 100 kcal/mol ... > In your case, the difference comes probably because the older MMPBSA > used different default values for certain parameters ... > > The other issue is that the "best" combination of parmeters seem to > depend quite a bit on the system under study. This makes the choices for > the defaults very tricky .... > > Short answer, nobody but yourself after very careful investigation will > probably be able to tell you which of your result is "good" and which > one is "bad" ... > > Longer answer ... > > My advice is to understand and test very carefully all parameters used > by MMPBSA and read as much literature with MMPBSA studies as possible > ... Ideally you have a toy system for which you have some experimental > data that has similar properties with your system. You can then use this > toy system to test which combination of parameters is best for your case > .... The other important thing, use your knowledge and physico-chemical > intuition to understand whether a result is potentially reasnable or is > non-sense ... > > MMPBSA can be a very useful technique but is very tricky .... > > Good luck, > Vlad > > On 02/21/2014 12:56 PM, Arun Kumar Somavarapu wrote: > Thanks all for your valuable information. As like Dr. Jason said i changed > the environment variables to AmberTools 13 and it got worked out. Thanks > Dr. Vlad I got the result in the way i was expecting with -eo option, but > there was a huge difference in POISSON BOLTZMANN Avg binding energy > say -35 with old version and 42 with Ambertools 13, where as not the case > with GENERALIZED BORN, which one i have to consider and why is that > difference occurred only in case of Poisson Boltzmann? Regards On > 2014-02-21 00:12, Vlad Cojocaru wrote: Hi Arun, Sorry, I overlooked one > phrase in your error message (the most important one) ... "getpdb: can't > open file pdb" ... I have never seen this error before. I guess somebody > else can help more ... When I mentioned about the memory issue, I referred > to the error "failed with prmtop" Vlad On 02/20/2014 05:55 PM, Arun Kumar > Somavarapu wrote: yes Sir, the -eo option is present in AmberTools 13 and > i was using Amber 11 and AmberTools 12 where -eo option is not present. later on i tried MMPBSA.py in AmberTools 13 with command like MMPBSA.py -O -i mmpbsa.in -o FINAL_RESULTS_MMPBSA.dat -sp ../complex-solv.prmtop -cp ../complex-gas.prmtop -rp ../receptor-gas.prmtop -lp ../ligand-gas.prmtop -y ../prod1.mdcrd.gz -eo energyout this time it is exiting with an error as fallows Loading and checking parameter files for compatibility... mmpbsa_py_energy found! Using /home/braf/md/amber11/bin/mmpbsa_py_energy cpptraj found! Using /home/braf/md/amber11/bin/cpptraj Preparing trajectories for simulation... 50 frames were processed by cpptraj for use in calculation. Running calculations on normal system... Beginning GB calculations with /home/braf/md/amber11/bin/mmpbsa_py_energy calculating complex contribution... getpdb: can't open file pdb CalcError: /home/braf/md/amber11/bin/mmpbsa_py_energy failed with prmtop ../complex-gas.prmtop! Exiting. All files have been retained. can you please help me to resolve this. Thanking you. On 2014-02-20 18:09, Vlad Cojocaru wrote: No, it is not. Please check the AmberTools 13 user guide. The "-eo" option is described very clear in the section describing how to run MMPBSA.py. Best wishes Vlad On 02/20/2014 12:45 PM, Arun Kumar Somavarapu wrote: Hello Sir, Thanks for reply. I am not able to find option -eo. There is an option of -do (decomp_output_file), is that you are talking about? Regards On 2014-02-20 16:48, Vlad Cojocaru wrote: Please check the "-eo" option when running MMPBSA.py ... This outputs a file with energies at every processed frame. Best Vlad On 02/20/2014 12:12 PM, Arun Kumar Somavarapu wrote: Hello Sir, I am calculating free energy of a protein ligand complex and want to see the binding energy variation in each frame through out time scale. After sing MMPBSA.py I am able to see only one value for Delta G binding energy in FINAL_RESULTS_MMPBSA.dat file. I have also checked MMPBSA_complex_pb.mdout where individual energies are present to each trj frame, will these be further processed to get final binding energy for each frame? or else, if there is any other method please guide me. Thanking you. Regards -- Dr. Vlad Cojocaru Max Planck Institute for Molecular Biomedicine Department of Cell and Developmental Biology R?ntgenstrasse 20, 48149 M?nster, Germany Tel: +49-251-70365-324; Fax: +49-251-70365-399 Email: vlad.cojocaru[at]mpi-muenster.mpg.de http://www.mpi-muenster.mpg.de/research/teams/groups/rgcojocaru [1] _______________________________________________ AMBER mailing list AMBER.ambermd.org http://lists.ambermd.org/mailman/listinfo/amber [2] -- Arun Kumar Somavarapu Project Fellow, Dr. Pawan Gupta Lab, Protein Science and Engineering Dept, Institute of Microbial Tecnology, Sec 39-A, Chandigarh - 160036. Links: ------ [1] http://www.mpi-muenster.mpg.de/research/teams/groups/rgcojocaru [2] http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 31 Date: Mon, 24 Feb 2014 21:29:48 +0800 (CST) From: Sun <sunbintyy.163.com> Subject: Re: [AMBER] pbsa calculation using sander To: "AMBER Mailing List" <amber.ambermd.org> Message-ID: <49221da3.1ef53.1446416517a.Coremail.sunbintyy.163.com> Content-Type: text/plain; charset=GBK Hi Jason, We have figured it out : Only the parallel version of sander has been compiled on the platform and the native name ?sander.MPI? has been changed as "sander" for convenience. So when I typed "sander" , It was actually the sander.MPI being executed. After all, thanks for your implying . -Sun At 2014-02-24 21:11:13,"Jason Swails" <jason.swails.gmail.com> wrote: >On Mon, 2014-02-24 at 20:58 +0800, Sun wrote: >> Hi dac, >> >> >> Thanks for your kindly reply, but I actually did NOT use sander.MPI. >> the program I used was JUST sander. > >Then Amber was not compiled 'properly'. It's certainly possible to have >a sander executable that is _really_ sander.MPI, but this would indicate >a non-standard compilation procedure. I suggest recompiling, following >the instructions in the first chapter of the AmberTools manual. > >Without knowing exactly what you did it's impossible to provide any more >help. > >HTH, >Jason > >-- >Jason M. Swails >BioMaPS, >Rutgers University >Postdoctoral Researcher > > >_______________________________________________ >AMBER mailing list >AMBER.ambermd.org >http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 32 Date: Mon, 24 Feb 2014 14:34:25 +0100 From: Vlad Cojocaru <vlad.cojocaru.mpi-muenster.mpg.de> Subject: Re: [AMBER] MMPBSA binding energy for all frames To: AMBER Mailing List <amber.ambermd.org> Message-ID: <530B4A61.60502.mpi-muenster.mpg.de> Content-Type: text/plain; charset=UTF-8; format=flowed Dear Arun, Sorry, I do not have experience with MMPBSA in earlier versions of Amber Tools. Personally, I would really recommend to use the MMPBSA from Amber Tools 13 regardless of the program you used to run your simulations.... The MMPBSA does not depend in any way on the program you run the simulations ... The method undergoes continuous development and the latest version is I believe significantly improved ... Best, Vlad On 02/24/2014 02:21 PM, Arun Kumar Somavarapu wrote: > > > Thank you Dr. Vlad. > > As i have done my simulation with amber 11 i want to calculate binding > energy with MMPBSA from Ambertools1.5, is there any way to calculate > binding energy to all frames as like -eo option in new MMPBSA. > > Regards > > On 2014-02-21 18:11, Vlad Cojocaru wrote: > >> We and others did lots of tests with different MMPBSA parameters and the >> result is that parameters can influence the dG even by 100 kcal/mol ... >> In your case, the difference comes probably because the older MMPBSA >> used different default values for certain parameters ... >> >> The other issue is that the "best" combination of parmeters seem to >> depend quite a bit on the system under study. This makes the choices for >> the defaults very tricky .... >> >> Short answer, nobody but yourself after very careful investigation will >> probably be able to tell you which of your result is "good" and which >> one is "bad" ... >> >> Longer answer ... >> >> My advice is to understand and test very carefully all parameters used >> by MMPBSA and read as much literature with MMPBSA studies as possible >> ... Ideally you have a toy system for which you have some experimental >> data that has similar properties with your system. You can then use this >> toy system to test which combination of parameters is best for your case >> .... The other important thing, use your knowledge and physico-chemical >> intuition to understand whether a result is potentially reasnable or is >> non-sense ... >> >> MMPBSA can be a very useful technique but is very tricky .... >> >> Good luck, >> Vlad >> >> On 02/21/2014 12:56 PM, Arun Kumar Somavarapu wrote: >> Thanks all for your valuable information. As like Dr. Jason said i >> changed the environment variables to AmberTools 13 and it got worked out. >> Thanks Dr. Vlad I got the result in the way i was expecting with -eo >> option, but there was a huge difference in POISSON BOLTZMANN Avg binding >> energy say -35 with old version and 42 with Ambertools 13, where as not >> the case with GENERALIZED BORN, which one i have to consider and why is >> that difference occurred only in case of Poisson Boltzmann? Regards On >> 2014-02-21 00:12, Vlad Cojocaru wrote: Hi Arun, Sorry, I overlooked one >> phrase in your error message (the most important one) ... "getpdb: can't >> open file pdb" ... I have never seen this error before. I guess somebody >> else can help more ... When I mentioned about the memory issue, I >> referred to the error "failed with prmtop" Vlad On 02/20/2014 05:55 PM, >> Arun Kumar Somavarapu wrote: yes Sir, the -eo option is present in >> AmberTools 13 and i was using Amber 11 and AmberTools 12 where -eo option > is not present. later on i tried MMPBSA.py in AmberTools 13 with command > like MMPBSA.py -O -i mmpbsa.in -o FINAL_RESULTS_MMPBSA.dat -sp > ../complex-solv.prmtop -cp ../complex-gas.prmtop -rp > ../receptor-gas.prmtop -lp ../ligand-gas.prmtop -y ../prod1.mdcrd.gz -eo > energyout this time it is exiting with an error as fallows Loading and > checking parameter files for compatibility... mmpbsa_py_energy found! > Using /home/braf/md/amber11/bin/mmpbsa_py_energy cpptraj found! Using > /home/braf/md/amber11/bin/cpptraj Preparing trajectories for simulation... > 50 frames were processed by cpptraj for use in calculation. Running > calculations on normal system... Beginning GB calculations with > /home/braf/md/amber11/bin/mmpbsa_py_energy calculating complex > contribution... getpdb: can't open file pdb CalcError: > /home/braf/md/amber11/bin/mmpbsa_py_energy failed with prmtop > ../complex-gas.prmtop! Exiting. All files have been retained. can you > please help me to resolve this. Thanking you. On 2014-02-20 18:09, > Vlad Cojocaru wrote: No, it is not. Please check the AmberTools 13 user > guide. The "-eo" option is described very clear in the section describing > how to run MMPBSA.py. Best wishes Vlad On 02/20/2014 12:45 PM, Arun Kumar > Somavarapu wrote: Hello Sir, Thanks for reply. I am not able to find > option -eo. There is an option of -do (decomp_output_file), is that you > are talking about? Regards On 2014-02-20 16:48, Vlad Cojocaru wrote: > Please check the "-eo" option when running MMPBSA.py ... This outputs a > file with energies at every processed frame. Best Vlad On 02/20/2014 12:12 > PM, Arun Kumar Somavarapu wrote: Hello Sir, I am calculating free energy > of a protein ligand complex and want to see the binding energy variation > in each frame through out time scale. After sing MMPBSA.py I am able to > see only one value for Delta G binding energy in FINAL_RESULTS_MMPBSA.dat > file. I have also checked MMPBSA_complex_pb.mdout where individual > energies are present to each trj frame, will these be further > processed to get final binding energy for each frame? or else, if there is > any other method please guide me. Thanking you. Regards > -- Dr. Vlad Cojocaru Max Planck Institute for Molecular Biomedicine Department of Cell and Developmental Biology R?ntgenstrasse 20, 48149 M?nster, Germany Tel: +49-251-70365-324; Fax: +49-251-70365-399 Email: vlad.cojocaru[at]mpi-muenster.mpg.de http://www.mpi-muenster.mpg.de/research/teams/groups/rgcojocaru ------------------------------ Message: 33 Date: Mon, 24 Feb 2014 08:45:57 -0500 From: Jason Swails <jason.swails.gmail.com> Subject: Re: [AMBER] PME with cutoff = 0 To: amber.ambermd.org Message-ID: <1393249557.13429.86.camel.heroes-out.rutgers.edu> Content-Type: text/plain; charset="UTF-8" On Mon, 2014-02-24 at 10:31 +0100, FyD wrote: > Dear Robert, > > > The cutoff value of "0.d0" in pmemd for a pme run is equivalent to > > requesting that the default values be used - probably 8.0 angstrom, > > if memory serves, assuming igb 0 for a pme simulation. > > Yes - this corresponds to what I get... > > I compare MD simulations (with PME) with cut = 12 vs cut = 0 > the obtained results are very similar. > > This means 'cut = O' does not do what I want; I wonder if crashing is > not better than generating data in this case... > > > PME does strange things at small-ish cutoff, but does not allow 0 > > (in the sense that it says "oh, you wanted 8"), and I presume later > > catches and disallows cut < 0. In my experience, reducing the > > direct space cut below roughly 7.0 angstrom causes unacceptable > > error limits unless you increase grid density for reciprocal space > > (there is basically a balancing act between reciprocal and direct > > space in terms of what is necessary to keep error acceptable). And > > if you think long cutoffs are expensive, play around a bit with > > greatly increasing nfft1,2,3 in a large system :-}. So all I am > > really answering here is why pmemd ran - it basically ignored you... > > ok > > > I would have to read the paper done with amber 4.1 to have a clue > > what they were really up to, > > See http://pubs.acs.org/doi/full/10.1021/jp9717655 - It is written: > > "The heat of vaporization is computed from the average intermolecular > interaction energy Eint via dHvap = -Eint + RT > For molecules that do not have an internal nonbonded interaction > beyond 1?4 (e.g., the chloromethanes), Eint is calculated > straightforwardly as the sum of EELEC and ENONB in the SANDER output, > divided by the number of molecules in the system. For all other > molecules, EELEC and ENONB also contain contributions from > intramolecular nonbonded interactions. To correct for these, we > performed a short simulation with the nonbonded cutoff radius set to > zero. Due to the residue-based cutoff in AMBER, EELEC and ENONB now > accumulate only the intraresidue nonbonded interactions that can be > subtracted from the total to yield the intermolecular portion needed > for the calculation of dHvap." > > > but pmemd is designed to always use either > > pme or generalized Born, so resurrecting an old copy of sander may > > be your best bet.. > > I use PME & would like to continue to use PME. > Resurrecting an old copy of sander? uff... I would actually suggest that you really _don't_ want to use PME for this particular calculation. What you're effectively trying to do is eliminate the intra-molecular nonbonded interactions so that you can compute the inter-molecular nonbonded interactions exclusively. It seems that the strategy is to compute the full electrostatics (using PME) and then subtract out the intramolecular nonbonded energies (using no PME and a group-based cutoff of 0 to ensure that atoms interact only with other atoms in the same residue). This is a trick that takes advantage of a key assumption: each solvent molecule is made up of a single residue only. > Does it means this is not possible to carefully study/check solvent > boxes with Amber nowadays? I've never tried pure group-based cutoffs with no Ewald sum. It may not work anymore since it's a somewhat unusual simulation (nor is it particularly general since it relies on the above assumption). If group-based cutoffs still work and the assumption above holds for your system, that's the easiest solution. There are alternatives, though, that depend on the nature of your 'molecule'. 1) Does the molecule have any atoms that are no farther than 2 bonds away? If not (like with water and chloromethane), then there are no intramolecular nonbonded interactions and this step is unnecessary. 2) Does the molecule have any atoms that are no farther than 3 bonds away? If not (like with ethane and ethanol), then you can simply ignore the 1-4 VDW and 1-4 EEL contributions (again, making this step unnecessary). 3) The most tedious scenario if there are intramolecular energies you need to get rid of. You can, using ParmEd, zero out the charges and van der Waals parameters for every molecule *except* the molecule whose intramolecular NB interactions you want and simply compute a (non-periodic) energy in which you know the EEL and VDW contributions are strictly intramolecular. You can then do this for every molecule in your system and sum them up to get the total intramolecular nonbonded energy (or, alternatively, if your molecules are rigid due to constraints you can simply multiply by the number of molecules you have). If you are comfortable with Python programming, you can do step 3 in a single Python script using the ParmEd API like so: from chemistry.amber.readparm import AmberParm from ParmedTools.ParmedActions import change, addljtype for i in range(num_molecules): parm = AmberParm('path/to/prmtop') change(parm, 'CHARGE', '!:%d' % i, 0.0) addljtype(parm, '!:%d' % i, radius=0.0, epsilon=0.0) parm.writeParm('tmp.parm7') # System call to compute energy Alternatively you can write a quick NAB program to do something equivalent. In both cases, help can be found in the AmberTools manual. HTH, Jason -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ------------------------------ Message: 34 Date: Mon, 24 Feb 2014 14:28:09 +0000 From: almarques <almarques.itqb.unl.pt> Subject: Re: [AMBER] MMPBSA.py error To: AMBER Mailing List <amber.ambermd.org> Message-ID: <a7565c0811e21da1b599e5b0c3e47d87.itqb.unl.pt> Content-Type: text/plain; charset=UTF-8; format=flowed Thank you. I did that but I obtained the same error. I also extracted the pdb file from frame 1 of the trajectory without solvent to see if the residue numbers are correct and indeed they match those in the top file of the complex. Does anyone has other suggestion about what may be wrong? I am using AmberTools12. Em 2014-02-24 13:13, Jason Swails escreveu: > On Mon, 2014-02-24 at 11:31 +0000, almarques wrote: >> Hi, >> >> I have bee trying to run the mmpbsa.py for alanine scanning >> mutagenesis >> but I always get this error: >> >> Loading and checking parameter files for compatibility... >> PrmtopError: Couldn't predict mask from topology files! >> Your ligand residues must be sequential in your complex. >> There are likely problems with your topology files if this is not the >> case. >> >> My input is: >> >> sample input file for running alanine scanning >> &general >> startframe=3000, endframe=5000, interval=1000, >> verbose=1, >> ligand_mask=':1-200,806,810', >> receptor_mask=':201-401,402-603,604-805,807,808,809,811,812,813', > > Consider simplifying your receptor mask to ':201-805,807-809,811-813' > > Also, it would help to know what version of AmberTools you are using. ------------------------------ Message: 35 Date: Mon, 24 Feb 2014 15:50:43 +0100 From: Karl Kirschner <k.n.kirschner.gmail.com> Subject: Re: [AMBER] using ff99SB forcefiled to a complex where ligand charge is from Glycam_04 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CAF=D-byXtZW7ZWTj9KBLhDwxPgj4DbeisXczA8gb9AwMd3weTA.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Concerning your questions, there are two issue when creating a model for which you will run an MD simulation upon. As you noted, you have been careful concerning the development of partial atomic charges for your ligand. This is the first issue and is an attempt to correctly capture the Coulomb forces. The second is concerning the force-field parameters that govern all other forces that are present in your model, such as van der Waals, bonds, angles, and torsions. These forces are defined by your force-field parameters (e.g. Glycam06, parm12SB, gaff). As a complete set of forces, your Coulomb forces need to be balanced with the other forces-field parameters - meaning that the the partial atomic charge methodology that was used to develop the residue/ligands was also used in developing the force fields that you will apply. Different force fields have used different methodologies for determining partial atomic charge (i.e. Glycam06 charges are different than parm12SB). When creating your leap input file, you can source different force fields. If you source two force fields, then the parameters in the second referenced force field will over write those of the first referenced if they are present if both force fields. Because of this, different force fields are generated such that the atom type names prevents this from occurring as much as possible. Thus, parm12SB uses XX naming for an atom type, gaff uses xx, Glycam-06j uses xX, or custom made force fields introduce new atom types (e.g. CT in parm12SB versus CG in early versions of Glycam-06, both describing sp3 hybridized carbons). All residues within the Glycam-06j database will have their atoms following its naming convention, while all parm12SB residues will follow its own naming convention. Now back to your question. If you have correctly named the atom types within your ligand to follow the naming convention of the Glycam force field that you will use, then yes you should source both. If you are following a different atom type naming convention for your ligand, then I would consider this to be nonstandard and would not feel comfortable giving you an answer. It is nonstandard because you are using Glycam06 charge development methodology with atom types (and thus parameters) that belong to a different force field. If you used the R.E.D. server, then follow what Francois has told you as he is the expert concerning R.E.D. and its usage. If you are still confused by this, then take a look at the AmberTools manual and take a look at the Glycam06 and parm94 papers. Parm94 is the predecessor of the ParmXX force-field family, and they all use the same basic charge development method (i.e. 2-stage resp). Bests regards, Karl On Mon, Feb 24, 2014 at 2:08 PM, Arun Kumar Somavarapu <arunks.imtech.res.in > wrote: > > > Thank you Sir. > > I am in little bit confuse, i have ligand bound to protein whose charge > is defined through Glycam ff, now do i have to source GLYCAM_06 ff also > along with ff12SB. > > Regards > > On 2014-02-24 18:20, David A Case wrote: > > > On Mon, Feb 24, 2014, Karl Kirschner wrote: > > > >> If you have a pure oligosaccharides that is composed of residue found > within Glycam04 and does not contain any unusual linkages to the protein > (e.g. it is a nonbonded complex), then you should use the Glycam parameter > set for the carbohydrates and the ff99SB for the protein. > > > > Just a minor update: we recommend using the ff12SB force field for the > > protein. This is also compatible with Glycam, but has improved torsion > > parameters for the protein part, and generally should give better > results. > > > > ....dac > > > > _______________________________________________ > > AMBER mailing list > > AMBER.ambermd.org > > http://lists.ambermd.org/mailman/listinfo/amber [1] > > -- > Arun Kumar Somavarapu > Project Fellow, > Dr. Pawan Gupta Lab, > Protein Science and Engineering Dept, > Institute of Microbial Tecnology, > Sec 39-A, Chandigarh - 160036. > > > Links: > ------ > [1] http://lists.ambermd.org/mailman/listinfo/amber > _______________________________________________ > AMBER mailing list > AMBER.ambermd.org > http://lists.ambermd.org/mailman/listinfo/amber > ------------------------------ Message: 36 Date: Mon, 24 Feb 2014 09:57:57 -0500 From: Jason Swails <jason.swails.gmail.com> Subject: Re: [AMBER] MMPBSA.py error To: amber.ambermd.org Message-ID: <1393253877.1632.9.camel.heroes-out.rutgers.edu> Content-Type: text/plain; charset="UTF-8" On Mon, 2014-02-24 at 14:28 +0000, almarques wrote: > Thank you. I did that but I obtained the same error. > I also extracted the pdb file from frame 1 of the trajectory without > solvent to see if the residue numbers are correct and indeed they match > those in the top file of the complex. Does anyone has other suggestion > about what may be wrong? > I am using AmberTools12. Try AmberTools 13 instead. If you send me your topology files and an example with your topology files and a trajectory that has 2 frames I will look into it (in a compressed tarball please). You may have to post them on Dropbox or something if they're too big to attach here. Thanks, Jason -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ------------------------------ Message: 37 Date: Mon, 24 Feb 2014 07:26:46 -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: <CF30A1CB.3AAC7%ross.rosswalker.co.uk> Content-Type: text/plain; charset="US-ASCII" 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. ------------------------------ Message: 38 Date: Mon, 24 Feb 2014 10:33:23 -0500 From: Carlos Simmerling <carlos.simmerling.gmail.com> Subject: Re: [AMBER] pmemd.CUDA.mpi micro-second long simulation To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CAGk3s-Sw3SZA=8PfdMk+mKh6VKKM=YYwDa9F=dUM3mMRv44ZiQ.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 I agree with Ross - unless you have a fairly large number of successful binding events, you would not be able to predict affinity, kinetics, allostery, or even the actual binding pocket. It's not clear what you could actually "predict" at all (without already knowing the answer). My opinion is that just because you could simulate the process as it occurs in vitro, it doesn't mean that doing the brute force calculation is the smart thing to do. Stat mech gives us many ways to solve problems more easily than just mimicking the dynamics of the real world. And yes, this will have a huge dependence on ligand concentration in the simulation (as will your ability to compare your results to experiment). carlos On Mon, Feb 24, 2014 at 10: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 > ------------------------------ Message: 39 Date: Mon, 24 Feb 2014 08:03:08 -0800 From: Scott Le Grand <varelse2005.gmail.com> Subject: Re: [AMBER] GTX670 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CAOU=08f9MdvV3pRy9zbJ6WJXgCqXrD_VPu6tihsmz5oi+LCApw.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 How many atoms? Also does this always happen at the same step in the simulation? If so, it may be an AMBER bug. If it's happening at random places given the same input however, it's probably bad hardware Also, none of the Ge Force cards have been qualified in any way whatsoever for AMBER or other HPC applications. In general, they work just fine for them though. You get what you pay for of course. Scott On Mon, Feb 24, 2014 at 3:01 AM, De?k Robert <kokumetto.gmail.com> wrote: > Dear Amber users, > > Recently we bought 2 GTX 670 DC mini ( > http://www.asus.com/Graphics_Cards/GTX670DCMOC2GD5/) but with both of them > I experienced the same error message after random run time. > > The message is: > *cudaMemcpy GpuBuffer::Download failed unspecified launch failure* > > With exactly the same input files and input settings there are no error > messages using a GTX TITAN or a TESLA card. I have tried the GTX 670 cards > in the other machine, and also a TITAN card in this server, but the error > is related to GTX 670 cards, independently from the server. > > My question is, this type of error message means hardware failure? > > These are my input parameters: > &cntrl > imin = 0, irest = 0, ntx = 1, > ntb = 2, pres0 = 1.0, ntp = 1, > taup = 2.0, > cut = 11.0, ntr = 0, > ntc = 2, ntf = 2, > tempi = 300.0, temp0 = 300.0, > ntt = 3, gamma_ln = 0.1, > nstlim = 100000000, dt = 0.002, > ntpr = 1000, ntwx = 1000, ntwr = 1000, > ig=1, nscm=1000 > / > > Thanks, > Robert > _______________________________________________ > AMBER mailing list > AMBER.ambermd.org > http://lists.ambermd.org/mailman/listinfo/amber > ------------------------------ Message: 40 Date: Mon, 24 Feb 2014 08:12:43 -0800 From: Ross Walker <ross.rosswalker.co.uk> Subject: Re: [AMBER] GTX670 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CF30AD94.3AAEC%ross.rosswalker.co.uk> Content-Type: text/plain; charset="ISO-8859-1" Hi Robert, This does indeed sound like faulty GPUs - do they both do it? First download the latest version of the NVIDIA driver and install it - v331.49 from here: http://www.nvidia.com/object/unix.html See if that helps at all. Then try downloading my test suite: https://dl.dropboxusercontent.com/u/708185/GPU_Validation_Test_2cards.tar.g z Run this and it should run for about 24 hours (you might have to tweak the run script a little for your setup, paths etc). At the end check the log files - all 10 runs should give the same final energy and both GPUs should also match. If they don't (or you see crashes during the run) then it means your GPUs are faulty. All the best Ross On 2/24/14, 3:01 AM, "De?k Robert" <kokumetto.gmail.com> wrote: >Dear Amber users, > >Recently we bought 2 GTX 670 DC mini ( >http://www.asus.com/Graphics_Cards/GTX670DCMOC2GD5/) but with both of them >I experienced the same error message after random run time. > >The message is: >*cudaMemcpy GpuBuffer::Download failed unspecified launch failure* > >With exactly the same input files and input settings there are no error >messages using a GTX TITAN or a TESLA card. I have tried the GTX 670 cards >in the other machine, and also a TITAN card in this server, but the error >is related to GTX 670 cards, independently from the server. > >My question is, this type of error message means hardware failure? > >These are my input parameters: > &cntrl > imin = 0, irest = 0, ntx = 1, > ntb = 2, pres0 = 1.0, ntp = 1, > taup = 2.0, > cut = 11.0, ntr = 0, > ntc = 2, ntf = 2, > tempi = 300.0, temp0 = 300.0, > ntt = 3, gamma_ln = 0.1, > nstlim = 100000000, dt = 0.002, > ntpr = 1000, ntwx = 1000, ntwr = 1000, > ig=1, nscm=1000 > / > >Thanks, >Robert >_______________________________________________ >AMBER mailing list >AMBER.ambermd.org >http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 41 Date: Mon, 24 Feb 2014 17:30:15 +0100 From: De?k Robert <kokumetto.gmail.com> Subject: Re: [AMBER] GTX670 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CAEYkJNUGy+m1gUgx9NQQ4TphE6vU+2SDKkZLoe1stxCgR-Aq9w.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Thanks Scott and Ross! I have 23950 atoms and it's happening at random places given the same input as you wrote, Scott. The cards (both of them) produce the mentioned error from the first use ... I have tried the 319.60, 331.20, 331.38 drivers. Now, I will try the 331.49 driver, and the test tool from Ross, than I will write again. All the best, Robert 2014-02-24 17:12 GMT+01:00 Ross Walker <ross.rosswalker.co.uk>: > Hi Robert, > > This does indeed sound like faulty GPUs - do they both do it? > > First download the latest version of the NVIDIA driver and install it - > v331.49 from here: http://www.nvidia.com/object/unix.html > > See if that helps at all. Then try downloading my test suite: > > https://dl.dropboxusercontent.com/u/708185/GPU_Validation_Test_2cards.tar.g > z > > Run this and it should run for about 24 hours (you might have to tweak the > run script a little for your setup, paths etc). At the end check the log > files - all 10 runs should give the same final energy and both GPUs should > also match. If they don't (or you see crashes during the run) then it > means your GPUs are faulty. > > All the best > Ross > > > > On 2/24/14, 3:01 AM, "De?k Robert" <kokumetto.gmail.com> wrote: > > >Dear Amber users, > > > >Recently we bought 2 GTX 670 DC mini ( > >http://www.asus.com/Graphics_Cards/GTX670DCMOC2GD5/) but with both of > them > >I experienced the same error message after random run time. > > > >The message is: > >*cudaMemcpy GpuBuffer::Download failed unspecified launch failure* > > > >With exactly the same input files and input settings there are no error > >messages using a GTX TITAN or a TESLA card. I have tried the GTX 670 > >cards > >in the other machine, and also a TITAN card in this server, but the error > >is related to GTX 670 cards, independently from the server. > > > >My question is, this type of error message means hardware failure? > > > >These are my input parameters: > > &cntrl > > imin = 0, irest = 0, ntx = 1, > > ntb = 2, pres0 = 1.0, ntp = 1, > > taup = 2.0, > > cut = 11.0, ntr = 0, > > ntc = 2, ntf = 2, > > tempi = 300.0, temp0 = 300.0, > > ntt = 3, gamma_ln = 0.1, > > nstlim = 100000000, dt = 0.002, > > ntpr = 1000, ntwx = 1000, ntwr = 1000, > > ig=1, nscm=1000 > > / > > > >Thanks, > >Robert > >_______________________________________________ > >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: 42 Date: Mon, 24 Feb 2014 16:33:59 +0000 From: "Gould, Ian R" <i.gould.imperial.ac.uk> Subject: Re: [AMBER] GTX670 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CF312126.3DE5E%i.gould.imperial.ac.uk> Content-Type: text/plain; charset="iso-8859-1" Dear All, A few anecdotes, I recently bought 4 GTX780 Ti's and due to the PSU being out of stock I ended up temporarily utilising them in older machines with well used PSU's and all the motherboards were PCI 2.0 not 3.0. I ran my own version of Ross's 24 hour validation tests, 1 card was completely unreliable and would not report the same numbers on any rerun. The other three would report exactly the same numbers after numerous, greater than 20 repeats of the same run. However, one of them would occasionally have the "cudaMemcpy GpuBuffer::Download failed unspecified launch failure" error and this seemed totally random in its occurrence. Recently I received the PSU, a 1350W guaranteed with 108A on the +12V rail, and installed all three cards in a big chasis, ie well ventilated, with an ASROCK PCI 3.0 compliant board. Having rerun the test jobs on a loop that meant they were tested for 72 hours nonstop I had absolutely no failures. So my own personal conclusion is to 1) run Ross's test suite on all new GPU cards and if they fail RMA them 2) get the biggest and best PSU's you can afford, I would contend that 850W is minimum for a 1 GPU, 1000W for 2GPU's and 1350W for 3GPU's 3) I would not advise try a "home-brew" GTX 4 GPU solution as I really don't think it is easy to get an off the shelf PSU that would be rated 1.5Kw and above Cheers Ian On 24/02/2014 16:12, "Ross Walker" <ross.rosswalker.co.uk> wrote: >Hi Robert, > >This does indeed sound like faulty GPUs - do they both do it? > >First download the latest version of the NVIDIA driver and install it - >v331.49 from here: http://www.nvidia.com/object/unix.html > >See if that helps at all. Then try downloading my test suite: > >https://dl.dropboxusercontent.com/u/708185/GPU_Validation_Test_2cards.tar. >g >z > >Run this and it should run for about 24 hours (you might have to tweak the >run script a little for your setup, paths etc). At the end check the log >files - all 10 runs should give the same final energy and both GPUs should >also match. If they don't (or you see crashes during the run) then it >means your GPUs are faulty. > >All the best >Ross > > > >On 2/24/14, 3:01 AM, "De?k Robert" <kokumetto.gmail.com> wrote: > >>Dear Amber users, >> >>Recently we bought 2 GTX 670 DC mini ( >>http://www.asus.com/Graphics_Cards/GTX670DCMOC2GD5/) but with both of >>them >>I experienced the same error message after random run time. >> >>The message is: >>*cudaMemcpy GpuBuffer::Download failed unspecified launch failure* >> >>With exactly the same input files and input settings there are no error >>messages using a GTX TITAN or a TESLA card. I have tried the GTX 670 >>cards >>in the other machine, and also a TITAN card in this server, but the error >>is related to GTX 670 cards, independently from the server. >> >>My question is, this type of error message means hardware failure? >> >>These are my input parameters: >> &cntrl >> imin = 0, irest = 0, ntx = 1, >> ntb = 2, pres0 = 1.0, ntp = 1, >> taup = 2.0, >> cut = 11.0, ntr = 0, >> ntc = 2, ntf = 2, >> tempi = 300.0, temp0 = 300.0, >> ntt = 3, gamma_ln = 0.1, >> nstlim = 100000000, dt = 0.002, >> ntpr = 1000, ntwx = 1000, ntwr = 1000, >> ig=1, nscm=1000 >> / >> >>Thanks, >>Robert >>_______________________________________________ >>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: 43 Date: Mon, 24 Feb 2014 22:17:54 +0530 From: Arun Kumar Somavarapu <arunks.imtech.res.in> Subject: Re: [AMBER] using ff99SB forcefiled to a complex where ligand charge is from Glycam_04 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <f9ad95e0f31ee7fe06d0202f610ccc05.imtech.res.in> Content-Type: text/plain; charset=UTF-8 Thank you very much Karl for a detailed explanation, now i understand the point. In my case i have generated ligand charges from Red Dev server by using Glycam_04 ff and i have not changed any atom types which leads to nonstranded, like i mentioned earlier i sourced Glycam_06 ff, Gaff and ff99SB ff respectively for building complex. In Amber12 I came across leaprc.GLYCAM_06h-12SB ff, would it be useful in my case which can cover both glycam and 12SB parameters? Regards On 2014-02-24 20:20, Karl Kirschner wrote: > Concerning your questions, there are two issue when creating a model for > which you will run an MD simulation upon. As you noted, you have been > careful concerning the development of partial atomic charges for your > ligand. This is the first issue and is an attempt to correctly capture the > Coulomb forces. The second is concerning the force-field parameters that > govern all other forces that are present in your model, such as van der > Waals, bonds, angles, and torsions. These forces are defined by your > force-field parameters (e.g. Glycam06, parm12SB, gaff). As a complete set > of forces, your Coulomb forces need to be balanced with the other > forces-field parameters - meaning that the the partial atomic charge > methodology that was used to develop the residue/ligands was also used in > developing the force fields that you will apply. Different force fields > have used different methodologies for determining partial atomic charge > (i.e. Glycam06 charges are different than parm12SB). > > When creating your leap input file, you can source different force fields. > If you source two force fields, then the parameters in the second > referenced force field will over write those of the first referenced if > they are present if both force fields. Because of this, different force > fields are generated such that the atom type names prevents this from > occurring as much as possible. Thus, parm12SB uses XX naming for an atom > type, gaff uses xx, Glycam-06j uses xX, or custom made force fields > introduce new atom types (e.g. CT in parm12SB versus CG in early versions > of Glycam-06, both describing sp3 hybridized carbons). All residues within > the Glycam-06j database will have their atoms following its naming > convention, while all parm12SB residues will follow its own naming > convention. > > Now back to your question. If you have correctly named the atom types > within your ligand to follow the naming convention of the Glycam force > field that you will use, then yes you should source both. If you are > following a different atom type naming convention for your ligand, then I > would consider this to be nonstandard and would not feel comfortable > giving > you an answer. It is nonstandard because you are using Glycam06 charge > development methodology with atom types (and thus parameters) that belong > to a different force field. If you used the R.E.D. server, then follow > what > Francois has told you as he is the expert concerning R.E.D. and its usage. > > If you are still confused by this, then take a look at the AmberTools > manual and take a look at the Glycam06 and parm94 papers. Parm94 is the > predecessor of the ParmXX force-field family, and they all use the same > basic charge development method (i.e. 2-stage resp). > > Bests regards, > Karl > > On Mon, Feb 24, 2014 at 2:08 PM, Arun Kumar Somavarapu > <arunks.imtech.res.in > >> wrote: > Thank you Sir. I am in little bit confuse, i have ligand bound to protein > whose charge is defined through Glycam ff, now do i have to source > GLYCAM_06 ff also along with ff12SB. Regards On 2014-02-24 18:20, David A > Case wrote: On Mon, Feb 24, 2014, Karl Kirschner wrote: If you have a pure > oligosaccharides that is composed of residue found within Glycam04 and does not contain any unusual linkages to the protein (e.g. it is a nonbonded complex), then you should use the Glycam parameter set for the carbohydrates and the ff99SB for the protein. > Just a minor update: we recommend using the ff12SB force field for the > protein. This is also compatible with Glycam, but has improved torsion > parameters for the protein part, and generally should give better results. > ....dac _______________________________________________ AMBER mailing list > AMBER.ambermd.org http://lists.ambermd.org/mailman/listinfo/amber [1] [1] -- Arun Kumar Somavarapu Project Fellow, Dr. Pawan Gupta Lab, Protein Science and Engineering Dept, Institute of Microbial Tecnology, Sec 39-A, Chandigarh - 160036. Links: ------ [1] http://lists.ambermd.org/mailman/listinfo/amber [1] _______________________________________________ AMBER mailing list AMBER.ambermd.org http://lists.ambermd.org/mailman/listinfo/amber [1] _______________________________________________ AMBER mailing list AMBER.ambermd.org http://lists.ambermd.org/mailman/listinfo/amber [1] -- Arun Kumar Somavarapu Project Fellow, Dr. Pawan Gupta Lab, Protein Science and Engineering Dept, Institute of Microbial Tecnology, Sec 39-A, Chandigarh - 160036. Links: ------ [1] http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 44 Date: Mon, 24 Feb 2014 17:48:52 +0100 From: De?k Robert <kokumetto.gmail.com> Subject: Re: [AMBER] GTX670 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CAEYkJNX70fGZ2qFXCUht8mmrwzR+_VJ_M=WOqvKrK-8HV3K4vg.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 OK, after the tests, if it's the case, I will try your suggestions. Thanks, Robert 2014-02-24 17:33 GMT+01:00 Gould, Ian R <i.gould.imperial.ac.uk>: > Dear All, > > A few anecdotes, I recently bought 4 GTX780 Ti's and due to the PSU being > out of stock I ended up temporarily utilising them in older machines with > well used PSU's and all the motherboards were PCI 2.0 not 3.0. I ran my > own version of Ross's 24 hour validation tests, 1 card was completely > unreliable and would not report the same numbers on any rerun. > The other three would report exactly the same numbers after numerous, > greater than 20 repeats of the same run. However, one of them would > occasionally have the "cudaMemcpy GpuBuffer::Download failed unspecified > launch failure" error and this seemed totally random in its occurrence. > > Recently I received the PSU, a 1350W guaranteed with 108A on the +12V > rail, and installed all three cards in a big chasis, ie well ventilated, > with an ASROCK PCI 3.0 compliant board. Having rerun the test jobs on a > loop that meant they were tested for 72 hours nonstop I had absolutely no > failures. So my own personal conclusion is to > 1) run Ross's test suite on all new GPU cards and if they fail RMA them > 2) get the biggest and best PSU's you can afford, I would contend that > 850W is minimum for a 1 GPU, 1000W for 2GPU's and 1350W for 3GPU's > 3) I would not advise try a "home-brew" GTX 4 GPU solution as I really > don't think it is easy to get an off the shelf PSU that would be rated > 1.5Kw and above > > Cheers > Ian > > > On 24/02/2014 16:12, "Ross Walker" <ross.rosswalker.co.uk> wrote: > > >Hi Robert, > > > >This does indeed sound like faulty GPUs - do they both do it? > > > >First download the latest version of the NVIDIA driver and install it - > >v331.49 from here: http://www.nvidia.com/object/unix.html > > > >See if that helps at all. Then try downloading my test suite: > > > >https://dl.dropboxusercontent.com/u/708185/GPU_Validation_Test_2cards.tar > . > >g > >z > > > >Run this and it should run for about 24 hours (you might have to tweak > >the > >run script a little for your setup, paths etc). At the end check the log > >files - all 10 runs should give the same final energy and both GPUs > >should > >also match. If they don't (or you see crashes during the run) then it > >means your GPUs are faulty. > > > >All the best > >Ross > > > > > > > >On 2/24/14, 3:01 AM, "De?k Robert" <kokumetto.gmail.com> wrote: > > > >>Dear Amber users, > >> > >>Recently we bought 2 GTX 670 DC mini ( > >>http://www.asus.com/Graphics_Cards/GTX670DCMOC2GD5/) but with both of > >>them > >>I experienced the same error message after random run time. > >> > >>The message is: > >>*cudaMemcpy GpuBuffer::Download failed unspecified launch failure* > >> > >>With exactly the same input files and input settings there are no error > >>messages using a GTX TITAN or a TESLA card. I have tried the GTX 670 > >>cards > >>in the other machine, and also a TITAN card in this server, but the > >>error > >>is related to GTX 670 cards, independently from the server. > >> > >>My question is, this type of error message means hardware failure? > >> > >>These are my input parameters: > >> &cntrl > >> imin = 0, irest = 0, ntx = 1, > >> ntb = 2, pres0 = 1.0, ntp = 1, > >> taup = 2.0, > >> cut = 11.0, ntr = 0, > >> ntc = 2, ntf = 2, > >> tempi = 300.0, temp0 = 300.0, > >> ntt = 3, gamma_ln = 0.1, > >> nstlim = 100000000, dt = 0.002, > >> ntpr = 1000, ntwx = 1000, ntwr = 1000, > >> ig=1, nscm=1000 > >> / > >> > >>Thanks, > >>Robert > >>_______________________________________________ > >>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: 45 Date: Mon, 24 Feb 2014 16:56:44 +0000 From: "Mele N." <nm10g13.soton.ac.uk> Subject: Re: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be accomplished To: AMBER Mailing List <amber.ambermd.org> Message-ID: <5729F3D82873334E960C2D13696DB0BB016F905F.SRV00047.soton.ac.uk> Content-Type: text/plain; charset="iso-8859-1" Thanks you for your answer. I applied what you told me: - first I tried to turn on shake during minimization but the minimization crash with the same error: Coordinate resetting (SHAKE) cannot be accomplished, deviation is too large - after this error I run a new minimization without shake and no problem. - So i modified my equilibration input file as we advice me with ntb=1 and ntp=0 : Equilibration &cntrl imin=0, irest=0, ntx=1, nstlim=100, dt=0.001, ntc=2, ntf=2, ntb=1, ntp=0, taup=2.0, ntpr=1, ntwx=1, ntwr=1, ntt=3, gamma_ln=2.0, temp0=300.0,iwrap=1, / and unfurtunally same error: vlimit exceeded for step 0; vmax = 54.5176 Coordinate resetting (SHAKE) cannot be accomplished, deviation is too large NITER, NIT, LL, I and J are : 0 1 35579 45871 45873 Note: This is usually a symptom of some dee Have you any iea what is wrong with my system ?? Many thanks, Regards, ________________________________________ De : David A Case [case.biomaps.rutgers.edu] Envoy? : lundi 24 f?vrier 2014 12:54 ? : AMBER Mailing List Objet : Re: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be accomplished On Mon, Feb 24, 2014, Mele N. wrote: > > I am trying to equilibrate a box of mixture water DMSO/Water created > thanks to packmol software. During the equilibration step I get this > error: > > vlimit exceeded for step 0; vmax = 128.9242 > > Equilibration > &cntrl > imin=0, irest=0, ntx=1, > nstlim=100, dt=0.002, > ntc=2, ntf=2, > ntb=2, ntp=1, taup=2.0, > ntpr=1, ntwx=1, ntwr=1, > ntt=3, gamma_ln=2.0, > temp0=300.0,iwrap=1, > / Equilibrate first with ntb=1,npt=0, then move to ntb=2,ntp=1. Also, for some systems, doing a bit of equilibration with dt=0.001, before moving to dt=0.002 sometimes helps. The fact that you get the error at step 0 is odd. It might be good to re-do the minimization step with SHAKE turned on. Generally, you want the minimization and MD steps to use identical parameters. ...dac _______________________________________________ AMBER mailing list AMBER.ambermd.org http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 46 Date: Mon, 24 Feb 2014 12:03:48 -0500 From: Carlos Simmerling <carlos.simmerling.gmail.com> Subject: Re: [AMBER] GTX670 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CAGk3s-SZi7bnbCCqghGaoeW83Srepu93+X3pvHoNmCeTAc0aXQ.mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 FWIW, we've been building machines that are very stable with 4 GTX680s or 4 GTX780s using this power supply (and lots of ventilation): SILVERSTONE ST1500 1500W ATX 12V 2.3 & EPS 12V SLI Ready 80 PLUS SILVER Certified Active PFC Power Supply On Mon, Feb 24, 2014 at 11:33 AM, Gould, Ian R <i.gould.imperial.ac.uk>wrote: > Dear All, > > A few anecdotes, I recently bought 4 GTX780 Ti's and due to the PSU being > out of stock I ended up temporarily utilising them in older machines with > well used PSU's and all the motherboards were PCI 2.0 not 3.0. I ran my > own version of Ross's 24 hour validation tests, 1 card was completely > unreliable and would not report the same numbers on any rerun. > The other three would report exactly the same numbers after numerous, > greater than 20 repeats of the same run. However, one of them would > occasionally have the "cudaMemcpy GpuBuffer::Download failed unspecified > launch failure" error and this seemed totally random in its occurrence. > > Recently I received the PSU, a 1350W guaranteed with 108A on the +12V > rail, and installed all three cards in a big chasis, ie well ventilated, > with an ASROCK PCI 3.0 compliant board. Having rerun the test jobs on a > loop that meant they were tested for 72 hours nonstop I had absolutely no > failures. So my own personal conclusion is to > 1) run Ross's test suite on all new GPU cards and if they fail RMA them > 2) get the biggest and best PSU's you can afford, I would contend that > 850W is minimum for a 1 GPU, 1000W for 2GPU's and 1350W for 3GPU's > 3) I would not advise try a "home-brew" GTX 4 GPU solution as I really > don't think it is easy to get an off the shelf PSU that would be rated > 1.5Kw and above > > Cheers > Ian > > > On 24/02/2014 16:12, "Ross Walker" <ross.rosswalker.co.uk> wrote: > > >Hi Robert, > > > >This does indeed sound like faulty GPUs - do they both do it? > > > >First download the latest version of the NVIDIA driver and install it - > >v331.49 from here: http://www.nvidia.com/object/unix.html > > > >See if that helps at all. Then try downloading my test suite: > > > >https://dl.dropboxusercontent.com/u/708185/GPU_Validation_Test_2cards.tar > . > >g > >z > > > >Run this and it should run for about 24 hours (you might have to tweak > >the > >run script a little for your setup, paths etc). At the end check the log > >files - all 10 runs should give the same final energy and both GPUs > >should > >also match. If they don't (or you see crashes during the run) then it > >means your GPUs are faulty. > > > >All the best > >Ross > > > > > > > >On 2/24/14, 3:01 AM, "De?k Robert" <kokumetto.gmail.com> wrote: > > > >>Dear Amber users, > >> > >>Recently we bought 2 GTX 670 DC mini ( > >>http://www.asus.com/Graphics_Cards/GTX670DCMOC2GD5/) but with both of > >>them > >>I experienced the same error message after random run time. > >> > >>The message is: > >>*cudaMemcpy GpuBuffer::Download failed unspecified launch failure* > >> > >>With exactly the same input files and input settings there are no error > >>messages using a GTX TITAN or a TESLA card. I have tried the GTX 670 > >>cards > >>in the other machine, and also a TITAN card in this server, but the > >>error > >>is related to GTX 670 cards, independently from the server. > >> > >>My question is, this type of error message means hardware failure? > >> > >>These are my input parameters: > >> &cntrl > >> imin = 0, irest = 0, ntx = 1, > >> ntb = 2, pres0 = 1.0, ntp = 1, > >> taup = 2.0, > >> cut = 11.0, ntr = 0, > >> ntc = 2, ntf = 2, > >> tempi = 300.0, temp0 = 300.0, > >> ntt = 3, gamma_ln = 0.1, > >> nstlim = 100000000, dt = 0.002, > >> ntpr = 1000, ntwx = 1000, ntwr = 1000, > >> ig=1, nscm=1000 > >> / > >> > >>Thanks, > >>Robert > >>_______________________________________________ > >>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: 47 Date: Mon, 24 Feb 2014 12:10:04 -0500 From: Jason Swails <jason.swails.gmail.com> Subject: Re: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be accomplished To: amber.ambermd.org Message-ID: <1393261804.1632.11.camel.heroes-out.rutgers.edu> Content-Type: text/plain; charset="UTF-8" On Mon, 2014-02-24 at 16:56 +0000, Mele N. wrote: > Thanks you for your answer. > > I applied what you told me: > > - first I tried to turn on shake during minimization but the minimization > crash with the same error: > > Coordinate resetting (SHAKE) cannot be accomplished, > deviation is too large > > - after this error I run a new minimization without shake and no problem. > > - So i modified my equilibration input file as we advice me with ntb=1 and > ntp=0 : > > Equilibration > &cntrl > imin=0, irest=0, ntx=1, > nstlim=100, dt=0.001, > ntc=2, ntf=2, > ntb=1, ntp=0, taup=2.0, > ntpr=1, ntwx=1, ntwr=1, > ntt=3, gamma_ln=2.0, > temp0=300.0,iwrap=1, > / > > > and unfurtunally same error: > > vlimit exceeded for step 0; vmax = 54.5176 > > Coordinate resetting (SHAKE) cannot be accomplished, > deviation is too large > NITER, NIT, LL, I and J are : 0 1 35579 45871 45873 > > Note: This is usually a symptom of some dee > > Have you any iea what is wrong with my system ?? Did you look at the specified atoms to see what was happening at the end of the heating stage? > > > Many thanks, > > Regards, > > ________________________________________ > De : David A Case [case.biomaps.rutgers.edu] > Envoy? : lundi 24 f?vrier 2014 12:54 > ? : AMBER Mailing List > Objet : Re: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be > accomplished > > On Mon, Feb 24, 2014, Mele N. wrote: > > > > I am trying to equilibrate a box of mixture water DMSO/Water created > > thanks to packmol software. During the equilibration step I get this > > error: > > > > vlimit exceeded for step 0; vmax = 128.9242 > > > > Equilibration > > &cntrl > > imin=0, irest=0, ntx=1, > > nstlim=100, dt=0.002, > > ntc=2, ntf=2, > > ntb=2, ntp=1, taup=2.0, > > ntpr=1, ntwx=1, ntwr=1, > > ntt=3, gamma_ln=2.0, > > temp0=300.0,iwrap=1, > > / > > Equilibrate first with ntb=1,npt=0, then move to ntb=2,ntp=1. Also, for > some systems, doing a bit of equilibration with dt=0.001, before moving > to dt=0.002 sometimes helps. > > The fact that you get the error at step 0 is odd. It might be good to > re-do > the minimization step with SHAKE turned on. Generally, you want the > minimization and MD steps to use identical parameters. > > ...dac > > > _______________________________________________ > 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 -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ------------------------------ Message: 48 Date: Mon, 24 Feb 2014 17:22:06 +0000 From: "Mele N." <nm10g13.soton.ac.uk> Subject: Re: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be accomplished To: AMBER Mailing List <amber.ambermd.org> Message-ID: <5729F3D82873334E960C2D13696DB0BB016F907F.SRV00047.soton.ac.uk> Content-Type: text/plain; charset="iso-8859-1" ________________________________________ De : Jason Swails [jason.swails.gmail.com] Envoy? : lundi 24 f?vrier 2014 17:10 ? : amber.ambermd.org Objet : Re: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be accomplished On Mon, 2014-02-24 at 16:56 +0000, Mele N. wrote: > Thanks you for your answer. > > I applied what you told me: > > - first I tried to turn on shake during minimization but the minimization > crash with the same error: > > Coordinate resetting (SHAKE) cannot be accomplished, > deviation is too large > > - after this error I run a new minimization without shake and no problem. > > - So i modified my equilibration input file as we advice me with ntb=1 and > ntp=0 : > > Equilibration > &cntrl > imin=0, irest=0, ntx=1, > nstlim=100, dt=0.001, > ntc=2, ntf=2, > ntb=1, ntp=0, taup=2.0, > ntpr=1, ntwx=1, ntwr=1, > ntt=3, gamma_ln=2.0, > temp0=300.0,iwrap=1, > / > > > and unfurtunally same error: > > vlimit exceeded for step 0; vmax = 54.5176 > > Coordinate resetting (SHAKE) cannot be accomplished, > deviation is too large > NITER, NIT, LL, I and J are : 0 1 35579 45871 45873 > > Note: This is usually a symptom of some dee > > Have you any iea what is wrong with my system ?? Did you look at the specified atoms to see what was happening at the end of the heating stage? THe problem is I can' t see anything because I don' t get any output file. The mdcrd that I get at the end is empty. I can't pass any step during the heating. > > > Many thanks, > > Regards, > > ________________________________________ > De : David A Case [case.biomaps.rutgers.edu] > Envoy? : lundi 24 f?vrier 2014 12:54 > ? : AMBER Mailing List > Objet : Re: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be > accomplished > > On Mon, Feb 24, 2014, Mele N. wrote: > > > > I am trying to equilibrate a box of mixture water DMSO/Water created > > thanks to packmol software. During the equilibration step I get this > > error: > > > > vlimit exceeded for step 0; vmax = 128.9242 > > > > Equilibration > > &cntrl > > imin=0, irest=0, ntx=1, > > nstlim=100, dt=0.002, > > ntc=2, ntf=2, > > ntb=2, ntp=1, taup=2.0, > > ntpr=1, ntwx=1, ntwr=1, > > ntt=3, gamma_ln=2.0, > > temp0=300.0,iwrap=1, > > / > > Equilibrate first with ntb=1,npt=0, then move to ntb=2,ntp=1. Also, for > some systems, doing a bit of equilibration with dt=0.001, before moving > to dt=0.002 sometimes helps. > > The fact that you get the error at step 0 is odd. It might be good to > re-do > the minimization step with SHAKE turned on. Generally, you want the > minimization and MD steps to use identical parameters. > > ...dac > > > _______________________________________________ > 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 -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher _______________________________________________ AMBER mailing list AMBER.ambermd.org http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 49 Date: Mon, 24 Feb 2014 22:53:47 +0530 From: nalini chauhan <nalinichauhan.05.gmail.com> Subject: Re: [AMBER] ERROR in sidechain.bcl file in MCPB To: amber.ambermd.org Message-ID: <CAPn0GuH1SwXtG4PVdvKKfvEx5DZobWcVhHV8N4jiU7bL=k_41A.mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Respected Sir, I am working on MCPB and trying to get charge on my protein linked with zinc ion. While running PROTEIN_sidechain.bcl file, I am getting this error while building the cluster. Here I am attaching my pdb and .bcl file and kindly look into it and help me out ### ### ### ### ### MTK++ Info ### ### Function: selection::parse ### ### Message: selection string = /PROTEIN/CLR/HE1 ### ### ### ### ### ### ### ### ### MTK++ Info ### ### Function: selection::parse ### ### Message: selection string = /PROTEIN/1/HIE-65 ### ### ### ### ### ### ### ### ### MTK++ Error ### ### Function: selection::parse ### ### Message: Can't find: HIE-65 in molecule: PROTEIN_fixed /col/mol/smol selection error (4) ### ### ### ### ### ### ### ### ### MTK++ Error ### ### Function: MCPB::addToResidue ### ### Message: Error in selection parsing ### ### ### ### Thanks, Regards, Nalini Regards, Nalini -------------- next part -------------- A non-text attachment was scrubbed... Name: PROTEIN_sidechain.bcl Type: application/octet-stream Size: 2963 bytes Desc: not available Url : http://lists.ambermd.org/mailman/private/amber/attachments/20140224/90ac53b5/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: PROTEIN.pdb Type: chemical/x-pdb Size: 134547 bytes Desc: not available Url : http://lists.ambermd.org/mailman/private/amber/attachments/20140224/90ac53b5/attachment-0001.pdb ------------------------------ Message: 50 Date: Mon, 24 Feb 2014 09:26:52 -0800 From: Ross Walker <ross.rosswalker.co.uk> Subject: Re: [AMBER] GTX670 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CF30C08B.3AB27%ross.rosswalker.co.uk> Content-Type: text/plain; charset="ISO-8859-1" If you've already tried 331.20 or 38 then .49 is for sure not going to help so I'd skip that. Try one GPU at a time in the machine - that might tell you if it is a power supply issue. Also I've found that just reseating the GPUs can help sometimes. Beyond that it's a faulty GPU. On 2/24/14, 8:30 AM, "De?k Robert" <kokumetto.gmail.com> wrote: >Thanks Scott and Ross! > >I have 23950 atoms and it's happening at random places given the same >input >as you wrote, Scott. >The cards (both of them) produce the mentioned error from the first use >... > >I have tried the 319.60, 331.20, 331.38 drivers. Now, I will try the >331.49 >driver, and the test tool from Ross, than I will write again. > >All the best, >Robert > > >2014-02-24 17:12 GMT+01:00 Ross Walker <ross.rosswalker.co.uk>: > >> Hi Robert, >> >> This does indeed sound like faulty GPUs - do they both do it? >> >> First download the latest version of the NVIDIA driver and install it - >> v331.49 from here: http://www.nvidia.com/object/unix.html >> >> See if that helps at all. Then try downloading my test suite: >> >> >>https://dl.dropboxusercontent.com/u/708185/GPU_Validation_Test_2cards.tar >>.g >> z >> >> Run this and it should run for about 24 hours (you might have to tweak >>the >> run script a little for your setup, paths etc). At the end check the log >> files - all 10 runs should give the same final energy and both GPUs >>should >> also match. If they don't (or you see crashes during the run) then it >> means your GPUs are faulty. >> >> All the best >> Ross >> >> >> >> On 2/24/14, 3:01 AM, "De?k Robert" <kokumetto.gmail.com> wrote: >> >> >Dear Amber users, >> > >> >Recently we bought 2 GTX 670 DC mini ( >> >http://www.asus.com/Graphics_Cards/GTX670DCMOC2GD5/) but with both of >> them >> >I experienced the same error message after random run time. >> > >> >The message is: >> >*cudaMemcpy GpuBuffer::Download failed unspecified launch failure* >> > >> >With exactly the same input files and input settings there are no error >> >messages using a GTX TITAN or a TESLA card. I have tried the GTX 670 >>cards >> >in the other machine, and also a TITAN card in this server, but the >>error >> >is related to GTX 670 cards, independently from the server. >> > >> >My question is, this type of error message means hardware failure? >> > >> >These are my input parameters: >> > &cntrl >> > imin = 0, irest = 0, ntx = 1, >> > ntb = 2, pres0 = 1.0, ntp = 1, >> > taup = 2.0, >> > cut = 11.0, ntr = 0, >> > ntc = 2, ntf = 2, >> > tempi = 300.0, temp0 = 300.0, >> > ntt = 3, gamma_ln = 0.1, >> > nstlim = 100000000, dt = 0.002, >> > ntpr = 1000, ntwx = 1000, ntwr = 1000, >> > ig=1, nscm=1000 >> > / >> > >> >Thanks, >> >Robert >> >_______________________________________________ >> >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: 51 Date: Mon, 24 Feb 2014 17:44:49 +0000 From: "Duke, Robert E Jr" <rduke.email.unc.edu> Subject: Re: [AMBER] PME with cutoff = 0 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <129A87CAD90E384C93AC78D2ACBAB8034533B2E7.ITS-MSXMBS4M.ad.unc.edu> Content-Type: text/plain; charset="us-ascii" Hi Francois, I think Jason's reply to this is the direction you need to look. I saw your email and was mostly trying to explain why you could misunderstand and think pmemd ran a 0 cutoff for you when sander wouldn't. The further story here - the code initializes the cut to 0.0 to check and see if you set a value for cut in the namelist, and assumes that after you read the namelist, if the cut value is still 0.0, then the defaults should be set for pme electrostatics cut and vdw cut instead (and it is even more complicated really, in that there are other variables specific for electrostatics vs. vdw cutoffs you could have specified). We could use some weird negative value for cut I suppose, but ultimately someone can surprise you with input, and the only way to be sure that they provided input for a value, at least as far as I know, is to read the namelist twice against different initial values for a variable. Anyway, I defer to Jason regarding the solution to your actual problem here - my intent was merely to try to be sure you understood what pmemd had done. By the way, there should be clear indications in the mdout output as to the cutoff actually used - in the "ewald parameters" subsection (and of course in an ideal world, you would get the same result using an infinitesimal cut near 0 for the direct space calc because the reciprocal space calc would compensate - but in the real world, if you start messing with the actual pme run parameters, the accuracy of your results varies; messing with the parameters is not turning off pme, so you are always attempting a full pbc system electrostatics evaluation). Regards - Bob ________________________________________ From: FyD [fyd.q4md-forcefieldtools.org] Sent: Monday, February 24, 2014 1:31 AM To: AMBER Mailing List Subject: Re: [AMBER] PME with cutoff = 0 Dear Robert, > The cutoff value of "0.d0" in pmemd for a pme run is equivalent to > requesting that the default values be used - probably 8.0 angstrom, > if memory serves, assuming igb 0 for a pme simulation. Yes - this corresponds to what I get... I compare MD simulations (with PME) with cut = 12 vs cut = 0 the obtained results are very similar. This means 'cut = O' does not do what I want; I wonder if crashing is not better than generating data in this case... > PME does strange things at small-ish cutoff, but does not allow 0 > (in the sense that it says "oh, you wanted 8"), and I presume later > catches and disallows cut < 0. In my experience, reducing the > direct space cut below roughly 7.0 angstrom causes unacceptable > error limits unless you increase grid density for reciprocal space > (there is basically a balancing act between reciprocal and direct > space in terms of what is necessary to keep error acceptable). And > if you think long cutoffs are expensive, play around a bit with > greatly increasing nfft1,2,3 in a large system :-}. So all I am > really answering here is why pmemd ran - it basically ignored you... ok > I would have to read the paper done with amber 4.1 to have a clue > what they were really up to, See http://pubs.acs.org/doi/full/10.1021/jp9717655 - It is written: "The heat of vaporization is computed from the average intermolecular interaction energy Eint via dHvap = -Eint + RT For molecules that do not have an internal nonbonded interaction beyond 1?4 (e.g., the chloromethanes), Eint is calculated straightforwardly as the sum of EELEC and ENONB in the SANDER output, divided by the number of molecules in the system. For all other molecules, EELEC and ENONB also contain contributions from intramolecular nonbonded interactions. To correct for these, we performed a short simulation with the nonbonded cutoff radius set to zero. Due to the residue-based cutoff in AMBER, EELEC and ENONB now accumulate only the intraresidue nonbonded interactions that can be subtracted from the total to yield the intermolecular portion needed for the calculation of dHvap." > but pmemd is designed to always use either > pme or generalized Born, so resurrecting an old copy of sander may > be your best bet.. I use PME & would like to continue to use PME. Resurrecting an old copy of sander? uff... Does it means this is not possible to carefully study/check solvent boxes with Amber nowadays? thank you, regards, Francois Dear Ross, > Both sander and pmemd almost certainly make assumptions about the cutoff. > Since the days of AMBER 4.1 there have been huge changes in the way the > pairlist is built etc. I can understand that ;-) > For example the code use to just rebuild the > pairlist at set intervals. These days it is smart and only rebuilds it > when an atom has moved more than the distance skinnb such that the > pairlist cutoff is really cut+skinnb. Thus reducing cut to zero probably > messes up logic in this part of the code. There are likely other issues as > well, like divisions by zero inside the code that determines the Ewald > coefficient etc. My understanding is that division by zero should always be checked. > The fact one code crashes and the other doesn't is likely > just dependent on where they hit the first problem. From what you show it > looks like pmemd just hangs while sander crashes with an error - both > could be considered a crash. pmemd does not hang; see above. > Anyway, to cut a long story short neither code officially supports a value > of cut=0 for PME runs and it is something that isn't tested. It may be > possible to run the simulation in GB in sander by setting igb=6 - this > will run a gas phase simulation. I doubt there is anyway to run a periodic > simulation with a cutoff of 0. If you really want to then your options are > likely see if you can find a PRE-PME copy of sander (such as AMBER 4.1) or > (sander-classic from AMBER 6 perhaps?) or crack open the debugger and see > if you can trace through the use of the cutoff value and find out where > the problems are occurring. This may just be a case of going down the > rabbit hole though. sander-classic from AMBER 6: do you think this is possible to get sander-classic from AMBER 6 compiled using 4.4 GNU compiler? Does it means this is not possible to carefully study/check solvent boxes with Amber nowadays? See http://pubs.acs.org/doi/full/10.1021/jp9717655 > Sorry I can't offer much more help than that. - Note you could also try > cut=0.001 and see if that works. There is almost certainly a 1.0d0/cut^2 > somewhere in the code and this might work around that and still give you > what you want from the simulation. I am testing... thank you, regards, Francois > On 2/23/14, 9:19 AM, "FyD" <fyd.q4md-forcefieldtools.org> wrote: > >> Dear All, >> >> I ran amber10/sander.MPI with PME + cutoff = 0 -> sander crashes >> amber12/sander.MPI with PME + cutoff = 0 -> sander crashes >> (compiled with intel13 + mkl) >> amber12/pmemd.MPI with PME + cutoff = 0 -> pmemd does not crash... >> >> Printed output: printing stops in section 4: >> >> -------------------------------------------------------------------------- >> 4. RESULTS >> -------------------------------------------------------------------------- >> >> | # of SOLUTE degrees of freedom (RNDFP): 24936. >> | # of SOLVENT degrees of freedom (RNDFS): 0. >> | NDFMIN = 24933. NUM_NOSHAKE = 0 CORRECTED RNDFP = 24933. >> | TOTAL # of degrees of freedom (RNDF) = 24933. >> >> -> nothing else is printed... >> >> In Fox & Kollman J.Phys.Chem.B 1998, 102, 8070, MD simulation with >> cutoff = 0 is reported & Sander from Amber 4.1 was used. >> >> Why does sander crash, while pmemd does not crash in this case? >> (with the same input & cut = 12, sander does not crash) >> >> thank you, regards, >> Francois >> >> >> >> # Cst pressure simulation with cutoff = 0 Angs; 300 K short >> $PARAL -np $NPROC $EXE -O -i md-cstpres0.in \ >> -o md-cstpres0b.out \ >> -p $mol.parm7 \ >> -c md-cstvol.rst7 \ >> -r md-cstpres0b.rst7 \ >> -x md-cstpres0b.mdcrd >> >> my test input below: >> >> cst pressure MD, nstlim*dt psec, PME with cutoff >> &cntrl >> nmropt = 0, ioutfm = 1, iwrap = 0, >> ntx = 1, irest = 0, ntrx = 1, ntxo = 1, >> ntpr = 100, ntwr = 1000, ntwx = 500, >> ntave = 0, ntwv = 0, ntwe = 0, >> ntf = 2, ntb = 2, >> ntc = 2, tol = 0.00001, >> dielc = 1, ipol = 0, >> cut = 0, ig = 71277, comp = 52.5, >> ibelly = 0, ntr = 0, igb = 0, >> imin = 0, nstlim = 5000, >> nscm = 1000, t = 0.0, dt = 0.002, >> temp0 = 300, tempi = 300, >> ntt = 1, tautp = 0.2, vlimit = 20, >> ntp = 1, pres0 = 1.0, taup = 0.2, >> &end _______________________________________________ AMBER mailing list AMBER.ambermd.org http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 52 Date: Mon, 24 Feb 2014 09:54:00 -0800 From: Ross Walker <ross.rosswalker.co.uk> Subject: Re: [AMBER] PME with cutoff = 0 To: AMBER Mailing List <amber.ambermd.org> Message-ID: <CF30C6C0.3AB42%ross.rosswalker.co.uk> Content-Type: text/plain; charset="US-ASCII" Note - residue based cutoffs have NOT been supported in Sander since v6.0 (or ever in pmemd). Thus if you want to look at purely intermolecular non-bonded interactions by relying on residue based cutoffs then you will need to go back to AMBER 5.0 (or sander.classic from AMBER 6). All the best Ross On 2/24/14, 5:45 AM, "Jason Swails" <jason.swails.gmail.com> wrote: >On Mon, 2014-02-24 at 10:31 +0100, FyD wrote: >> Dear Robert, >> >> > The cutoff value of "0.d0" in pmemd for a pme run is equivalent to >> > requesting that the default values be used - probably 8.0 angstrom, >> > if memory serves, assuming igb 0 for a pme simulation. >> >> Yes - this corresponds to what I get... >> >> I compare MD simulations (with PME) with cut = 12 vs cut = 0 >> the obtained results are very similar. >> >> This means 'cut = O' does not do what I want; I wonder if crashing is >> not better than generating data in this case... >> >> > PME does strange things at small-ish cutoff, but does not allow 0 >> > (in the sense that it says "oh, you wanted 8"), and I presume later >> > catches and disallows cut < 0. In my experience, reducing the >> > direct space cut below roughly 7.0 angstrom causes unacceptable >> > error limits unless you increase grid density for reciprocal space >> > (there is basically a balancing act between reciprocal and direct >> > space in terms of what is necessary to keep error acceptable). And >> > if you think long cutoffs are expensive, play around a bit with >> > greatly increasing nfft1,2,3 in a large system :-}. So all I am >> > really answering here is why pmemd ran - it basically ignored you... >> >> ok >> >> > I would have to read the paper done with amber 4.1 to have a clue >> > what they were really up to, >> >> See http://pubs.acs.org/doi/full/10.1021/jp9717655 - It is written: >> >> "The heat of vaporization is computed from the average intermolecular >> interaction energy Eint via dHvap = -Eint + RT >> For molecules that do not have an internal nonbonded interaction >> beyond 1?4 (e.g., the chloromethanes), Eint is calculated >> straightforwardly as the sum of EELEC and ENONB in the SANDER output, >> divided by the number of molecules in the system. For all other >> molecules, EELEC and ENONB also contain contributions from >> intramolecular nonbonded interactions. To correct for these, we >> performed a short simulation with the nonbonded cutoff radius set to >> zero. Due to the residue-based cutoff in AMBER, EELEC and ENONB now >> accumulate only the intraresidue nonbonded interactions that can be >> subtracted from the total to yield the intermolecular portion needed >> for the calculation of dHvap." >> >> > but pmemd is designed to always use either >> > pme or generalized Born, so resurrecting an old copy of sander may >> > be your best bet.. >> >> I use PME & would like to continue to use PME. >> Resurrecting an old copy of sander? uff... > >I would actually suggest that you really _don't_ want to use PME for >this particular calculation. What you're effectively trying to do is >eliminate the intra-molecular nonbonded interactions so that you can >compute the inter-molecular nonbonded interactions exclusively. It >seems that the strategy is to compute the full electrostatics (using >PME) and then subtract out the intramolecular nonbonded energies (using >no PME and a group-based cutoff of 0 to ensure that atoms interact only >with other atoms in the same residue). > >This is a trick that takes advantage of a key assumption: each solvent >molecule is made up of a single residue only. > >> Does it means this is not possible to carefully study/check solvent >> boxes with Amber nowadays? > >I've never tried pure group-based cutoffs with no Ewald sum. It may not >work anymore since it's a somewhat unusual simulation (nor is it >particularly general since it relies on the above assumption). If >group-based cutoffs still work and the assumption above holds for your >system, that's the easiest solution. There are alternatives, though, >that depend on the nature of your 'molecule'. > >1) Does the molecule have any atoms that are no farther than 2 bonds >away? If not (like with water and chloromethane), then there are no >intramolecular nonbonded interactions and this step is unnecessary. > >2) Does the molecule have any atoms that are no farther than 3 bonds >away? If not (like with ethane and ethanol), then you can simply ignore >the 1-4 VDW and 1-4 EEL contributions (again, making this step >unnecessary). > >3) The most tedious scenario if there are intramolecular energies you >need to get rid of. You can, using ParmEd, zero out the charges and van >der Waals parameters for every molecule *except* the molecule whose >intramolecular NB interactions you want and simply compute a >(non-periodic) energy in which you know the EEL and VDW contributions >are strictly intramolecular. You can then do this for every molecule in >your system and sum them up to get the total intramolecular nonbonded >energy (or, alternatively, if your molecules are rigid due to >constraints you can simply multiply by the number of molecules you >have). > >If you are comfortable with Python programming, you can do step 3 in a >single Python script using the ParmEd API like so: > >from chemistry.amber.readparm import AmberParm >from ParmedTools.ParmedActions import change, addljtype > >for i in range(num_molecules): > parm = AmberParm('path/to/prmtop') > change(parm, 'CHARGE', '!:%d' % i, 0.0) > addljtype(parm, '!:%d' % i, radius=0.0, epsilon=0.0) > parm.writeParm('tmp.parm7') > # System call to compute energy > >Alternatively you can write a quick NAB program to do something >equivalent. In both cases, help can be found in the AmberTools manual. > >HTH, >Jason > >-- >Jason M. Swails >BioMaPS, >Rutgers University >Postdoctoral Researcher > > >_______________________________________________ >AMBER mailing list >AMBER.ambermd.org >http://lists.ambermd.org/mailman/listinfo/amber ------------------------------ Message: 53 Date: Mon, 24 Feb 2014 12:55:47 -0500 From: Jason Swails <jason.swails.gmail.com> Subject: Re: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be accomplished To: amber.ambermd.org Message-ID: <1393264547.1632.15.camel.heroes-out.rutgers.edu> Content-Type: text/plain; charset="UTF-8" On Mon, 2014-02-24 at 17:22 +0000, Mele N. wrote: > THe problem is I can' t see anything because I don' t get any output file. > The mdcrd that I get at the end is empty. > I can't pass any step during the heating. I'm confused. You kept giving the 'equilibration' input file yet you say the heating stage was the one having problems? If the heating stage went fine, look at the output files from that step to see if anything looks wrong (the "checkoverlaps" command in cpptraj can help when looking for close contacts). If the heating stage didn't work, look closely at the result from the minimization step. I've also seen this type of error occur when the box information is set incorrectly (e.g., did you build an octahedron box with packmol but set your box to an orthorhombic shape in tleap? vice versa?). If the box information is wrong, then periodic images will most likely overlap strongly and these errors are sure to occur. Good luck, Jason -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ------------------------------ Message: 54 Date: Mon, 24 Feb 2014 13:32:28 -0500 From: David A Case <case.biomaps.rutgers.edu> Subject: Re: [AMBER] Shake problem: Coordinate resetting (SHAKE) cannot be accomplished To: AMBER Mailing List <amber.ambermd.org> Message-ID: <20140224183228.GA66705.biomaps.rutgers.edu> Content-Type: text/plain; charset=us-ascii On Mon, Feb 24, 2014, Mele N. wrote: > - first I tried to turn on shake during minimization but the > minimization crash with the same error: > > Coordinate resetting (SHAKE) cannot be accomplished, > deviation is too large > > - after this error I run a new minimization without shake and no problem. How about trying an additional minimization with shake, starting from the output of the first minimization? If these still have SHAKE failures, your MD runs are all likely to fail as well. Jason's suggestions about checking the box info are also good ones. ...dac ------------------------------ _______________________________________________ AMBER mailing list AMBER.ambermd.org http://lists.ambermd.org/mailman/listinfo/amber End of AMBER Digest, Vol 775, Issue 1 ************************************* --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com _______________________________________________ AMBER mailing list AMBER.ambermd.org http://lists.ambermd.org/mailman/listinfo/amberReceived on Tue Feb 25 2014 - 10:00:03 PST