From owner-chemistry@ccl.net Mon Nov 8 08:22:00 2010 From: "Jean Jules FIFEN julesfifen[a]gmail.com" To: CCL Subject: CCL:G: help Message-Id: <-43095-101108044737-4976-brVKYB9LK4i9T6Vu71IvQQ^server.ccl.net> X-Original-From: Jean Jules FIFEN Content-Type: multipart/alternative; boundary=20cf301cc3c041af030494878390 Date: Mon, 8 Nov 2010 10:47:30 +0100 MIME-Version: 1.0 Sent to CCL by: Jean Jules FIFEN [julesfifen^^^gmail.com] --20cf301cc3c041af030494878390 Content-Type: text/plain; charset=ISO-8859-1 To hope very effecient solution, you would have send all geometry optimization steps results. Despite of this, regarding the last step of your geometry optimization, the thing you can do to solve the problem, 1. is to restart the computation from the last geometry optimizations step by adding the key word:* opt(maxcycle=999) scf(maxcycle=999) *instead of merely type *opt* for geometry optimization. Note that this will increase the number of iterations for geometry optimization and energy computation. 2. If this does not work, analyse carrefully the output file to find from which step the computation begins to diverge. Then send a new job from the previous step by adding the key words *Geom=(check,step=n) guess=read* if the target step is the step number n. Obviously, you need to have save the checkpoint file from the previous job. 3. If previous steps are unsuccessfull, try modifying the geometry of the molecule regarding physical senses. Best regards, Jules. On 7 November 2010 12:02, Bilel Mansouri bilelmansouri80/ayahoo.fr < owner-chemistry||ccl.net> wrote: > > > HI > > I'm doing a (what I thought was simple) test job of tow water molecules > whith supermolecule methode using B3LYP > > and the 6-311G basis set. > I have the error message > > Item Value Threshold Converged? > Maximum Force 0.000882 0.000450 NO > RMS Force 0.000269 0.000300 YES > Maximum Displacement 0.056470 0.001800 NO > RMS Displacement 0.014132 0.001200 NO > Predicted change in Energy=-1.659919D-03 > Optimization stopped. > -- Number of steps exceeded, NStep= 100 > -- Flag reset to prevent archiving. > ---------------------------- > ! Non-Optimized Parameters ! > ! (Angstroms and Degrees) ! > -------------------------- > -------------------------- > ! Name Definition Value Derivative > Info. ! > > -------------------------------------------------------------------------------- > ! R1 R(1,3) 3.9996 -DE/DX = > -0.0023 ! > ! R2 R(1,5) 1.003 -DE/DX = > 0.0 ! > ! R3 R(1,6) 1.003 -DE/DX = > 0.0 ! > ! R4 R(1,7) 2.9817 -DE/DX = > -0.0009 ! > ! R5 R(1,9) 3.0732 -DE/DX = > -0.001 ! > ! R6 R(2,4) 3.9997 -DE/DX = > -0.0029 ! > ! R7 R(2,7) 0.9737 -DE/DX = > 0.0004 ! > ! R8 R(2,8) 0.9697 -DE/DX = > 0.0007 ! > ! R9 R(3,9) 0.9722 -DE/DX = > -0.0013 ! > ! R10 R(3,10) 0.9664 -DE/DX = > -0.0001 ! > ! R11 R(3,11) 1.7428 -DE/DX = > 0.0002 ! > ! R12 R(4,8) 4.4728 -DE/DX = > -0.0008 ! > ! R13 R(4,11) 0.981 -DE/DX = > 0.0003 ! > ! R14 R(4,12) 0.9659 -DE/DX = > 0.0 ! > ! A1 A(3,1,5) 99.0096 -DE/DX = > 0.0 ! > ! A2 A(3,1,6) 99.0096 -DE/DX = > 0.0 ! > ! A3 A(3,1,7) 68.5648 -DE/DX = > 0.0 ! > ! A4 A(5,1,6) 104.9845 -DE/DX = > -0.0007 ! > ! A5 A(5,1,7) 60.6293 -DE/DX = > -0.0003 ! > ! A6 A(5,1,9) 101.859 -DE/DX = > 0.0001 ! > ! A7 A(6,1,7) 60.6293 -DE/DX = > -0.0003 ! > ! A8 A(6,1,9) 101.859 -DE/DX = > 0.0001 ! > ! A9 A(7,1,9) 73.3866 -DE/DX = > 0.0 ! > ! A10 A(4,2,7) 3.2523 -DE/DX = > 0.001 ! > ! A11 A(7,2,8) 110.0485 -DE/DX = > 0.0001 ! > ! A12 A(1,3,10) 126.5996 -DE/DX = > 0.0001 ! > ! A13 A(1,3,11) 96.7028 -DE/DX = > -0.0001 ! > ! A14 A(9,3,10) 111.1913 -DE/DX = > -0.0001 ! > ! A15 A(9,3,11) 112.1111 -DE/DX = > 0.0001 ! > ! A16 A(10,3,11) 136.6976 -DE/DX = > 0.0 ! > ! A17 A(2,4,11) 95.2594 -DE/DX = > -0.0002 ! > ! A18 A(2,4,12) 154.9369 -DE/DX = > -0.0001 ! > ! A19 A(8,4,11) 106.7444 -DE/DX = > -0.0002 ! > ! A20 A(8,4,12) 143.4519 -DE/DX = > -0.0001 ! > ! A21 A(11,4,12) 109.8037 -DE/DX = > 0.0003 ! > ! A22 L(1,7,2,4,-1) 285.8641 -DE/DX = > -0.0011 ! > ! A23 L(3,11,4,2,-1) 168.2659 -DE/DX = > -0.0003 ! > ! A24 L(1,7,2,4,-2) 180.0 -DE/DX = > 0.0 ! > ! A25 L(3,11,4,2,-2) 180.0 -DE/DX = > 0.0 ! > ! D1 D(3,1,2,4) 0.0 -DE/DX = > 0.0 ! > ! D2 D(3,1,2,8) 180.0 -DE/DX = > 0.0 ! > ! D3 D(5,1,2,4) 102.9058 -DE/DX = > 0.0001 ! > ! D4 D(5,1,2,8) -77.0942 -DE/DX = > 0.0001 ! > ! D5 D(6,1,2,4) -102.9058 -DE/DX = > -0.0001 ! > ! D6 D(6,1,2,8) 77.0942 -DE/DX = > -0.0001 ! > ! D7 D(9,1,2,4) 0.0 -DE/DX = > 0.0 ! > ! D8 D(9,1,2,8) 180.0 -DE/DX = > 0.0 ! > ! D9 D(5,1,3,10) 126.5651 -DE/DX = > 0.0004 ! > ! D10 D(5,1,3,11) -53.4349 -DE/DX = > 0.0004 ! > ! D11 D(6,1,3,10) -126.5651 -DE/DX = > -0.0004 ! > ! D12 D(6,1,3,11) 53.4349 -DE/DX = > -0.0004 ! > ! D13 D(7,1,3,10) 180.0 -DE/DX = > 0.0 ! > ! D14 D(7,1,3,11) 0.0 -DE/DX = > 0.0 ! > ! D15 D(7,2,4,11) 180.0 -DE/DX = > 0.0 ! > ! D16 D(7,2,4,12) 0.0 -DE/DX = > 0.0 ! > ! D17 D(1,3,4,2) 0.0 -DE/DX = > 0.0 ! > ! D18 D(1,3,4,8) 0.0 -DE/DX = > 0.0 ! > ! D19 D(1,3,4,12) 180.0 -DE/DX = > 0.0 ! > ! D20 D(9,3,4,2) 0.0 -DE/DX = > 0.0 ! > ! D21 D(9,3,4,8) 0.0 -DE/DX = > 0.0 ! > ! D22 D(9,3,4,12) 180.0 -DE/DX = > 0.0 ! > ! D23 D(10,3,4,2) 180.0 -DE/DX = > 0.0 ! > ! D24 D(10,3,4,8) 180.0 -DE/DX = > 0.0 ! > ! D25 D(10,3,4,12) 0.0 -DE/DX = > 0.0 ! > > -------------------------------------------------------------------------------- > GradGradGradGradGradGradGradGradGradGradGradGradGradGradGradGradGradGrad > Input orientation: > --------------------------------------------------------------------- > Center Atomic Atomic Coordinates (Angstroms) > Number Number Type X Y Z > --------------------------------------------------------------------- > 1 8 0 0.184505 0.000000 0.154984 > 2 8 0 0.033034 0.000000 2.881640 > 3 8 0 4.161469 0.000000 0.583652 > 4 8 0 4.011921 0.000000 3.292071 > 5 1 0 -0.032703 -0.765799 0.712955 > 6 1 0 -0.032703 0.765799 0.712955 > 7 1 0 0.995253 0.000000 3.035531 > 8 1 0 -0.438867 0.000000 3.727326 > 9 1 0 3.261177 0.000000 0.215677 > 10 1 0 4.826475 0.000000 -0.117892 > 11 1 0 4.189967 0.000000 2.324276 > 12 1 0 4.842678 0.000000 3.787965 > --------------------------------------------------------------------- > Distance matrix (angstroms): > 1 2 3 4 5 > 1 O 0.000000 > 2 O 2.730860 0.000000 > 3 O 4.000000 4.724906 0.000000 > 4 O 4.948780 4.000000 2.712545 0.000000 > 5 H 0.972090 2.300862 4.265472 4.857702 0.000000 > 6 H 0.972090 2.300862 4.265472 4.857702 1.531598 > 7 H 2.992467 0.974448 4.004577 3.027557 2.652829 > 8 H 3.626323 0.968439 5.571875 4.472020 3.136535 > 9 H 3.077270 4.186678 0.972590 3.166673 3.418096 > 10 H 4.649983 5.654580 0.966641 3.505901 4.988824 > 11 H 4.555168 4.194133 1.740858 0.984036 4.584076 > 12 H 5.907378 4.894293 3.275922 0.967506 5.814764 > 6 7 8 9 10 > 6 H 0.000000 > 7 H 2.652829 0.000000 > 8 H 3.136535 1.592257 0.000000 > 9 H 3.418096 3.617456 5.101177 0.000000 > 10 H 4.988824 4.962090 6.519933 1.600445 0.000000 > 11 H 4.584076 3.272932 4.836802 2.304093 2.523753 > 12 H 5.814764 3.920311 5.281894 3.906711 3.905890 > 11 12 > 11 H 0.000000 > 12 H 1.602627 0.000000 > Stoichiometry H8O4 > Framework group CS[SG(H6O4),X(H2)] > Deg. of freedom 20 > Full point group CS > Largest Abelian subgroup CS NOp 2 > Largest concise Abelian subgroup CS NOp 2 > Standard orientation: > --------------------------------------------------------------------- > Center Atomic Atomic Coordinates (Angstroms) > Number Number Type X Y Z > --------------------------------------------------------------------- > 1 8 0 -2.501070 0.069787 0.000000 > 2 8 0 -0.827351 2.227623 0.000000 > 3 8 0 0.782472 -2.214584 0.000000 > 4 8 0 2.445684 -0.071777 0.000000 > 5 1 0 -2.299150 0.633470 0.765799 > 6 1 0 -2.299150 0.633470 -0.765799 > 7 1 0 0.000000 1.712804 0.000000 > 8 1 0 -0.629035 3.175540 0.000000 > 9 1 0 -0.138519 -1.901999 0.000000 > 10 1 0 0.824466 -3.180313 0.000000 > 11 1 0 1.945446 -0.919177 0.000000 > 12 1 0 3.398064 -0.242189 0.000000 > --------------------------------------------------------------------- > Rotational constants (GHZ): 3.6566956 1.7161673 1.1744164 > ********************************************************************** > Population analysis using the SCF density. > ********************************************************************** > Electronic spatial extent (au): = 919.2008 > Charge= 0.0000 electrons > Dipole moment (field-independent basis, Debye): > X= 1.8028 Y= -0.6387 Z= 0.0000 Tot= 1.9126 > Quadrupole moment (field-independent basis, Debye-Ang): > XX= -30.6350 YY= -7.6894 ZZ= -26.4884 > XY= -5.0915 XZ= 0.0000 YZ= 0.0000 > Traceless Quadrupole moment (field-independent basis, Debye-Ang): > XX= -9.0307 YY= 13.9149 ZZ= -4.8841 > XY= -5.0915 XZ= 0.0000 YZ= 0.0000 > Octapole moment (field-independent basis, Debye-Ang**2): > XXX= 53.7799 YYY= -7.6173 ZZZ= 0.0000 XYY= 5.7536 > XXY= -2.5321 XXZ= 0.0000 XZZ= -7.1177 YZZ= 1.2264 > YYZ= 0.0000 XYZ= 0.0000 > Hexadecapole moment (field-independent basis, Debye-Ang**3): > XXXX= -509.3830 YYYY= -156.7525 ZZZZ= -23.2511 XXXY= 30.6051 > XXXZ= 0.0000 YYYX= 48.4794 YYYZ= 0.0000 ZZZX= 0.0000 > ZZZY= 0.0000 XXYY= -160.2397 XXZZ= -90.8949 YYZZ= -82.4570 > XXYZ= 0.0000 YYXZ= 0.0000 ZZXY= 26.3538 > Atom 7 needs variable 8= 0.9744477035 but is 0.9720898606 > Input z-matrix variables are not compatible with final structure. > > FAULTILY FAULTLESS, ICILY REGULAR, SPLENDIDLY NULL... > MAUDE BY TENNYSON > Error termination request processed by link 9999. > Error termination via Lnk1e in C:\G03W\l9999.exe at Thu Nov 04 19:09:35 > 2010. > Job cpu time: 0 days 1 hours 13 minutes 15.0 seconds. > File lengths (MBytes): RWF= 20 Int= 0 D2E= 0 Chk= 11 > Scr= 1 > Any insight would be very helpful. > > Thanks! > > > -- Jean Jules FIFEN, +237 75 21 61 39 +237 94 67 65 05 University of Ngaoundere, PO.BOX 454 Ngaoundere --20cf301cc3c041af030494878390 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+VG8gaG9wZSB2ZXJ5IGVmZmVjaWVudCBzb2x1dGlvbiwgeW91IHdvdWxk IGhhdmUgc2VuZCBhbGwgZ2VvbWV0cnkgb3B0aW1pemF0aW9uIHN0ZXBzIHJlc3VsdHMuIDxicj5E ZXNwaXRlIG9mIHRoaXMsIHJlZ2FyZGluZyB0aGUgbGFzdCBzdGVwIG9mIHlvdXIgZ2VvbWV0cnkg b3B0aW1pemF0aW9uLCB0aGUgdGhpbmcgeW91IGNhbiBkbyB0byBzb2x2ZSB0aGUgcHJvYmxlbSwg PGJyPgo8b2w+PGxpPmlzIHRvIHJlc3RhcnQgdGhlIGNvbXB1dGF0aW9uIGZyb20gdGhlIGxhc3Qg Z2VvbWV0cnkgb3B0aW1pemF0aW9ucyBzdGVwIGJ5IGFkZGluZyB0aGUga2V5IHdvcmQ6PGI+IG9w dChtYXhjeWNsZT05OTkpIHNjZihtYXhjeWNsZT05OTkpIDwvYj5pbnN0ZWFkIG9mIG1lcmVseSB0 eXBlIDxiPm9wdDwvYj4gZm9yIGdlb21ldHJ5IG9wdGltaXphdGlvbi4gTm90ZSB0aGF0IHRoaXMg d2lsbCBpbmNyZWFzZSB0aGUgbnVtYmVyIG9mIGl0ZXJhdGlvbnMgZm9yIGdlb21ldHJ5IG9wdGlt aXphdGlvbiBhbmQgZW5lcmd5IGNvbXB1dGF0aW9uLjwvbGk+CjxsaT5JZiB0aGlzIGRvZXMgbm90 IHdvcmssIGFuYWx5c2UgY2FycmVmdWxseSB0aGUgb3V0cHV0IGZpbGUgdG8gZmluZCBmcm9tIHdo aWNoIHN0ZXAgdGhlIGNvbXB1dGF0aW9uIGJlZ2lucyB0byBkaXZlcmdlLiBUaGVuIHNlbmQgYSBu ZXcgam9iIGZyb20gdGhlIHByZXZpb3VzIHN0ZXAgYnkgYWRkaW5nIHRoZSBrZXkgd29yZHMgPGI+ R2VvbT0oY2hlY2ssc3RlcD1uKSBndWVzcz1yZWFkPC9iPiBpZiB0aGUgdGFyZ2V0IHN0ZXAgaXMg dGhlIHN0ZXAgbnVtYmVyIG4uIE9idmlvdXNseSwgeW91IG5lZWQgdG8gaGF2ZSBzYXZlIHRoZSBj aGVja3BvaW50IGZpbGUgZnJvbSB0aGUgcHJldmlvdXMgam9iLjwvbGk+CjxsaT5JZiBwcmV2aW91 cyBzdGVwcyBhcmUgdW5zdWNjZXNzZnVsbCwgdHJ5IG1vZGlmeWluZyB0aGUgZ2VvbWV0cnkgb2Yg dGhlIG1vbGVjdWxlIHJlZ2FyZGluZyBwaHlzaWNhbCBzZW5zZXMuPC9saT48L29sPjxicj5CZXN0 IHJlZ2FyZHMsPGJyPjxicj5KdWxlcy48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5P biA3IE5vdmVtYmVyIDIwMTAgMTI6MDIsIEJpbGVsIE1hbnNvdXJpIGJpbGVsbWFuc291cmk4MC88 YSBocmVmPSJodHRwOi8vYXlhaG9vLmZyIj5heWFob28uZnI8L2E+IDxzcGFuIGRpcj0ibHRyIj4m bHQ7PGEgaHJlZj0ibWFpbHRvOm93bmVyLWNoZW1pc3RyeUBjY2wubmV0Ij5vd25lci1jaGVtaXN0 cnlAY2NsLm5ldDwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IGJvcmRlci1sZWZ0 OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPjx0YWJs ZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRib2R5Pjx0cj48 dGQgc3R5bGU9ImZvbnQ6IGluaGVyaXQ7IiB2YWxpZ249InRvcCI+Cjxicj48YnI+SEk8YnI+Jmd0 OyBJJiMzOTttIGRvaW5nIGEgKHdoYXQgSSB0aG91Z2h0IHdhcyBzaW1wbGUpIHRlc3Qgam9iIG9m oHRvd6B3YXRlciBtb2xlY3VsZXMgd2hpdGggc3VwZXJtb2xlY3VsZSBtZXRob2RloHVzaW5nIEIz TFlQPGJyPiZndDsgYW5kIHRoZSA2LTMxMUcgYmFzaXMgc2V0Ljxicj5JIGhhdmUgdGhlIGVycm9y IG1lc3NhZ2UgCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItbGVmdDogMnB4IHNvbGlkIHJnYigx NiwgMTYsIDI1NSk7IHBhZGRpbmctbGVmdDogNXB4OyBtYXJnaW4tbGVmdDogNXB4OyI+CjxkaXY+ CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sbmV3IHlvcmssdGltZXMs c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPgo8ZGl2PqCgoKCgoKCgIEl0ZW2goKCgoKCgoKCgoKCg oCBWYWx1ZaCgoKAgVGhyZXNob2xkoCBDb252ZXJnZWQ/PGJyPqBNYXhpbXVtIEZvcmNloKCgoKCg oKCgoKAgMC4wMDA4ODKgoKCgIDAuMDAwNDUwoKCgoCBOTyA8YnI+oFJNU6CgoKAgRm9yY2WgoKCg oKCgoKCgoCAwLjAwMDI2OaCgoKAgMC4wMDAzMDCgoKCgIFlFUzxicj6gTWF4aW11bSBEaXNwbGFj ZW1lbnSgoKCgIDAuMDU2NDcwoKCgoCAwLjAwMTgwMKCgoKAgTk8gPGJyPgqgUk1ToKCgoCBEaXNw bGFjZW1lbnSgoKCgIDAuMDE0MTMyoKCgoCAwLjAwMTIwMKCgoKAgTk8gPGJyPqBQcmVkaWN0ZWQg Y2hhbmdlIGluIEVuZXJneT0tMS42NTk5MTlELTAzPGJyPqBPcHRpbWl6YXRpb24gc3RvcHBlZC48 YnI+oKCgIC0tIE51bWJlciBvZiBzdGVwcyBleGNlZWRlZCygIE5TdGVwPQogMTAwPGJyPqCgoCAt LSBGbGFnIHJlc2V0IHRvIHByZXZlbnQgYXJjaGl2aW5nLjxicj6goKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPqCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgICEgTm9uLU9wdGltaXplZCBQYXJhbWV0ZXJzICE8YnI+oKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKAgISAoQW5nc3Ryb21zIGFuZCBEZWdyZWVzKaAgITxicj4KoC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0toKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPqAhIE5hbWWgCiBEZWZpbml0aW9uoKCgoKCgoKCgoKCgoCBWYWx1ZaCg oKCgoKCgoCBEZXJpdmF0aXZlIEluZm8uoKCgoKCgoKCgoKCgoKCgICE8YnI+oC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPqAhIFIxoKCgIFIoMSwzKaCgoKCgoKCgoKCgoKCgoKCgIDMuOTk5NqCg oKCgoKCgIC1ERS9EWCA9oKAgLTAuMDAyM6CgoKCgoKCgoKCgoKAgITxicj4KoCEgUjKgoKAgUigx LDUpoKCgoKCgoKCgoKCgoKCgoKAgMS4wMDOgoKCgoKCgoKAgLURFL0RYID2goKAKIDAuMKCgoKCg oKCgoKCgoKCgoKAgITxicj6gISBSM6CgoCBSKDEsNimgoKCgoKCgoKCgoKCgoKCgoCAxLjAwM6Cg oKCgoKCgoCAtREUvRFggPaCgoCAwLjCgoKCgoKCgoKCgoKCgoKCgICE8YnI+oCEgUjSgoKAgUigx LDcpoKCgoKCgoKCgoKCgoKCgoKAgMi45ODE3oKCgoKCgoKAgLURFL0RYID2goCAtMC4wMDA5oKCg oKCgoKCgoKCgoCAhPGJyPqAhIFI1oKCgIFIoMSw5KaCgoKCgoKCgoKCgoKCgoKCgIDMuMDczMqCg oKCgoKCgIC1ERS9EWCA9oKAKIC0wLjAwMaCgoKCgoKCgoKCgoKCgICE8YnI+oCEgUjagoKAgUigy LDQpoKCgoKCgoKCgoKCgoKCgoKAgMy45OTk3oKCgoKCgoKAgLURFL0RYID2goCAtMC4wMDI5oKCg oKCgoKCgoKCgoCAhPGJyPqAhIFI3oKCgIFIoMiw3KaCgoKCgoKCgoKCgoKCgoKCgIDAuOTczN6Cg oKCgoKCgIC1ERS9EWCA9oKCgIDAuMDAwNKCgoKCgoKCgoKCgoKAgITxicj6gISBSOKCgoCBSKDIs OCmgoKCgoKCgoKCgoKCgoKCgoCAwLjk2OTegoKCgoKCgoCAtREUvRFggPaCgoAogMC4wMDA3oKCg oKCgoKCgoKCgoCAhPGJyPqAhIFI5oKCgIFIoMyw5KaCgoKCgoKCgoKCgoKCgoKCgIDAuOTcyMqCg oKCgoKCgIC1ERS9EWCA9oKAgLTAuMDAxM6CgoKCgoKCgoKCgoKAgITxicj6gISBSMTCgoCBSKDMs MTApoKCgoKCgoKCgoKCgoKCgoCAwLjk2NjSgoKCgoKCgoCAtREUvRFggPaCgIC0wLjAwMDGgoKCg oKCgoKCgoKCgICE8YnI+oCEgUjExoKAgUigzLDExKaCgoKCgoKCgoKCgoKCgoKAgMS43NDI4oKCg oKCgoKAgLURFL0RYID2goKAKIDAuMDAwMqCgoKCgoKCgoKCgoKAgITxicj6gISBSMTKgoCBSKDQs OCmgoKCgoKCgoKCgoKCgoKCgoCA0LjQ3MjigoKCgoKCgoCAtREUvRFggPaCgIC0wLjAwMDigoKCg oKCgoKCgoKCgICE8YnI+oCEgUjEzoKAgUig0LDExKaCgoKCgoKCgoKCgoKCgoKAgMC45ODGgoKCg oKCgoKAgLURFL0RYID2goKAgMC4wMDAzoKCgoKCgoKCgoKCgoCAhPGJyPqAhIFIxNKCgIFIoNCwx MimgoKCgoKCgoKCgoKCgoKCgIDAuOTY1OaCgoKCgoKCgIC1ERS9EWCA9oKCgCiAwLjCgoKCgoKCg oKCgoKCgoKCgICE8YnI+oCEgQTGgoKAgQSgzLDEsNSmgoKCgoKCgoKCgoKCgoCA5OS4wMDk2oKCg oKCgoKAgLURFL0RYID2goKAgMC4woKCgoKCgoKCgoKCgoKCgoCAhPGJyPqAhIEEyoKCgIEEoMywx LDYpoKCgoKCgoKCgoKCgoKAgOTkuMDA5NqCgoKCgoKCgIC1ERS9EWCA9oKCgIDAuMKCgoKCgoKCg oKCgoKCgoKAgITxicj6gISBBM6CgoCBBKDMsMSw3KaCgoKCgoKCgoKCgoKCgIDY4LjU2NDigoKCg oKCgoCAtREUvRFggPaCgoAogMC4woKCgoKCgoKCgoKCgoKCgoCAhPGJyPqAhIEE0oKCgIEEoNSwx LDYpoKCgoKCgoKCgoKCgoCAxMDQuOTg0NaCgoKCgoKCgIC1ERS9EWCA9oKAgLTAuMDAwN6CgoKCg oKCgoKCgoKAgITxicj6gISBBNaCgoCBBKDUsMSw3KaCgoKCgoKCgoKCgoKCgIDYwLjYyOTOgoKCg oKCgoCAtREUvRFggPaCgIC0wLjAwMDOgoKCgoKCgoKCgoKCgICE8YnI+oCEgQTagoKAgQSg1LDEs OSmgoKCgoKCgoKCgoKCgIDEwMS44NTmgoKCgoKCgoKAgLURFL0RYID2goKAKIDAuMDAwMaCgoKCg oKCgoKCgoKAgITxicj6gISBBN6CgoCBBKDYsMSw3KaCgoKCgoKCgoKCgoKCgIDYwLjYyOTOgoKCg oKCgoCAtREUvRFggPaCgIC0wLjAwMDOgoKCgoKCgoKCgoKCgICE8YnI+oCEgQTigoKAgQSg2LDEs OSmgoKCgoKCgoKCgoKCgIDEwMS44NTmgoKCgoKCgoKAgLURFL0RYID2goKAgMC4wMDAxoKCgoKCg oKCgoKCgoCAhPGJyPqAhIEE5oKCgIEEoNywxLDkpoKCgoKCgoKCgoKCgoKAgNzMuMzg2NqCgoKCg oKCgIC1ERS9EWCA9oKCgCiAwLjCgoKCgoKCgoKCgoKCgoKCgICE8YnI+oCEgQTEwoKAgQSg0LDIs NymgoKCgoKCgoKCgoKCgoKAgMy4yNTIzoKCgoKCgoKAgLURFL0RYID2goKAgMC4wMDGgoKCgoKCg oKCgoKCgoCAhPGJyPqAhIEExMaCgIEEoNywyLDgpoKCgoKCgoKCgoKCgoCAxMTAuMDQ4NaCgoKCg oKCgIC1ERS9EWCA9oKCgIDAuMDAwMaCgoKCgoKCgoKCgoKAgITxicj6gISBBMTKgoCBBKDEsMywx MCmgoKCgoKCgoKCgoKAgMTI2LjU5OTagoKCgoKCgoCAtREUvRFggPaCgoCAwLjAwMDGgoKCgoKCg oKCgoKCgCiAhPGJyPqAhIEExM6CgIEEoMSwzLDExKaCgoKCgoKCgoKCgoKAgOTYuNzAyOKCgoKCg oKCgIC1ERS9EWCA9oKAgLTAuMDAwMaCgoKCgoKCgoKCgoKAgITxicj6gISBBMTSgoCBBKDksMywx MCmgoKCgoKCgoKCgoKAgMTExLjE5MTOgoKCgoKCgoCAtREUvRFggPaCgIC0wLjAwMDGgoKCgoKCg oKCgoKCgICE8YnI+oCEgQTE1oKAgQSg5LDMsMTEpoKCgoKCgoKCgoKCgIDExMi4xMTExoKCgoKCg oKAgLURFL0RYID2goKAgMC4wMDAxoKCgoKCgoKCgoKCgoCAhPGJyPgqgISBBMTagoCBBKDEwLDMs MTEpoKCgoKCgoKCgoKAKIDEzNi42OTc2oKCgoKCgoKAgLURFL0RYID2goKAgMC4woKCgoKCgoKCg oKCgoKCgoCAhPGJyPqAhIEExN6CgIEEoMiw0LDExKaCgoKCgoKCgoKCgoKAgOTUuMjU5NKCgoKCg oKCgIC1ERS9EWCA9oKAgLTAuMDAwMqCgoKCgoKCgoKCgoKAgITxicj6gISBBMTigoCBBKDIsNCwx MimgoKCgoKCgoKCgoKAgMTU0LjkzNjmgoKCgoKCgoCAtREUvRFggPaCgIC0wLjAwMDGgoKCgoKCg oKCgoKCgICE8YnI+CqAhIEExOaCgIEEoOCw0LDExKaCgoKCgoKCgoKCgoCAxMDYuNzQ0NKCgoKCg oKCgIC1ERS9EWCA9oKAKIC0wLjAwMDKgoKCgoKCgoKCgoKCgICE8YnI+oCEgQTIwoKAgQSg4LDQs MTIpoKCgoKCgoKCgoKCgIDE0My40NTE5oKCgoKCgoKAgLURFL0RYID2goCAtMC4wMDAxoKCgoKCg oKCgoKCgoCAhPGJyPqAhIEEyMaCgIEEoMTEsNCwxMimgoKCgoKCgoKCgoCAxMDkuODAzN6CgoKCg oKCgIC1ERS9EWCA9oKCgIDAuMDAwM6CgoKCgoKCgoKCgoKAgITxicj6gISBBMjKgoCBMKDEsNywy LDQsLTEpoKCgoKCgoKAgMjg1Ljg2NDGgoKCgoKCgoCAtREUvRFggPaCgIC0wLjAwMTGgoKCgoKCg oKCgoKCgICE8YnI+CqAhIEEyM6CgCiBMKDMsMTEsNCwyLC0xKaCgoKCgoKAgMTY4LjI2NTmgoKCg oKCgoCAtREUvRFggPaCgIC0wLjAwMDOgoKCgoKCgoKCgoKCgICE8YnI+oCEgQTI0oKAgTCgxLDcs Miw0LC0yKaCgoKCgoKCgIDE4MC4woKCgoKCgoKCgoKAgLURFL0RYID2goKAgMC4woKCgoKCgoKCg oKCgoKCgoCAhPGJyPqAhIEEyNaCgIEwoMywxMSw0LDIsLTIpoKCgoKCgoCAxODAuMKCgoKCgoKCg oKCgIC1ERS9EWCA9oKCgIDAuMKCgoKCgoKCgoKCgoKCgoKAgITxicj4KoCEgRDGgoKAgRCgzLDEs Miw0KaCgoKCgoKCgoKCgoKAKIDAuMKCgoKCgoKCgoKCgIC1ERS9EWCA9oKCgIDAuMKCgoKCgoKCg oKCgoKCgoKAgITxicj6gISBEMqCgoCBEKDMsMSwyLDgpoKCgoKCgoKCgoKAgMTgwLjCgoKCgoKCg oKCgoCAtREUvRFggPaCgoCAwLjCgoKCgoKCgoKCgoKCgoKCgICE8YnI+oCEgRDOgoKAgRCg1LDEs Miw0KaCgoKCgoKCgoKCgIDEwMi45MDU4oKCgoKCgoKAgLURFL0RYID2goKAgMC4wMDAxoKCgoKCg oKCgoKCgoCAhPGJyPgqgISBENKCgoCBEKDUsMSwyLDgpoKCgoKCgoKCgoKAgLTc3LjA5NDKgoKCg oKCgoCAtREUvRFgKID2goKAgMC4wMDAxoKCgoKCgoKCgoKCgoCAhPGJyPqAhIEQ1oKCgIEQoNiwx LDIsNCmgoKCgoKCgoKCgIC0xMDIuOTA1OKCgoKCgoKCgIC1ERS9EWCA9oKAgLTAuMDAwMaCgoKCg oKCgoKCgoKAgITxicj6gISBENqCgoCBEKDYsMSwyLDgpoKCgoKCgoKCgoKCgIDc3LjA5NDKgoKCg oKCgoCAtREUvRFggPaCgIC0wLjAwMDGgoKCgoKCgoKCgoKCgICE8YnI+oCEgRDegoKAgRCg5LDEs Miw0KaCgoKCgoKCgoKCgoKAgMC4woKCgoKCgoKCgoKAgLURFL0RYID2goKAKIDAuMKCgoKCgoKCg oKCgoKCgoKAgITxicj6gISBEOKCgoCBEKDksMSwyLDgpoKCgoKCgoKCgoKAgMTgwLjCgoKCgoKCg oKCgoCAtREUvRFggPaCgoCAwLjCgoKCgoKCgoKCgoKCgoKCgICE8YnI+oCEgRDmgoKAgRCg1LDEs MywxMCmgoKCgoKCgoKCgIDEyNi41NjUxoKCgoKCgoKAgLURFL0RYID2goKAgMC4wMDA0oKCgoKCg oKCgoKCgoCAhPGJyPqAhIEQxMKCgIEQoNSwxLDMsMTEpoKCgoKCgoKCgoCAtNTMuNDM0OaCgoKCg oKCgIC1ERS9EWCA9oKCgIDAuMDAwNKCgoKCgoKCgoKCgoKAgITxicj4KoCEKIEQxMaCgIEQoNiwx LDMsMTApoKCgoKCgoKCgIC0xMjYuNTY1MaCgoKCgoKCgIC1ERS9EWCA9oKAgLTAuMDAwNKCgoKCg oKCgoKCgoKAgITxicj6gISBEMTKgoCBEKDYsMSwzLDExKaCgoKCgoKCgoKCgIDUzLjQzNDmgoKCg oKCgoCAtREUvRFggPaCgIC0wLjAwMDSgoKCgoKCgoKCgoKCgICE8YnI+oCEgRDEzoKAgRCg3LDEs MywxMCmgoKCgoKCgoKCgIDE4MC4woKCgoKCgoKCgoKAgLURFL0RYID2goKAgMC4woKCgoKCgoKCg oKCgoKCgoCAhPGJyPgqgISBEMTSgoCBEKDcsMSwzLDExKaCgoKCgoKCgoKCgoAogMC4woKCgoKCg oKCgoKAgLURFL0RYID2goKAgMC4woKCgoKCgoKCgoKCgoKCgoCAhPGJyPqAhIEQxNaCgIEQoNywy LDQsMTEpoKCgoKCgoKCgoCAxODAuMKCgoKCgoKCgoKCgIC1ERS9EWCA9oKCgIDAuMKCgoKCgoKCg oKCgoKCgoKAgITxicj6gISBEMTagoCBEKDcsMiw0LDEyKaCgoKCgoKCgoKCgoCAwLjCgoKCgoKCg oKCgoCAtREUvRFggPaCgoCAwLjCgoKCgoKCgoKCgoKCgoKCgICE8YnI+CqAhIEQxN6CgIEQoMSwz LDQsMimgoKCgoKCgoKCgoKCgCiAwLjCgoKCgoKCgoKCgoCAtREUvRFggPaCgoCAwLjCgoKCgoKCg oKCgoKCgoKCgICE8YnI+oCEgRDE4oKAgRCgxLDMsNCw4KaCgoKCgoKCgoKCgoKAgMC4woKCgoKCg oKCgoKAgLURFL0RYID2goKAgMC4woKCgoKCgoKCgoKCgoKCgoCAhPGJyPqAhIEQxOaCgIEQoMSwz LDQsMTIpoKCgoKCgoKCgoCAxODAuMKCgoKCgoKCgoKCgIC1ERS9EWCA9oKCgIDAuMKCgoKCgoKCg oKCgoKCgoKAgITxicj4KoCEgRDIwoKAgRCg5LDMsNCwyKaCgoKCgoKCgoKCgoKAKIDAuMKCgoKCg oKCgoKCgIC1ERS9EWCA9oKCgIDAuMKCgoKCgoKCgoKCgoKCgoKAgITxicj6gISBEMjGgoCBEKDks Myw0LDgpoKCgoKCgoKCgoKCgoCAwLjCgoKCgoKCgoKCgoCAtREUvRFggPaCgoCAwLjCgoKCgoKCg oKCgoKCgoKCgICE8YnI+oCEgRDIyoKAgRCg5LDMsNCwxMimgoKCgoKCgoKCgIDE4MC4woKCgoKCg oKCgoKAgLURFL0RYID2goKAgMC4woKCgoKCgoKCgoKCgoKCgoCAhPGJyPgqgISBEMjOgoCBEKDEw LDMsNCwyKaCgoKCgoKCgoKAKIDE4MC4woKCgoKCgoKCgoKAgLURFL0RYID2goKAgMC4woKCgoKCg oKCgoKCgoKCgoCAhPGJyPqAhIEQyNKCgIEQoMTAsMyw0LDgpoKCgoKCgoKCgoCAxODAuMKCgoKCg oKCgoKCgIC1ERS9EWCA9oKCgIDAuMKCgoKCgoKCgoKCgoKCgoKAgITxicj6gISBEMjWgoCBEKDEw LDMsNCwxMimgoKCgoKCgoKCgoCAwLjCgoKCgoKCgoKCgoCAtREUvRFggPaCgoCAwLjCgoKCgoKCg oKCgoKCgoKCgCiAhPGJyPqAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj6gR3JhZEdyYWRHcmFk R3JhZEdyYWRHcmFkR3JhZEdyYWRHcmFkR3JhZEdyYWRHcmFkR3JhZEdyYWRHcmFkR3JhZEdyYWRH cmFkPC9kaXY+CjxkaXY+oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBJbnB1dCBvcmllbnRhdGlv bjqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIDxicj6gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPqBDZW50ZXKg oKCgIEF0b21pY6CgoKAgQXRvbWljoKCgoKCgoKCgoKCgoCBDb29yZGluYXRlcyAoQW5nc3Ryb21z KTxicj4KoE51bWJlcqCgoKAgTnVtYmVyoKCgoKAgVHlwZaCgoKCgoKCgoKCgoKAgWKCgoKCgoKCg oKAgWaCgoKCgoKCgoKAKIFo8YnI+oC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj6goKAgMaCgoKCgoKCgoCA4oKCg oKCgoKCgoKCgIDCgoKCgoKCgIDAuMTg0NTA1oKCgIDAuMDAwMDAwoKCgIDAuMTU0OTg0PGJyPqCg oCAyoKCgoKCgoKCgIDigoKCgoKCgoKCgoKAgMKCgoKCgoKAgMC4wMzMwMzSgoKAgMC4wMDAwMDCg oKAgMi44ODE2NDA8YnI+CqCgoCAzoKCgoKCgoKCgIDigoKCgoKCgoKCgoKAgMKCgoKCgoKAgNC4x NjE0NjmgoKAgMC4wMDAwMDCgoKAgMC41ODM2NTI8YnI+oKCgIDSgoKCgoKCgoKAKIDigoKCgoKCg oKCgoKAgMKCgoKCgoKAgNC4wMTE5MjGgoKAgMC4wMDAwMDCgoKAgMy4yOTIwNzE8YnI+oKCgIDWg oKCgoKCgoKAgMaCgoKCgoKCgoKCgoCAwoKCgoKCgIC0wLjAzMjcwM6CgIC0wLjc2NTc5OaCgoCAw LjcxMjk1NTxicj6goKAgNqCgoKCgoKCgoCAxoKCgoKCgoKCgoKCgIDCgoKCgoKAgLTAuMDMyNzAz oKCgIDAuNzY1Nzk5oKCgIDAuNzEyOTU1PGJyPqCgoCA3oKCgoKCgoKCgIDGgoKCgoKCgoKCgoKAg MKCgoKCgoKAgMC45OTUyNTOgoKAgMC4wMDAwMDCgoKAgMy4wMzU1MzE8YnI+CqCgoAogOKCgoKCg oKCgoCAxoKCgoKCgoKCgoKCgIDCgoKCgoKAgLTAuNDM4ODY3oKCgIDAuMDAwMDAwoKCgIDMuNzI3 MzI2PGJyPqCgoCA5oKCgoKCgoKCgIDGgoKCgoKCgoKCgoKAgMKCgoKCgoKAgMy4yNjExNzegoKAg MC4wMDAwMDCgoKAgMC4yMTU2Nzc8YnI+oKAgMTCgoKCgoKCgoKAgMaCgoKCgoKCgoKCgoCAwoKCg oKCgoCA0LjgyNjQ3NaCgoCAwLjAwMDAwMKCgIC0wLjExNzg5Mjxicj6goCAxMaCgoKCgoKCgoCAx oKCgoKCgoKCgoKCgIDCgoKCgoKCgIDQuMTg5OTY3oKCgCiAwLjAwMDAwMKCgoCAyLjMyNDI3Njxi cj6goCAxMqCgoKCgoKCgoCAxoKCgoKCgoKCgoKCgIDCgoKCgoKCgIDQuODQyNjc4oKCgIDAuMDAw MDAwoKCgIDMuNzg3OTY1PGJyPqAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+oKCgoKCgoKCgoKCgoKCgoKCgoCBE aXN0YW5jZSBtYXRyaXggKGFuZ3N0cm9tcyk6PGJyPgqgoKCgoKCgoKCgoKCgoKCgoKCgIDGgoKCg oKCgoKAgMqCgoKCgoKCgoCAzoKCgoKCgoKCgIDSgoKCgoKCgoKAgNTxicj6goKCgIDGgIE+goKAg MC4wMDAwMDA8YnI+oKCgoCAyoAogT6CgoCAyLjczMDg2MKCgIDAuMDAwMDAwPGJyPqCgoKAgM6Ag T6CgoCA0LjAwMDAwMKCgIDQuNzI0OTA2oKAgMC4wMDAwMDA8YnI+oKCgoCA0oCBPoKCgIDQuOTQ4 NzgwoKAgNC4wMDAwMDCgoCAyLjcxMjU0NaCgIDAuMDAwMDAwPGJyPqCgoKAgNaAgSKCgoCAwLjk3 MjA5MKCgIDIuMzAwODYyoKAgNC4yNjU0NzKgoCA0Ljg1NzcwMqCgIDAuMDAwMDAwPGJyPqCgoKAg NqAgSKCgoCAwLjk3MjA5MKCgIDIuMzAwODYyoKAgNC4yNjU0NzKgoCA0Ljg1NzcwMqCgIDEuNTMx NTk4PGJyPgqgoKCgIDegIEigoKAgMi45OTI0NjegoCAwLjk3NDQ0OKCgIDQuMDA0NTc3oKAgMy4w Mjc1NTegoCAyLjY1MjgyOTxicj6goKCgIDigIEigoKAgMy42MjYzMjOgoCAwLjk2ODQzOaCgIDUu NTcxODc1oKAgNC40NzIwMjCgoCAzLjEzNjUzNTxicj6goKCgIDmgIEigoKAgMy4wNzcyNzCgoAog NC4xODY2NzigoCAwLjk3MjU5MKCgIDMuMTY2NjczoKAgMy40MTgwOTY8YnI+oKCgIDEwoCBIoKCg IDQuNjQ5OTgzoKAgNS42NTQ1ODCgoCAwLjk2NjY0MaCgIDMuNTA1OTAxoKAgNC45ODg4MjQ8YnI+ oKCgIDExoCBIoKCgIDQuNTU1MTY4oKAgNC4xOTQxMzOgoCAxLjc0MDg1OKCgIDAuOTg0MDM2oKAg NC41ODQwNzY8YnI+oKCgIDEyoCBIoKCgIDUuOTA3Mzc4oKAgNC44OTQyOTOgoCAzLjI3NTkyMqCg IDAuOTY3NTA2oKAgNS44MTQ3NjQ8YnI+CqCgoKCgoKCgoKCgoKCgoKCgoKAgNqCgoKCgoKCgoCA3 oKCgoKCgoKCgIDigoKCgoKCgoKAgOaCgoKCgoKCgIDEwPGJyPqCgoKAgNqAgSKCgoCAwLjAwMDAw MDxicj6goKCgIDegIEigoKAKIDIuNjUyODI5oKAgMC4wMDAwMDA8YnI+oKCgoCA4oCBIoKCgIDMu MTM2NTM1oKAgMS41OTIyNTegoCAwLjAwMDAwMDxicj6goKCgIDmgIEigoKAgMy40MTgwOTagoCAz LjYxNzQ1NqCgIDUuMTAxMTc3oKAgMC4wMDAwMDA8YnI+oKCgIDEwoCBIoKCgIDQuOTg4ODI0oKAg NC45NjIwOTCgoCA2LjUxOTkzM6CgIDEuNjAwNDQ1oKAgMC4wMDAwMDA8YnI+oKCgIDExoCBIoKCg IDQuNTg0MDc2oKAgMy4yNzI5MzKgoCA0LjgzNjgwMqCgIDIuMzA0MDkzoKAgMi41MjM3NTM8YnI+ CqCgoCAxMqAgSKCgoCA1LjgxNDc2NKCgIDMuOTIwMzExoKAgNS4yODE4OTSgoCAzLjkwNjcxMaCg IDMuOTA1ODkwPGJyPqCgoKCgoKCgoKCgoKCgoKCgoCAxMaCgoKCgoKCgIDEyPGJyPqCgoCAxMaAg SKCgoCAwLjAwMDAwMDxicj6goKAgMTKgCiBIoKCgIDEuNjAyNjI3oKAgMC4wMDAwMDA8YnI+oFN0 b2ljaGlvbWV0cnmgoKAgSDhPNDxicj6gRnJhbWV3b3JrIGdyb3VwoCBDU1tTRyhINk80KSxYKEgy KV08YnI+oERlZy4gb2YgZnJlZWRvbaCgoCAyMDxicj6gRnVsbCBwb2ludCBncm91cKCgoKCgoKCg oKCgoKCgoKAgQ1M8YnI+oExhcmdlc3QgQWJlbGlhbiBzdWJncm91cKCgoKCgoKCgIENToKCgoKAg Tk9woKAgMjxicj6gTGFyZ2VzdCBjb25jaXNlIEFiZWxpYW4gc3ViZ3JvdXAgQ1OgoKCgoCBOT3Cg oCAyPGJyPgqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgU3RhbmRhcmQgb3JpZW50YXRpb246oKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgCiA8YnI+oC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj6gQ2VudGVyoKCgoCBB dG9taWOgoKCgIEF0b21pY6CgoKCgoKCgoKCgoKAgQ29vcmRpbmF0ZXMgKEFuZ3N0cm9tcyk8YnI+ oE51bWJlcqCgoKAgTnVtYmVyoKCgoKAgVHlwZaCgoKCgoKCgoKCgoKAgWKCgoKCgoKCgoKAgWaCg oKCgoKCgoKAgWjxicj4KoC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj6goKAgMaCgoKCgoKCgoCA4oKCgoKCgoKCg oKCgIDCgoKCgoKAgLTIuNTAxMDcwoKCgIDAuMDY5Nzg3oKCgIDAuMDAwMDAwPGJyPqCgoCAyoKCg oKCgoKCgCiA4oKCgoKCgoKCgoKCgIDCgoKCgoKAgLTAuODI3MzUxoKCgIDIuMjI3NjIzoKCgIDAu MDAwMDAwPGJyPqCgoCAzoKCgoKCgoKCgIDigoKCgoKCgoKCgoKAgMKCgoKCgoKAgMC43ODI0NzKg oCAtMi4yMTQ1ODSgoKAgMC4wMDAwMDA8YnI+oKCgIDSgoKCgoKCgoKAgOKCgoKCgoKCgoKCgoCAw oKCgoKCgoCAyLjQ0NTY4NKCgIC0wLjA3MTc3N6CgoCAwLjAwMDAwMDxicj6goKAgNaCgoKCgoKCg oCAxoKCgoKCgoKCgoKCgIDCgoKCgoKAgLTIuMjk5MTUwoKCgIDAuNjMzNDcwoKCgIDAuNzY1Nzk5 PGJyPgqgoKAKIDagoKCgoKCgoKAgMaCgoKCgoKCgoKCgoCAwoKCgoKCgIC0yLjI5OTE1MKCgoCAw LjYzMzQ3MKCgIC0wLjc2NTc5OTxicj6goKAgN6CgoKCgoKCgoCAxoKCgoKCgoKCgoKCgIDCgoKCg oKCgIDAuMDAwMDAwoKCgIDEuNzEyODA0oKCgIDAuMDAwMDAwPGJyPqCgoCA4oKCgoKCgoKCgIDGg oKCgoKCgoKCgoKAgMKCgoKCgoCAtMC42MjkwMzWgoKAgMy4xNzU1NDCgoKAgMC4wMDAwMDA8YnI+ oKCgIDmgoKCgoKCgoKAgMaCgoKCgoKCgoKCgoCAwoKCgoKCgIC0wLjEzODUxOaCgCiAtMS45MDE5 OTmgoKAgMC4wMDAwMDA8YnI+oKAgMTCgoKCgoKCgoKAgMaCgoKCgoKCgoKCgoCAwoKCgoKCgoCAw LjgyNDQ2NqCgIC0zLjE4MDMxM6CgoCAwLjAwMDAwMDxicj6goCAxMaCgoKCgoKCgoCAxoKCgoKCg oKCgoKCgIDCgoKCgoKCgIDEuOTQ1NDQ2oKAgLTAuOTE5MTc3oKCgIDAuMDAwMDAwPGJyPqCgIDEy oKCgoKCgoKCgIDGgoKCgoKCgoKCgoKAgMKCgoKCgoKAgMy4zOTgwNjSgoCAtMC4yNDIxODmgoKAg MC4wMDAwMDA8YnI+CqAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+oFJvdGF0aW9uYWwgY29uc3RhbnRzIChHSFop OqCgoKCgCiAzLjY1NjY5NTagoKCgoCAxLjcxNjE2NzOgoKCgoCAxLjE3NDQxNjQ8L2Rpdj4KPGRp dj6gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKjwvZGl2Pgo8ZGl2PqCgoKCgoKCgoKCgIFBvcHVsYXRpb24gYW5hbHlz aXMgdXNpbmcgdGhlIFNDRiBkZW5zaXR5LjwvZGl2Pgo8ZGl2PqAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9kaXY+ CjxkaXY+oEVsZWN0cm9uaWMgc3BhdGlhbCBleHRlbnQgKGF1KTqgICZsdDtSKioyJmd0Oz2goCA5 MTkuMjAwODxicj6gQ2hhcmdlPaCgoKAgMC4wMDAwIGVsZWN0cm9uczxicj6gRGlwb2xlIG1vbWVu dCAoZmllbGQtaW5kZXBlbmRlbnQgYmFzaXMsIERlYnllKTo8YnI+oKCgIFg9oKCgoCAxLjgwMjig oKAgWT2goKAgLTAuNjM4N6CgoCBaPaCgoKAgMC4wMDAwoCBUb3Q9oKCgoCAxLjkxMjY8YnI+CqBR dWFkcnVwb2xlIG1vbWVudCAoZmllbGQtaW5kZXBlbmRlbnQgYmFzaXMsIERlYnllLUFuZyk6PGJy PqCgIFhYPaCgIC0zMC42MzUwoKAgWVk9oKCgIC03LjY4OTSgoCBaWj2goCAtMjYuNDg4NDxicj6g oCBYWT2goKAgLTUuMDkxNaCgIFhaPaCgoKAgMC4wMDAwoKAgWVo9oKCgoCAwLjAwMDA8YnI+oFRy YWNlbGVzcyBRdWFkcnVwb2xlIG1vbWVudCAoZmllbGQtaW5kZXBlbmRlbnQgYmFzaXMsIERlYnll LUFuZyk6PGJyPgqgoCBYWD2goKAgLTkuMDMwN6CgIFlZPaCgoCAxMy45MTQ5oKAgWlo9oKCgIC00 Ljg4NDE8YnI+oKAgWFk9oKCgCiAtNS4wOTE1oKAgWFo9oKCgoCAwLjAwMDCgoCBZWj2goKCgIDAu MDAwMDxicj6gT2N0YXBvbGUgbW9tZW50IChmaWVsZC1pbmRlcGVuZGVudCBiYXNpcywgRGVieWUt QW5nKioyKTo8YnI+oCBYWFg9oKCgIDUzLjc3OTmgIFlZWT2goKAgLTcuNjE3M6AgWlpaPaCgoKAg MC4wMDAwoCBYWVk9oKCgoCA1Ljc1MzY8YnI+oCBYWFk9oKCgIC0yLjUzMjGgIFhYWj2goKCgIDAu MDAwMKAgWFpaPaCgoCAtNy4xMTc3oCBZWlo9oKCgoCAxLjIyNjQ8YnI+CqAgWVlaPaCgoKAgMC4w MDAwoCBYWVo9oKCgoCAwLjAwMDA8YnI+oEhleGFkZWNhcG9sZSBtb21lbnQgKGZpZWxkLWluZGVw ZW5kZW50IGJhc2lzLCBEZWJ5ZS1BbmcqKjMpOjxicj6gWFhYWD2gIC01MDkuMzgzMCBZWVlZPaAg LTE1Ni43NTI1IFpaWlo9oKAgLTIzLjI1MTEgWFhYWT2goKAgMzAuNjA1MTxicj6gWFhYWj2goKCg IDAuMDAwMCBZWVlYPaCgoCA0OC40Nzk0IFlZWVo9oKCgoCAwLjAwMDAgWlpaWD2goKCgIDAuMDAw MDxicj4KoFpaWlk9oKCgoCAwLjAwMDAKIFhYWVk9oCAtMTYwLjIzOTcgWFhaWj2goCAtOTAuODk0 OSBZWVpaPaCgIC04Mi40NTcwPGJyPqBYWFlaPaCgoKAgMC4wMDAwIFlZWFo9oKCgoCAwLjAwMDAg WlpYWT2goKAgMjYuMzUzODxicj6gQXRvbaCgIDcgbmVlZHMgdmFyaWFibGWgoCA4PaCgIDAuOTc0 NDQ3NzAzNSBidXQgaXOgoKAgMC45NzIwODk4NjA2PGJyPqBJbnB1dCB6LW1hdHJpeCB2YXJpYWJs ZXMgYXJlIG5vdCBjb21wYXRpYmxlIHdpdGggZmluYWwgc3RydWN0dXJlLjwvZGl2PgoKPGRpdj48 YnI+oEZBVUxUSUxZIEZBVUxUTEVTUywgSUNJTFkgUkVHVUxBUiwgU1BMRU5ESURMWSBOVUxMLi4u PGJyPqCgoKCgoKCgoKAgTUFVREUgQlkgVEVOTllTT048YnI+oEVycm9yIHRlcm1pbmF0aW9uIHJl cXVlc3QgcHJvY2Vzc2VkIGJ5IGxpbmsgOTk5OS48YnI+oEVycm9yIHRlcm1pbmF0aW9uIHZpYSBM bmsxZSBpbiBDOlxHMDNXXGw5OTk5LmV4ZSBhdCBUaHUgTm92IDA0IDE5OjA5OjM1IDIwMTAuPGJy PgqgSm9iIGNwdSB0aW1lOqAgMCBkYXlzoCAxIGhvdXJzIDEzIG1pbnV0ZXMgMTUuMCBzZWNvbmRz Ljxicj6gRmlsZSBsZW5ndGhzIChNQnl0ZXMpOqAgUldGPaCgoKAgMjAgSW50PaCgoKCgIDAgRDJF PaCgoKCgIDAgQ2hrPaCgoKAgMTEgU2NyPaCgoKCgIDE8YnI+PC9kaXY+CjxkaXY+oEFueSBpbnNp Z2h0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bC48YnI+PGJyPjwvZGl2Pgo8ZGl2PqBUaGFua3MhPGJy PjwvZGl2PjwvZGl2Pjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC90ZD48L3RyPjwvdGJvZHk+PC90 YWJsZT48YnI+CgoKCgogICAgICA8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxs Ij48YnI+LS0gPGJyPkplYW4gSnVsZXMgRklGRU4sPGJyPisyMzcgNzUgMjEgNjEgMzk8YnI+KzIz NyA5NCA2NyA2NSAwNTxicj5Vbml2ZXJzaXR5IG9mIE5nYW91bmRlcmUsPGJyPlBPLkJPWCA0NTQg Tmdhb3VuZGVyZTxicj4KPC9kaXY+Cg== --20cf301cc3c041af030494878390-- From owner-chemistry@ccl.net Mon Nov 8 08:57:00 2010 From: "FyD fyd]=[q4md-forcefieldtools.org" To: CCL Subject: CCL: Release of R.E.D. Server 2.0 Message-Id: <-43096-101108044329-23384-hnIkpUqygxwW/i6XGG5qGg!^!server.ccl.net> X-Original-From: FyD Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Date: Mon, 08 Nov 2010 10:43:18 +0100 MIME-Version: 1.0 Sent to CCL by: FyD [fyd*|*q4md-forcefieldtools.org] Dear Rick, > I'm afraid I still have an issue with the use of the misleading > phrase "force field library" to describe the charge templates > produced by the R.E.D. server, at least in the context of CHARMM. A > force field is generally regarded as the complete description of > all the parameters for all of the terms in the potential, and not > just charges and connectivity. We do not claim the R.E.D. tools/R.E.D. Server deal with an entire FF; but only with RESP and ESP charges embedded in a FF library format with some specificities. When one develops a new FF for a new molecule (i.e. charge values + Lennard-Jones (LJ) parameters + FF parameters), the first step consists in developing non-bonding (NB) parameters (i.e. charges + LJ parameters). Then, in a second approach, using the NB parameters obtained in the first step, one develops FF parameters (i.e. bonding parameters). I think, this approach is followed by many FF developers (non-additive FF model). With the R.E.D. tools, R.E.D. Server & R.E.DD.B. a user is able to derive/make public RESP and ESP charges embedded in force field (FF) library(ies); i.e. this corresponds to the work to be carried out at the beginning of the development of a FF for a new molecule. Once again, this is in full agreement with the statement we wrote in the back cover of the 10/2010 issue of PCCP (a reviewer from PCCP suggest us to write such a sentence) i.e. "Methods and computational tools useful for charge derivation and force field topology database building are presented. They give researchers the means to derive rigorously QM MEP-based charges embedded in force field libraries that are ready to be used in force field development, charge validation and/or MD simulations." You can find a similar idea at the end of the introduction as well: "More generally, the goal of this work is not to provide a methodology for developing atomic charges suitable for any particular MD condition, but to give the researchers the means to derive rigorously QM MEP-based charges embedded in force field libraries ready to be used in force field development, charge validation and/or MD simulations." Once again from the literature, ESP charges are used in CHARMM-based FF simulations (after validation or even sometimes directly used). I repeat I understand some CHARMM developers do not like this idea. > Depending on the novelty of the topology, esp. the case where there > is no close correspondence to existing LJ types, a considerable > additional effort would be required. So? This is FF development... in agreement with what we wrote; nothing else - nothing more. > I am not aware of any "script or program" which can reliably > convert a .mol2 file to a complete CHARMM description, a residue > together with all of the other parameters needed to perform energy > evaluations in conjunction with the distributed biomolecule force > fields. As I already told R.E.DD.B. can handle such programs. I want to provide links for that. See for instance: http://q4md-forcefieldtools.org/REDDB/projects/F-60/ For AMBER, a LEaP script: http://q4md-forcefieldtools.org/REDDB/projects/F-60/script1.ff For CHARMM, to come: http://q4md-forcefieldtools.org/REDDB/projects/F-60/script2.ff ( To update a project in R.E.DD.B. see: http://q4md-forcefieldtools.org/REDDB/faq.php#12 ) We do have an approach to convert mol2 file into the CHARMM format. Still buggy, but we made some progresses: To come. I agree with you this is an important step for the project. > In the case of novel functional groups this will fail; further, a > non-trivial amount of high-theory QM calculations would be needed > in order to derive the missing force field parameters, esp. for > rotatable torsions. Well, this is force field development. This is the work that has to be done. Once again, this is in agreement with what we wrote in the back cover of the 10/2010 issue of PCCP. > I don't have an issue with what the server does, just the accuracy > of the phrases used to describe what is produced, and the > trivializing of the amount of effort that would be required to > produce usable CHARMM topology and parameter files, i.e. a force > field. Rick, I would like to underline two points in this discussion: - To the best of my knowledge, R.E.D. IV is the only program able to generate an entire FFTopDB for potentially any type of biopolymers in a single run (we are going to release a major update of R.E.DD.B. with many new FFTopDBs by now). See http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#23 http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#24 http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#25 http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#26 & even http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#27 ! This represents a lot of work. I agree with you some pieces of the whole puzzle might still be missing. All our approach is under the GNU General Public License by now. This means every researcher is free to work on it, and develop her/his own tools. - R.E.D. IV June 2010 incorporates now a statistics module allowing charge comparison between RESP/ESP/Mulliken/Lowdin; charge comparison for different conformations & molecular orientations; comparison between charge values obtained from averaging and from fitting; finally, charge comparison when building a molecular fragment versus its whole molecule. See http://q4md-forcefieldtools.org/REDS/news.php#IV & http://q4md-forcefieldtools.org/REDS/popup/popstatistics.php An example is at: http://q4md-forcefieldtools.org/REDS/faq.php#1 http://q4md-forcefieldtools.org/Tutorial/DNA-FFTopDB/P1.html The outputs are still crude, but this is a starting point ;-) We do believe this represents a first step in charge validation. regards, Francois > On 11/6/10 3:50 AM, "Barry Hardy barry.hardy*o*vtxmail.ch" > wrote: > > Sent to CCL by: FyD [fyd:+:q4md-forcefieldtools.org] > Dear Rick, > > The main idea with the R.E.D. program is to generate a force field > (FF) library format (.mol2 file format) with RESP or ESP charge values > for new molecules and for potentially any type of molecular fragments > (organic, bio-organic & bio-inorganic). Entire Force Field Topology > DataBase (FFTopDB) can now be directly generated. These FF libraries > are FF atom type independent allowing any user to add the atom types > corresponding to the force field of her/his choice. We believe this > force field library is convenient because it can be directly displayed > in many graphical programs. This FF library can also be converted into > a more specific FF library format such as the prep/off/rtf/others? > file formats (using a script based approach or a specific program; > R.E.DD.B. can handle such scripts/program even for CHARMM). > > I think this main idea is also summarized (may be in another way) in > the back cover of the 12/2010 issue of PCCP: "Methods and > computational tools useful for charge derivation and force field > topology database building are presented. They give researchers the > means to derive rigorously QM MEP-based charges embedded in force > field libraries that are ready to be used in force field development, > charge validation and/or MD simulations." > All is said here. > > More generally, we selected the references 17-20 in our article taking > works from well established groups among others. You can find > different references in the literature where ESP charges are used in > "CHARMM" (after validation/adjustment or even directly used by users). > That being said, I understand some CHARMM developers do not like this > idea. > > Please, Rick, download the R.E.D.-III.4 Tools (it is distributed under > the GNU General Public License), use it and tell us what you think > should be improved. > > regards, Francois > > > Quoting "Venable, Richard (NIH/NHLBI) E venabler(a)nhlbi.nih.gov" > : > >> Sent to CCL by: "Venable, Richard (NIH/NHLBI) [E]" [venabler__nhlbi.nih.gov] >> >> I've read through the paper and the two specific CHARMM citations, >> and have to admit my first response over-assumed a reliance on RESP >> charges. However, I am still concerned about the claim to be to >> produce complete force field libraries for CHARMM, which I initially >> interpreted as ready-to-use residues in the proper topology file >> format, which wasn't the case. I believe a claim of being able to >> produce entire CHARMM compatible force field libraries should be >> demonstrated much more completely. >> >> This quote from the cited paper itself raises question about the >> level of CHARMM and OPLS compatibility: >> >> "Indeed, RESP and ESP charge values derived using R.E.D. are fully >> compatible with Amber and GLYCAM force fields, (40-47) and can be >> used in CHARMM and OPLS force field based simulations as well. >> (17-20)" >> >> References 19 and 20 are not really demonstrations of the exact use >> of R.E.D., but use CHELPG for the initial charges, which are further >> adjusted for CHARMM compatibility. >> >> Reading further, it seems the burden of choosing the correct LJ >> types, and thereby the mapping to angle and dihedral terms, is left >> completely up to the end user, which I see as a major weakness. >> Thus, the type independence may pose a problem, in that novel >> bonding geometries can be created for which there are no angle and >> dihedral parameters during the user mediated atom typing process. > > >> On 11/4/10 10:09 PM, "Barry Hardy barry.hardy*o*vtxmail.ch" >> wrote: >> >> Sent to CCL by: FyD [fyd : q4md-forcefieldtools.org] >> >> Dear Rick Venable, >> >> R.E.D. means RESP and ESP charge Derivation. >> >> The R.E.D. Tools and R.E.D. Server do not only deal with _RESP_ >> charges but with _ESP_ charges using various algorithms used in MEP >> computation. And ESP charges are used in FFs different from AMBER FFs... >> Then, charge derivation is the first step - charge validation is done >> in a second step. >> See http://www.ncbi.nlm.nih.gov/pubmed/20574571 & references cited herein. >> >> This is why we wrote >> "R.E.D. Server is a web service designed to automatically derive RESP >> and ESP charges, and to build force field libraries for new >> molecules/molecular fragments. R.E.D. Server provides to computational >> biologists involved in AMBER, CHARMM, GLYCAM & OPLS force field based >> biological studies the software and hardware required for charge >> derivation and force field library building." >> >> regards, Francois > >>> Sent to CCL by: "Venable, Richard (NIH/NHLBI) [E]" >>> [venabler!=!nhlbi.nih.gov] >>> >>> Given that RESP/ESP methods are **not** used for the development of >>> CHARMM force fields (a fragment approach similar to OPLS is used), >>> the compatibility of molecules with RESP-based charges with the rest >>> of the CHARMM force fields is somewhat questionable. The use of >>> other approaches, notably the CHARMM General force field (CGenFF), >>> is recommended instead of ad hoc web servers for extending the >>> CHARMM force field to new molecules. >>> >>> I did not see anything on the q4md site which discussed this, or >>> that gave any hints about validation of the molecular descriptions >>> produced in the context of CHARMM and its distributed force fields. >>> From owner-chemistry@ccl.net Mon Nov 8 10:33:00 2010 From: "Jim Kress ccl_nospam||kressworks.com" To: CCL Subject: CCL: Release of R.E.D. Server 2.0 Message-Id: <-43097-101108095915-26949-JlIneMCaW8AOmX7tfEcuhw.@.server.ccl.net> X-Original-From: "Jim Kress" Content-Language: en-us Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Nov 2010 09:58:36 -0500 MIME-Version: 1.0 Sent to CCL by: "Jim Kress" [ccl_nospam/./kressworks.com] Rick is right, you are wrong, get over it and modify your description appropriately. Otherwise you are going to destroy the credibility of your R.E.D. tools/R.E.D. Server. Jim Kress -----Original Message----- > From: owner-chemistry+ccl_nospam==kressworks.com .. ccl.net [mailto:owner-chemistry+ccl_nospam==kressworks.com .. ccl.net] On Behalf Of FyD fyd]=[q4md-forcefieldtools.org Sent: Monday, November 08, 2010 4:43 AM To: Kress, Jim Subject: CCL: Release of R.E.D. Server 2.0 Sent to CCL by: FyD [fyd*|*q4md-forcefieldtools.org] Dear Rick, > I'm afraid I still have an issue with the use of the misleading > phrase "force field library" to describe the charge templates > produced by the R.E.D. server, at least in the context of CHARMM. A > force field is generally regarded as the complete description of > all the parameters for all of the terms in the potential, and not > just charges and connectivity. We do not claim the R.E.D. tools/R.E.D. Server deal with an entire FF; but only with RESP and ESP charges embedded in a FF library format with some specificities. When one develops a new FF for a new molecule (i.e. charge values + Lennard-Jones (LJ) parameters + FF parameters), the first step consists in developing non-bonding (NB) parameters (i.e. charges + LJ parameters). Then, in a second approach, using the NB parameters obtained in the first step, one develops FF parameters (i.e. bonding parameters). I think, this approach is followed by many FF developers (non-additive FF model). With the R.E.D. tools, R.E.D. Server & R.E.DD.B. a user is able to derive/make public RESP and ESP charges embedded in force field (FF) library(ies); i.e. this corresponds to the work to be carried out at the beginning of the development of a FF for a new molecule. Once again, this is in full agreement with the statement we wrote in the back cover of the 10/2010 issue of PCCP (a reviewer from PCCP suggest us to write such a sentence) i.e. "Methods and computational tools useful for charge derivation and force field topology database building are presented. They give researchers the means to derive rigorously QM MEP-based charges embedded in force field libraries that are ready to be used in force field development, charge validation and/or MD simulations." You can find a similar idea at the end of the introduction as well: "More generally, the goal of this work is not to provide a methodology for developing atomic charges suitable for any particular MD condition, but to give the researchers the means to derive rigorously QM MEP-based charges embedded in force field libraries ready to be used in force field development, charge validation and/or MD simulations." Once again from the literature, ESP charges are used in CHARMM-based FF simulations (after validation or even sometimes directly used). I repeat I understand some CHARMM developers do not like this idea. > Depending on the novelty of the topology, esp. the case where there > is no close correspondence to existing LJ types, a considerable > additional effort would be required. So? This is FF development... in agreement with what we wrote; nothing else - nothing more. > I am not aware of any "script or program" which can reliably > convert a .mol2 file to a complete CHARMM description, a residue > together with all of the other parameters needed to perform energy > evaluations in conjunction with the distributed biomolecule force > fields. As I already told R.E.DD.B. can handle such programs. I want to provide links for that. See for instance: http://q4md-forcefieldtools.org/REDDB/projects/F-60/ For AMBER, a LEaP script: http://q4md-forcefieldtools.org/REDDB/projects/F-60/script1.ff For CHARMM, to come: http://q4md-forcefieldtools.org/REDDB/projects/F-60/script2.ff ( To update a project in R.E.DD.B. see: http://q4md-forcefieldtools.org/REDDB/faq.php#12 ) We do have an approach to convert mol2 file into the CHARMM format. Still buggy, but we made some progresses: To come. I agree with you this is an important step for the project. > In the case of novel functional groups this will fail; further, a > non-trivial amount of high-theory QM calculations would be needed > in order to derive the missing force field parameters, esp. for > rotatable torsions. Well, this is force field development. This is the work that has to be done. Once again, this is in agreement with what we wrote in the back cover of the 10/2010 issue of PCCP. > I don't have an issue with what the server does, just the accuracy > of the phrases used to describe what is produced, and the > trivializing of the amount of effort that would be required to > produce usable CHARMM topology and parameter files, i.e. a force > field. Rick, I would like to underline two points in this discussion: - To the best of my knowledge, R.E.D. IV is the only program able to generate an entire FFTopDB for potentially any type of biopolymers in a single run (we are going to release a major update of R.E.DD.B. with many new FFTopDBs by now). See http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#23 http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#24 http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#25 http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#26 & even http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#27 ! This represents a lot of work. I agree with you some pieces of the whole puzzle might still be missing. All our approach is under the GNU General Public License by now. This means every researcher is free to work on it, and develop her/his own tools. - R.E.D. IV June 2010 incorporates now a statistics module allowing charge comparison between RESP/ESP/Mulliken/Lowdin; charge comparison for different conformations & molecular orientations; comparison between charge values obtained from averaging and from fitting; finally, charge comparison when building a molecular fragment versus its whole molecule. See http://q4md-forcefieldtools.org/REDS/news.php#IV & http://q4md-forcefieldtools.org/REDS/popup/popstatistics.php An example is at: http://q4md-forcefieldtools.org/REDS/faq.php#1 http://q4md-forcefieldtools.org/Tutorial/DNA-FFTopDB/P1.html The outputs are still crude, but this is a starting point ;-) We do believe this represents a first step in charge validation. regards, Francois > On 11/6/10 3:50 AM, "Barry Hardy barry.hardy*o*vtxmail.ch" > wrote: > > Sent to CCL by: FyD [fyd:+:q4md-forcefieldtools.org] > Dear Rick, > > The main idea with the R.E.D. program is to generate a force field > (FF) library format (.mol2 file format) with RESP or ESP charge values > for new molecules and for potentially any type of molecular fragments > (organic, bio-organic & bio-inorganic). Entire Force Field Topology > DataBase (FFTopDB) can now be directly generated. These FF libraries > are FF atom type independent allowing any user to add the atom types > corresponding to the force field of her/his choice. We believe this > force field library is convenient because it can be directly displayed > in many graphical programs. This FF library can also be converted into > a more specific FF library format such as the prep/off/rtf/others? > file formats (using a script based approach or a specific program; > R.E.DD.B. can handle such scripts/program even for CHARMM). > > I think this main idea is also summarized (may be in another way) in > the back cover of the 12/2010 issue of PCCP: "Methods and > computational tools useful for charge derivation and force field > topology database building are presented. They give researchers the > means to derive rigorously QM MEP-based charges embedded in force > field libraries that are ready to be used in force field development, > charge validation and/or MD simulations." > All is said here. > > More generally, we selected the references 17-20 in our article taking > works from well established groups among others. You can find > different references in the literature where ESP charges are used in > "CHARMM" (after validation/adjustment or even directly used by users). > That being said, I understand some CHARMM developers do not like this > idea. > > Please, Rick, download the R.E.D.-III.4 Tools (it is distributed under > the GNU General Public License), use it and tell us what you think > should be improved. > > regards, Francois > > > Quoting "Venable, Richard (NIH/NHLBI) E venabler(a)nhlbi.nih.gov" > : > >> Sent to CCL by: "Venable, Richard (NIH/NHLBI) [E]" [venabler__nhlbi.nih.gov] >> >> I've read through the paper and the two specific CHARMM citations, >> and have to admit my first response over-assumed a reliance on RESP >> charges. However, I am still concerned about the claim to be to >> produce complete force field libraries for CHARMM, which I initially >> interpreted as ready-to-use residues in the proper topology file >> format, which wasn't the case. I believe a claim of being able to >> produce entire CHARMM compatible force field libraries should be >> demonstrated much more completely. >> >> This quote from the cited paper itself raises question about the >> level of CHARMM and OPLS compatibility: >> >> "Indeed, RESP and ESP charge values derived using R.E.D. are fully >> compatible with Amber and GLYCAM force fields, (40-47) and can be >> used in CHARMM and OPLS force field based simulations as well. >> (17-20)" >> >> References 19 and 20 are not really demonstrations of the exact use >> of R.E.D., but use CHELPG for the initial charges, which are further >> adjusted for CHARMM compatibility. >> >> Reading further, it seems the burden of choosing the correct LJ >> types, and thereby the mapping to angle and dihedral terms, is left >> completely up to the end user, which I see as a major weakness. >> Thus, the type independence may pose a problem, in that novel >> bonding geometries can be created for which there are no angle and >> dihedral parameters during the user mediated atom typing process. > > >> On 11/4/10 10:09 PM, "Barry Hardy barry.hardy*o*vtxmail.ch" >> wrote: >> >> Sent to CCL by: FyD [fyd : q4md-forcefieldtools.org] >> >> Dear Rick Venable, >> >> R.E.D. means RESP and ESP charge Derivation. >> >> The R.E.D. Tools and R.E.D. Server do not only deal with _RESP_ >> charges but with _ESP_ charges using various algorithms used in MEP >> computation. And ESP charges are used in FFs different from AMBER FFs... >> Then, charge derivation is the first step - charge validation is done >> in a second step. >> See http://www.ncbi.nlm.nih.gov/pubmed/20574571 & references cited herein. >> >> This is why we wrote >> "R.E.D. Server is a web service designed to automatically derive RESP >> and ESP charges, and to build force field libraries for new >> molecules/molecular fragments. R.E.D. Server provides to computational >> biologists involved in AMBER, CHARMM, GLYCAM & OPLS force field based >> biological studies the software and hardware required for charge >> derivation and force field library building." >> >> regards, Francois > >>> Sent to CCL by: "Venable, Richard (NIH/NHLBI) [E]" >>> [venabler!=!nhlbi.nih.gov] >>> >>> Given that RESP/ESP methods are **not** used for the development of >>> CHARMM force fields (a fragment approach similar to OPLS is used), >>> the compatibility of molecules with RESP-based charges with the rest >>> of the CHARMM force fields is somewhat questionable. The use of >>> other approaches, notably the CHARMM General force field (CGenFF), >>> is recommended instead of ad hoc web servers for extending the >>> CHARMM force field to new molecules. >>> >>> I did not see anything on the q4md site which discussed this, or >>> that gave any hints about validation of the molecular descriptions >>> produced in the context of CHARMM and its distributed force fields.http://www.ccl.net/cgi-bin/ccl/send_ccl_messagehttp://www.ccl.net/chemistry/sub_unsub.shtmlhttp://www.ccl.net/spammers.txt From owner-chemistry@ccl.net Mon Nov 8 12:24:00 2010 From: "Jason Swails swails^^qtp.ufl.edu" To: CCL Subject: CCL: Release of R.E.D. Server 2.0 Message-Id: <-43098-101108121312-27265-NHZa6DBUD/lP5juGy8wXIg++server.ccl.net> X-Original-From: Jason Swails Content-Type: multipart/alternative; boundary=00163645800a739a1204948dbc42 Date: Mon, 8 Nov 2010 12:12:59 -0500 MIME-Version: 1.0 Sent to CCL by: Jason Swails [swails{}qtp.ufl.edu] --00163645800a739a1204948dbc42 Content-Type: text/plain; charset=ISO-8859-1 Black and white? I opt for the gray. Points are valid on both sides. Peace, Jason On Mon, Nov 8, 2010 at 9:58 AM, Jim Kress ccl_nospam||kressworks.com < owner-chemistry||ccl.net> wrote: > > Sent to CCL by: "Jim Kress" [ccl_nospam/./kressworks.com] > Rick is right, you are wrong, get over it and modify your description > appropriately. Otherwise you are going to destroy the credibility of your > R.E.D. tools/R.E.D. Server. > > Jim Kress > > -----Original Message----- > > From: owner-chemistry+ccl_nospam==kressworks.com|-|ccl.net > [mailto:owner-chemistry+ccl_nospam == > kressworks.com|-|ccl.net] On Behalf Of FyD > fyd]=[q4md-forcefieldtools.org > Sent: Monday, November 08, 2010 4:43 AM > To: Kress, Jim > Subject: CCL: Release of R.E.D. Server 2.0 > > > Sent to CCL by: FyD [fyd*|*q4md-forcefieldtools.org] > Dear Rick, > > > I'm afraid I still have an issue with the use of the misleading > > phrase "force field library" to describe the charge templates > > produced by the R.E.D. server, at least in the context of CHARMM. A > > force field is generally regarded as the complete description of > > all the parameters for all of the terms in the potential, and not > > just charges and connectivity. > > We do not claim the R.E.D. tools/R.E.D. Server deal with an entire FF; > but only with RESP and ESP charges embedded in a FF library format > with some specificities. > > When one develops a new FF for a new molecule (i.e. charge values + > Lennard-Jones (LJ) parameters + FF parameters), the first step > consists in developing non-bonding (NB) parameters (i.e. charges + LJ > parameters). Then, in a second approach, using the NB parameters > obtained in the first step, one develops FF parameters (i.e. bonding > parameters). I think, this approach is followed by many FF developers > (non-additive FF model). > > With the R.E.D. tools, R.E.D. Server & R.E.DD.B. a user is able to > derive/make public RESP and ESP charges embedded in force field (FF) > library(ies); i.e. this corresponds to the work to be carried out at > the beginning of the development of a FF for a new molecule. Once > again, this is in full agreement with the statement we wrote in the > back cover of the 10/2010 issue of PCCP (a reviewer from PCCP suggest > us to write such a sentence) i.e. "Methods and computational tools > useful for charge derivation and force field topology database > building are presented. They give researchers the means to derive > rigorously QM MEP-based charges embedded in force field libraries that > are ready to be used in force field development, charge validation > and/or MD simulations." > > You can find a similar idea at the end of the introduction as well: > "More generally, the goal of this work is not to provide a methodology > for developing atomic charges suitable for any particular MD > condition, but to give the researchers the means to derive rigorously > QM MEP-based charges embedded in force field libraries ready to be > used in force field development, charge validation and/or MD > simulations." > > Once again from the literature, ESP charges are used in CHARMM-based > FF simulations (after validation or even sometimes directly used). I > repeat I understand some CHARMM developers do not like this idea. > > > Depending on the novelty of the topology, esp. the case where there > > is no close correspondence to existing LJ types, a considerable > > additional effort would be required. > > So? This is FF development... in agreement with what we wrote; nothing > else - nothing more. > > > I am not aware of any "script or program" which can reliably > > convert a .mol2 file to a complete CHARMM description, a residue > > together with all of the other parameters needed to perform energy > > evaluations in conjunction with the distributed biomolecule force > > fields. > > As I already told R.E.DD.B. can handle such programs. > I want to provide links for that. See for instance: > http://q4md-forcefieldtools.org/REDDB/projects/F-60/ > For AMBER, a LEaP script: > http://q4md-forcefieldtools.org/REDDB/projects/F-60/script1.ff > For CHARMM, to come: > http://q4md-forcefieldtools.org/REDDB/projects/F-60/script2.ff > > ( To update a project in R.E.DD.B. see: > http://q4md-forcefieldtools.org/REDDB/faq.php#12 ) > > We do have an approach to convert mol2 file into the CHARMM format. > Still buggy, but we made some progresses: To come. > I agree with you this is an important step for the project. > > > In the case of novel functional groups this will fail; further, a > > non-trivial amount of high-theory QM calculations would be needed > > in order to derive the missing force field parameters, esp. for > > rotatable torsions. > > Well, this is force field development. This is the work that has to be > done. > Once again, this is in agreement with what we wrote in the back cover > of the 10/2010 issue of PCCP. > > > I don't have an issue with what the server does, just the accuracy > > of the phrases used to describe what is produced, and the > > trivializing of the amount of effort that would be required to > > produce usable CHARMM topology and parameter files, i.e. a force > > field. > > Rick, I would like to underline two points in this discussion: > > - To the best of my knowledge, R.E.D. IV is the only program able to > generate an entire FFTopDB for potentially any type of biopolymers in > a single run (we are going to release a major update of R.E.DD.B. with > many new FFTopDBs by now). > See http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#23 > http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#24 > http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#25 > http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#26 > & even > http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#27 ! > This represents a lot of work. I agree with you some pieces of the > whole puzzle might still be missing. All our approach is under the GNU > General Public License by now. This means every researcher is free to > work on it, and develop her/his own tools. > > - R.E.D. IV June 2010 incorporates now a statistics module allowing > charge comparison between RESP/ESP/Mulliken/Lowdin; charge comparison > for different conformations & molecular orientations; comparison > between charge values obtained from averaging and from fitting; > finally, charge comparison when building a molecular fragment versus > its whole molecule. > See http://q4md-forcefieldtools.org/REDS/news.php#IV > & http://q4md-forcefieldtools.org/REDS/popup/popstatistics.php > An example is at: > http://q4md-forcefieldtools.org/REDS/faq.php#1 > http://q4md-forcefieldtools.org/Tutorial/DNA-FFTopDB/P1.html > The outputs are still crude, but this is a starting point ;-) > We do believe this represents a first step in charge validation. > > regards, Francois > > > > > On 11/6/10 3:50 AM, "Barry Hardy barry.hardy*o*vtxmail.ch" > > wrote: > > > > Sent to CCL by: FyD [fyd:+:q4md-forcefieldtools.org] > > Dear Rick, > > > > The main idea with the R.E.D. program is to generate a force field > > (FF) library format (.mol2 file format) with RESP or ESP charge values > > for new molecules and for potentially any type of molecular fragments > > (organic, bio-organic & bio-inorganic). Entire Force Field Topology > > DataBase (FFTopDB) can now be directly generated. These FF libraries > > are FF atom type independent allowing any user to add the atom types > > corresponding to the force field of her/his choice. We believe this > > force field library is convenient because it can be directly displayed > > in many graphical programs. This FF library can also be converted into > > a more specific FF library format such as the prep/off/rtf/others? > > file formats (using a script based approach or a specific program; > > R.E.DD.B. can handle such scripts/program even for CHARMM). > > > > I think this main idea is also summarized (may be in another way) in > > the back cover of the 12/2010 issue of PCCP: "Methods and > > computational tools useful for charge derivation and force field > > topology database building are presented. They give researchers the > > means to derive rigorously QM MEP-based charges embedded in force > > field libraries that are ready to be used in force field development, > > charge validation and/or MD simulations." > > All is said here. > > > > More generally, we selected the references 17-20 in our article taking > > works from well established groups among others. You can find > > different references in the literature where ESP charges are used in > > "CHARMM" (after validation/adjustment or even directly used by users). > > That being said, I understand some CHARMM developers do not like this > > idea. > > > > Please, Rick, download the R.E.D.-III.4 Tools (it is distributed under > > the GNU General Public License), use it and tell us what you think > > should be improved. > > > > regards, Francois > > > > > > Quoting "Venable, Richard (NIH/NHLBI) E venabler(a)nhlbi.nih.gov" > > : > > > >> Sent to CCL by: "Venable, Richard (NIH/NHLBI) [E]" > [venabler__nhlbi.nih.gov] > >> > >> I've read through the paper and the two specific CHARMM citations, > >> and have to admit my first response over-assumed a reliance on RESP > >> charges. However, I am still concerned about the claim to be to > >> produce complete force field libraries for CHARMM, which I initially > >> interpreted as ready-to-use residues in the proper topology file > >> format, which wasn't the case. I believe a claim of being able to > >> produce entire CHARMM compatible force field libraries should be > >> demonstrated much more completely. > >> > >> This quote from the cited paper itself raises question about the > >> level of CHARMM and OPLS compatibility: > >> > >> "Indeed, RESP and ESP charge values derived using R.E.D. are fully > >> compatible with Amber and GLYCAM force fields, (40-47) and can be > >> used in CHARMM and OPLS force field based simulations as well. > >> (17-20)" > >> > >> References 19 and 20 are not really demonstrations of the exact use > >> of R.E.D., but use CHELPG for the initial charges, which are further > >> adjusted for CHARMM compatibility. > >> > >> Reading further, it seems the burden of choosing the correct LJ > >> types, and thereby the mapping to angle and dihedral terms, is left > >> completely up to the end user, which I see as a major weakness. > >> Thus, the type independence may pose a problem, in that novel > >> bonding geometries can be created for which there are no angle and > >> dihedral parameters during the user mediated atom typing process. > > > > > >> On 11/4/10 10:09 PM, "Barry Hardy barry.hardy*o*vtxmail.ch" > >> wrote: > >> > >> Sent to CCL by: FyD [fyd : q4md-forcefieldtools.org] > >> > >> Dear Rick Venable, > >> > >> R.E.D. means RESP and ESP charge Derivation. > >> > >> The R.E.D. Tools and R.E.D. Server do not only deal with _RESP_ > >> charges but with _ESP_ charges using various algorithms used in MEP > >> computation. And ESP charges are used in FFs different from AMBER FFs... > >> Then, charge derivation is the first step - charge validation is done > >> in a second step. > >> See http://www.ncbi.nlm.nih.gov/pubmed/20574571 & references cited > herein. > >> > >> This is why we wrote > >> "R.E.D. Server is a web service designed to automatically derive RESP > >> and ESP charges, and to build force field libraries for new > >> molecules/molecular fragments. R.E.D. Server provides to computational > >> biologists involved in AMBER, CHARMM, GLYCAM & OPLS force field based > >> biological studies the software and hardware required for charge > >> derivation and force field library building." > >> > >> regards, Francois > > > >>> Sent to CCL by: "Venable, Richard (NIH/NHLBI) [E]" > >>> [venabler!=!nhlbi.nih.gov] > >>> > >>> Given that RESP/ESP methods are **not** used for the development of > >>> CHARMM force fields (a fragment approach similar to OPLS is used), > >>> the compatibility of molecules with RESP-based charges with the rest > >>> of the CHARMM force fields is somewhat questionable. The use of > >>> other approaches, notably the CHARMM General force field (CGenFF), > >>> is recommended instead of ad hoc web servers for extending the > >>> CHARMM force field to new molecules. > >>> > >>> I did not see anything on the q4md site which discussed this, or > >>> that gave any hints about validation of the molecular descriptions > >>> produced in the context of CHARMM and its distributed force fields.http://www.ccl.net/chemistry/sub_unsub.shtmlhttp://www.ccl.net/spammers.txt> > > -- Jason M. Swails Quantum Theory Project, University of Florida Ph.D. Graduate Student 352-392-4032 --00163645800a739a1204948dbc42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Black and white? I opt for the gray.=A0 Points are valid on both sides.
=
Peace,
Jason

