From ccl@www.ccl.net Thu Jun 25 04:00:13 1998 Received: from ccl.net (atlantis.ccl.net [192.148.249.4]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id EAA13289 Thu, 25 Jun 1998 04:00:12 -0400 (EDT) Received: from pandora.cryst.bbk.ac.uk (pandora.cryst.bbk.ac.uk [192.84.212.49]) by ccl.net (8.8.6/8.8.6/OSC 1.1) with ESMTP id EAA24873 for ; Thu, 25 Jun 1998 04:00:11 -0400 (EDT) Received: from localhost (anina01@localhost) by pandora.cryst.bbk.ac.uk (8.8.7/8.8.7) with SMTP id JAA01966; Thu, 25 Jun 1998 09:04:49 +0100 X-Authentication-Warning: pandora.cryst.bbk.ac.uk: anina01 owned process doing -bs Date: Thu, 25 Jun 1998 09:04:49 +0100 (BST) From: Alex Ninaber X-Sender: anina01@pandora.cryst.bbk.ac.uk To: chemistry@ccl.net Subject: Re: Linux -malign-double? In-Reply-To: <199806231953.PAA15506@ccl.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Dave, As far as I know the -mallign-double option has its biggest effect on the pentium-pro/II since that processor has a more complex double pipeline compared to the pentium. I think -mallign-double has to do with the optimization of a certain order of execution, making sure that the double pipeline is optimal used. Alex On Tue, 23 Jun 1998, Dave Close wrote: > > > Dear CCL Users: > Recently I posted a LINUX makefile for installing G94 on a Pentium > running RedHat Linux. Milan Hodoscek wrote me to say that I had > omitted the -malign-double compiler option. In fact I recalled his > posting of this several months ago. When we tried it here there was > hardly any difference in runtime. Milan has written me again to say > this option could make a large difference in run time on a Pentium. > My question is does anyone know about this option? Is it now a default > setting so now it is not important? Or have I done something wrong? > To see what we used go to: > > http://physweb,etsu.edu/c_r_g94_linux.html > > Regards, Dave Close. > > > --- > Administrivia: This message is automatically appended by the mail exploder: > CHEMISTRY@www.ccl.net: Everybody | CHEMISTRY-REQUEST@www.ccl.net: Coordinator > MAILSERV@www.ccl.net: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net 73 > Anon. ftp: www.ccl.net | CHEMISTRY-SEARCH@www.ccl.net -- archive search > Web: http://www.ccl.net/chemistry.html > --- > > From fgonzale@lauca.usach.cl Thu Jun 25 15:06:13 1998 Received: from ralun.usach.cl (ralun.usach.cl [158.170.64.21]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id PAA19771 Thu, 25 Jun 1998 15:06:06 -0400 (EDT) Received: from lauca.usach.cl (lauca.usach.cl [158.170.64.28]) by ralun.usach.cl (8.8.5/8.8.8) with ESMTP id PAA01367 for ; Thu, 25 Jun 1998 15:06:04 -0400 (CST) Received: from lauca.usach.cl (kekule.usach.cl [158.170.16.6]) by lauca.usach.cl (8.6.12/8.6.12) with ESMTP id PAA11511 for ; Thu, 25 Jun 1998 15:15:02 -0400 Message-ID: <35929E6D.6882B256@lauca.usach.cl> Date: Thu, 25 Jun 1998 15:01:01 -0400 From: Danilo Gonzalez Organization: Universidad de Santiago de Chile X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "chemistry@www.ccl.net" Subject: Summary: Solvation Free Energy Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear CCLers, Here is a summary of responses to the question I posted a few weeks ago concerning Solvation Free Energy for organic molecules. I appreciate all of your responses and comments. Thank you very much. Danilo/// My original inquiry was: ******************************************************* Hi all! I´m looking information about solvation free energy of organic molecules. Anybody have any reference or internet site, where I can look these data? Thanks a lot! ******************************************************* RESPONSES 1)*************************************** There is a useful overview with several specific examples at http://www.schrodinger.com/Notes/ntssolv.html Regards, George =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= George Vacek + Schrodinger, Inc. (503) 299-1150 + 121 SW Morrison, Suite 1212 vacek@schrodinger.com + Portland, OR 97204 http://www.schrodinger.com/~vacek/ "Outside of the killings, Washington has one of the lowest crime rates in the country." -- Mayor Marion Barry, Washington, D.C. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2)**************************************** please have a look at Andreas Klamt's papers about his COSMO and COSMO-RS solvation model: J. Andzelm, Chr. Koelmel and A. Klamt, J. Chem. Phys. 103, 1995, 9312 A. Klamt, J. Phys. Chem. 99, 1995, 2224 A. Klamt and G. Scuurmann, J. Chem. Soc., Perkin. Trans. 2, 1993, 799 Recently there appeared another paper by A. Klamt and co-workers, which is published in one of the latest issues of J. Pys. Chem., but I don't have the reference handy Hope that helps Klaus ------------------------------------------- Klaus Stark,PhD Application Scientist Molecular Simulations Ltd. 230/250 The Quorum, Barnwell Road Cambridge CB5 8RE England Phone : 0044-1223-507548 ********** NEW ******************* Mobile : 0044-411-886564 ********** NEW ******************* Fax : 0044-1223-413301 E-Mail : kstark@msicam.co.uk Web Page : http://skanda.msicam.co.uk/~kstark (only for internal use) Catalysis Examples : http://www.msi.com/info/applications 4)************************************************ Hi Danilo, Here are some references I have. Hope they help. 1. "Molecular Interactions in Solution: An Overview of Methods Based on Continuous Distribution of the Solvent", J. Tomasi, M. Persico, Chem. Rev., 1994, 94, 2027-2094 2. "Self-Consisitent Field Calculation of Pauli Repulsion and Dispersion Contributions to the Solvation Free Energy in the Polarizable Continuum Model", C. Amovilli, B. Mennucci, J. Phys. Chem. B, 1997, 101, 1051-1057 3. "A new difinition of cavities for the computation of solvation free energies by the polarizable continuum model", V. Barone, M. Cossi, J. Tomasi, J. Chem. Phys., 107(8), 3210-3220 Regards, Shiang-Tai Lin Center for Molecular and Engineering Thermodynamics Department of Chemical Engineering University of Delaware (O) (302) 831-6857 (H) (302) 368-8388 E-mail: stlin@udel.edu 5) ********************************************** look at the amber home page. 6) ******************************************* Hi Danilo, I recall that Ned Arnett measured solvation free energies as part of a thermodynamic cycle to determine gas phase pKa's back in the late seventies and early eighties. Cheers, Eric -- Eric Martin martine@chiron.com 4560 Horton St., Emeryville, CA 94608 (510)923-3306, FAX (510)923-3360 ******************************************* THANKS! -- Fernando Danilo González Nilo University of Santiago de Chile, Faculty of Chemistry and Biology, Computational Chemistry Lab. Casilla 40, Correo 33, Santiago-CHILE Phone: (562) 681 2575-Anexo:799 ; Fax: (562) 681 2108 URL : http://quimbio.usach.cl/~danilo/ E-mail: fgonzale@lauca.usach.cl =================================================================== From robert@pauli.utmb.edu Fri Jun 26 12:33:47 1998 Received: from nmr.utmb.edu (dggin1.utmb.edu [129.109.73.3]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with SMTP id MAA02295 Fri, 26 Jun 1998 12:33:41 -0400 (EDT) Received: from pauli.utmb.edu (pauli.utmb.edu [129.109.73.25]) by nmr.utmb.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09987 for <@nmr.utmb.edu:CHEMISTRY@www.ccl.net>; Fri, 26 Jun 1998 11:43:08 -0500 Received: (from robert@localhost) by pauli.utmb.edu (980616/Sun/9.16./980616/Sun_Microsystems) id LAA22438 for CHEMISTRY@www.ccl.net; Fri, 26 Jun 1998 11:34:34 -0500 (CDT) From: "Robert Fraczkiewicz" Message-Id: <9806261134.ZM22436@pauli.utmb.edu> Date: Fri, 26 Jun 1998 11:34:33 -0500 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: CHEMISTRY@www.ccl.net Subject: Summary: Uploading PDB files to a CGI script Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Great "thank you" to all who replied to my requests (copies enclosed below) regarding CGI scripts. Duplicate text has been removed for clarity. Robert Fraczkiewicz University of Texas Medical Branch > Dear Netters: > > We would like to start a web service where people would upload atomic > coordinates in PDB format through an HTML form (e.g., by pasting them > to TEXTAREA, or direct upload of a disk file via > tag) and get results back to their browsers. The form and CGI script work > wonderfully as long as the PDB data size stays below ~20000 characters, which > is insufficient for any practical application. Above this number the server > times out without even touching the CGI script. > > Is there a limit on the amount of data a web client can transfer to > a web server through forms? Personally, I don't believe that. I am > sure many of you had faced similar problem. Any hints will be greatly > appreciated and summarized on the list. > > With best regards, > Robert Fraczkiewicz > University of Texas Medical Branch > ----------------------------------------------------------------------------- On Jun 23, 12:02pm, Bruce Luxon wrote: > Subject: Re: CCL:Uploading PDB files to a CGI script > Robert, > > What did you write the cgi-script in? I have some in .c that had this > problem until I explicitly increased the number of chars in the > message array in main. I've never seen a web server-based limit on > transfers - only software imposed limits. > > Bruce > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Bruce A. Luxon, Ph.D > Associate Professor > Sealy Center for Structural Biology > Dept. of Human Biological Chemistry & Genetics > University of Texas Medical Branch > Galveston, TX 77555-1157 > (409)747-6802; Fax (409)747-6850 > http://www.hbcg.utmb.edu/ http://www.nmr.utmb.edu/ > mailto:bruce@nmr.utmb.edu > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >-- End of excerpt from Bruce Luxon ------------------------------------------------------------------------------ On Jun 23, 1:15pm, M Dominic Ryan wrote: > Subject: Web forms > The most reliable for me has been to get the browser to dump a file. You need > to use the multipart form mechanism. I think the textarea mode is limited > by shell args limits. We transfer pretty large files this way. > __ > M. Dominic Ryan (610)-270-6529 SmithKline Beecham Pharmaceuticals > Internet: ryanmd@mms.sbphrd.com King of Prussia, PA >-- End of excerpt from M Dominic Ryan ------------------------------------------------------------------------------ On Jun 23, 12:42pm, TJ O'Donnell wrote: > Subject: RE: your CCL post > Hi Robert- > > There is no inherent limit on the amount of data that > can be sent through forms. Whenever I expect to xfer > a large amount of data, I do it via the > mechanism. I have sucessfully transferred and processed > files as large as several hundred Mbytes this way. > The timeout is your problem, I think. When I xfer > large data files via an INTRAnet, it hardly ever fails. > When I do it over a 28.8 modem, it hardly ever > succeeds - the server times out. It is simply a matter > of making your server more patient. You can configure > this on the server side. How you do it depends on which > server you're using. > -- > tj@eecs.uic.edu > http://www.eecs.uic.edu/~tj >-- End of excerpt from TJ O'Donnell ----------------------------------------------------------------------- On Jun 23, 3:07pm, Jesus Castagnetto wrote: > Subject: Re: CCL:Uploading PDB files to a CGI script > Hello Robert, > > If you are using POST as the method to send the form, in theory > there should not be a hard limit on the size, in practice > the limit is only dependent on the browser/OS combination. > > An alternative that will not suffer from this problem (AFIAK), is > to use the element so the user can send the > file w/o needing to copy/paste the whole thing. You will need to > modify your CGI to handle this. More info on this particular > element can be found in the Netscape reference site. This is a tag > that is understood by Netscape 3.x or higher, and Internet Explorer 4.x > > Good luck. > > ===== > Jesus M. Castagnetto, Ph.D. - jesusmc@scripps.edu > TSRI, Dept. of Molecular Biology |"Activation Energy: The useful > 10550 N. Torrey Pines Rd. MBP326 | quantity of energy available > La Jolla, CA 92037 | in one cup of coffee." > Phone: 619-784-8582 Fax: 619-784-2289 > E-Paper: http://www.ch.ic.ac.uk/ectoc/echet96/papers/003/ > Lab: http://www.scripps.edu/research/metallo/ > MetalloDB: http://metallo.scripps.edu/index.html > Pilot Stuff: http://www.geocities.com/ResearchTriangle/Lab/1059/ > >-- End of excerpt from Jesus Castagnetto ------------------------------------------------------------------------------ On Jun 24, 11:17am, Malcolm Gillies wrote: > > In general, no. I'd suspect network problems causing the HTTP connection > to be prematurely broken. This may be caused or exacerbated by shortcomings > in the TCP/IP implementation on the client and/or server machines. It's > also possible that the TCP timeouts as defined by the operating system > are too short. > > The solution to this problem depends a great deal on which operating system > and web server software you are running. > > I would begin by trying to obtain some more detailed error messages from > the web server -- it may be necessary to reconfigure it to produce more > detailed error logging. > > good luck, > > Malcolm > -- > Malcolm Gillies > PhD student, Computational Medicinal Chemistry > Dept Medicinal Chemistry, Faculty of Pharmacy, > Utrecht University, The Netherlands >-- End of excerpt from Malcolm Gillies --------------------------------------------------------------------- On Jun 24, 2:54am, Paddy Kane wrote: > Subject: Re: CCL:Uploading PDB files to a CGI script > Hi, > > Unfortunately, I don't have an answer to your question, but I would be interested in using the service when you get it running. Please post a message to the CCL mailing list when you are ready to offer this service. > > Kind rgds, > Paddy. > > --- > Paddy Kane > School Of Chemical Sciences > Dublin City University > Glasnevin > Dublin 9 > Ireland. > > E-mail: p_kane@mailcity.com >-- End of excerpt from Paddy Kane --------------------------------------------------------------------------- Later I have realized that the problem is somewhere else. Second posting and replies to it are included below. Special thanks to Malcolm Gillies, a man with genuine curiosity, who contributed his time and effort to solve this puzzle. On Jun 23, 6:27pm, Robert Fraczkiewicz wrote: > Subject: CCL:CCL:Uploading PDB files to a CGI script > > > Dear Netters: > > Thanks to all who replied to my inquiry. In my original posting I have > reported a web server timing out when large files are uploaded via an > HTML form. > > After some wrestling with the script I have figured out that the web > server is basically OK and can accept data of any size. The problem is > with Netscape browsers: server times out because browsers cannot handle > large amounts of data from CGI programs. Let me present an example: > > This simple HTML form will let you upload any readable disk file into > a CGI program: > > > > Simple form > >
> Enter PDB file name:
> >

> > >

> > > > The CGI program I used takes the data and returns it to the browser > as plain text (compile it and replace "your_CGI_script" by the executable > pathname): > > > #include > #include > > main() > { > unsigned long i, n=0; > char *cl; > > printf("Content-type:text/plain\n\n"); > cl=getenv("CONTENT_LENGTH"); > if(cl) n=atoi(cl); > > for(i=0; i putchar('\n'); > fflush(stdout); > } > > > This works fine for small input files. For PDB data the threshold correspond > to about ~300 atom coordinates. Submitting larger file locks the browser > and causes the server to time out. When the "putchar" function is removed > from the "for" loop (i.e., no data are returned to the browser) everything > works fine. Same when the loop is slightly modified to output characters > for "i" below certain threshold (10000 works here). Clearly, there is a > miscommunication between the CGI program and the browser. > > I tried Netscape 3.04 and 4.02 on SGI, Netscape 3.0 on PC and Netscape 4.02 on > Apple Macintosh. All of them show the same symptoms. Is it a bug, or am I doing > something wrong? Any hints will be greatly appreciated and summarized on the > list. > > With best regards, > Robert Fraczkiewicz > University of Texas Medical Branch >-- End of excerpt from Robert Fraczkiewicz ------------------------------------------------------------------------- On Jun 24, 7:47pm, ross@cgl.ucsf.EDU wrote: > Subject: Re: CCL:CCL:Uploading PDB files to a CGI script > What if you did fflush more often? > > Bill Ross >-- End of excerpt from ross@cgl.ucsf.EDU I tried fflush every 1000, 100 and 10 characters to no avail. ---------------------------------------------------------------------------- On Jun 25, 9:26am, Yongxing Liu wrote: > Subject: Re: CCL:CCL:Uploading PDB files to a CGI script > Hi, > > A while ago, I down load a PERL script from the web for uploading files, My > goal is putting a MD analysis program on the web and let people submit their > trajactories and do the analysis. I soon found that it is difficult to > uplaod 1Gig files for the analysis. So I gave up the idea. > > I just simply attatch the script and you may test it on your PDB files. > > By the way, try to look at http://www.doe-mbi.ucla.edu/Services/Verify3D.html, > It seems to me big pdb files works OK to upload to them. Maybe just e-mail > them and ask what they are doing with their uploading. > > Best Wishes, > > Yongxing Liu > > ---------------------------------------------------------------------------- > ---- > #!/usr/bin/perl > # > # File Upload Script Version 4.01 > # Created by Jeff Carnahan jeffc@terminalp.com > # Created on: 4/8/95 Last Modified on: 08/07/96 11:20 > # Scripts Archive: http://www.terminalp.com/scripts/ > # > # Copyright (C) 1996 - Jeffrey D. Carnahan > # Copyright Information Can Be found in the attacted README file. > # > # --------------------------------------------------------------------- > # Program Specific Quickie Notes: > # * Make Sure The First Line Is Pointing To The Correct Location Of Perl. > # * Make Sure This Program is chmodded with the permissions '755'. > # * Make Sure You Have The correct information in @refer. > # > # Version: Time Stamp: History: > # ____________________________________________________________________ > # > # 4.00 08/04/96 23:16 Revision Histroy Now Intact. > # 4.00 08/04/96 23:16 Security hole regarding '../' paths > # fixed. Thanks to: Rus Berrett. Mime > # type error fixed. Thanks to: Bob Stewart. > # 4.01 08/07/96 11:20 Typo fixed in &NoOpen. Thanks to Marco > # Dings. > # > # --------------------------------------------------------------------- > # Configurable Options Follow: > # > $userid = "1003"; > $groupid = "100"; > $url = "http://linus.chem.wesleyan.edu/yliu/upload"; > $path = "/usr3/people/yliu/public_html/upload"; > $overwrite = "1"; > $index_rename = "1"; > $rename_val = "ppp"; > > @refer = ('www.terminalp.com','terminalp.com','207.86.130.85'); > > > # > # End of Configurable Options. > # --------------------------------------------------------------------- > # --------------------------------------------------------------------- > # Don't Modify Anything Past This Line Unless You Know What Your Doing! > # --------------------------------------------------------------------- > # --------------------------------------------------------------------- > # > > &CheckHost; > > $| = 1; # Set This To 1, so Perl doesn't Buffer the Data... =) > > if ($ENV{'REQUEST_METHOD'} eq "POST") { > read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'}); > } elsif ($ENV{'REQUEST_METHOD'} eq "GET") { > $buffer=$ENV{'QUERY_STRING'}; > } > > $buffer =~ /^(.+)\r\n/; > $bound = $1; > @pairs = split(/$bound/, $buffer); > print "Content-type: text/html\n\n"; > > if (@pairs != 4) { > print "Sorry!"; > print "

Sorry.

"; > print "

Sorry, your browser doesn't support the HTML 3.0 codes needed > to upload files."; > print " Please try again with a browser that supports these functions, > (Such as print > "http://home.netscape.com/comprod/products/navigator/version_2.0/index.html\ > ">Netscape 2.0.)\n"; > print "\n"; > exit; > } > > > $agent = $ENV{'HTTP_USER_AGENT'}; > @var = split(/\r\n/,$pairs[1]); > $filename = $var[3]; > if (($filename !~ /[A-Za-z_\-0-9\.]/) || ($filename =~ /\.\./)) { > print "Sorry! BGCOLOR=\"\#FFFFFF\">"; > print "

Sorry.

"; > print "

Sorry, the file you want to upload contains illegal > characters. Please only use characters that include any combinations of > letters, underscores (_), hyphens, numbers, or periods."; > print "
Please select another filename and try again.\n"; > print "\n"; > exit; > } > if ($index_rename) { > $filename =~ s/index.html/$rename_val/g; > } > > if ($pairs[2] =~ /Content-Type:/) { # includes a MIME definition > $pairs[2] =~ s/^\r\n.+filename.+[^\w\.\%-]([\w\.\%-]+)"\r\n(.*\r\n)\r\n//; > $pairs[2] =~ s/\r\n$//; > } else { > @var = split(/\r\n/,$pairs[2]); > $pairs[2] = $var[3]; > } > > if ($overwrite) { > open (OUTPUT, "> $path/$filename" ) || die &NoOpen($!); > print OUTPUT $pairs[2]; > close (OUTPUT); > chmod (0644, "$path/$filename"); > chown ($userid, $groupid, $file); > } else { > if (-e "$path/$filename") { > print "Sorry! BGCOLOR=\"#FFFFFF\">"; > print "

Sorry.

"; > print "

Sorry, the file you want to write to is already in use, > and you are not allowed to overwrite it."; > print " Please select another filename and try again.\n"; > print "\n"; > exit; > } else { > open (OUTPUT, "> $path/$filename" ) || die &NoOpen($!); > print OUTPUT $pairs[2]; > close (OUTPUT); > chmod (0644, "$path/$filename"); > chown ($userid, $groupid, $file); > } > } > > > > print "Thanks!"; > print "

Thanks!

\n"; > print "

Thanks for uploading the file: $filename. It is now known under > the URL of: print "$url/$filename\">$url/$filename. If you would like to upload > another file, click print "$ENV{'HTTP_REFERER'}\">here to return to the previous page.\n"; > print "

\n"; > print "
href=\"http://www.terminalp.com/scripts/\">Obtain This Script - href=\"mailto:jeffc\@terminalp.com\">jeffc\@terminalp.com
 >\n"; > print "\n"; > > > sub NoOpen { > print "Error!! BGCOLOR=\"#FFFFFF\">\n"; > print "

Error!

\n"; > print "

There was an error: 

@_[0]
\n"; > print "
Please make sure that the directory the file should be > written to, $path, has been chmodded with the premissions 777.\n"; > print "
Or, if you are trying to overwrite a existing file, check to > see that the existing file has been chmodded with the premissions > 666.\n"; > print "

\n"; > print "
href=\"http://www.terminalp.com/scripts/\">Obtain This Script - href=\"mailto:jeffc\@terminalp.com\">jeffc\@terminalp.com
 >\n"; > print "\n"; > } > > > sub CheckHost { > if ($ENV{'HTTP_REFERER'}) { > foreach (@refer) { > if ($ENV{'HTTP_REFERER'} =~ /$_/i) { > $ok = 1; > last; > } } > } else { # If There isn't a refering URL, then we'll assume it's ok. > $ok = 1; > } > if ($ok) { # It Checked, We Can Continue > } else { # Nope... Someone's trying to hack their way in. > print "Content-type: text/html\n\n"; > print "Sorry! BGCOLOR=\"#FFFFFF\">"; > print "

Sorry.

\n"; > print "

Sorry, you are not allowed to post information to this > server from print "$ENV{'HTTP_REFERER'}\">$ENV{'HTTP_REFERER'}. Please Use > a document that is already"; > print " on this server to upload a file.\n"; > print "\n"; > exit; > } > } > >-- End of excerpt from Yongxing Liu ------------------------------------------------------------------------------ On Jun 25, 4:07pm, Malcolm Gillies wrote: > Subject: Re: CCL:CCL:Uploading PDB files to a CGI script > Dear Robert, > > It looks like a buffering problem to me. > > While I reproduced your problem using the HTML and C included in > your post on the setup here (Irix 6.2/NCSA httpd 1.5.2/Netscape 3.04), > when I used the C code included below, it works fine. > > The difference is that I read and buffer all input before writing > to stdout. Not quite sure why this prevents what looks like a dead-lock. > > #include > #include > > main() > { > unsigned long i, n=0; > char *cl, *buf; > int c; > > printf("Content-type:text/plain\n"); > cl=getenv("CONTENT_LENGTH"); > if(cl) { > n=atoi(cl); > printf("Content-length:%d\n",n); > printf("\n"); > > if(buf = malloc(n)) { > fread (buf, n, 1, stdin); > fwrite (buf, n, 1, stdout); > } else > printf("Out of memory\n"); > } else { > printf("\n"); > printf("I'm not playing with you!\n"); > } > > fflush(stdout); > } > > cheers, > > Malcolm >-- End of excerpt from Malcolm Gillies ----------------------------------------------------------------------------- On Jun 25, 6:56pm, Malcolm Gillies wrote: > Subject: Re: CCL:CCL:Uploading PDB files to a CGI script > > You are right: buffering all input into a memory chunk created > > by program prevents the deadlock. It works fine on my system. > > I am going to submit a bug report to Netscape. > > Have you checked any other browsers? > > I suspect that it's the cgi that's deadlocking, and that it's > buffering in the httpd which is causing it. But that's just a guess. > I can't find any relevant info via Altavista or Dejanews. > > cheers, > > Malcolm >-- End of excerpt from Malcolm Gillies ------------------------------------------------------------------------ On Jun 25, 7:08pm, Malcolm Gillies wrote: > Subject: Re: CCL:CCL:Uploading PDB files to a CGI script > Robert, > > >> Have you checked any other browsers? > > > > Yes. I tried Netscape browsers: 3.04, 4.02 and 4.05 for SGI IRIX, > > 4.02 for Macintosh and 3.0 for Windows'95. Besides, I use different > > server than you: Netscape Commerce httpd and stil reproduce this bug. > > I have just submitted the bug report. > > I'm still suspicious that it's a pathological case inhererent in the > CGI interface, rather than an actual bug. If I can organise it, I might > try testing your original code against MS IE. > > But I should probably just take it easy ;-) > > >> I suspect that it's the cgi that's deadlocking, and that it's > >> buffering in the httpd which is causing it. But that's just a guess. > >> I can't find any relevant info via Altavista or Dejanews. > > cheers, > > Malcolm >-- End of excerpt from Malcolm Gillies ------------------------------------------------------------------- Since this problem was always reproducible irregardless of the version number of Netscape browsers and was also confirmed by other users with different HTTP server, I have submitted a bug report to Netscape.com. I will post their answer as soon as I hear from them. Robert Fraczkiewicz From val@acdlabs.com Fri Jun 26 19:25:43 1998 Received: from toronto.acdlabs.com (root@toronto.acdlabs.com [207.176.233.2]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id TAA06691 Fri, 26 Jun 1998 19:25:43 -0400 (EDT) Received: from val (val.acdlabs.com [207.176.233.28]) by toronto.acdlabs.com (8.8.5/8.7.3) with SMTP id TAA19521 for ; Fri, 26 Jun 1998 19:25:49 -0400 (EDT) Message-ID: <01e501bda159$bf9f95b0$1ce9b0cf@val.acdlabs.com> From: "Val Kulkov" To: Subject: Programming language for ChemSketch 3.5 freeware Date: Fri, 26 Jun 1998 19:25:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Dear CCLers, Advanced Chemistry Development announces a competition for the best application written in ChemBasic, a free programming language for ChemSketch 3.5. Top prize is $1500 worth of software. Both ChemSketch and ChemBasic are available for free at http://www.acdlabs.com/download/ The ChemBasic language, which is integrated with ACD/ChemSketch chemistry drawing software, is intended to be a tool for (i) manipulating chemical structures, both 2D- and 3D; (ii) customizing ACD/Labs software, through direct access to its embedded functionality; (iii) developing add-ons to ACD/Labs chemistry software. The ChemBasic language itself is a mixture of good old BASIC with thoroughly integrated chemistry and drawing objects (e.g., Assembly, Conformation, Molecule, Structure, ...). For more information, visit http://www.acdlabs.com/chembasic/ The ACD/ChemBasic competition has begun! Contest rules are at: http://www.acdlabs.com/chembasic/basic3.html -- ************************************************************** Val Kulkov val@acdlabs.com Phone +1(416)368-3435 Fax +1(416)368-5596 Visit ACD/ILab at http://www.acdlabs.com/ilab/ Advanced Chemistry Development, Inc. 133 Richmond St, Suite 605, Toronto, Ontario M5H 2L3, CANADA From mn1@helix.nih.gov Fri Jun 26 20:19:48 1998 Received: from helix.nih.gov (helix.nih.gov [128.231.2.3]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id UAA07903 Fri, 26 Jun 1998 20:19:48 -0400 (EDT) Received: (from mn1@localhost) by helix.nih.gov (8.8.5/8.8.5) id UAA25588; Fri, 26 Jun 1998 20:19:48 -0400 (EDT) Date: Fri, 26 Jun 1998 20:19:48 -0400 (EDT) From: "M. Nicklaus" Message-Id: <199806270019.UAA25588@helix.nih.gov> To: CHEMISTRY@www.ccl.net Subject: SUMMARY: DFT B3LYP/6-31+G(d,p) Convergence Problem Dear CCL'ers, This is the summary of the responses (slightly edited for brevity) I received to my question. The stepwise approach of going to successively higher basis sets, suggested by several people, worked just fine. Thanks to all who responded. Marc ================= Original Question (Tue, 9 Jun 1998) ================= After optimizing a structure (60 atoms, 37 non-H) at the HF/3-21G* level, I'm trying to calculate a DFT single point energy at the B3LYP/6-31+G(d,p) level, reading geometry and initial wave function from the checkpoint file. After nearly seven days (!) of CPU time on a very fast machine, the job aborts without having converged, with the following end of the output file: [snip] >>>>>>>>>> Convergence criterion not met. SCF Done: E(RB+HF-LYP) = -34352969.2846 A.U. after 65 cycles Convg = 0.1924D-03 -V/T = ******* S**2 = 0.0000 Convergence failure -- run terminated. Error termination via Lnk1e in /sbin/loader. Job cpu time: 6 days 21 hours 27 minutes 49.9 seconds. File lengths (MBytes): RWF= 539 Int= 0 D2E= 0 Chk= 30 Scr= 1 Any hints? TIA ============================== Responses ============================== From: Matt Challacombe T-12 It's hard to know exactly what is happening, but you may have instabilities from the "single point" cutoffs. This can cause small but serious electron leakages, as can a cheasy grid. I think you should tighten up your integrals, and try again with a more verbose output. Out of curriosity, what kind of system is it? ----------------------------------------------------------------------- From: Han Zuilhof This frequently has happened to me as well, and a good work-around is usually the following: go from HF/3-21G* to B3LYP/3-21G* (just single point), then to B3LYP/6-31G(d,p) (just single point again), and only finally to B3LYP/6-31+G(d,p). Use geom=check & guess=read in every step, and the same checkpoint-file. I.e. a job like (for a neutral singlet system): %chk=marc %mem=6000000 #p b3lyp/3-21G* geom=check guess=read marc's structure 0,1 --link1-- %chk=marc %mem=6000000 #p b3lyp/6-31G(d,p) geom=check guess=read marc's structure 0,1 --link1-- %chk=marc %mem=6000000 #p b3lyp/6-31+G(d,p) geom=check guess=read scf=tight marc's structure 0,1 An approach like this worked in nearly all of my b3lyp/6-31+G(d,p) jobs! ----------------------------------------------------------------------- From: Serguei Patchkovskii Try to run it with SCF=(NOVARACC,NOINCFOCK,TIGHT), and do NOT use GUESS=READ. Incidentally, your "very fast machine" is either not very fast indeed, or heavily loaded. A 90MHz R8k PowerChallenge (which is reasonably fast, but not the hottest machine out there by a very long shot) can do single-point B3LYP/6-311G** calculation on a molecule with *120* carbon atoms in under a week. ----------------------------------------------------------------------- From: Georg Schreckenbach well, I guess everybody who tried to do metal systems with Gaussian has seen that kind of convergence failure, at least I find it all the time. It is, indeed, pretty annoying, and for such a large calculation in particular. Here are a few things that may help. 1) The reason DFT is generally harder to converge than HF is that the HOMO-LUMO gaps are larger (too large) in HF. Further, larger basis sets with diffuse functions are often harder to converge than smaller ones. In fact, this convergence failure is not all that surprising from my experience. 2) Typically, I do, for metal systems that are hard to converge, a stepwise procedure of "building the guess". It goes somehow like this. a) Single point HF calculation at a small basis set level. You have done that already. b) Feed in the resulting wavefunction (guess=read in G94) into a single point DFT (e.g., B3LYP) calculation at the same basis set level. c) Use this result as input for a somewhat higher basis set (e.g., 6-31G or 6-31G*) ... d) ... continue like that with successive single point calculations until you reach the desired level of basis sets. 3) Further, I do, at a given level of basis set, two single point calculations each: first with level shifting (e.g., Vshift=500), and second without, again feeding the results of one calculation into the next one. Whether all of this is necessary -- or feasible! -- for your system, I don't know. It works, however, pretty well for a lot of different molecules. ----------------------------------------------------------------------- From: "Steven . Trohalaki MLPJ LAI" marc - i had a similar problem but my molecule had a Ni atom. still, the solution to your problem may be the same. doug fox said that the problem was a poor initial guess and suggested that i use the wavefunction from an HF run. i'll append his original reply to me below. steve t One problem relates to the fact that Gaussian needs a better initial guess generator for metals. This is in the works but will not be in G94. The other problem can be independent of initial guess, there are a large number of potential low lying states for metal systems. If you look at the SCF the energy is oscillating wildly which indicates to me that simply letting it iterate will not solve things and a better initial guess is required. First, move down to a single point with a smaller basis. STO-3G or more likely 3-21G. LANL1MB is an ECP option. These have fewer degrees of freedom and so even a poor guess will converge. Use POP=REG on this so you can see the valence region and you can look for either virtuals with negative energies or positive occupied, often signs that GUESS=(READ,ALTER) might shift to a lower energy. STABLE=OPT can be helpful but this requires a fully converged SCF to begin with and even with the smaller basis you might not get this. Then use GUESS=READ with the bigger basis set. Second, you might try using HF to generate the initial guess. The definition of the valence space is often quite different and cases where SCF converges DFT does not. Then use B3LYP GUESS=READ SCF=TIGHT and see if you can get full convergence before launching the optimization. You might also try SCF=QC at this point since the initial guess is fairly close. Third, if you still have problems try running the dication. This overbinds the remaining electrons and can give you a well defined set of core orbitals and with POP=REG followed by GUESS=(READ,ALTER) you can pick the most likely orbital for the remaining two electrons. There is no magic formula and if there is no dominant single configuration you might continue to have problems. You might need to consider a UHF singlet using GUESS=(READ,MIX) to break the spin symmetry which is what STABLE=OPT may end up doing in a more formally correct form. ----------------------------------------------------------------------- From: Krzysztof Radacki First - it's error termineted because in 65 steps it couldn't find minima. Second - I would presume that difference between 631+** and 321* is big so you have not a very nice starting point for your b3lyp. Third - 631+** it's REALY high level. I did some opt. with 7 atoms from second period (3* methyl group) on 631++** and it takes TIME. Fourth - fast computer is relative ;) for me at home double-PII 300MHz (ca. 300-400MFlops) would be very fast (I haven't it) on uni Challenge M with R8000 processor is slow. :( Practicaly. I would sugest some medium level of complication. I never made 321* with b3lyp but maybe it can help (or 631* if not) ----------------------------------------------------------------------- From: Timothy Dransfield I'm afraid I don't have a very good answer for *why* this works, and it's not a particularly satisfying solution, but you can use SCF=QC for those points where convergence is a problem. I see this at long range, or in extended bonds, myself. Alas, SCF=QC makes the job take an order of magnitude longer, so I'm hoping someone provides you with a better workaround. Please let me know if they do!! ----------------------------------------------------------------------- From: "Oscar N. Ventura" I have found the same problem in the study of transition metal complexes. My workaround has been to use a smaller basis set. I employ normally a B3LYP/3-21G* calculation after the HF one. I later perform the B3LYP/6-311+G(2d,p) calculation or similar employing the GUESS=CHECK option, so that the calculation starts from the converged B3LYP/3-21G* density. The only caveat is that sometimes I have found that the B3LYP/3-21G* calculation can converge to a different state of that I am interested in. Just check the output. ----------------------------------------------------------------------- From: Peter Sturm Gaussian gives some hints about failed SCF convergence in its "Gaussian94 User's Reference" in Chapter 4, p. 162 under "Problem Convergence Cases" If you haven't this Manual, just look at http://www.gaussian.com/g94.htm under "Using Gaussian 94 Efficiently" - "SCF Energies and Gradients" or directly at http://www.gaussian.com/00000029.htm There you can find the right part of the online manual. The entry "PROBLEM CONVERGENCE CASES" is identical to the text of the User's Reference. Perhaps you will find there a solution to your SCF convergence problem, but trying out can be very time expensive! ----------------------------------------------------------------------- From: Frank Jensen Try adding some level shift (vshift=xxx) ----------------------------------------------------------------------- From: German Sastre Navarro it seems the initial guess from your previous calc is really far from being good. you can either try to: 1./ increase the maximum scf cycles with: SCF+(MAXCYC=100) (i guess your default is 65) 2./ try to re-run the calc without reading the scf from the previous calc I was anyway very surprised for this to take 6 days. May be you can speed it up with a bit more physycal memory. You can also try to run the calc with a less severe convergence criteria such as: SCF=(conver=5) sets conversion to 10^-5 SCF=sleazy reduce cutoffs for integrals otherwise you may end up with another 6-days run ----------------------------------------------------------------------- From: Tapas Kar It is sometime worth to use #P in the 1st line of com file to get more info on energies in each step. This gives an idea about the oscillating pattern of energies. Normally we use vshift if energy is oscillating. Try with more scf cycles, IOP(5/7=n), n is the no. of cycles you want. SCF=QC is another option but it takes huge CPU time. You can restart the SCF from checkpoint file with vshift and increased number of scf steps. ( some cases i used 150 or even more number of cycles ) ----------------------------------------------------------------------- From: Thomas Dargel in my experience, I would say Tapas is partially not right: >You can restart the SCF from checkpoint file with vshift and increased >number of scf steps. ( some cases i used 150 or even >more number of cycles ) You could only restart and use the new produced and unconverged wafe function if you plug iop(5/13=1) in the route card. This forces G94 to handle the unconverged SCF calculation not as an error, and writes the gues back to checkpoint. So, you can do several singlepoint calculations, which read in the guess from before. This works really good for me if I have had a problem with convergence in SCF for molecules containing transition metals. E.g.: %mem=... %chk=/home/marc/dG-C8-FAAF_01-711_75.49.chk #p B3LYP 6-31+G(d,p) SP scf=(nosp) scfcyc=25 Title 0 1 geometry --link1-- %mem=... %chk=/home/marc/dG-C8-FAAF_01-711_75.49.chk #p B3LYP 6-31+G(d,p) SP scf=(nosp) scfcyc=25 geom=check guess=check Title 0 1 --link1-- . . . . scfcyc=25, because I think the SCF also converges better using the re-calculated integrals. It is better than running one job with 200 or more SCF cycles. ----------------------------------------------------------------------- From: Bill Glauser We came across your recent posting about the convergence problem encountered while attempting a single point DFT calculation. The Jaguar ab initio/DFT program that we develop and market is significantly faster and more robust than other programs - especially for large systems. It therefore occurred to us that Jaguar might be able to handle this case. ======================================================================= ------------------------------------------------------------------------ Marc C. Nicklaus National Institutes of Health E-mail: mn1@helix.nih.gov Bldg 37, Rm 5B29 Phone: (301) 402-3111 37 Convent Dr, MSC 4255 Fax: (301) 496-5839 BETHESDA, MD 20892-4255 USA http://rex.nci.nih.gov/RESEARCH/basic/medchem/mcnbio.htm Laboratory of Medicinal Chemistry, National Cancer Institute, & Center for Molecular Modeling, Ctr. for Information Technology, NIH ------------------------------------------------------------------------ From yliu@mail.wesleyan.edu Sat Jun 27 21:00:25 1998 Received: from mail.wesleyan.edu (dns.wesleyan.edu [129.133.12.10]) by www.ccl.net (8.8.3/8.8.6/OSC/CCL 1.0) with ESMTP id VAA16771 Sat, 27 Jun 1998 21:00:24 -0400 (EDT) Received: from dkombo.wesleyan.edu (jellyfish.chem.wesleyan.edu [129.133.20.75]) by mail.wesleyan.edu (8.8.6/8.7.3) with SMTP id VAA17762 for ; Sat, 27 Jun 1998 21:00:24 -0400 (EDT) Date: Sat, 27 Jun 1998 21:00:24 -0400 (EDT) Message-Id: <199806280100.VAA17762@mail.wesleyan.edu> X-Sender: yliu@wesleyan.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: chemistry@www.ccl.net From: Yongxing Liu Subject: Programs that can perform MD only in torsional space Dear Friends, This is a repost message because of a local network failure. Those who recieved this messagse on Friday please just discard it. I have not recieve any response yet, those who have answered this question please forward a copy to me. I want to know if there exists one program that can perform Molecular Dynamics Simulation only in torsional space. I also want to know related algorithms and the degree of difficulty to implement such a program compared with normal Cartesian MD programs. I know some programs can do this by restrain bond length and bond angles, but this will have extra cost. Please correct me if I am wrong. Thank you very much in advance. Sincerely, Yongxing Liu