From owner-chemistry@ccl.net Sat Oct 15 10:19:00 2005 From: "andreas orthaber andreas.orthaber!A!uni-graz.at" To: CCL Subject: CCL: W:CCL: TCP connect error Message-Id: <-29618-051015022458-30115-VQttLrr0dOtEK7KQay0ZwQ|,|server.ccl.net> X-Original-From: "andreas orthaber" Sent to CCL by: "andreas orthaber" [andreas.orthaber*uni-graz.at] Hi, This problem looks very similar to a problem i had. You might have to double your hostlist like "node01 node01 node02 node02". could you give me some details about your cluster, compilation details of your gamess. cheers andreas From owner-chemistry@ccl.net Sat Oct 15 13:09:01 2005 From: "Cory Pye cpye^crux.smu.ca" To: CCL Subject: CCL: Where can you publish articles on software? Message-Id: <-29619-051015125906-15231-8AKrr6SREPAtA3AQ+InO6w::server.ccl.net> X-Original-From: Cory Pye Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sat, 15 Oct 2005 13:59:00 -0300 (ADT) MIME-Version: 1.0 Sent to CCL by: Cory Pye [cpye[-]crux.smu.ca] On Fri, 14 Oct 2005, Warren DeLano warren],[delsci.com wrote: > No -- let me clarify -- I do not imply that closed-source is tantamount > to deception. It is simply non-disclosure -- a willful holding back of > pertinent helpful information. It is tantamount to saying "trust me" -- > I have correctly applied chemistry, physics, math, and computer science > to create a working solution to your problem. Every time somebody publishes a paper, there is a matter of trust inherent between the readers, journal, and author. This trust entails, for example, the author declaring "I did not fabricate my data", "I have not already published this work elsewhere", and the editor declaring "This manuscript has undergone a rigorous peer-review process", "I did not let any personal connection with the author influence my views", etc. There is a certain amount of trust inherent in scientific publishing. A (complicated) program is the author's "baby", and it is up to the author as to whether he or she wishes to make it publically available. I don't think that the trust argument is applicable here, as it is an inevitable fact. One difficulty with making a program publically available is it can mutate into a non-viable form by an inexperienced programmer, and if the mutant happens to be widely circulated, then a lot of the blame ends up on the original programmer, who has essentially given up his "baby" for adoption, instead of the modifier. One can easily waste weeks of time addressing irate "customers" because of someone else's goof-up. > > Thorough testing of closed-source code can of course lay an empirical > foundation for extending such trust, and testing is equally necessary > with open-source code. But testing alone is not the same as disclosing > an implementation that can itself be subjected to direct intellectual > scrutiny. > > While there are valid personal, economic, political, legal, practical, > and insitutional reasons for not disclosing source code, I challenge > anyone to come up with a compelling scientific reason for why source > code should not be disclosed -- when possible -- to enable > understanding, reproduction, verification, and extension of > computational advances. Suppose a junior faculty member publishes a paper and publicly releases some code with his first graduate student. The idea becomes so popular that a senior researcher or company takes that open-source code, with acknowledgements, and incorporates it into a popular commercial program, with some modifications and writes 2 or 3 papers describing the advances. Science is advanced. Lots of people use it, but only quote the paper in the manual of the senior researcher. Now suppose that the advances were supposed to be the rest of the graduate student's Ph. D. work. This student cannot re-publish this work because the other ideas have been published already by the borrower. The junior faculty, for lack of sufficient publications, loses his grant, and is denied tenure. The student's thesis, being mostly unpublishable, is not accepted. Has science advanced at the expense of the careers of the two individuals? Are computational chemists a species known for eating their young? :-) Had the junior faculty member not disclosed his source, it would have been more difficult for this hypothetical travesty to happen. The sad reality is that things like this can and do happen and a little paranoia goes a long way. It would have been far better if the company had approached the junior faculty and come to an agreement. In order to be able to do your own science, pragmatics such as having tenure, a grant, etc. have to be looked at first. It is a lot less stressful (and the temptation to cut corners less i.e. thorough testing) to implement a new code, building on some older code, when you don't have someone breathing down your neck trying to outdo you. Writing and debugging code is a lot of effort, and you want to be rewarded for your efforts, either through publications, citations, or financial remuneration. I would like to say for the record that my experience coding the COSMO routine within the ADF package (97-99) has been absolutely wonderful, as I have found SCM to be very cooperative in pointing out my errors and vice versa. I am also grateful to the many users who have been patient when they hit the occasional snag, esp. Heiko Jacobsen and Michael Atanasov. Through dialogue the resulting code was much better. I will certainly celebrate with a bottle of good scotch when I hit 100 citations on the TCA paper describing our implementation either late his year or early next year. > > Is there ever a legitimate *purely scientific* reason for settling with > empirical evidence alone (just test results) when mathematical proof is > itself attainable (via inspection of source code)? I cannot think of > any. > Source code is "not" mathematical proof, just ask anyone who had to use a buggy Fortran compiler, say when the runtime "check array bounds" debugging option, didn't work with a character array. > Or are we all agreed that making source code available is the > *scientific* ideal to which we should all aspire? > > If so, then when we do not make source available, we should certainly > have some compelling non-scientific reason for holding it back, and as > honest scientists, we must realize that doing so will have the effect of > limiting the value and impact of our work -- at least from a scientific > standpoint. Intellectual advances are either shared or lost, and > software implementations are no exception to this. > > Cheers, > Warren > > [stuff deleted] ************* ! Dr. Cory C. Pye ***************** ! Associate Professor *** ** ** ** ! Theoretical and Computational Chemistry ** * **** ! Department of Chemistry, Saint Mary's University ** * * ! 923 Robie Street, Halifax, NS B3H 3C3 ** * * ! cpye]![crux.stmarys.ca http://apwww.stmarys.ca/~cpye *** * * ** ! Ph: (902)-420-5654 FAX:(902)-496-8104 ***************** ! ************* ! Les Hartree-Focks (Apologies to Montreal Canadien Fans) From owner-chemistry@ccl.net Sat Oct 15 15:13:00 2005 From: "Warren DeLano warren**delsci.com" To: CCL Subject: CCL: Where can you publish articles on software? Message-Id: <-29620-051015150930-8654-0T/10aKR91ITypyo7sFl7A=server.ccl.net> X-Original-From: "Warren DeLano" Content-class: urn:content-classes:message Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Oct 2005 12:09:52 -0700 MIME-Version: 1.0 Sent to CCL by: "Warren DeLano" [warren() delsci.com] Dear Cory, Thank you for that response, which includes excellent discussion of the "valid personal, economic, political, legal, practical, and insitutional reasons for not disclosing source code" to which I referred. Releasing source code can very well make it harder for the involved parties to do *more science*, due to distraction, giving up control, lack of proper credit, loss of funding, risk of tenure, and so forth. But also understand that by not releasing source code, you absolutely deny the rest of the scientific community the opportunity of doing *more science* using your source code. Perhaps your TCA paper would now have 1,000 citations had the code been open from the start. Who can say? It depends. Regardless, both sides of the above argument are pragmatic in nature and do not address the question I again pose: If we solely consider the standards of disclosure, verifiability, and reproducibility inherent in the scientific method, is it not the case that sharing source code comes much closer to meeting that ideal than does not sharing source code? And if so, then as good scientists, shouldn't we seek opportunities to advance science through open source scientific code, whenever possible, while fully taking into account pragmatic concerns like those you described? Cheers, Warren PS. Aside... > Source code is "not" mathematical proof, just ask anyone who > had to use a buggy Fortran compiler, say when the runtime > "check array bounds" debugging option, didn't work with a > character array. Source code is a symbolic representation of an information process that has a precise mathematical meaning, subject to the nature of the implementation language. One can indeed prove mathematical equivalence or non-equivalence between an abstract mathematical expression and the mathematical meaning of a given source code implementation. For example, take the expression "F=ma", and the source code implementation "def F(m,a): return m*a". In Python, this implementation is proven to be correct to the precision limits of the double-precision numeric representation. In contrast "def F(m,a): return m+a" is proven to be non-equivalent. In other words, having a broken "+" key on a calculator does not invalidate Addition any more than having a broken Fortran compiler invalidates the mathematical validity of the Fortran program you compile. -- Warren L. DeLano, Ph.D. Principal Scientist . DeLano Scientific LLC . 400 Oyster Point Blvd., Suite 213 . South San Francisco, CA 94080 USA . Biz:(650)-872-0942 Tech:(650)-872-0834 . Fax:(650)-872-0273 Cell:(650)-346-1154 . mailto:warren__delsci.com > -----Original Message----- > From: owner-chemistry__ccl.net [mailto:owner-chemistry__ccl.net] > Sent: Saturday, October 15, 2005 10:36 AM > To: Warren DeLano > Subject: CCL: Where can you publish articles on software? > > > Sent to CCL by: Cory Pye [cpye[-]crux.smu.ca] On Fri, 14 Oct > 2005, Warren DeLano warren],[delsci.com wrote: > > > No -- let me clarify -- I do not imply that closed-source is > > tantamount to deception. It is simply non-disclosure -- a willful > > holding back of pertinent helpful information. It is tantamount to > > saying "trust me" -- I have correctly applied chemistry, physics, > > math, and computer science to create a working solution to > your problem. > > Every time somebody publishes a paper, there is a matter of > trust inherent between the readers, journal, and author. This > trust entails, for example, the author declaring "I did not > fabricate my data", "I have not already published this work > elsewhere", and the editor declaring "This manuscript has > undergone a rigorous peer-review process", "I did not let any > personal connection with the author influence my views", etc. > There is a certain amount of trust inherent in scientific > publishing. A (complicated) program is the author's "baby", > and it is up to the author as to whether he or she wishes to > make it publically available. I don't think that the trust > argument is applicable here, as it is an inevitable fact. > > One difficulty with making a program publically available is > it can mutate into a non-viable form by an inexperienced > programmer, and if the mutant happens to be widely > circulated, then a lot of the blame ends up on the original > programmer, who has essentially given up his "baby" for > adoption, instead of the modifier. One can easily waste weeks > of time addressing irate "customers" > because of someone else's goof-up. > > > > > Thorough testing of closed-source code can of course lay an > empirical > > foundation for extending such trust, and testing is equally > necessary > > with open-source code. But testing alone is not the same as > > disclosing an implementation that can itself be subjected to direct > > intellectual scrutiny. > > > > While there are valid personal, economic, political, legal, > practical, > > and insitutional reasons for not disclosing source code, I > challenge > > anyone to come up with a compelling scientific reason for > why source > > code should not be disclosed -- when possible -- to enable > > understanding, reproduction, verification, and extension of > > computational advances. > > Suppose a junior faculty member publishes a paper and > publicly releases some code with his first graduate student. > The idea becomes so popular that a senior researcher or > company takes that open-source code, with acknowledgements, > and incorporates it into a popular commercial program, with > some modifications and writes 2 or 3 papers describing the > advances. Science is advanced. Lots of people use it, but > only quote the paper in the manual of the senior researcher. > > Now suppose that the advances were supposed to be the rest of > the graduate student's Ph. D. work. This student cannot > re-publish this work because the other ideas have been > published already by the borrower. The junior faculty, for > lack of sufficient publications, loses his grant, and is > denied tenure. > The student's thesis, being mostly unpublishable, is not accepted. > Has science advanced at the expense of the careers of the two > individuals? > Are computational chemists a species known for eating their > young? :-) Had the junior faculty member not disclosed his > source, it would have been more difficult for this > hypothetical travesty to happen. > > The sad reality is that things like this can and do happen > and a little paranoia goes a long way. It would have been far > better if the company had approached the junior faculty and > come to an agreement. > > In order to be able to do your own science, pragmatics such > as having tenure, a grant, etc. have to be looked at first. > It is a lot less stressful (and the temptation to cut corners > less i.e. thorough testing) to implement a new code, building > on some older code, when you don't have someone breathing > down your neck trying to outdo you. Writing and debugging > code is a lot of effort, and you want to be rewarded for your > efforts, either through publications, citations, or financial > remuneration. > > I would like to say for the record that my experience coding > the COSMO routine within the ADF package (97-99) has been > absolutely wonderful, as I have found SCM to be very > cooperative in pointing out my errors and vice versa. I am > also grateful to the many users who have been patient when > they hit the occasional snag, esp. Heiko Jacobsen and Michael > Atanasov. Through dialogue the resulting code was much > better. I will certainly celebrate with a bottle of good > scotch when I hit 100 citations on the TCA paper describing > our implementation either late his year or early next year. > > > > > Is there ever a legitimate *purely scientific* reason for settling > > with empirical evidence alone (just test results) when mathematical > > proof is itself attainable (via inspection of source code)? > I cannot > > think of any. > > > > Source code is "not" mathematical proof, just ask anyone who > had to use a buggy Fortran compiler, say when the runtime > "check array bounds" debugging option, didn't work with a > character array. > > > Or are we all agreed that making source code available is the > > *scientific* ideal to which we should all aspire? > > > > If so, then when we do not make source available, we should > certainly > > have some compelling non-scientific reason for holding it > back, and as > > honest scientists, we must realize that doing so will have > the effect > > of limiting the value and impact of our work -- at least from a > > scientific standpoint. Intellectual advances are either shared or > > lost, and software implementations are no exception to this. > > > > Cheers, > > Warren > > > > [stuff deleted] > > ************* ! Dr. Cory C. Pye > ***************** ! Associate Professor > *** ** ** ** ! Theoretical and Computational Chemistry > ** * **** ! Department of Chemistry, Saint Mary's > University > ** * * ! 923 Robie Street, Halifax, NS B3H 3C3 > ** * * ! cpye .. crux.stmarys.ca > http://apwww.stmarys.ca/~cpye > *** * * ** ! Ph: (902)-420-5654 FAX:(902)-496-8104 > ***************** ! > ************* ! Les Hartree-Focks (Apologies to > Montreal Canadien Fans) > > > > -= This is automatically added to each message by the mailing > script =- To recover the email address of the author of the > message, please change the strange characters on the top line > to the __ sign. You can also look up the X-Original-From: line > in the mail header.> > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > -+-+-+-+-+ > > > > > > > From owner-chemistry@ccl.net Sat Oct 15 15:48:01 2005 From: "Tell Tuttle tell.tuttle*gmx.net" To: CCL Subject: CCL: Cremer & Pople Fortran source Message-Id: <-29621-051015123528-13766-kiEfkebHFd61QOx/G0NPzQ(a)server.ccl.net> X-Original-From: Tell Tuttle Content-transfer-encoding: 7bit Content-type: text/plain; charset="US-ASCII" Date: Sat, 15 Oct 2005 17:32:25 +0200 Mime-version: 1.0 Sent to CCL by: Tell Tuttle [tell.tuttle{=}gmx.net] Dear Rick, The program RING, written by Cremer, can be downloaded from the QCPE. It can do what you need. Regards, Tell ----------------------------------------------- Dr. C. T. Tell Tuttle Max-Planck-Institut fuer Kohlenforschung Kaiser-Wilheim-Platz 1 D-45470, Muelheim an der Ruhr Tel: +49 208 306 2163 E-Mail: tell^^mpi-muelheim.mpg.de Web: http://www.mpi-muelheim.mpg.de/private/tell ------------------------------------------------ On 14/10/05 11:30 PM, "Rick Venable rvenable[*]pollux.cber.nih.gov" wrote: > > Sent to CCL by: Rick Venable [rvenable#,#pollux.cber.nih.gov] > I'm looking for Fortran source code which computes the C+P puckering > parameters for 5- and esp. 6-membered rings; source code or other tips > would be greatly appreciated. > > Regards, > > ------------------------------------- > Rick Venable 29/500 > FDA/CBER/OVRR Biophysics Lab > 1401 Rockville Pike HFM-419 > Rockville, MD 20852-1448 U.S.A. > (301) 496-1905 Rick_Venable AT nih*gov > ALT email: rvenable AT speakeasy*org > ------------------------------------- > www.redcross.org> > > From owner-chemistry@ccl.net Sat Oct 15 20:24:00 2005 From: "Rick Venable rvenable++pollux.cber.nih.gov" To: CCL Subject: CCL: Cremer & Pople Fortran source Message-Id: <-29622-051015175951-8044-yaS/2tjI1lIOl7hYGCP5Qg_+_server.ccl.net> X-Original-From: Rick Venable Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sat, 15 Oct 2005 17:57:13 -0400 MIME-Version: 1.0 Sent to CCL by: Rick Venable [rvenable- -pollux.cber.nih.gov] I should have mentioned-- I checked the QCPE catalog and found that the RING program is apparently no longer available. QCPE Program Number: 288 Program Title: RING: A Coordinate Transformation Program for Evaluating the Degree and Type of Puckering of a Ring Compound Author: D. Cremer Lehrstuhl fur Theoretische Chemie Universite Koln, Koln, FRG Lines of Code: 789 Academic Fee: THIS PROGRAM IS NOT AVAILABLE Commercial Fee: THIS PROGRAM IS NOT AVAILABLE I've gone ahead and written my own implementation based on the original C+P reference and a 1986 paper by Harvey and Prabhakaran. On Sat, 15 Oct 2005, Tell Tuttle tell.tuttle*gmx.net wrote: > The program RING, written by Cremer, can be downloaded from the QCPE. > It can do what you need. > > ----------------------------------------------- > Dr. C. T. Tell Tuttle > Max-Planck-Institut fuer Kohlenforschung > Kaiser-Wilheim-Platz 1 > D-45470, Muelheim an der Ruhr > Tel: +49 208 306 2163 > E-Mail: tell-$-mpi-muelheim.mpg.de > Web: http://www.mpi-muelheim.mpg.de/private/tell > ------------------------------------------------ > On 14/10/05 11:30 PM, "Rick Venable rvenable[*]pollux.cber.nih.gov" > > I'm looking for Fortran source code which computes the C+P puckering > > parameters for 5- and esp. 6-membered rings; source code or other > > tips would be greatly appreciated. ------------------------------------- Rick Venable 29/500 FDA/CBER/OVRR Biophysics Lab 1401 Rockville Pike HFM-419 Rockville, MD 20852-1448 U.S.A. (301) 496-1905 Rick_Venable AT nih*gov ALT email: rvenable AT speakeasy*org ------------------------------------- www.redcross.org From owner-chemistry@ccl.net Sat Oct 15 20:59:01 2005 From: "John McKelvey jmmckel-.-attglobal.net" To: CCL Subject: CCL: Where can you publish articles on software? Message-Id: <-29623-051015155318-11914-3yl3wM0rVlDXmgb6pSbn+w _ server.ccl.net> X-Original-From: John McKelvey Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Date: Sat, 15 Oct 2005 14:50:53 -0500 MIME-Version: 1.0 Sent to CCL by: John McKelvey [jmmckel : attglobal.net] Corey Pye commented: "One difficulty with making a program publically available is it can mutate into a non-viable form by an inexperienced programmer, and if the mutant happens to be widely circulated, then a lot of the blame ends up on the original programmer, who has essentially given up his "baby" for adoption, instead of the modifier. One can easily waste weeks of time addressing irate "customers" because of someone else's goof-up." I believe that this is exactly what happened to one version of Gaussian when someone hacked a d-orbital capability and got it wrong ... John McKelvey From owner-chemistry@ccl.net Sat Oct 15 22:36:00 2005 From: "Perry E. Metzger perry[]piermont.com" To: CCL Subject: CCL: Where can you publish articles on software? Message-Id: <-29624-051015223141-23888-aS9SvV6ofK5rabxRfTBA5w/./server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Oct 2005 22:31:30 -0400 MIME-Version: 1.0 Sent to CCL by: "Perry E. Metzger" [perry*|*piermont.com] "Cory Pye" writes: > One difficulty with making a program publically available is it can > mutate into a non-viable form by an inexperienced programmer, and if > the mutant happens to be widely circulated, then a lot of the blame > ends up on the original programmer, who has essentially given up his > "baby" for adoption, instead of the modifier. One can easily waste > weeks of time addressing irate "customers" because of someone else's > goof-up. I've been writing open source software for something like 15 years now. I've never once had this happen to me or to anyone I know -- not once. > Suppose a junior faculty member publishes a paper and publicly > releases some code with his first graduate student. The idea becomes > so popular that a senior researcher or company takes that > open-source code, with acknowledgements, and incorporates it into a > popular commercial program, with some modifications and writes 2 or > 3 papers describing the advances. Science is advanced. Lots of > people use it, but only quote the paper in the manual of the senior > researcher. > > Now suppose that the advances were supposed to be the rest of the graduate > student's Ph. D. work. This student cannot re-publish this work because the > other ideas have been published already by the borrower. Well, suppose you publish some research and, even without the use of your code, other people make advancements that you wanted to make first just by looking at your work and saying "hey, this is a cool thing to try next". Tough luck for you. That's how science works. Of course, if you aren't silly, you don't mind and it doesn't hurt you. Einstein didn't come up with spacetime -- Minkowski did, looking at Einstein's 1905 papers. Did Einstein then winge "you did that before I could"? No. Did Poincare spend all his time complaining that Einstein was influenced by him and published first? No. As it happens, I've had code I've written incorporated into commercial products that have made other people money and I haven't gotten a nickel. I've had code I've written taken by others, improved and re-released as open source, too. I have no regrets at all and continue to write open source software. My goal when I release something is for it to be used, you see. If no one uses it, it's as useless as writing a symphony no one will ever hear or painting a canvas no one will ever see. Who wants that? > Has science advanced at the expense of the careers of the two individuals? I'm going to be so bold as to say that science doesn't exist to advance people's careers, and that good science isn't done very often by people so obsessed with careerism that they withhold information in the hope of gaining an edge over scientific competitors. I'll go further and say that people obsessed with their careers to this extent don't actually have good ones, either on the level of enjoying them or on the level of getting ahead. Not so paradoxically, doing good work is more important than relentless scheming and gamesmanship. That doesn't mean you should ignore personal advancement, but it does mean that spending all your time being a backbiting bitter schemer doesn't really do as much good as having good ideas and getting them out. If you want to live in a world filled with smart people who withhold information from each other and spend their whole time being cuthroats, become a hedge fund manager instead of a chemist. Most chemists are smart enough to do that for a living, and it pays literally orders of magnitude (no exaggeration) better than chemistry. If your goal is not to live in that sort of world -- if the reason you are in science is because you love science (and if you are in science for any other reason you're probably foolish -- the money sucks and the recognition sucks compared to almost anything else a smart person can do for a living), then feel happy that others have built on your work and build further on it or do something else interesting. The whole point of science is for people to stand on each other's shoulders, not on each other's feet. Long ago in my computer science career I was one of the co-inventors of a computer security protocol that is currently in use by a large fraction of the planet. (It is called "IPSEC" for those that know anything about such things.) Very quickly after I helped create it, other people became far more expert on it than I was and advanced it far past where we started. Am I bitter? Of course not. If you're bitter about stuff like that you're in the wrong field of endeavor. I'm HAPPY. The thing I helped bring into the world grew up and had a life past me. > The sad reality is that things like this can and do happen and a little > paranoia goes a long way. So you claim, but I really think you're presenting a very twisted view of the world. If you really live your life that way, you're going to be bitter all the time instead of productive. >> Is there ever a legitimate *purely scientific* reason for settling with >> empirical evidence alone (just test results) when mathematical proof is >> itself attainable (via inspection of source code)? I cannot think of >> any. > > Source code is "not" mathematical proof, No, but it is just as valuable to show your code to someone as to say what your equipment was, and IMHO just as necessary. By the way, I'll point out that the bioinformatics guys seem to be doing all of this right. They don't seem to spend all their time being paranoid that someone out there might actually USE something they built as intended -- they seem happy when it happens. They've got big public databases filled with useful information, lots of tools anyone can use, they code in high level languages, they aren't insanely secretive, etc. I think they're a good model to follow. Perry