On Mon, Nov 8, 2010 a= t 9:58 AM, Jim Kress ccl_nospam||kresswor= ks.com <owner-chemistry||ccl.net> wrote:

Sent to CCL by: "Jim Kress" [ccl_nospam/./kressworks.com]
Rick is right, you are wrong, get over it and modify your description
appropriately. Otherwise you are going to destroy the credibility of your R.E.D. tools/R.E.D. Server.

Jim Kress

-----Original Message-----
> From: owner-chemistry+ccl_nospam=3D=3Dkressworks.com|-|ccl.net
[mailto:owner-chemistry+ccl= _nospam=3D=3Dkressw= orks.com|-|ccl.net] On= Behalf Of FyD
fyd]=3D[q4md-= forcefieldtools.org
Sent: Monday, November 08, 2010 4:4= 3 AM
To: Kress, Jim
Subject: CCL: Release of R.E.D. Server 2.0


Sent to CCL by: FyD [fyd*|*q4md-forcefieldtools.org]
Dear Rick,

> I'm afraid I still have an issue with the use of the misleading > phrase "force field library" to describe the charge template= s
> produced by the R.E.D. server, at least in the context of CHARMM. =A0A=
> =A0force field is generally regarded as the complete description of > all =A0the parameters for all of the terms in the potential, and not > just =A0charges and connectivity.

We do not claim the R.E.D. tools/R.E.D. Server deal with an entire FF;
but only with RESP and ESP charges embedded in a FF library format
with some specificities.

When one develops a new FF for a new molecule (i.e. charge values +
Lennard-Jones (LJ) parameters + FF parameters), the first step
consists in developing non-bonding (NB) parameters (i.e. charges + LJ
parameters). Then, in a second approach, using the NB parameters
obtained in the first step, one develops FF parameters (i.e. bonding
parameters). I think, this approach is followed by many FF developers
(non-additive FF model).

With the R.E.D. tools, R.E.D. Server & R.E.DD.B. a user is able to
derive/make public RESP and ESP charges embedded in force field (FF)
library(ies); i.e. this corresponds to the work to be carried out at
the beginning of the development of a FF for a new molecule. Once
again, this is in full agreement with the statement we wrote in the
back cover of the 10/2010 issue of PCCP (a reviewer from PCCP suggest
us to write such a sentence) i.e. "Methods and computational tools
useful for charge derivation and force field topology database
building are presented. They give researchers the means to derive
rigorously QM MEP-based charges embedded in force field libraries that
are ready to be used in force field development, charge validation
and/or MD simulations."

You can find a similar idea at the end of the introduction as well:
"More generally, the goal of this work is not to provide a methodology=
for developing atomic charges suitable for any particular MD
condition, but to give the researchers the means to derive rigorously
QM MEP-based charges embedded in force field libraries ready to be
used in force field development, charge validation and/or MD
simulations."

Once again from the literature, ESP charges are used in CHARMM-based
FF simulations (after validation or even sometimes directly used). I
repeat I understand some CHARMM developers do not like this idea.

> Depending on the novelty of the topology, =A0esp. the case where there=
> is no close correspondence to existing LJ =A0types, a considerable
> additional effort would be required.

So? This is FF development... in agreement with what we wrote; nothing
else - nothing more.

> I am not aware of =A0any "script or program" which can relia= bly
> convert a .mol2 file to a complete CHARMM description, a residue
> together with all of the other parameters needed to perform energy
> evaluations in conjunction with the distributed biomolecule force
> fields.

As I already told R.E.DD.B. can handle such programs.
I want to provide links for that. See for instance:
http://q4md-forcefieldtools.org/REDDB/projects/F-60/
=A0For AMBER, a LEaP script:
http://q4md-forcefieldtools.org/REDDB/projects/F-60/scrip= t1.ff
=A0For CHARMM, to come:
http://q4md-forcefieldtools.org/REDDB/projects/F-60/scrip= t2.ff

=A0( To update a project in R.E.DD.B. see:
http://q4md-forcefieldtools.org/REDDB/faq.php#12 )

We do have an approach to convert mol2 file into the CHARMM format.
Still buggy, but we made some progresses: To come.
I agree with you this is an important step for the project.

> In the case of novel functional groups this will fail; =A0further, a > non-trivial amount of high-theory QM calculations would =A0be needed > in order to derive the missing force field parameters, =A0esp. for
> rotatable torsions.

Well, this is force field development. This is the work that has to be done= .
Once again, this is in agreement with what we wrote in the back cover
of the 10/2010 issue of PCCP.

> I don't have an issue with what the server does, just the accuracy=
> of the phrases used to describe what is produced, and the
> trivializing of the amount of effort that would be required to
> produce usable CHARMM topology and parameter files, i.e. a force
> field.

Rick, I would like to underline two points in this discussion:

- To the best of my knowledge, R.E.D. IV is the only program able to
generate an entire FFTopDB for potentially any type of biopolymers in
a single run (we are going to release a major update of R.E.DD.B. with
many new FFTopDBs by now).
See http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.php#2= 3
=A0 =A0 http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.= php#24
=A0 =A0 http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.= php#25
=A0 =A0 http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.= php#26
=A0 & even
=A0 =A0 http://q4md-forcefieldtools.org/Tutorial/Tutorial-3.= php#27 !
This represents a lot of work. I agree with you some pieces of the
whole puzzle might still be missing. All our approach is under the GNU
General Public License by now. This means every researcher is free to
work on it, and develop her/his own tools.

- R.E.D. IV June 2010 incorporates now a statistics module allowing
charge comparison between RESP/ESP/Mulliken/Lowdin; charge comparison
for different conformations & molecular orientations; comparison
between charge values obtained from averaging and from fitting;
finally, charge comparison when building a molecular fragment versus
its whole molecule.
See http://q4md-forcefieldtools.org/REDS/news.php#IV
=A0 & http://q4md-forcefieldtools.org/REDS/popup/popst= atistics.php
An example is at:
=A0 =A0 http://q4md-forcefieldtools.org/REDS/faq.php#1
=A0 =A0 http://q4md-forcefieldtools.org/Tutorial/DNA-FFTop= DB/P1.html
The outputs are still crude, but this is a starting point ;-)
We do believe this represents a first step in charge validation.

regards, Francois



> On 11/6/10 3:50 AM, "Barry Hardy barry.hardy*o*vtxmail.ch"
> <owner-chemistry-,-ccl= .net> wrote:
>
> Sent to CCL by: FyD [fyd:+:q4md-forcefieldtools.org]
> Dear Rick,
>
> The main idea with the R.E.D. program is to generate a force field
> (FF) library format (.mol2 file format) with RESP or ESP charge values=
> for new molecules and for potentially any type of molecular fragments<= br> > (organic, bio-organic & bio-inorganic). Entire Force Field Topolog= y
> DataBase (FFTopDB) can now be directly generated. These FF libraries > are FF atom type independent allowing any user to add the atom types > corresponding to the force field of her/his choice. We believe this > force field library is convenient because it can be directly displayed=
> in many graphical programs. This FF library can also be converted into=
> a more specific FF library format such as the prep/off/rtf/others?
> file formats (using a script based approach or a specific program;
> R.E.DD.B. can handle such scripts/program even for CHARMM).
>
> I think this main idea is also summarized (may be in another way) in > the back cover of the 12/2010 issue of PCCP: "Methods and
> computational tools useful for charge derivation and force field
> topology database building are presented. They give researchers the > means to derive rigorously QM MEP-based charges embedded in force
> field libraries that are ready to be used in force field development,<= br> > charge validation and/or MD simulations."
> All is said here.
>
> More generally, we selected the references 17-20 in our article taking=
> works from well established groups among others. You can find
> different references in the literature where ESP charges are used in > "CHARMM" (after validation/adjustment or even directly used = by users).
> That being said, I understand some CHARMM developers do not like this<= br> > idea.
>
> Please, Rick, download the R.E.D.-III.4 Tools (it is distributed under=
> the GNU General Public License), use it and tell us what you think
> should be improved.
>
> regards, Francois
>
>
> Quoting "Venable, Richard (NIH/NHLBI) E venabler(a)nhlbi.nih.gov"
> <owner-chemistry,+,ccl= .net>:
>
>> Sent to CCL by: "Venable, Richard (NIH/NHLBI) [E]"
[venabler__nhl= bi.nih.gov]
>>
>> I've read through the paper and the two specific CHARMM citati= ons,
>> and have to admit my first response over-assumed a reliance on RES= P
>> charges. =A0However, I am still concerned about the claim to be to=
>> produce complete force field libraries for CHARMM, which I initial= ly
>> =A0interpreted as ready-to-use residues in the proper topology fil= e
>> format, which wasn't the case. =A0I believe a claim of being a= ble to
>> produce entire CHARMM compatible force field libraries should be >> demonstrated much more completely.
>>
>> This quote from the cited paper itself raises question about the >> level of CHARMM and OPLS compatibility:
>>
>> "Indeed, RESP and ESP charge values derived using R.E.D. are = fully
>> compatible with Amber and GLYCAM force fields, (40-47) and can be<= br> >> used in CHARMM and OPLS force field based simulations as well.
>> (17-20)"
>>
>> References 19 and 20 are not really demonstrations of the exact us= e
>> of R.E.D., but use CHELPG for the initial charges, which are furth= er
>> =A0adjusted for CHARMM compatibility.
>>
>> Reading further, it seems the burden of choosing the correct LJ >> types, and thereby the mapping to angle and dihedral terms, is lef= t
>> completely up to the end user, which I see as a major weakness. >> Thus, the type independence may pose a problem, in that novel
>> bonding geometries can be created for which there are no angle and=
>> dihedral parameters during the user mediated atom typing process.<= br> >
>
>> On 11/4/10 10:09 PM, "Barry Hardy barry.hardy*o*vtxmail.ch"
>> <owner-chemistry[#]ccl.net> wrote:
>>
>> Sent to CCL by: FyD [fyd : q4md-forcefieldtools.org]
>>
>> Dear Rick Venable,
>>
>> R.E.D. means RESP and ESP charge Derivation.
>>
>> The R.E.D. Tools and R.E.D. Server do not only deal with _RESP_ >> charges but with _ESP_ charges using various algorithms used in ME= P
>> computation. And ESP charges are used in FFs different from AMBER = FFs...
>> Then, charge derivation is the first step - charge validation is d= one
>> in a second step.
>> See http://www.ncbi.nlm.nih.gov/pubmed/20574571 & reference= s cited
herein.
>>
>> This is why we wrote
>> "R.E.D. Server is a web service designed to automatically der= ive RESP
>> and ESP charges, and to build force field libraries for new
>> molecules/molecular fragments. R.E.D. Server provides to computati= onal
>> biologists involved in AMBER, CHARMM, GLYCAM & OPLS force fiel= d based
>> biological studies the software and hardware required for charge >> derivation and force field library building."
>>
>> regards, Francois
>
>>> Sent to CCL by: "Venable, Richard (NIH/NHLBI) [E]" >>> [venabler!=3D!nhlbi.nih.gov]
>>>
>>> Given that RESP/ESP methods are **not** used for the developme= nt of
>>> CHARMM force fields (a fragment approach similar to OPLS is us= ed),
>>> the compatibility of molecules with RESP-based charges with th= e rest
>>> =A0of the CHARMM force fields is somewhat questionable. =A0The= use of
>>> other approaches, notably the CHARMM General force field (CGen= FF),
>>> is recommended instead of ad hoc web servers for extending the=
>>> CHARMM force field to new molecules.
>>>
>>> I did not see anything on the q4md site which discussed this, = or
>>> that gave any hints about validation of the molecular descript= ions
>>> produced in the context of CHARMM and its distribu= ted force fields.http://www.ccl.net/cgi-bin/ccl/send_ccl_messagehttp://w= ww.ccl.net/chemistry/sub_unsub.shtmlhttp://www.ccl.net/spammers.txt



--
Jason M. Sw= ails
Quantum Theory Project,
University of Florida
Ph.D. Graduate = Student
352-392-4032
--00163645800a739a1204948dbc42-- From owner-chemistry@ccl.net Mon Nov 8 19:01:00 2010 From: "Abdullah Ozkanlar aozkanla(~)purdue.edu" To: CCL Subject: CCL:G: Operation on file out of range. Message-Id: <-43099-101108185855-10441-dMdfNmI/oQl/rLPGlQw1eg,server.ccl.net> X-Original-From: Abdullah Ozkanlar Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 8 Nov 2010 18:58:45 -0500 MIME-Version: 1.0 Sent to CCL by: Abdullah Ozkanlar [aozkanla:-:purdue.edu] Dear all, I am running Gaussian09 to do a natural orbital analysis. Since, natural orbitals are not included in the checkpoint file by default, I am using a a second job step to place the natural orbitals into the checkpoint file: --Link1-- %Chk=name # Guess=(Save,Only,NaturalOrbitals) Geom=AllCheck ChkBasis However, I keep getting the error message: "Operation on file out of range." Does anybody have an idea what may go wrong here? Thanks, -Abdullah -- Abdullah Ozkanlar Purdue University Department of Physics Office: PHYS 289 525 Northwestern Avenue West Lafayette, IN 47907 Phone:(765)496 3274 From owner-chemistry@ccl.net Mon Nov 8 20:32:00 2010 From: "Jamin Krinsky jamink^_^berkeley.edu" To: CCL Subject: CCL:G: Operation on file out of range. Message-Id: <-43100-101108202854-15711-5tHrVfTFXE04V4vaWBcYyQ(a)server.ccl.net> X-Original-From: Jamin Krinsky Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 8 Nov 2010 17:28:29 -0800 MIME-Version: 1.0 Sent to CCL by: Jamin Krinsky [jamink^^^berkeley.edu] Hi Abdullah, I think I remember having the same problem, and that the instructions in the manual do not work. I don't have the program handy to test this but you might try adding the Guess=read keyword, and maybe the Pop=naturalorbitals keyword as well, like: # Guess=(Read,Only,Save,NaturalOrbitals) Pop=NaturalOrbitals Geom=AllCheck ChkBasis Best of luck. Jamin On Mon, Nov 8, 2010 at 3:58 PM, Abdullah Ozkanlar aozkanla(~)purdue.edu wrote: > > Sent to CCL by: Abdullah Ozkanlar [aozkanla:-:purdue.edu] > >  Dear all, > >  I am running Gaussian09 to do a natural orbital analysis. Since, natural > orbitals are not included in the checkpoint file by default, I am using a a > second job step to place the natural orbitals into the checkpoint file: > > --Link1-- > %Chk=name > # Guess=(Save,Only,NaturalOrbitals) Geom=AllCheck ChkBasis > > However, I keep getting the error message: "Operation on file out of range." > Does anybody have an idea what may go wrong here? > Thanks, > > -Abdullah > > > -- > Abdullah Ozkanlar > Purdue University > Department of Physics > Office: PHYS 289 > 525 Northwestern Avenue > West Lafayette, IN 47907 > Phone:(765)496 3274>      http://www.ccl.net/cgi-bin/ccl/send_ccl_message>      http://www.ccl.net/cgi-bin/ccl/send_ccl_message>      http://www.ccl.net/chemistry/sub_unsub.shtml>      http://www.ccl.net/spammers.txt> > > From owner-chemistry@ccl.net Mon Nov 8 21:52:00 2010 From: "Zhou Panwang pwzhou .. gmail.com" To: CCL Subject: CCL: RICC2 Message-Id: <-43101-101108215105-12953-N1zFGk0tagynrHSTbSLdEw#%#server.ccl.net> X-Original-From: Zhou Panwang Content-Type: multipart/alternative; boundary=000e0ce0d684795fcf049495cf4f Date: Tue, 9 Nov 2010 10:50:28 +0800 MIME-Version: 1.0 Sent to CCL by: Zhou Panwang [pwzhou .. gmail.com] --000e0ce0d684795fcf049495cf4f Content-Type: text/plain; charset=ISO-8859-1 Dear All: Is there any other program that can perform RICC2 calculations except Turbomole? -- ======================================== Panwang Zhou State Key Laboratory of Molecular Reaction Dynamics Dalian Institute of Chemical Physics Chinese Academy of Sciences. Tel: 0411-84379195 Fax: 0411-84675584 ======================================== --000e0ce0d684795fcf049495cf4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear All:

Is there any other program that can perform RICC2 calculat= ions except Turbomole?

--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Panwang Zhou
State Key Laboratory of Molecular = Reaction Dynamics
Dalian Institute of Chemical Physics
Chinese Academy of Sciences.
Tel= : 0411-84379195 Fax: 0411-84675584
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

--000e0ce0d684795fcf049495cf4f-- From owner-chemistry@ccl.net Mon Nov 8 22:43:00 2010 From: "Sharan sara180681(0)gmail.com" To: CCL Subject: CCL: low imaginary freq-IR Message-Id: <-43102-101108223818-2528-qux4cyQyhyfP3wfFx46IzA+/-server.ccl.net> X-Original-From: Sharan Content-Type: multipart/alternative; boundary=0015174c3d4e49178404949678b7 Date: Tue, 9 Nov 2010 09:08:10 +0530 MIME-Version: 1.0 Sent to CCL by: Sharan [sara180681-,-gmail.com] --0015174c3d4e49178404949678b7 Content-Type: text/plain; charset=ISO-8859-1 Hi all If your getting low imaginary frequencies, few trick to get rid of imaginary frequencies are 1) try run with very low level theory and basis set and see whether you are able to get rid of imaginary frequencies. 2) try using opt = Tight or opt= VeryTight in low level theory itself. I am sure you can get rid of imaginary frequencies. Now use the coordinates of optimized geometry of low level theory/basis set as input for your level of theory. * because Imaginary frequency means optimization is not complete ( global minimum is not reached). Reaching global minima is heart of computation. Omitting an imaginary frequency means your deleting a bond in the molecule literally and calculating vibrations for rest of the molecule. can this be agreed? with regards saravanan.I 2010/11/2 Chenghua Zhang zchua126.com]^[126.com Hi, > as far as I know, it doesn't matter in the mechanism calculation if there > are some low imaginary*.* > * ref: 1: JCP,1993,98,5648* > * 2: JPCA,2003,107,11445 > * > > -- > Sincerely > Chenghua Zhang > College of Chemistry > Sichuan University, China. > > > > > -- SARAVANAN.I Jr. Scientist Chemoinformatics http://www.linkedin.com/in/saravananilangovan -- SARAVANAN.I Jr. Scientist Chemoinformatics http://www.linkedin.com/in/saravananilangovan --0015174c3d4e49178404949678b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all=A0


If y= our getting low imaginary frequencies, =A0few trick to get rid of imaginary= frequencies are=A0
1) =A0try run with very low level theory and = basis set and see=A0whether you are able to=A0get rid=A0of imaginary freque= ncies.=A0
2) try using opt =3D Tight or opt=3D VeryTight in low level theory its= elf.

I am sure you can get rid of imaginary freque= ncies. Now use the coordinates of optimized geometry of low level=A0theory/= basis set=A0as input for your level of theory.

* because Imaginary=A0frequency=A0means optimization is= not complete ( global minimum is not reached). Reaching global minima is h= eart of computation. Omitting an imaginary=A0frequency=A0means your deletin= g a bond in the molecule literally and calculating vibrations for rest of t= he molecule. can this be agreed?

with regards
saravanan.I

=

2010/11/2 Chenghua Zhang zchua126.com]^[126.com <owner-chemistry|a|ccl.net>= ;

Hi,
=A0as far as I know, it doesn't = matter in the mechanism calculation if there are some=A0low imaginary.
ref: 1: JCP,1993,98,5648<= /b>
= 2: JPCA,2003,107,11445

--
Sincerely
Chenghua Zhang
College of Chemistry
Sichuan University, China.


<= br>



--
SARAVANAN.I
Jr. Scientist= Chemoinformatics

http://www.linkedin.com/in/saravananilangovan



--
SARAVANAN.I
Jr. Scientist Chemoi= nformatics

http://www.linkedin.com/in/saravananilangovan
--0015174c3d4e49178404949678b7--