From owner-chemistry@ccl.net Sun Oct 2 02:53:01 2005 From: "Panida Surawatanawong paninid[-]gmail.com" To: CCL Subject: CCL: Pair excitation by using Molpro Message-Id: <-29458-051002025044-5780-NqlbW7MN85srHBY35BpeTg#%#server.ccl.net> X-Original-From: Panida Surawatanawong Content-Type: multipart/alternative; boundary="----=_Part_7791_4960274.1128232426689" Date: Sat, 1 Oct 2005 22:53:46 -0700 MIME-Version: 1.0 Sent to CCL by: Panida Surawatanawong [paninid]=[gmail.com] ------=_Part_7791_4960274.1128232426689 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear CCL, Recently, I have some problems with calculation MCSCF by adding keyword RESTRICT on Molpro program. I tried to do PEMCSCF for BeH2. From Molpro manual, I think if I put keyword: restrict,-1,-1,orb1,orb2, ..., orbn, the program should omit singly excited configurations in those orbital. However= , after I calculated it, I got the exactly same energy as the one without restrict keyword. The result energies should be different, isn't it? Did I do anything wrong? My input is following. ***,BeH2PE file,2,beh2pe.wfu geometry=3D{ Be; H1,Be,r1; H2,Be,r1,H1,theta; } r1=3D2.52955373 theta=3D180.00 basis=3Dvdz hf; config; wf,6,1,0; orbprint,nvirt=3D3 multi; occ,3,0,0,0,2,0,0,0; core,1,0,0,0,0,0,0,0; wf,6,1,0; restrict,-1,-1,2.1,1.5,3.1,2.5; print,ref Thanks for your help. Best Regards, Panida S. Department of Chemistry, Texas A&M University email: panidasu|,|neo.tamu.edu ------=_Part_7791_4960274.1128232426689 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear CCL,

Recently, I have some problems with calculation MCSCF by adding keyword
RESTRICT on Molpro program. I tried to do PEMCSCF for BeH2. From Molpro
manual, I think if I put keyword: restrict,-1,-1,orb1,orb2, ..., orbn, the<= br> program should omit singly excited configurations in those orbital. However= ,
after I calculated it, I got the exactly same energy as the one without
restrict keyword. The result energies should be different, isn't it? Did I<= br> do anything wrong? My input is following.

***,BeH2PE
file,2,beh2pe.wfu
geometry=3D{
Be;
H1,Be,r1;
H2,Be,r1,H1,theta;
}
r1=3D2.52955373
theta=3D180.00
basis=3Dvdz

hf;
config;
wf,6,1,0;
orbprint,nvirt=3D3

multi;
occ,3,0,0,0,2,0,0,0;
core,1,0,0,0,0,0,0,0;
wf,6,1,0;
restrict,-1,-1,2.1,1.5,3.1,2.5;
print,ref

Thanks for your help.

Best Regards,
Panida S.
Department of Chemistry,
Texas A&M University
email: panidasu|,|neo.tamu.edu ------=_Part_7791_4960274.1128232426689-- From owner-chemistry@ccl.net Sun Oct 2 08:15:00 2005 From: "Eugen Leitl eugen[a]leitl.org" To: CCL Subject: CCL: W:hardware for computational chemistry calculations Message-Id: <-29459-051002081235-21535-MnBHrtrGKrx3ioJ2o5B+3Q(~)server.ccl.net> X-Original-From: Eugen Leitl Content-Disposition: inline Content-Type: text/plain; charset=us-ascii Date: Sun, 2 Oct 2005 14:12:22 +0200 Mime-Version: 1.0 Sent to CCL by: Eugen Leitl [eugen===leitl.org] On Sat, Oct 01, 2005 at 11:48:10PM +0100, John Hearns john.hearns##streamline-computing.com wrote: > I'd say the X2100 is more suited to Monte Carlo 'farm' type > applications, and as you say the beefier 4100 for computational > chemistry applications. It would depend on the kind of scaling required. Embarrassingly parallel application will do fine on farmed low-end hardware. Notice that low end systems can be expanded with dual-cores and 10 GBit Ethernet or InfiniBand and similiar signalling interconnects. > The V20 line was well engineered and reliable, and we have no doubt > these will follow suit. This wasn't Sun's fault actually, as they were reselling Newisys systems. The new systems were designed in-house. -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From owner-chemistry@ccl.net Sun Oct 2 10:21:00 2005 From: "ghomri amina ghomriamina-,-yahoo.fr" To: CCL Subject: CCL: help with Fukui indices Message-Id: <-29460-051002091300-6110-KdzIrYpOt9ShTJchp6vsRw+*+server.ccl.net> X-Original-From: ghomri amina Content-Transfer-Encoding: 8bit Content-Type: multipart/alternative; boundary="0-1360382801-1128255176=:62891" Date: Sun, 2 Oct 2005 14:12:56 +0200 (CEST) MIME-Version: 1.0 Sent to CCL by: ghomri amina [ghomriamina*o*yahoo.fr] --0-1360382801-1128255176=:62891 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Does anyone have information about Fukui indices calculated by taking (∆N=-0.01, 0.01)for pyrrole. thanks amina --------------------------------- Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez le ici ! --0-1360382801-1128255176=:62891 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 
Does anyone have information about Fukui indices calculated by taking (∆N=-0.01, 0.01)for pyrrole.
thanks
 
