Re: [Wien] Fwd: How to force a particular charge state
Hello Negi, did yu read (and understand) the response of Peter Blaha in this mailing list to your questions? - dateMo 07:20 Thanks for your reply reg. Co+3 substitution in ZnO. But still I have some additional queries as following. 1) By removing an electron from case.in2c, how do I ensure that the electron removed is from the Co atom (and not from Zn). Do the scf-cycle and check (partial DOS), where the Zn states and the Co states are. 2) If there are more than one Co atom in the cell, how do I tag the Co+3 atom and differenciate it from the rest of Co+2 atoms? Again, first check what comes out. For a localized 3d TM impurity in an oxide you will need anyway GGA+U calculations. With GGA+U you can force certain states by constraining a particular density-matrix (case.dmatup/dn), x orb -up/dn, runsp -orbc In any case: I guess Co3+ in ZnO will only be generated if you have O-vacancies On Wed, 17 Apr 2013 10:05:04 +0530 (IST), devendran...@jncasr.ac.in wrote: > Dear wien2k users, >I am studying Co+2 and Co+3 substitution in ZnO. In >this context with xavier reply i have some additional >queries as following. > > (1)By removing an electron from case.in2c, how do I ensure that the > electron removed is from the Co atom (and not from Zn). > > 2) If there are more than one Co atom in the cell then how do i ensure > that which Co atom is going to be Co+3. > > > > > Thanks, > Negi > > > > > > > - Forwarded Message - > From: "Rocquefelte" > To: "A Mailing list for WIEN2k users" > Sent: Saturday, March 2, 2013 3:07:08 PM > Subject: Re: [Wien] How to force a particular charge state > > > > You should first check where are the Co(d) states in the DOS. > If the Co(d) states are at the Fermi level, you simply have to do the > following: > > 1. Remove one electron in the case.in2(c) file (line 2 / column 2) > > 2. Add a background charge "-1" in the mixer in order to have charge > neutrality (line 1 / column 2) > > -- top of file: case.inm > MSEC3 -1.d0 YES (PRATT/MSEC1/3/MSR1/a bg charge (+1 for additional e), > NORM > 0.2 MIXING GREED > 1.0 1.0 Not used, retained for compatibility only > 999 8 nbroyd nuse > --- bottom of file > > After the scf calculation, check the DOS and partial charges to insure > that you have stabilized the Co(3+) charged state. > > Best Regards > > Xavier > > > > > Le 3/2/2013 8:45 AM, dil...@jncasr.ac.in a écrit : > > > Hello users, > > In Wien2k I want to study Co doped ZnO and I want to force the Co atom to > be in the Co3+ charged state instead of Co2+ and run the scf. How will I do > that? > > -Thanks > Dileep Krishnan > c/O Dr. Ranjan Datta, > ICMS, JNCASR, > Jakkur, Bangalore. > ___ > Wien mailing list Wien@zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > > ___ > Wien mailing list > Wien@zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > ___ > Wien mailing list > Wien@zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > SEARCH the MAILING-LIST at: > http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- Dr. Martin Pieper Karl-Franzens University Experimentalphysik Universitätsplatz 5 A-8010 Graz Austria Tel. +43-316-380-8564 ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Help Wien2k
Thank you sir, I got the desired result.
On 4/16/13, Stefaan Cottenier wrote:
>
> You are probably using the structure editor of w2web, and did it
> analogously to the TiC example in the usersguide? Mind that while TiC
> has only one atom of each kind in the primitive cell, hcp-Cd has two of
> them. Both coordinates should be specified when you provide only the
> lattice type ('H').
>
> Alternatively, you can select the space group in w2web (nr. 194). In
> that case, only one coordinate (per inequivalent atom) should be given.
>
> Stefaan
>
>
>
>> I was trying to reproduce the results of hcp Cd from DFT & Family Of
>> LAPW methods: a step by step intoduction by S. Cottenier pg 36. The
>> following struct.file is created by giving input: no. of inequivalent
>> atoms = 1, latt. const.= 5.63, 5.63, 10.61(bohr), 90, 90 ,120 (deg).
>> cad
>> H LATTICE,NONEQUIV.ATOMS: 1
>> MODE OF CALC=RELA unit=bohr
>>5.630252 5.630252 10.617619 90.00 90.00120.00
>> ATOM -1: X=0. Y=0.6667 Z=0.2500
>>MULT= 1 ISPLIT= 8
>> Cd NPT= 781 R0=0.1000 RMT=2.5000 Z: 48.0
>> LOCAL ROT MATRIX:1.000 0.000 0.000
>> 0.000 1.000 0.000
>> 0.000 0.000 1.000
>> 0 NUMBER OF SYMMETRY OPERATIONS
>>
>> which is different from the struct.file given in the text. When
>> initializing the following warning appears in view.outputsgroup
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] compilation erroe during installation
Looks like you are using Wien2k 12.1. Sequential Build a) I see no "-DFFTW2" in your compiler options and "-lfftw" in your R_LIB for fftw 2.1.5. So I assume you have used the patches to vresp.F and fft_modules.F for the fftpack [http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-November/017911.html]. b) Your sequential settings seem to be okay assuming you are using ifort and mkl 11.0.074 [http://zeus.theochem.tuwien.ac.at/pipermail/wien/2009-February/012160.html]. Regarding "undefined reference to `vmlsetmode_'", I don't know why you are getting this error. My guess is it might be an environmental setting problem with a missing path for the mkl include directory containing "mkl_vml.fi" [http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05385.html]. MPI Parallel Build c) As Prof. Blaha has said previously on the mailing list: Once you installed and can run the sequential version, you can go on with the mpi-version. But note: it makes sense only if you have a larger cluster with infiniband network, or a "super-server" with shared memory and at least 8 cores). We have a k-point parallel version, which does not need mpi, but is perfect for a small cluster with a common NFS filesystem. If you have the necessary hardware described in c): d) You should be using -DFFTW2, not -DFFTW3, in FPOPT and the path and library in RP_LIBS for fftw 2.1.5. e) For fftw 2.1.5, I assume you have applied the additional fix to fft_modules.F [http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-December/018007.html]. f) Regarding "gfortran: error: unrecognized option", you need to recompile mpich-3.0.3 with ifort instead of gfortran. On 4/17/2013 12:19 AM, wasim raja Mondal wrote: Dear wien2k developer I am installing wien2k in ubuntu 11.0 operating system. I chose ifort and cc compiler. I have given also installed mpich-3.0.3 and fftw 2.1.5 in the system. I have compiled all the program and check the error message in compile.msg for each program. I have found error in 12 SRC_* programe and other programe are successfully installed. For example I giving one error file given below in the SRC_lapwo programme... please help me. ifort -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c ykav.f ... ifort -o lapw0 cputim.o modules.o fftpack_helpers.o fft_modules.o reallocate.o ainv.o am05_xscss.o b88.o blyp.o brj.o charg2.o charg3.o charge.o chfac.o chslv.o corgga.o corpbe_revtpss.o corpbe_tpss.o cub_xc_back.o corlsd.o dfxhpbe.o dfxrevtpss.o dfxtpss.o drho.o dylm.o efg.o energy.o epot1.o eramps.o errclr.o errflg.o ev92.o ev92ex.o exch.o exch17.o fithi.o fxhpbe.o fx_revtpss.o fx_tpss.o gbass.o gcor.o gea.o geaex.o getff1.o getfft.o gpoint.o gpointm.o grans.o gtfnam.o hcth.o htbs.o ifflim.o kcis.o lapw0.o latgen.o multfc.o multsu.o outerr.o pbea.o pbem.o pbe1.o pbe2.o pbesol.o poissn.o potfac.o pwxad4.o pwxad5.o qranf.o readstruct.o rean0.o rean1.o rean3.o rean4.o rhopw.o rotate.o rotdef.o rpbe.o setff0.o setff1.o setfft.o setff2.o seval.o sevald.o sevaldd.o sevali.o sevalin.o sicpbe.o sicpbe_revtpss.o sicpbe_tpss.o sogga.o sphbes.o spline.o srolyl.o stern.o sumfac.o suml.o SymmRot.o th1.o th2.o vpw91.o vresp.o vs98.o vxc15.o vxc16.o vxc17.o vxc24.o vxc26.o vxclm2.o vxcpw2.o vxi35.o vxi35a.o wc05.o workf1.o xcener.o xcpot.o xcpot1.o xcpot3.o ykav.o ylm.o W2kutils.o W2kinit.o vx_screened.o lyp.o vwn5.o -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -L/opt/intel/11.0/074/mkl/lib/em64t -pthread -i-static -lmkl_lapack -lmkl -lguide W2kinit.o: In function `w2kinit_': W2kinit.F:(.text+0x133): undefined reference to `vmlsetmode_' make[1]: *** [lapw0] Error 1 make[1]: Leaving directory `/home/naushad/attem_install/SRC_lapw0' make: *** [seq] Error 2 make: *** No rule to make target `complex'. Stop. if [ -f .sequential ]; then \ rm -f .sequential modules.o fft_modules.o reallocate.o energy.o getff1.o getfft.o gtfnam.o lapw0.o rean0.o rean3.o rean4.o setff1.o setff2.o setfft.o xcpot1.o xcpot3.o eramps.o W2kinit.o *.mod; \ fi touch .parallel make PARALLEL='-DParallel' lapw0_mpi \ FORT=mpif90 FFLAGS=' -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -DFFTW3 '-DParallel'' make[1]: Entering directory `/home/naushad/attem_install/SRC_lapw0' mpif90 -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -DFFTW3 -DParallel -c modules.F gfortran: error: unrecognized option '-prec_div' gfortran: error: unrecognized option '-pc80' gfortran: error: unrecognized option '-pad' gfortran: error: unrecognized option '-align' gfortran: error: unrecognized option '-traceback' make[1]: *** [modules.o] Error 1 make[1]: Leaving directory `/home/naushad/attem_install/SRC_lapw0' make: *** [para] Error 2 ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at:http:/
Re: [Wien] Charge distance
N.B., As a relevant potential source of confusion, the " DIFFERENCE CHARGE**2" in case.scfm is in fact a typo -- those lines are correctly the RMS charge difference. This will be corrected in a future release. On Mon, Apr 15, 2013 at 1:24 PM, Laurence Marks wrote: > The units are electrons/atom where multiplicity of sites is taken into > account (and it is only within the muffin tins and for L=0). > > I will guess that "-cc" was probably used for "charge convergence", > although since the variables are charge density your second one makes more > sense to me. > > Unless you had to use a very small value (e.g. for phonons) or had issues > for some reason with bad convergence I would not worry too much; saying > "used the standard convergence criteria for the charge density as -cc > 0.0001" would be fine for me if I was on your committee. > > > On Mon, Apr 15, 2013 at 1:01 PM, Francisco Garcia > wrote: > >> Dear Prof. Marks, >> >> Thank you for your reply. >> >> I guess the question I should have asked is: how is the charge >> convergence criteria (-cc XXX) determined? To be more technical, does -cc >> implies "charge convergence" or "charge density convergence?" Is the unit >> electrons, electrons/Bohr**3, Bohr**-3. This is not quite explicit in the >> user guide. I just want to be precise with the way I present it in my >> dissertation. >> >> Thank you. >> > > > > -- > Professor Laurence Marks > Department of Materials Science and Engineering > Northwestern University > www.numis.northwestern.edu 1-847-491-3996 > "Research is to see what everybody else has seen, and to think what nobody > else has thought" > Albert Szent-Gyorgi > -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu 1-847-491-3996 "Research is to see what everybody else has seen, and to think what nobody else has thought" Albert Szent-Gyorgi ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] compilation erroe during installation
Dear Gavin Thanks for your reply. I am giving the details of the Makefile of the SRC_lapw file. SUFFIXES:.F .SUFFIXES:.F90 SHELL = /bin/sh FC = ifort MPF = mpif90 CC = cc FOPT = -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback FPOPT = $(FOPT) -DFFTW2 DParallel = '-DParallel' FGEN = $(PARALLEL) LDFLAGS = $(FOPT) -L/opt/intel/11.0/074/mkl/lib/em64t -pthread -i-static R_LIBS = -lmkl_lapack -lmkl -lguide RP_LIBS = -lmkl_scalapack -lmkl_blacs_lp64 -L/opt/fftw-2.1.5/fftw-install/lib -lfftw2.1.5_mpi -lftw2.1.5 $(R_LIBS) S_EXECNAME = lapw0 P_EXECNAME = lapw0_mpi WIth this when I am compiling SRC_lapw i am facing the same error. But with no gfortran error W2kinit.o: In function `w2kinit_': W2kinit.F:(.text+0x133): undefined reference to `vmlsetmode_' make[1]: *** [lapw0] Error 1 make[1]: Leaving directory `/home/naushad/attem_install/SRC_lapw0' make: *** [seq] Error 2 As it was suggested in the previous mail, my mkl_vml.f file is given below /opt/intel/Compiler/11.0/074/mkl/include/mkl_vml.fi Please give me some suggestion. Regards wasim On Wed, Apr 17, 2013 at 8:39 PM, Gavin Abo wrote: > Looks like you are using Wien2k 12.1. > > Sequential Build > > a) I see no "-DFFTW2" in your compiler options and "-lfftw" in your R_LIB > for fftw 2.1.5. So I assume you have used the patches to vresp.F > and fft_modules.F for the fftpack [ > http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-November/017911.html > ]. > > b) Your sequential settings seem to be okay assuming you are using ifort > and mkl 11.0.074 [ > http://zeus.theochem.tuwien.ac.at/pipermail/wien/2009-February/012160.html]. > Regarding "undefined reference to `vmlsetmode_'", I don't know why you are > getting this error. My guess is it might be an environmental setting > problem with a missing path for the mkl include directory containing " > mkl_vml.fi" [ > http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05385.html > ]. > > MPI Parallel Build > > c) As Prof. Blaha has said previously on the mailing list: > > Once you installed and can run the sequential version, you can go on with > the mpi-version. But note: it makes sense only if you have a larger cluster > with infiniband network, or a "super-server" with shared memory and at > least 8 cores). We have a k-point parallel version, which does not need > mpi, but is perfect for a small cluster with a common NFS filesystem. > > If you have the necessary hardware described in c): > > d) You should be using -DFFTW2, not -DFFTW3, in FPOPT and the path and > library in RP_LIBS for fftw 2.1.5. > > e) For fftw 2.1.5, I assume you have applied the additional fix to > fft_modules.F [ > http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-December/018007.html > ]. > > f) Regarding "gfortran: error: unrecognized option", you need to recompile > mpich-3.0.3 with ifort instead of gfortran. > > On 4/17/2013 12:19 AM, wasim raja Mondal wrote: > > Dear wien2k developer > > I am installing wien2k in ubuntu 11.0 operating system. I chose ifort > and cc compiler. I have given also installed mpich-3.0.3 and fftw 2.1.5 in > the system. I have compiled all the program and check the error message in > compile.msg for each program. I have found error in 12 SRC_* programe and > other programe are successfully installed. For example I giving one error > file given below in the SRC_lapwo programme... please help me. > > ifort -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -traceback -c > ykav.f > ... > > ifort -o lapw0 cputim.o modules.o fftpack_helpers.o fft_modules.o > reallocate.o ainv.o am05_xscss.o b88.o blyp.o brj.o charg2.o charg3.o > charge.o chfac.o chslv.o corgga.o corpbe_revtpss.o corpbe_tpss.o > cub_xc_back.o corlsd.o dfxhpbe.o dfxrevtpss.o dfxtpss.o drho.o dylm.o efg.o > energy.o epot1.o eramps.o errclr.o errflg.o ev92.o ev92ex.o exch.o exch17.o > fithi.o fxhpbe.o fx_revtpss.o fx_tpss.o gbass.o gcor.o gea.o geaex.o > getff1.o getfft.o gpoint.o gpointm.o grans.o gtfnam.o hcth.o htbs.o > ifflim.o kcis.o lapw0.o latgen.o multfc.o multsu.o outerr.o pbea.o pbem.o > pbe1.o pbe2.o pbesol.o poissn.o potfac.o pwxad4.o pwxad5.o qranf.o > readstruct.o rean0.o rean1.o rean3.o rean4.o rhopw.o rotate.o rotdef.o > rpbe.o setff0.o setff1.o setfft.o setff2.o seval.o sevald.o sevaldd.o > sevali.o sevalin.o sicpbe.o sicpbe_revtpss.o sicpbe_tpss.o sogga.o sphbes.o > spline.o srolyl.o stern.o sumfac.o suml.o SymmRot.o th1.o th2.o vpw91.o > vresp.o vs98.o vxc15.o vxc16.o vxc17.o vxc24.o vxc26.o vxclm2.o vxcpw2.o > vxi35.o vxi35a.o wc05.o workf1.o xcener.o xcpot.o xcpot1.o xcpot3.o ykav.o > ylm.o W2kutils.o W2kinit.o vx_screened.o lyp.o vwn5.o -FR -mp1 -w > -prec_div -pc80 -pad -align -DINTEL_VML -traceback > -L/opt/intel/11.0/074/mkl/lib/em64t -pthread -i-static -lmkl_lapack -lmkl > -lguide > W2kinit.o: In function `w2kinit_': > W2kinit.F:(.text+0x133): undefined reference to `vmlsetmode_' > make[1]: *** [lapw0] Error 1 > make[1]: Leaving directory `/home
Re: [Wien] Multicore on i7 iMac
Dear Prof. Blaha and WIEN2k experts, I have 4 physical cores (Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz). It seems that on my compilation using HT and filling up all 8 threads makes some particular calculation just a bit faster compared to the settings you have suggested, but with HT CPU gets more hot (fan is on more often), so it makes no sense. I will use the settings you have recommended. I have now an error for the slab with spin-polarized but without spin orbit (see below part of STDOUT file). I tried to look at old emails from this group, but could not quickly find a solution. Same slab has converged before in a non-parallel mode with spin-polarized and with spin-orbit. I use cutoff 8 Ry and: K-VECTORS FROM UNIT:4 -11.0 5.5 933 emin/emax/nband in case.in1c. Regards, Lukasz ... CORE END CORE END MIXER END in cycle 22ETEST: .381681805000 CTEST: 1.9705727 LAPW0 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW2 - FERMI; weighs written LAPW2 END LAPW2 END SUMPARA END LAPW2 - FERMI; weighs written LAPW2 END LAPW2 END SUMPARA END CORE END CORE END MIXER END in cycle 23ETEST: .294226365000 CTEST: 2.3441252 LAPW0 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END FERMI - Error cp: .in.tmp: No such file or directory > stop error How many "real" cores do you have ? Most likely only 4 (the 8 comes from hyperthreading, but for numerical intensive application one should probably not use hyperthreading). So the "best" performance can probably be reached either by: OMP_NUM_THREADS=2 and 2 lines in .machines or OMP_NUM_THREADS=1 and 4 lines in .machines (it may even depend on the number of k-points in the specific case ..) On 04/16/2013 02:49 PM, pl...@physics.ucdavis.edu wrote: > Dear Prof. Blaha, > > Thank you for the answer. In the meantime I have realized this mistake. > > I have now all 8 threads practically fully utilized (HT Intel i7 in iMac) > for lapw1 and lapw2. It reduced the iteration from approx. 7.2min to > 5.5min (compared to utilizing 4 threads only with OMP_NUM_THREADS). > > I think it solves my problems for now. Again thank you for your support > and rapid answers. > > Regards, > Lukasz > > > >> Your .machines file is wrong. It contains more than one hostname per >> line (or has a localhost:2) >> >> With the proper .machines file, mpirun is not needed: >> > bash: mpirun: command not found >> >> .machines -- >> 1:localhost >> 1:localhost >> >> This file with split the klist into two parts and run two lapw1-jobs >> simultaneously. >> >> On 04/16/2013 11:48 AM, pl...@physics.ucdavis.edu wrote: >>> Hello Prof. Blaha, Prof. Marks, >>> >>> ssh localhost works now without login!! >>> >>> I have more errors now when trying to run parallel mode, see below. >>> >>> In UG there are sections 5.5.1 (k-point parallelization) and 5.5.2 (MPI >>> parallelization). I understand these two modes are separate, and I would >>> like to focus on k-point parallelization for now. I am not sure why >>> there >>> is an error regarding the mpirun. My parallel_options file is now: >>> >>> setenv USE_REMOTE 0 >>> setenv MPI_REMOTE "1" >>> setenv WIEN_GRANULARITY 1 >>> >>> But with other options I have the same error. >>> >>> I would appreciate if there is something obvious which I do wrong. In >>> any >>> case I will continue to work on the issue with my IT department here. >>> >>> Regards, >>> Lukasz >>> >>> >>> >>>LAPW0 END >>> bash: mpirun: command not found >>> >>> real0m0.001s >>> user0m0.000s >>> sys0m0.000s >>> Mo-bulk-so.scf1_1: No such file or directory. >>> ERROR IN OPENING UNIT: 9 >>> FILENAME: >>>./Mo-bulk-so.vector_1 >>> STATUS: old FORM:unformatted >>> OPEN FAILED >>> >>> >>> >>> >>> Original Message >>> Subject: Re: [Wien] Multicore on i7 iMac >>> Date: Mon, 15 Apr 2013 08:49:39 -0500 >>> From: Laurence Marks >>> Reply-To: A Mailing list for WIEN2k users >>> >>> To: A Mailing list for WIEN2k users >>> >>> You may also be able to turn off USE_REMOTE and MPI_REMOTE (set both >>> to 0) and/or use something other than ssh to launch processes. >>> >>> On Mon, Apr 15, 2013 at 8:33 AM, Peter Blaha >>> wrote: Try it again. I think it ask this disturbing question only once ! otherwise: you must be able to do: ssh localhost and login without any other response. > The authenticity of host 'localhost (::1)' can't be established. > RSA key fingerprint is > 50:c3:da:fa:0c:35:c5:aa:d1:b4:c1:52:a1:18:08:c2. > Are you sure you want to continue connecting (yes/no)? yes > > ^C > > > > > > Original Message > Subject: Re: [Wien] Multicore on i7 iMac > Date: Mon, 15 Apr 2013 08:16:11 +0200 > From: Peter Blaha > Reply-To: A Mailing list for WIEN2k users >>> > To: A Mailing lis
