[Pw_forum] graphite cell optimization failed
I have exactly the same problem with ifort on my MacPro and gfortran on my AMD cluster % % from read_kernel_table : error # 1 No \"vdW_kernel_table\" file could be found % % Le 24 mars 11 ? 04:47, Mehmet Topsakal a ?crit : > just run generate_vdW_kernel_table.x executable and wait for > vdW_kernel_table file to appear. > > > On Thu, Mar 24, 2011 at 4:19 AM, Chenghua Sun > wrote: > Dear Nicola, > > Thanks for your reply. I installed the QE4.3a and run a test with > input_dft = 'vdW-DF', but I got the error message below: > > % > % > from read_kernel_table : error # 1 > No \"vdW_kernel_table\" file could be found > > %% > > > To fix it, should I install the kernel table or add some option with > my compiling? > > Thanks. > > chenghua > > Chenghua Sun, PhD > Australian Institute for Bioengineering and Nanotechnology > Centre for Computational Molecular Science, Director > The University of Queensland > > Postal Address: > CCMS, AIBN Building #75, > The University of Queensland > Brisbane, Qld 4072, Australia > > Tel: +61 7 3346 3972 > Fax : +61 7 3346 3992 > Email: c.sun1 at uq.edu.au > Web: http://web.aibn.uq.edu.au/cbn > ** > > > From: Nicola Marzari [nicola.marzari at materials.ox.ac.uk] > Sent: Thursday, 24 March 2011 10:03 AM > Cc: Chenghua Sun; PWSCF Forum > Subject: Re: [Pw_forum] graphite cell optimization failed > > On 3/23/11 11:51 PM, Chenghua Sun wrote: > > Deal All, > > > > I didn't try QE4.3a yet, but I am wondering what is the theory > basis for the first-principle vdW-DFT by 'vdW-DF' in QE 4.3a. > > See "physical review" papers from Dion/Thonhauser/Langreth/Langreth > > Any improvement compared with semiempirical vdW scheme? In additional, > is it applicable for all elements? > > I think so, but do not have extensive data. yes, it depends on the > charge density, not on the elements. > >nicola > > -- > Prof Nicola MarzariDepartment of MaterialsUniversity of Oxford > Chair of Materials Modelling Director, Materials Modelling Laboratory > nicola.marzari at materials.ox.ac.uk http://mml.materials.ox.ac.uk/NM > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > > > > -- > > Mehmet Topsakal (Ph.D. Student) > UNAM-Institute of Materials Science and Nanotechnology. > Bilkent University. 06800 Bilkent, Ankara/Turkey > Tel: 0090 312 290 3527 ; Fax: 0090 312 266 4365 > http://www.researcherid.com/rid/A-5015-2010 > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum Dr. Alain ALLOUCHE Physique des Interactions Ioniques et Moleculaires CNRS / Universite de Provence Campus Saint Jerome Service 242 Avenue de l'Escadrille Normandie-Niemen 13397 Marseille Cedex 20 - France Tel : +33 (0) 4 91 28 85 76 Mobile:+33 681 84 80 66 Fax : +33 491.28.89.05 email: Alain.Allouche at univ-provence.fr -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/20110324/237a8f05/attachment.htm
[Pw_forum] Fwd: compiling QE 4.3a
Helle Layla, here is the make.sys Le 23 mars 11 ? 12:00, Layla Martin-Samos a ?crit : > > > Hi Alain, the warnings regarding iotk are not relevant. The messages > "nothing to be done for ... " are normal. This are checks to see > wheter things have to be compiled or not. The last message is realy > an error message and it seems the your C compiler is not recognizing > its own internal function call to STRLEN. Exactly which fortran and > c compiler are you using? can you attach the make.sys file produced > by the ESPRESSO configure? > > bests > > Layla > > > 2011/3/23 Alain Allouche > Dear all > Compiling QE v 4.3a with Intel compiler I got the messages: > > mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 - > nomodule -fpp -D__INTEL -D__FFTW -D__MPI -D__PARA -I../include -c > iotk_scan_interf.f90 > : warning #5117: Bad # preprocessor line > > which should be fatal > > then > iotk_stream.spp(54): warning #6843: A dummy argument with an explicit > INTENT(OUT) declaration is not given an explicit value. [VAL] > subroutine > iotk_stream_read_LOGICAL1(unit,header,val,setpos,getpos,noval,ierr) > -^ > iotk_stream.spp(54): warning #6843: A dummy argument with an explicit > INTENT(OUT) declaration is not given an explicit value. [VAL] > subroutine > iotk_stream_read_INTEGER1(unit,header,val,setpos,getpos,noval,ierr) > -^ > iotk_stream.spp(54): warning #6843: A dummy argument with an explicit > INTENT(OUT) declaration is not given an explicit value. [VAL] > subroutine > iotk_stream_read_REAL1(unit,header,val,setpos,getpos,noval,ierr) > --^ > iotk_stream.spp(54): warning #6843: A dummy argument with an explicit > INTENT(OUT) declaration is not given an explicit value. [VAL] > subroutine > iotk_stream_read_REAL2(unit,header,val,setpos,getpos,noval,ierr) > --^ > iotk_stream.spp(54): warning #6843: A dummy argument with an explicit > INTENT(OUT) declaration is not given an explicit value. [VAL] > subroutine > iotk_stream_read_COMPLEX1(unit,header,val,setpos,getpos,noval,ierr) > -^ > iotk_stream.spp(54): warning #6843: A dummy argument with an explicit > INTENT(OUT) declaration is not given an explicit value. [VAL] > subroutine > iotk_stream_read_COMPLEX2(unit,header,val,setpos,getpos,noval,ierr) > -^ > iotk_stream.spp(54): warning #6843: A dummy argument with an explicit > INTENT(OUT) declaration is not given an explicit value. [VAL] > subroutine > iotk_stream_read_CHARACTER1(unit,header,val,setpos,getpos,noval,ierr) > ---^ > > Then > > make loclib_only > make[3]: Nothing to be done for `loclib_only'. > mpif90 -o iotk_print_kinds.x iotk_print_kinds.o libiotk.a > mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 - > nomodule -fpp -D__INTEL -D__FFTW -D__MPI -D__PARA -I../include -c > iotk.f90 > make loclib_only > make[3]: Nothing to be done for `loclib_only'. > > And at the last step of pw compiling > > mpif90 -o pw.x \ >pwscf.o libpw.a ../Modules/libqemod.a ../flib/ptools.a ../ > flib/flib.a ../clib/clib.a ../iotk/src/libiotk.a -llapack -latlas / > Volumes/Work/espresso-4.3a/lapack-3.2/lapack.a -latlas > Undefined symbols: > "___intel_sse2_strlen", referenced from: > _get_md5 in clib.a(md5_from_file.o) > _file_md5_ in clib.a(md5_from_file.o) > ld: symbol(s) not found > make[1]: *** [pw.x] Error 1 > make: *** [pw] Error 2 > > Thanks for your help > Alain > > > > > Alain ALLOUCHE > Physique des Interactions Ioniques et Moleculaires > CNRS / Universite de Provence > Campus Saint Jerome Service 242 > email: Alain.Allouche at univ-provence.fr > > > > > > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum Dr. Alain ALLOUCHE Physique des Interactions Ioniques et Moleculaires CNRS / Universite de Provence Campus Saint Jerome Service 242 Avenue de l'Escadrille Normandie-Niemen 13397 Marseille Cedex 20 - France Tel : +33 (0) 4 91 28 85 76 Mobile:+33 681 84 80 66 Fax : +33 491.28.89.05 email: Alain.Allouche at univ-provence.fr -- next
[Pw_forum] compiling QE 4.3a
Dear all Compiling QE v 4.3a with Intel compiler I got the messages: mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 - nomodule -fpp -D__INTEL -D__FFTW -D__MPI -D__PARA -I../include -c iotk_scan_interf.f90 : warning #5117: Bad # preprocessor line which should be fatal then iotk_stream.spp(54): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [VAL] subroutine iotk_stream_read_LOGICAL1(unit,header,val,setpos,getpos,noval,ierr) -^ iotk_stream.spp(54): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [VAL] subroutine iotk_stream_read_INTEGER1(unit,header,val,setpos,getpos,noval,ierr) -^ iotk_stream.spp(54): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [VAL] subroutine iotk_stream_read_REAL1(unit,header,val,setpos,getpos,noval,ierr) --^ iotk_stream.spp(54): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [VAL] subroutine iotk_stream_read_REAL2(unit,header,val,setpos,getpos,noval,ierr) --^ iotk_stream.spp(54): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [VAL] subroutine iotk_stream_read_COMPLEX1(unit,header,val,setpos,getpos,noval,ierr) -^ iotk_stream.spp(54): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [VAL] subroutine iotk_stream_read_COMPLEX2(unit,header,val,setpos,getpos,noval,ierr) -^ iotk_stream.spp(54): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [VAL] subroutine iotk_stream_read_CHARACTER1(unit,header,val,setpos,getpos,noval,ierr) ---^ Then make loclib_only make[3]: Nothing to be done for `loclib_only'. mpif90 -o iotk_print_kinds.x iotk_print_kinds.o libiotk.a mpif90 -O2 -assume byterecl -g -traceback -par-report0 -vec-report0 - nomodule -fpp -D__INTEL -D__FFTW -D__MPI -D__PARA -I../include -c iotk.f90 make loclib_only make[3]: Nothing to be done for `loclib_only'. And at the last step of pw compiling mpif90 -o pw.x \ pwscf.o libpw.a ../Modules/libqemod.a ../flib/ptools.a ../ flib/flib.a ../clib/clib.a ../iotk/src/libiotk.a -llapack -latlas / Volumes/Work/espresso-4.3a/lapack-3.2/lapack.a -latlas Undefined symbols: "___intel_sse2_strlen", referenced from: _get_md5 in clib.a(md5_from_file.o) _file_md5_ in clib.a(md5_from_file.o) ld: symbol(s) not found make[1]: *** [pw.x] Error 1 make: *** [pw] Error 2 Thanks for your help Alain Alain ALLOUCHE Physique des Interactions Ioniques et Moleculaires CNRS / Universite de Provence Campus Saint Jerome Service 242 email: Alain.Allouche at univ-provence.fr
[Pw_forum] XSpectra on graphite slab
Thank you Matteo, I saw that but I referred to the ATOM_LIST not the ATOM_TYPE, thanks again A. Le 17 mars 11 ? 10:29, matteo calandra a ?crit : > Dear Alain, > > as you can read in the manual of the XSPECTRA code, > xiabs must be the type of the absorbing atom. In your case, > as you put the Ch as the second atom type, then your xiabs > must be 2. > > For what concerns the london option this has never been tested. > I have no idea where the DFT-D part of the code is and how it > interact with > the rest. So it will probably not work. But this is an independent > problem. > > Finally note that here > > http://cdsagenda5.ictp.it/full_display.php?agenda_id=3218 > > you can find my lectures on xspectra in which the case of diamond is > treated. > Convergence with respect to the cell size is very pathological in > diamond. > > All the best, M. > > > > > Quoting pw_forum-request at pwscf.org: > >> Send Pw_forum mailing list submissions to >> pw_forum at pwscf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://www.democritos.it/mailman/listinfo/pw_forum >> or, via email, send a message with subject or body 'help' to >> pw_forum-request at pwscf.org >> >> You can reach the person managing the list at >> pw_forum-owner at pwscf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Pw_forum digest..." >> >> >> Today's Topics: >> >> 1. Re: XSpectra on graphite slab (Paolo Giannozzi) >> 2. Re: norm conserving Ti pseudopotential (Nicola Marzari) >> 3. Re: XSpectra on graphite slab (Alain Allouche) >> >> >> -- >> >> Message: 1 >> Date: Wed, 16 Mar 2011 23:12:12 +0100 >> From: Paolo Giannozzi >> Subject: Re: [Pw_forum] XSpectra on graphite slab >> To: PWSCF Forum >> Message-ID: >> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed >> >> On Mar 16, 2011, at 16:22 , Alain Allouche wrote: >> >>> Can somebody explain me the curious behavior of pw.x accepting Ch >>> on diamond and not on graphite, and this "Wrong xiabs!!!" ?? >> >> >> I'll do half of the job. It is the "london" option that makes the >> difference. >> Actually "Ch" is not acceptable syntax, or, more exactly: function >> "atomic_number" accepts "X", "Xn", n=0,...,9, "X-*", "X_*", where X >> is any atomic symbol. "Xh" confuses it. Since such routine is not >> actually >> called, except in some special cases (DFT-D is one such cases), >> this has >> gine unnoticed until now >> >> P. >> --- >> Paolo Giannozzi, Dept of Chemistry, >> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy >> Phone +39-0432-558216, fax +39-0432-558222 >> >> >> >> >> >> >> -- >> >> Message: 2 >> Date: Wed, 16 Mar 2011 22:49:17 + >> From: Nicola Marzari >> Subject: Re: [Pw_forum] norm conserving Ti pseudopotential >> To: PWSCF Forum >> Cc: Paolo Giannozzi >> Message-ID: <4D813E6D.4040001 at materials.ox.ac.uk> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 3/16/11 6:15 PM, Paolo Giannozzi wrote: >>> >>> On Mar 16, 2011, at 19:01 , Nicola Marzari wrote: >>> >>>> Worse case scenario: download/compile the fritz-haber >>>> pseudopotential >>>> code, generate the troullier-martins Ti there, and convert it to >>>> UPF >>>> with the fhi2upf tool in the upftools directory of Q-E. >>> >>> this can be done directly with the "atomic" code in QE. Generating a >>> single-channel >>> norm-conserving PP without semi-core states is trivial and well >>> documented. >>> >> >> >> I agree - one still needs to choose core radii wisely, and avoid >> ghost states - so one could use those chosen by the fhi code. I also >> recall that Philippe Gosez, in his PhD thesis, had good/tested >> values - >> maybe one could ask him what he used. >> >> Thanks to Derek for pointing out the pseudo vault, as well. >> >> nicola >> >> -- >> Prof Nicola MarzariDepartment of MaterialsUni
[Pw_forum] XSpectra on graphite slab
Merci Paolo, I should have though by myself... But even without London, after the right results of pw, XSpectra gives the message which I had not with diamondh - --- Polarisation and k vector [cartesian coordinates] xepsilon(:)= 1. 0. 0. xkvec(:)= 1. 0. 0. % % from main program : error #63 Wrong xiabs!!! % % stopping ... using these data: _xspectra calculation='fermi_level', prefix='graphite', xread_wf=.true., xiabs=1 / / filecore='C.wfc', / _occ / 6 6 1 0 0 0 I saw in the source that this error occurs when the atom's type is not found, but which one? I cannot understand regards Alain Le 16 mars 11 ? 23:12, Paolo Giannozzi a ?crit : > On Mar 16, 2011, at 16:22 , Alain Allouche wrote: > >> Can somebody explain me the curious behavior of pw.x accepting Ch >> on diamond and not on graphite, and this "Wrong xiabs!!!" ?? > > > I'll do half of the job. It is the "london" option that makes the > difference. > Actually "Ch" is not acceptable syntax, or, more exactly: function > "atomic_number" accepts "X", "Xn", n=0,...,9, "X-*", "X_*", where X > is any atomic symbol. "Xh" confuses it. Since such routine is not > actually > called, except in some special cases (DFT-D is one such cases), this > has > gine unnoticed until now > > P. > --- > Paolo Giannozzi, Dept of Chemistry, > Univ. Udine, via delle Scienze 208, 33100 Udine, Italy > Phone +39-0432-558216, fax +39-0432-558222 > > > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum
[Pw_forum] XSpectra on graphite slab
Hi Derek, Of course I have it taken from the XS example pseudo files, I used it first on the diamondh case (I just duplicate and adapted the data files) Best Alain Le 16 mars 11 ? 16:41, Derek Stewart a ?crit : > Hi Alain, > > A quick question on your problem with the Ch atom. Did you have the > corresponding pseudopotential, "Ch_PBE_TM_2pj.UPF" in the pseudo > directory? > > Best regards, > > Derek > > > > > Derek Stewart, Ph. D. > Senior Research Associate > ** New Webpage ** > http://sites.google.com/site/dft4nano/ > 250 Duffield Hall > Cornell Nanoscale Facility (CNF) > Ithaca, NY 14853 > stewart (at) cnf.cornell.edu > (607) 255-2856 > > > > On 3/16/2011 11:22 AM, Alain Allouche wrote: >> Dear Espressionists, >> I tried to run the diamond example in espresso-4.2-examples/examples/ >> XSpectra_example and it works fine using espresso-4.2. Threfore I >> duplicated the diamond files to make the calculation on graphite and >> the input looks like: >> >> >> calculation='scf' >> restart_mode='from_scratch', >> ! restart_mode='restart', >> ! pseudo_dir = '/Users/allouche/pseudo_espresso/' >> ! pseudo_dir = '/homegpfs/rech/ams/rams001/pseudo_espresso/' >> pseudo_dir = '/home/allouche/pseudo_espresso' >> prefix='graphite' >> / >> >> ibrav = 4 >> a =9.880, >> b =9.880, >> c =20. >> cosab = 0.0 >> cosac = 0.0 >> cosbc = -0.5 >> nat= 64 >> ntyp= 2, >> ecutwfc=40. >> tot_charge=+1.0, >> degauss=0.001 >> nspin = 1 >> london=.true. >> / >> >> mixing_beta = 0.3, >> startingwfc = 'file' >> / >> ATOMIC_SPECIES >> C 12 C_PBE_TM_2pj.UPF >> Ch 12 Ch_PBE_TM_2pj.UPF >> ATOMIC_POSITIONS crystal >> Ch 0.166589 0.083384 0.827761 >> C 0.249912 0.250043 0.827591 >> C 0.80 0.166614 0.665253 >> C 0.250046 0.249946 0.665282 >> C 0.166590 0.82 0.827797 >> C 0.249927 0.500060 0.827753 >> C 0.81 0.416617 0.665261 >> C 0.250049 0.499953 0.665288 >> C 0.166617 0.583430 0.827809 >> C 0.249925 0.750054 0.827751 >> C 0.82 0.16 0.665260 >> C 0.250048 0.749950 0.665286 >> C 0.166616 0.833367 0.827787 >> C 0.249927 0.45 0.827690 >> C 0.84 0.916617 0.665257 >> C 0.250048 0.46 0.665282 >> C 0.416586 0.083370 0.827522 >> C 0.499907 0.250007 0.827142 >> C 0.583384 0.166614 0.665248 >> C 0.500045 0.249945 0.665274 >> C 0.416562 0.69 0.827235 >> C 0.499907 0.500070 0.827236 >> C 0.583381 0.416619 0.665246 >> C 0.500048 0.499951 0.665283 >> C 0.416589 0.583393 0.827627 >> C 0.499919 0.750051 0.827751 >> C 0.583381 0.16 0.665259 >> C 0.500046 0.749950 0.665287 >> C 0.416552 0.833366 0.827806 >> C 0.499916 0.42 0.827678 >> C 0.583386 0.916617 0.665253 >> C 0.500047 0.47 0.665279 >> C 0.666599 0.083383 0.827729 >> C 0.749937 0.250040 0.827505 >> C 0.833385 0.166614 0.665243 >> C 0.750051 0.249946 0.665273 >> C 0.13 0.68 0.827149 >> C 0.749971 0.500070 0.827145 >> C 0.833384 0.416616 0.665248 >> C 0.750053 0.499953 0.665273 >> C 0.11 0.583417 0.827236 >> C 0.749935 0.750067 0.827591 >> C 0.833383 0.18 0.665251 >> C 0.750054 0.749954 0.665279 >> C 0.666599 0.833390 0.827795 >> C 0.749964 0.70 0.827829 >> C 0.833383 0.916619 0.665245 >> C 0.750052 0.50 0.665271 >> C 0.916596 0.083383 0.827854 >> C 0.10 0.250017 0.827831 >> C 0.083378 0.166616 0.665246 >> C 0.49 0.249946 0.665273 >> C 0.916598 0.82 0.827732 >> C 0.37 0.500062 0.827682 >> C 0.083381 0.416612 0.665255 >> C 0.52 0.499951 0.665280 >> C 0.916611 0.583397 0.827525 >> C 0.32 0.750051 0.827692 >> C 0.083381 0.15 0.665256 >> C 0.52 0.749950 0.665280 >> C 0.916597 0.833392 0.827762 >> C 0.09 0.71 0.827828 >> C 0.083381 0.916617 0.665250 >> C 0.50 0.49 0.665269 >> K_POINTS Automatic >> 6 6 1 0 0 0 >> >> FIRST PROBLEM: expresso-4.2 and 4.1 do not like atom Ch (they did for >> diamond): >> >> This program is part of the open-source Quantum ESPRESSO suite >> for quantum simulation of materials; please cite >> "P. Giannozzi et al., J. Phys.:Condens. Matter 21 395502 >> (2009); >>URL http://www.quantum-espresso.org;, >>
[Pw_forum] XSpectra on graphite slab
000 0. % % from main program : error #63 Wrong xiabs!!! % % stopping ... rank 30 in job 1 node08_33288 caused collective abort of all ranks exit status of rank 30: killed by signal 9 rank 25 in job 1 node08_33288 caused collective abort of all ranks exit status of rank 25: killed by signal 9 rank 15 in job 1 node08_33288 caused collective abort of all ranks exit status of rank 15: killed by signal 9 rank 0 in job 1 node08_33288 caused collective abort of all ranks exit status of rank 0: killed by signal 9 Can somebody explain me the curious behavior of pw.x accepting Ch on diamond and not on graphite, and this "Wrong xiabs!!!" ?? Thank you in advance Dr. Alain ALLOUCHE Physique des Interactions Ioniques et Moleculaires CNRS / Universite de Provence Campus Saint Jerome Service 242 Avenue de l'Escadrille Normandie-Niemen 13397 Marseille Cedex 20 - France Tel : +33 (0) 4 91 28 85 76 Mobile:+33 681 84 80 66 Fax : +33 491.28.89.05 email: Alain.Allouche at univ-provence.fr
[Pw_forum] PWscf and highly parallel machines
I wonder if somebody have the experience of PW codes running on highly parallel machines like in those of the DEISA supercomputing grid, are the codes like pw.x supporting such an environment ? Thanks a lot
[Pw_forum] projwfc.x
Dear all, Running PROJWFC I often get the message: %% from davcio : error #10 i/o error in davcio %% although the pw.x step worked allright, what is the problem ? Thanks a lot
[Pw_forum] (no subject)
Dear all, I am trying to perform a temperature rescaling MD with PWscf ion_dynamics = 'verlet' ion_temperature = 'rescaling' tempw = 500.0 nraise = 1 tolp = 1.d-8 wfc_extrapolation = 'first_order' / The starting temperature is correct but it decreases very rapidly 358: Starting temperature = 500.00 K 405: temperature = 496.70493449 K 693: temperature = 0.24166052 K 903: temperature = 0.21332563 K 1113: temperature = 0.18863928 K 1323: temperature = 0.16711531 K 1533: temperature = 0.14835294 K 1743: temperature = 0.13194319 K 1953: temperature = 0.11759977 K 2163: temperature = 0.10503616 K 2373: temperature = 0.09401538 K 2583: temperature = 0.08433571 K 2793: temperature = 0.07582100 K 3003: temperature = 0.06832018 K 3213: temperature = 0.06170251 K 3423: temperature = 0.05585484 K 3633: temperature = 0.05067925 K 3843: temperature = 0.04609150 K 4053: temperature = 0.04201768 K 4263: temperature = 0.03839409 K 4473: temperature = 0.03516576 K 4683: temperature = 0.03228480 K The question is: what is the printed values ? the real scaled temperature, the temperature "before" scaling, the difference between the the calculated and the wanted temperature ? Thanks for your help -- next part -- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060112/d92c67ff/attachment.htm -- next part -- A non-text attachment was scrubbed... Name: Alain.Allouche.vcf Type: text/x-vcard Size: 530 bytes Desc: not available Url : /pipermail/attachments/20060112/d92c67ff/attachment.vcf
