From owner-chemistry@ccl.net Wed Oct 19 02:10:01 2005 From: "Joseph Han jhh3851]_[yahoo.com" To: CCL Subject: CCL: Compiling Gaussian on EM64T machines Message-Id: <-29651-051018232236-21267-QhgOWzbkhsGzNuVJOPltqw#server.ccl.net> X-Original-From: Joseph Han Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Tue, 18 Oct 2005 20:22:25 -0700 (PDT) MIME-Version: 1.0 Sent to CCL by: Joseph Han [jhh3851- -yahoo.com] IIRC, the error has to do with the cachesize script in $g03root/bsd/. The output from /proc/cpuinfo is not compatible with the assumptions used to write the script. $g03root/bsd/cachesize is called from $g03root/bsd/set-mflags which is in turn called from $g03/bsd/g03.login Joseph --- "Grant Hill jgh105 _ york.ac.uk" wrote: > > Sent to CCL by: Grant Hill [jgh105_._york.ac.uk] > Hi all, > > I'm trying to compile Gaussian 03 (Rev C01) on a machine with dual EM64T > intel Xeon cpus, running SuSE linux 9.3 (64-bit version, with all current > updates applied). When I source the the g03.login script I get errors of > the type: > > -#-: Badly formed number. > > When I launch the build process I get similar errors throughout the log > file suggesting to me that the shell (or perhaps automake / something > similar) is having trouble. The errors are of the type: > > ./bsd/updatelink1 ../bsd/g03.make JUNK1=JUNK DO-LIB abt1dt.F > -#-: Badly formed number. > -f: Command not found. > ar: No match. > rm: No match. > set noglob > end > > Is this something particular to the building of g03 on EM64T systems, or is > it perhaps something more sinister going on with my distro? FWIW, I've > tried with both the pgf compiler and intels compiler. > > Any tips or ideas will be much appreciated (I'll summarise anything useful > that comes off list). > > Thanks in advance, > > Grant Hill> > > > From owner-chemistry@ccl.net Wed Oct 19 03:30:00 2005 From: "David Cornil cornildavid- -yahoo.fr" To: CCL Subject: CCL: W:keyword_FIELD_for_AMPAC Message-Id: <-29652-051019032716-10554-mtFPxK2BtqZhSIRTJ5gzpQ||server.ccl.net> X-Original-From: "David Cornil" Sent to CCL by: "David Cornil" [cornildavid(~)yahoo.fr] I'm trying to use the keyword FIELD for a AMPAC file but I have some problems with that. Can anybody explain to me how use the keyword ? Any ansewers will be greatly appreciate David cornildavid|a|yahoo.fr From owner-chemistry@ccl.net Wed Oct 19 05:07:01 2005 From: "andras.borosy+*+givaudan.com" To: CCL Subject: CCL: constrained geometry optmisation of molecular complexes Message-Id: <-29653-051019050439-20727-gJKokDZHWSap5rm98+rrIw;;server.ccl.net> X-Original-From: andras.borosy%givaudan.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Date: Wed, 19 Oct 2005 11:04:03 +0200 MIME-Version: 1.0 Sent to CCL by: andras.borosy|,|givaudan.com Dear James, You may try semi-empirical methods as this has been done in the following articles: Timothy J. Giese, Edward C. Sherer, Christopher J. Cramer, and Darrin M. York, A Semiempirical Quantum Model for Hydrogen-Bonded Nucleic Acid Base Pairs, J. Chem. Theory Comput. (published in web in September 2005). E. NIKITINA, V. SULIMOV, V. ZAYETS, N. ZAITSEVA, International Journal of Quantum Chemistry, Vol 97, 747–763 (2004). Best wishes, Dr. András Borosy Seniour Scientist Delivery Systems, Fragrance Research Givaudan Schweiz AG Ueberlandstr. 138 8600 Dübendorf Switzerland tel: + 41-1-8242164 fax: +41-1-8242926 e-mail: andras.borosy-#-givaudan.com owner-chemistry-#-ccl.net wrote on 10.10.2005 19:54:09: > > Sent to CCL by: Andreas Serr [serr/a\theorie.physik.uni-muenchen.de] > Dear James, > > sorry I cannot answer your questions, but I would like to make a > short comment on > > > So far as I understand, HF > > methods, semi-empirical methods and most DFT functionals will not > > describe van-der-Waals forces (responsible for a good part of the > > non-binding interaction?) correctly. > > A standard HF or DFT calculation *does* incorporate Keesom and Debye > interactions (dipole-dipole, dipole-induced dipole) -- it will simply be > reflected in charge re-distributions of the molecules. > > You are right that they do *not* account for London (dispersion) interaction > (induced dipole-induced dipole). > > Depending on your system (mainly: magnitude of static dipole) either Keesom, > Debye or London interact. may dominate van-der-Waals forces. > > Sorry again, if it does not help for your question. > > Regards, > Andreas > > > Andreas Serr > > Biological Soft-Matter Theory > Sektion Physik - Ludwig-Maximilians-Universitaet > Theresienstr. 37, D-80333 Munich, Germany > tel: +49-(0)89-2180-4603 / fax: +49-(0)89-2180-4517 > room no: 304 / e-mail: serr*theorie.physik.uni-muenchen.de > http://www.theorie.physik.uni-muenchen.de/biophysics/> > From owner-chemistry@ccl.net Wed Oct 19 05:42:00 2005 From: "Andreas Orthaber andreas.orthaber(_)uni-graz.at" To: CCL Subject: CCL: W:Re: Gamess in parallel Message-Id: <-29654-051019054042-4857-PGNVlwhoNX3JHRtUlg/lWQ- -server.ccl.net> X-Original-From: "Andreas Orthaber" Sent to CCL by: "Andreas Orthaber" [andreas.orthaber(!)uni-graz.at] Using the rsh command, you might try to include your hostnames in your .rhosts file. So that the command can be executed properly. The other possible error might be that you have to double your hostlist (see exaxmple in the rungms script). Did you compile the gamess prperly, in your case use simple TCP/IP settings. best regards andreas you also might ask at the GAMESS mailing list http://lists.ciw.edu/mailman/listinfo/gamess From owner-chemistry@ccl.net Wed Oct 19 07:14:01 2005 From: "alex\.msilva alex.msilva_-_uol.com.br" To: CCL Subject: CCL: W:Re: Gamess in parallel Message-Id: <-29655-051019070314-808-OPYBOhNxxiooABKVUCTQww##server.ccl.net> X-Original-From: "alex\.msilva" Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 19 Oct 2005 09:03:00 -0200 MIME-Version: 1.0 Sent to CCL by: "alex\.msilva" [alex.msilva###uol.com.br] Hi, I have the rsh running and the .rhosts file. Even when I double my hostlist the error continue. Alexander. > > Sent to CCL by: "Andreas Orthaber" [andreas.orthaber(!)uni-graz.at] > Using the rsh command, you might try to include your hostnames in > your .rhosts file. So that the command can be executed properly. The other > possible error might be that you have to double your hostlist (see exaxmple > in the rungms script). Did you compile the gamess prperly, in your case use > simple TCP/IP settings. > > best regards andreas > > you also might ask at the GAMESS mailing list > http://lists.ciw.edu/mailman/listinfo/gamess> > > > From owner-chemistry@ccl.net Wed Oct 19 08:18:00 2005 From: "Andreas Klamt klamt_._cosmologic.de" To: CCL Subject: CCL: References for Ionic Liguids Message-Id: <-29656-051019030353-32487-fBB7QryiTmUcJFJJVk77zA-.-server.ccl.net> X-Original-From: Andreas Klamt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Date: Wed, 19 Oct 2005 08:04:23 +0200 MIME-Version: 1.0 Sent to CCL by: Andreas Klamt [klamt%cosmologic.de] There are thousands of reviews for ionic liquids themselves. For a very efficient simulation approach see Prediction of Infinite Dilution Activity Coefficients of Organic Compounds in Ionic Liquids Using COSMO-RS Michael Diedenhofen, Frank Eckert and Andreas Klamt Journal of Chemical and Engineering Data, 48, 475-479 (2003). Presents COSMOtherm applications to the prediction of organic compound properties in ionic liquid solvents. Abstract, Article-DOI: 10.1021/je025626e. Regards Andreas Takumi Hori thori3jp{=}mac.com wrote: > > Sent to CCL by: Takumi Hori [thori3jp()mac.com] > Dear CCL members, > > Can anyone tell me good references for ionic liquids including > experiments and simulations? > Any informations you know will be greatly appreciated. > > Best regard, > Takumi > > -- > > Dr. Takumi Hori > > Postdoctoral Research Associate > Department of Chemistry > Duke University > Durham, NC 27708-0349 > USA > > Tel : 1-919-660-1658 > E-mail : thori-x-duke.edu > thori3jp-x-mac.com > URL : http://www.chem.duke.edu/~yang/http://www.ccl.net/chemistry/sub_unsub.shtml> > > > > From owner-chemistry@ccl.net Wed Oct 19 09:03:00 2005 From: "Yvette Sturdy yvette.sturdy^^^chemistry.oxford.ac.uk" To: CCL Subject: CCL: Normal modes in internal coordinates Message-Id: <-29657-051019084834-7283-wsnrIz4h9JBtcKiA0WIDVg^_^server.ccl.net> X-Original-From: Yvette Sturdy Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain Date: Wed, 19 Oct 2005 12:28:26 +0100 (BST) MIME-Version: 1.0 Sent to CCL by: Yvette Sturdy [yvette.sturdy/a\chemistry.oxford.ac.uk] Dear all, I am trying to debug some code for transforming cartesian normal modes to internals and vice versa. Does anyone know of a package/code that can give the normal modes in internal coordinates. As far as i am aware Gaussian03 only gives the eigenvectors of the internal coordinate hessian (with the correct iop) - and not of the matrix obtained by converting the mass-weighted cartesian to internal coordinates. Thanks. Yvette Sturdy -- Yvette Sturdy Physical and Theoretical Chemistry Laboratory University of Oxford From owner-chemistry@ccl.net Wed Oct 19 09:45:00 2005 From: "Perry E. Metzger perry(-)piermont.com" To: CCL Subject: CCL: Gamess in parallel Message-Id: <-29658-051019094005-30180-RRMErCD2jcYnjZ0vpqYuuA:_:server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Oct 2005 09:40:00 -0400 MIME-Version: 1.0 Sent to CCL by: "Perry E. Metzger" [perry_._piermont.com] "Alexander Martins Silva alex.msilva,;,uol.com.br" writes: > TCP connect error: ECONNREFUSED. Just FYI, since similar problems have been reported in other contexts on this list, what this means in general is that your process is attempting to connect up to another host and the other machine's TCP stack is saying "sorry, we aren't listening on that port". It happens below the level of user code on the remote host. This can happen for two reasons: 1) There is no process listening on the given port on the remote machine. You can easily check whether there is or not under Unix variants using the "netstat" command. 2) One quick trick for checking if a given host is properly listening (whether you think it is based on netstat or not): try using the "telnet" command to connect to the remote port, i.e. telnet foo.bar.edu portnum you won't actually be able to *do* anything but it will tell you if the port is listening properly. You can then ^] out of the connection immediately. 2) Much more rarely, the error in question can happen even if there is a process listening on the remote machine, but its listen queue is full. The listen queue length is set with the listen(2) system call. Depending on how the listening program is written, it might (or might not) have a large enough listen queue to process all the the incoming requests as fast as they arrive. If you are almost completely certain (based on netstat and actually testing with telnet) that there is a program listening to the given port on the remote host, and it is possible that it is getting a truly vast number of simultaneous connect attempts, try upping the connection limit. I want to emphasize that this isn't advice specific to this particular program -- it is the general way to debug this particular problem for ANY system that is getting connections refused. Perry From owner-chemistry@ccl.net Wed Oct 19 10:46:01 2005 From: "Grant Hill jgh105]^[york.ac.uk" To: CCL Subject: CCL: Compiling Gaussian on EM64T machines [Summary] Message-Id: <-29659-051019104335-15699-w54ZkMXt2qe0qJoD5Qe+qw-.-server.ccl.net> X-Original-From: Grant Hill Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Date: 19 Oct 2005 15:43:30 +0100 Mime-Version: 1.0 Sent to CCL by: Grant Hill [jgh105]_[york.ac.uk] Hi, Yesterday I asked a question about compiling Gaussian03 on Intel EM64T machines and a peculiar error message of: -#-: Badly formed number. (please note, actual symbol may have been changed due to it's appearance in email addresses). Responses from Joseph Han and Doug Fox (of Gaussian technical support) both suggested that this is due to changes in /proc/cpuinfo in recent versions of Linux. The current workaround is to edit the line in g03/bsd/cachesize to: grep 'cache size' /proc/cpuinfo | uniq | tr -d "[:alpha:][:punct:]" I'm glad to report I can now compile and run g03 on my EM64T machine. Thanks also to the others who replied, especially Perry Metzger - I've been writing bash scripts for several years now and never realised there was a debugging mode!! Thanks again to all involved, Grant Hill From owner-chemistry@ccl.net Wed Oct 19 12:09:01 2005 From: "Stan van Gisbergen vangisbergen{=}scm.com" To: CCL Subject: CCL: W:Bond order Message-Id: <-29660-051019114154-10999-m7KunJu3S8j51Odnr7nSgA(~)server.ccl.net> X-Original-From: Stan van Gisbergen Content-Type: multipart/alternative; boundary=Apple-Mail-34--1045842834 Date: Wed, 19 Oct 2005 16:38:16 +0200 Mime-Version: 1.0 (Apple Message framework v619.2) Sent to CCL by: Stan van Gisbergen [vangisbergen=-=scm.com] --Apple-Mail-34--1045842834 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Dear Yang Zhen Na, ADF2005 can calculate bond orders using the Nalewajski-Mrozek approach. (Nalewajski, R.F.; Mrozek, J.; Michalak, A. International Journal of =20= Quantum Chemistry 1997, 61, 589.) This method gives results that are less basis set dependent than other =20= methods. It has also been successfully applied to transition metal compounds =20 with large basis sets: http://www.scm.com/Doc/Doc2005.01/ADF/ADFUsersGuide/=20 page190.html#keyscheme%20BONDORDER In addition the Gopinathan-Jug and Mayer bond order indices are =20 calculated for comparison. I do not think these bond orders are very time-consuming to calculate. Best regards, Stan van Gisbergen On Oct 18, 2005, at 8:20 PM, Eduard Matito eduard()stark.udg.es wrote: > > Sent to CCL by: Eduard Matito [eduard{=3D}stark.udg.es] > It depends on what you mean by "large", but maybe you can try using =20= > fuzzy-atom bond orders. > Check for instance: Mayer, Salvador CPL 383 (2004) 368. They give =20 > their program for free. > It has applied to C60, and maybe you can go further ... > > yang zhen na yangzn553/anenu.edu.cn wrote: > >> Sent to CCL by: "yang zhen na" [yangzn553**nenu.edu.cn] >> How to calculate the bond order of large molecule?> >> >> >> >> > > > > -=3D This is automatically added to each message by the mailing script = =3D- > To recover the email address of the author of the message, please =20 > change=20> > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > > > > Dr. S.J.A. van Gisbergen =A0 =A0 =A0 Scientific Computing & Modelling NV Theoretical Chemistry, Vrije Universiteit De Boelelaan 1083 1081 HV Amsterdam The Netherlands=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 vangisbergen%scm.com =A0 http://www.scm.com Please note NEW FAX AND TELEPHONE NUMBERS: T: +31-20-5987626 =A0 =A0 F: +31-20-5987629 =A0 =A0 =A0 --Apple-Mail-34--1045842834 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=ISO-8859-1 Dear Yang Zhen Na, ADF2005 can calculate bond orders using the Nalewajski-Mrozek approach. (Nalewajski, R.F.; Mrozek, J.; Michalak, A. International Journal of Quantum Chemistry 1997, 61, 589.) This method gives results that are less basis set dependent than other methods. It has also been successfully applied to transition metal compounds with large basis sets: = http://www.scm.com/Doc/Doc2005.01/ADF/ADFUsersGuide/page190.html#keyscheme= %20BONDORDER ArialIn addition the Gopinathan-Jug and Mayer bond order indices are calculated for comparison.=20 I do not think these bond orders are very time-consuming to calculate.=20= Best regards, Stan van Gisbergen On Oct 18, 2005, at 8:20 PM, Eduard Matito eduard()stark.udg.es wrote: Sent to CCL by: Eduard Matito [eduard{=3D}stark.udg.es] It depends on what you mean by "large", but maybe you can try using fuzzy-atom bond orders. Check for instance: Mayer, Salvador CPL 383 (2004) 368. They give their program for free. It has applied to C60, and maybe you can go further ... yang zhen na yangzn553/anenu.edu.cn wrote: Sent to CCL by: "yang zhen na" [yangzn553**nenu.edu.cn] How to calculate the bond order of large molecule?> =20 -=3D This is automatically added to each message by the mailing script = =3D-http://www.ccl.net/cgi-bin/ccl/send_ccl_message=20Job advertisements: http://www.ccl.net/jobs=20http://www.ccl.net/spammers.txtDr. S.J.A. van Gisbergen =A0 =A0 =A0 Scientific Computing & Modelling NV Theoretical Chemistry, Vrije Universiteit De Boelelaan 1083 1081 HV Amsterdam The Netherlands=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 vangisbergen%scm.com =A0 http://www.scm.com Please note NEW FAX AND TELEPHONE NUMBERS: T: +31-20-5987626 =A0 =A0 F: +31-20-5987629 =A0 =A0 =A0 --Apple-Mail-34--1045842834-- From owner-chemistry@ccl.net Wed Oct 19 13:46:00 2005 From: "Alexander Martins Silva alex.msilva#%#uol.com.br" To: CCL Subject: CCL: Gamess in parallel Message-Id: <-29661-051019134311-19648-HoDEEnBG54Dl6BhfKvDBdQ|-|server.ccl.net> X-Original-From: Alexander Martins Silva Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Date: Wed, 19 Oct 2005 15:43:03 +0000 MIME-Version: 1.0 Sent to CCL by: Alexander Martins Silva [alex.msilva- -uol.com.br] Hi, Using the netstat on the server node: $nestat .... Proto Recv-Q Send-Q Endere� Local Endere� Remoto Estado tcp 0 0 at1:nfs at1104.xxx:797 ESTABELECIDA tcp 0 0 at1:nfs at1106.xxx:799 ESTABELECIDA tcp 0 0 at1:nfs at1106.xxx:798 ESTABELECIDA tcp 0 0 at1:nfs at1102.xxx:793 ESTABELECIDA tcp 0 0 at1:nfs at1102.xxx:792 ESTABELECIDA tcp 0 0 at1:nfs at1104.xxx:792 ESTABELECIDA tcp 0 0 at1:nfs at1108.xxx:793 ESTABELECIDA ... tcp 0 0 at1:nfs at1105.xxx:798 ESTABELECIDA tcp 0 0 at1:nfs at1103.xxx:793 ESTABELECIDA You see then that the nodes are listening a rangeport ~792-800, while the ddikick require avlues above 30000. What can I do? Must I fix this tcp configuration? Can I change it? Or Can I control the ddikick? Thanks, Alexander. Perry E. Metzger perry(-)piermont.com wrote: >Sent to CCL by: "Perry E. Metzger" [perry_._piermont.com] > >"Alexander Martins Silva alex.msilva,;,uol.com.br" writes: > > >> TCP connect error: ECONNREFUSED. >> >> > >Just FYI, since similar problems have been reported in other contexts >on this list, what this means in general is that your process is >attempting to connect up to another host and the other machine's TCP >stack is saying "sorry, we aren't listening on that port". It happens >below the level of user code on the remote host. > >This can happen for two reasons: > >1) There is no process listening on the given port on the remote > machine. You can easily check whether there is or not under Unix > variants using the "netstat" command. >2) One quick trick for checking if a given host is properly listening > (whether you think it is based on netstat or not): try using the > "telnet" command to connect to the remote port, i.e. > telnet foo.bar.edu portnum > you won't actually be able to *do* anything but it will tell you if > the port is listening properly. You can then ^] out of the > connection immediately. >2) Much more rarely, the error in question can happen even if there is > a process listening on the remote machine, but its listen queue is > full. The listen queue length is set with the listen(2) system > call. Depending on how the listening program is written, it might > (or might not) have a large enough listen queue to process all the > the incoming requests as fast as they arrive. If you are almost > completely certain (based on netstat and actually testing with > telnet) that there is a program listening to the given port on the > remote host, and it is possible that it is getting a truly vast > number of simultaneous connect attempts, try upping the connection > limit. > >I want to emphasize that this isn't advice specific to this particular >program -- it is the general way to debug this particular problem for >ANY system that is getting connections refused. > >Perry> > > > > > From owner-chemistry@ccl.net Wed Oct 19 14:24:00 2005 From: "Warren DeLano warren^delsci.com" To: CCL Subject: CCL: Stereo 3D "in a window" now on Macs! Message-Id: <-29662-051019141944-1309-OnhA9A3XFxRffW83JB/8/w=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: Wed, 19 Oct 2005 11:20:07 -0700 MIME-Version: 1.0 Sent to CCL by: "Warren DeLano" [warren===delsci.com] Stereo 3D "in a window" now on Macs! Quote: "The optional NVIDIA Quadro FX 4500 graphics card features a stereo 3D graphics port, enabling scientists to use 3D goggles, such as those from Stereo Graphics Corporation, to view an added dimension on their CRT. Stereo-in-a-window support in Mac OS X further enhances visualization, making it possible to designate a quadrant of the display for stereo visualization, while using the rest of the display to control the model, edit data, or make notations.(2)" http://www.apple.com/powermac/graphics.html Cheers, Warren -- 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 From owner-chemistry@ccl.net Wed Oct 19 14:58:00 2005 From: "Perry E. Metzger perry^^^piermont.com" To: CCL Subject: CCL: Gamess in parallel Message-Id: <-29663-051019145152-23670-rW+QlYck/HbnMt09QKmgFg===server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Date: Wed, 19 Oct 2005 14:51:45 -0400 MIME-Version: 1.0 Sent to CCL by: "Perry E. Metzger" [perry{:}piermont.com] Alexander Martins Silva writes: > Using the netstat on the server node: > > $nestat > .... > Proto Recv-Q Send-Q Endere� Local Endere� Remoto Estado > tcp 0 0 at1:nfs at1104.xxx:797 ESTABELECIDA > tcp 0 0 at1:nfs at1106.xxx:799 ESTABELECIDA > tcp 0 0 at1:nfs at1106.xxx:798 ESTABELECIDA > tcp 0 0 at1:nfs at1102.xxx:793 ESTABELECIDA > tcp 0 0 at1:nfs at1102.xxx:792 ESTABELECIDA > tcp 0 0 at1:nfs at1104.xxx:792 ESTABELECIDA > tcp 0 0 at1:nfs at1108.xxx:793 ESTABELECIDA > ... > tcp 0 0 at1:nfs at1105.xxx:798 ESTABELECIDA > tcp 0 0 at1:nfs at1103.xxx:793 ESTABELECIDA > > You see then that the nodes are listening a rangeport ~792-800, while > the ddikick require avlues above 30000. What can I do? Must I fix this > tcp configuration? Can I change it? Or Can I control the ddikick? Actually, that's not quite what you see here. Unfortunately I don't read Portuguese so I'll explain this in terms of the command output in English: Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address State There are two things to note here -- one is that "State" for all these connections is "ESTABLISHED" -- these are live connections, not what you are looking for (which is a state marked "LISTEN"). Second, the column with all the at1:nfs bits is your side (see "Local Address") , and the at110x bits in the 79x range are the remote side ("Foreign Address"). This indicates your local machine is speaking to those foreign machines from its local port "nfs". I suspect that means that at1 is an NFS server and they're mounting file systems from it. Probably not the information you are looking for. Try doing this: netstat | grep LISTEN That will show just the sockets being listened on (or do the equivalent by hand in looking at the output.) BTW, if you could do LANG or LC_ALL=C before sending more output, it will make it more readable for those of us who don't read Portuguese. :) (In Bash, you can do this just for the duration of the command you are running by doing "VAR=val command".) Perry From owner-chemistry@ccl.net Wed Oct 19 15:38:00 2005 From: "Alexander Martins Silva alex.msilva * uol.com.br" To: CCL Subject: CCL: Gamess in parallel Message-Id: <-29664-051019153557-1207-lJXmtCEqG2vPD65Ds8c3Vg . server.ccl.net> X-Original-From: Alexander Martins Silva Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Date: Wed, 19 Oct 2005 17:35:53 +0000 MIME-Version: 1.0 Sent to CCL by: Alexander Martins Silva [alex.msilva ~ uol.com.br] Ok, SERVER $netstat -l Proto Recv-Q Send-Q Local Addr. Remote Add. State tcp 0 0 *:832 *:* LISTEN tcp 0 0 *:640 *:* LISTEN tcp 0 0 *:nfs *:* LISTEN tcp 0 0 *:login *:* LISTEN tcp 0 0 localhost:35297 *:* LISTEN tcp 0 0 *:35298 *:* LISTEN tcp 0 0 *:shell *:* LISTEN tcp 0 0 *:netbios-ssn *:* LISTEN tcp 0 0 *:19150 *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 *:x11 *:* LISTEN tcp 0 0 *:791 *:* LISTEN tcp 0 0 *:pbs *:* LISTEN tcp 0 0 *:698 *:* LISTEN tcp 0 0 *:pbs_mom *:* LISTEN tcp 0 0 *:pbs_resmom *:* LISTEN tcp 0 0 at1:pbs_sched *:* LISTEN tcp 0 0 *:microsoft-ds *:* LISTEN tcp 0 0 *:607 *:* LISTEN tcp 0 0 *:ssh *:* LISTEN udp 0 0 *:nfs *:* udp 0 0 at1:netbios-ns *:* udp 0 0 at1:netbios-ns *:* udp 0 0 *:netbios-ns *:* udp 0 0 at1:netbios-dgm *:* udp 0 0 at1:netbios-dgm *:* udp 0 0 *:netbios-dgm *:* udp 0 0 *:788 *:* udp 0 0 *:15001 *:* udp 0 0 *:pbs_resmom *:* udp 0 0 *:669 *:* udp 0 0 *:696 *:* udp 0 0 *:826 *:* udp 0 0 *:829 *:* udp 0 0 *:bootps *:* udp 0 0 *:tftp *:* udp 0 0 *:839 *:* udp 0 0 *:33096 *:* udp 0 0 *:604 *:* udp 0 0 *:sunrpc *:* udp 0 0 at1:ntp *:* udp 0 0 at1:ntp *:* udp 0 0 localhost:ntp *:* udp 0 0 *:ntp *:* udp 0 0 *:637 *:* udp 0 0 *:1022 *:* udp 0 0 *:1023 *:* udp 0 0 *:ntp *:* raw 0 0 *:icmp *:* 7 Domain sockets UNIX ativos (sem os servidores) Proto CntRef Flags Tipo Estado I-Node Rota Caminho unix 2 [ ACC ] STREAM LISTENING 5628 /tmp/.X11-unix/X0 unix 2 [ ACC ] STREAM LISTENING 5417 /tmp/.font-unix/fs-1 node $netstat -l Proto Recv-Q Send-Q Local Add. Remote Add. State tcp 0 0 *:32768 *:* LISTEN tcp 0 0 *:login *:* LISTEN tcp 0 0 localhost:32769 *:* LISTEN tcp 0 0 *:shell *:* LISTEN tcp 0 0 *:1001 *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 *:722 *:* LISTEN tcp 0 0 *:ssh *:* LISTEN udp 0 0 *:32768 *:* udp 0 0 *:920 *:* udp 0 0 *:tftp *:* udp 0 0 *:719 *:* udp 0 0 *:pop3s *:* udp 0 0 *:998 *:* udp 0 0 *:sunrpc *:* Alexander. Perry E. Metzger wrote: >Alexander Martins Silva writes: > > >>Using the netstat on the server node: >> >>$nestat >>.... >>Proto Recv-Q Send-Q Endere� Local Endere� Remoto Estado >>tcp 0 0 at1:nfs at1104.xxx:797 ESTABELECIDA >>tcp 0 0 at1:nfs at1106.xxx:799 ESTABELECIDA >>tcp 0 0 at1:nfs at1106.xxx:798 ESTABELECIDA >>tcp 0 0 at1:nfs at1102.xxx:793 ESTABELECIDA >>tcp 0 0 at1:nfs at1102.xxx:792 ESTABELECIDA >>tcp 0 0 at1:nfs at1104.xxx:792 ESTABELECIDA >>tcp 0 0 at1:nfs at1108.xxx:793 ESTABELECIDA >>... >>tcp 0 0 at1:nfs at1105.xxx:798 ESTABELECIDA >>tcp 0 0 at1:nfs at1103.xxx:793 ESTABELECIDA >> >>You see then that the nodes are listening a rangeport ~792-800, while >>the ddikick require avlues above 30000. What can I do? Must I fix this >>tcp configuration? Can I change it? Or Can I control the ddikick? >> >> > >Actually, that's not quite what you see here. > >Unfortunately I don't read Portuguese so I'll explain this in terms of >the command output in English: > >Active Internet connections >Proto Recv-Q Send-Q Local Address Foreign Address State > >There are two things to note here -- one is that "State" for all these >connections is "ESTABLISHED" -- these are live connections, not what >you are looking for (which is a state marked "LISTEN"). > >Second, the column with all the at1:nfs bits is your side (see "Local >Address") , and the at110x bits in the 79x range are the remote side >("Foreign Address"). This indicates your local machine is speaking to >those foreign machines from its local port "nfs". I suspect that means >that at1 is an NFS server and they're mounting file systems from it. >Probably not the information you are looking for. > >Try doing this: > >netstat | grep LISTEN > >That will show just the sockets being listened on (or do the >equivalent by hand in looking at the output.) > >BTW, if you could do LANG or LC_ALL=C before sending more output, it >will make it more readable for those of us who don't read >Portuguese. :) (In Bash, you can do this just for the duration of the >command you are running by doing "VAR=val command".) > >Perry > > > From owner-chemistry@ccl.net Wed Oct 19 16:12:00 2005 From: "Perry E. Metzger perry||piermont.com" To: CCL Subject: CCL: Gamess in parallel Message-Id: <-29665-051019155503-14382-zTV5VF5YMz6Wvdq1m3XSMQ(-)server.ccl.net> X-Original-From: "Perry E. Metzger" Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Oct 2005 15:54:58 -0400 MIME-Version: 1.0 Sent to CCL by: "Perry E. Metzger" [perry ~~ piermont.com] Alexander Martins Silva writes: > Ok, > > SERVER > $netstat -l > Proto Recv-Q Send-Q Local Addr. Remote Add. State > tcp 0 0 *:832 *:* > LISTEN By the way, when you send a report like this, is is moderately important to keep the tabs and line breaks intact. I suggest attaching files rather than cutting and pasting, which often nukes important information. Anyway, there is no specific evidence of your server process listening at all on the box (or at least not that I can see). Could you try using the "lsof" utility on the server process to see what it has open? If you have "lsof" installed, what you need to do is roughly: pgrep processname (or an equivalent like ps | grep, to get the pid of the process) lsof -p (whatever number "pid" happens to be). this will probably show far more open files than you care to see, and you'll have to cut the list down to just the open sockets (I can't remember off hand if there is a flag to do that automatically.) Given this, you'll know what socket your server *thinks* it is listening on. (It may correspond to one of the less obvious sockets in the listing from netstat.) Perry From owner-chemistry@ccl.net Wed Oct 19 17:03:01 2005 From: "Warren DeLano warren()delsci.com" To: CCL Subject: CCL: Stereo 3D Displays & Equipment Message-Id: <-29666-051019165826-22000-EbehKq4ZMINKcP/qQbFjeA[*]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: Wed, 19 Oct 2005 13:58:48 -0700 MIME-Version: 1.0 Sent to CCL by: "Warren DeLano" [warren\a/delsci.com] Here is some current information for those of you ordering yourself a new "Quad" Quadro-based Mac for doing Stereo 3D visualization. You will need a good CRT display, a stereo signal emitter, and shutter glasses. Stereo 3D glasses & emitters: - More expensive: StereoGraphics - Less expensive: NuVision3D Thanks to LCD dominance, it is getting mucher harder to find a good CRT display. You may need to hunt around a bit or buy "pre-owned". The critical monitor specifications for Stereo 3D are: - Must be a CRT (not an LCD). - Should be as big as you can afford (20-22"). - HD15 VGA input (DVI is very rare). - Vertical refresh must be at least 120 Hz. - Horizontal sync frequency must be at least 130 kHz (ideally 140 kHz). Note that the last point is CRITICAL. Do not buy a CRT monitor for stereo 3D until you have confired that it can do a horizontal sync of at least 130 kHz. Beware of consumer monitors have horizontal sync limits of 80-120 kHz and thus cannot do stereo well. Good stereo-capable CRT displays that are still available NEW: - Philips 202P73 - Iiyama Vision Master Pro 514 / HM204DT Good discontinued stereo-capable displays (buy USED on eBay, etc.): - IBM ThinkVision C220p - HP p1230 CRT Monitor (P9613W) - DELL p1230 - Sony GDM-C520K - NEC FP2141SB-BK - NEC-Mitsubishi Diamond Pro 2070SB-BK - Sun X7149A Borderline displays: - ViewSonic, P225FB (H-sync: 127 kHz - good for 1280x960 ]^[ ~110 Hz) - Samsung SyncMaster 1100 DF (H-sync: 121 kHz) - Sun X7149A (H-sync: 121 kHz) Unsuitable displays: - ViewSonic G220f/fb, G810, G90f/fb - Philips 201B40, 201B45 - NEC Accusync 120 - Mitsubishi Diamond Pro 930SB - Samsung SyncMaster 1000 P, 997DF/997MB See: http://monitors.alege.net for info on tons of monitors, old & new. Cheers, Warren -- 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