amina

Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez le ici ! --0-1360382801-1128255176=:62891-- From owner-chemistry@ccl.net Sun Oct 2 14:33:01 2005 From: "Bill Ross ross[*]cgl.ucsf.edu" To: CCL Subject: CCL: W:hardware for computational chemistry calculations Message-Id: <-29461-051002142555-22688-8tapb2MG4bOLGoRdMQXGdQ[*]server.ccl.net> X-Original-From: Bill Ross Date: Sun, 2 Oct 2005 10:49:46 -0700 (PDT) Sent to CCL by: Bill Ross [ross|*|cgl.ucsf.edu] > > I'd say the X2100 is more suited to Monte Carlo 'farm' type > > applications, and as you say the beefier 4100 for computational > > chemistry applications. > > It would depend on the kind of scaling required. Embarrassingly > parallel application will do fine on farmed low-end hardware. > Notice that low end systems can be expanded with dual-cores and > 10 GBit Ethernet or InfiniBand and similiar signalling interconnects. Power requirements and consequent air conditioning needs might tip the equation back toward the 4100 for higher-horsepower systems. Bill Ross From owner-chemistry@ccl.net Sun Oct 2 16:05:00 2005 From: "Ayorinde S Hassan ayo_hassan[#]yahoo.com" To: CCL Subject: CCL: W:help with job termination Message-Id: <-29462-051002160045-14154-ixkCTrP3PoL0qHNzRisrCw::server.ccl.net> X-Original-From: "Ayorinde S Hassan" Sent to CCL by: "Ayorinde S Hassan" [ayo_hassan]|[yahoo.com] I would like some help with a job am running. The job terminates with the following message: "The electronic state of the initial guess is 4-A. of initial guess= 3.7500 Defaulting to unpruned grid for atomic number 66. Gradient too large for Newton-Raphson or scaled steepest descent -- use steepest descent instead. Erroneous write. write 23584 instead of 80000. fd = 5" I would appreciate any help or suggestion . Thanks Ayorinde Hassan ayo_hassan]~[yahoo.com From owner-chemistry@ccl.net Sun Oct 2 16:40:01 2005 From: "Konrad Hinsen khinsen|-|cea.fr" To: CCL Subject: CCL: W:CCL: Cleaning up dusty deck fortran and converting to C/C++ - Wrap up Message-Id: <-29463-051002161150-19950-RCR2Uo1WWt+b0EJ/rSBF5Q|-|server.ccl.net> X-Original-From: "Konrad Hinsen" Sent to CCL by: "Konrad Hinsen" [khinsen _ cea.fr] On 30.09.2005, at 15:24, CCL: Robert Duke wrote: > are hard to ignore. I guess the reason, in the first place, that I jumped > in on this thread was that it was stated that one cannot do more sophisticated > algorithms and data structures in fortran, and I think this is a prejudice that > should not be extended past fortran 77 to fortran 90 and its successors. A At least not 100%. Fortran 90 has much better data structures, but for someone with an OO background it is still not good enough. Which is particularly regrettable considering that when the standard was fixed, the utility of OO concepts was already well established. > system calls for ipc it is a little limited. I guess a good standardized unix > system interface for Fortran would be a good thing, but I have no idea how I'd rather go for a standardized interface to C, because most of these problems already have good C solutions. > on; not on old prejudices against f77 extended forward to f90 et al. Why not > just use C and forget fortran, period? Basically there are 3 issues: 1) the Or do yet something else. There are other languages in the world, and there may be even better ones around the corner. Unfortunately, most of today's computational scientists consider programming tools as given by the outer world. Our professional ancestors were themselves implied in the definition of languages and in the implementation of compilers. We might not want to go back to that situation, but more interaction with language designers and compiler writers can only be beneficial. Language developers have largely turned away from scientific applications, but there are still a few projects around. Sisal was considered dead but there is a faint resurrection attempt: http://sisal.sourceforge.net/ http://www2.cmp.uea.ac.uk/~jrwg/Sisal/ A more recent project is Titanium, a parallel language based on Java: http://titanium.cs.berkeley.edu/ On 30.09.2005, at 16:18, CCL: Perry E. Metzger perry%a%piermont.com wrote: >> Personally, I do most of my array stuff in Python, which has a nice >> array package which also has a nice C interface. Just as a reminder >> that there are more options than just Fortran, C, and C++. > > That's very important to remember. Lots of people kept forcing me to > defend C, but I'm not even that big a fan of C. Me neither. I use it as little as possible, only for the most time-critical parts of my code. > be able to write the code fast than for it to run fast. You can always > write C routines for core math and link them in to your Python code, > too. In particular now that we have Pyrex. > Java and C are also possibilities -- they're VM based so again > they're not as fast as they could be, though with run time > optimization Java has gotten quite acceptably quick for lots of > stuff. I was quite surprised to find on a little test project (atomic-liquid MD) that Java is slower than the C version by only a factor of 2. I was even more surprised that both Sun's and IBM's virtual machines were faster than the native code generated by gcj. But I see little use for Java in my own applications: it has neither the ease of use of Python, nor the speed of C. > I'm also a big fan of Lisp, as I've said. In fact, it is by far my > favorite language, but many people are disturbed by how alien it is so > they never try it. It is amazing the sort of power you get by using > Lisp though. I never got far with Lisp, because my visual system doesn't deal well enough with clusters of parentheses. There is also the problem of too many competing standards and nearly-compatible implementations. Otherwise it is quite appealing, which leads me to... > Some friends of mine are now giant fans of Haskell. Haskell is a > strongly typed functional language in the ML family (i.e. it does type ... Haskell, which I think has most of the strong points of Lisp, plus some of its own. I have some doubts though that the current compilers generate good enough code for numerical applications. I'd also be surprised if computational scientists adopted the functional approach any time soon - it's too far from what they are used to. > Lastly, may I make a pitch for meta-programming? I know one researcher Good point. For many specialized optimizations, this is a good solution. > Writing programs that build programs is something I don't see done a > lot in the CChem world even though it is frequently the case that True. Perhaps the most used package that uses this technique is FFTW, which mostly consists of C code generated by an ML code generator. -- ------------------------------------------------------------------------------- Konrad Hinsen Laboratoire Leon Brillouin (CEA-CNRS), CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen%a%cea.fr ------------------------------------------------------------------------------- From owner-chemistry@ccl.net Sun Oct 2 22:44:01 2005 From: "Richard Casey rcasey!A!rmcbiosciences.com" To: CCL Subject: CCL: W:LACVP Message-Id: <-29464-051002223353-20818-kE6HsFgQB4BnX5brtgHYUA|server.ccl.net> X-Original-From: "Richard Casey" Sent to CCL by: "Richard Casey" [rcasey..rmcbiosciences.com] Hello, Does anyone know where we can find the LACVP basis set? We're interested in modeling Platinum based drug compounds. Regards, Richard Casey RMC Biosciences, Inc. 912 E. Ridgecrest Road Fort Collins, CO 80524 rcasey:-:rmcbiosciences.com www.rmcbiosciences.com tel: 970-224-0456 fax: 970-224-2831 mobile: 970-980-5975