[Wien] Knight's Landing
Has anyone testing Wien2k -- clues what is best? -- Professor Laurence Marks "Research is to see what everybody else has seen, and to think what nobody else has thought", Albert Szent-Gyorgi www.numis.northwestern.edu ; Corrosion in 4D: MURI4D.numis.northwestern.edu Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent Co-Editor, Acta Cryst A ___ 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 doping while preserving symmetry
No, you cannot preserve symmetry -- think about it! On Thu, Jun 29, 2017 at 8:47 AM, Chouaib AHMANI FERDI < ahmaniferdichou...@gmail.com> wrote: > Hello Wien users, > > I would like to know if it can be possible to reduce the calculation time > by preserving symmetry and replacing one atom of the non equivalent atoms > with the doping atom. If possible, how ? > > The case structure is LiMn2O4 (space group : fd3m) and the doping atom is > Ni which gives : LiNi0.5Mn1.5O4 > > Faithfully, > > > -- > AHMANI FERDI Chouaïb > Ph.D Student in Material Science > Ecole Normale Supérieure > Mohammed V University, Rabat. > Tel : +212 6 94 59 57 60 > > > -- Professor Laurence Marks "Research is to see what everybody else has seen, and to think what nobody else has thought", Albert Szent-Gyorgi www.numis.northwestern.edu ; Corrosion in 4D: MURI4D.numis.northwestern.edu Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent Co-Editor, Acta Cryst A ___ 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] help doping while preserving symmetry
Hello Wien users, I would like to know if it can be possible to reduce the calculation time by preserving symmetry and replacing one atom of the non equivalent atoms with the doping atom. If possible, how ? The case structure is LiMn2O4 (space group : fd3m) and the doping atom is Ni which gives : LiNi0.5Mn1.5O4 Faithfully, -- AHMANI FERDI Chouaïb Ph.D Student in Material Science Ecole Normale Supérieure Mohammed V University, Rabat. Tel : +212 6 94 59 57 60 ___ 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] Wien2wanner wplot error
Dear Elias and wien2wannier user, I tried to plot the wannier orbital of a perovskite system. Everything went well until the command x wplot -wf m. It creates the necessary case_m.psink and case_m.psiarg output files but, when i give the command wplot2xsf following error comes out.. File "/home/kjyoti/WIEN2k_14/wplot2xsf", line 375, in if psink.readline().split()[0] != '3D': IndexError: list index out of range Any suggestion will be highly appreciated. Thanks Avijeet -- Avijeet Ray Research Scholar Department of Physics Indian Institute of Technology Roorkee Roorkee -247667 Uttarakhand India Mob: +91 8938908313 ___ 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] Parallelization and PBS on a single computer
/var/spool/torque/mom_priv/jobs/44.milkbar-computer.kage.SC: line 12: run_lapw: command not found Perhaps the environmental variables need pushed out to all nodes, you might try adding the line #PBS -V [1,2] to your job submission script. [1] http://www.nics.tennessee.edu/node/387 [2] http://www.open-mpi.org/community/lists/users/2008/10/6982.php On 6/28/2017 11:49 PM, Yoji Kobayashi wrote: Dear Users, I have a some questions/problems regarding parallelization and PBS. I’m not sure if I’m really running parallel vs. serial, and my PBS script isn’t working. === My system info: Intel Xeon CPU E5-2630 v2 @2.6 GHz, 24 CPUS Memory: 32GB Running Wien2k_13, on Ubuntu 14.04.03 File system: ext4 (This is considered a single node with 24 processors?) === My first question is, am I really running a parallel calculation in a meaningful way? What I try: In w2web, a serial calculation (SCF only) for the TiC example (500 k points) takes about 25 sec. to converge. I do the same calculation (starting with a new case) but setting parallelization in w2web, with slightly different .machine files for each case: Case 1: 1:localhost Case 2 (i.e. 20 lines of below): 1:localhost 1:localhost … 1:localhost 1:localhost Case 3 1:localhost:20 (no lines referring to granularity, etc for now) What I get: Case 1 computes in about 54 sec; Case 2 computes in 1min23 sec.; Case 3 gives an error in runninglapw2, see thedayfile below: - Calculating YK-016-TiC in /home/milkbar/Yoji/YK-016-TiC on milkbar-computer with PID 18077 using WIEN2k_13.1 (Release 17/6/2013) in /home/milkbar/WIEN2k_13 start (2017å¹´ 6月 29æ—¥ 木曜日 14:23:39 JST) with lapw0 (40/99 to go) cycle 1(2017å¹´ 6月 29æ—¥ 木曜日 14:23:39 JST)(40/99 to go) > lapw0 -p (14:23:39) starting parallel lapw0 at 2017å¹´ 6月 29æ—¥ 木曜日 14:23:39 JST .machine0 : processors running lapw0 in single mode 1.7u 0.0s 0:01.84 98.3% 0+0k 16+440io 0pf+0w > lapw1 -p(14:23:41) starting parallel lapw1 at 2017å¹´ 6月 29æ—¥ 木曜日 14:23:41 JST -> starting parallel LAPW1 jobs at 2017å¹´ 6月 29æ—¥ 木曜日 14:23:41 JST running LAPW1 in parallel mode (using .machines) 1 number_of_parallel_jobs localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost(20) 20 total processes failed to start 0.0u 0.0s 0:00.20 10.0% 0+0k 8080+8io 23pf+0w Summary of lapw1para: localhostk=0 user=0 wallclock=0 0.0u 0.0s 0:02.10 0.9% 0+0k 8208+216io 24pf+0w > lapw2 -p (14:23:43) running LAPW2 in parallel mode ** LAPW2 crashed! 0.0u 0.0s 0:00.07 28.5% 0+0k 32+104io 0pf+0w error: command /home/milkbar/WIEN2k_13/lapw2para lapw2.def failed > stop error -- Is my “serial” calculation actually processed over 24 CPUs already, so this is why it is faster than Case 2? Or am I doing something wrong? Why does Case 3 crash? My second question is about PBS. I installed torque PBS, and created a queue: # create default queue qmgr -c 'create queue batch' qmgr -c 'set queue batch queue_type = execution' qmgr -c 'set queue batch started = true' qmgr -c 'set queue batch enabled = true' qmgr -c 'set queue batch resources_default.walltime = 1:00:00' qmgr -c 'set queue batch resources_default.nodes = 1' qmgr -c 'set server default_queue = batch’ and followed other instructions on https://jabriffa.wordpress.com/2015/02/11/installing-torquepbs-job-scheduler-on-ubuntu-14-04-lts/ The PBS system seems to work since I can submit very simple scripts and see them on qstat. My problem is that when I try to submit a serial wien2k job via PBS, it gives me an error (ultimately of course I’d like to submit them as parallel, but because of the ambiguity above I’ve kept it to serial) . Here's the PBS script and error message: #!/bin/tcsh ##PBS -A your_allocation # specify the allocation. Change it to your allocation #PBS -q batch #PBS -l nodes=1:ppn=20 #PBS -l walltime=1:00:00 #PBS -o wien2k_output #PBS -j oe #PBS -N wien2k_test cd $PBS_O_WORKDIR echo hello run_lapw -i 40 -ec .0001 -I Error message (contents of wien2k_output): hello /var/spool/torque/mom_priv/jobs/44.milkbar-computer.kage.SC: line 12: run_lapw: command not found The job is listed as complete in qstat, and the “hello” is written into thewien2k_output file. Changing the cd $PBS_O_WORKDIR to the path for the current case hasn’t changed anything. I can run run_lapwfrom the command line fine, though. Also, what do I write for allocation? (I commented it out, as I see other PBS scripts don’t always have this.) I’ve also tried the parallel case, with the following PBS script. I set up the .structure file and do the initialization with w2web. I leave the “parallel calculation” option unchecked when setting up the case file in w2web. #!/bin/tcsh ##PBS -A
Re: [Wien] Parallelization and PBS on a single computer
I hope you did read the chapter about parallelization in the UG ?? Then you should know what the 3 cases actually do. A few remarks: case 2: This is k-point parallelization and you are running just 1 k-point in each lapw1 case. Now the time for one k-point is very short (if it is standard TiC it should be below 0.1 sec/k). In this mode you have to span 20 jobs (which are even delayed by DELAY seconds in lapw1para_lapw) and this takes MUCH more time then the actual run time of 20 k-points on a single core. In essence: you cannot speedup with parallelization to an arbitrary level, but you have to "think" or eventually test each case individually until you get a feeling what the optimal number of cores is for your present input. If the single core time is "nearly zero", parallelization will not be faster, but in fact it will be SLOWER due to parallelization overhead and this is what you observe. PS: In addition: If one k-point on one core takes 10 seconds, if you run 20 such jobs in parallel, each single job will be MUCH slower. These Intel multicore cpus are "memory-bus limited", i.e. Intel sells you expensive cpus with 24 cores, but the memory bus can handle only much less cores efficiently and in fact these many cores are useless for most (memory bound applications) applications and everything slows down when you try to use all of them. case 3) this is mpi-fine grain parallelization. Basically here the same thing is happening: Splitting up such a small matrix on 20 cores is very inefficient and will run slower than a non-parallel run. It is mentioned explicitly in the UG that you should use mpi-parallelization for cells with more than 50 atoms. Your tests will be VERY different, when you use a "big" case with a larger unit cell. Strategy: Use larger cases for parallel tests. Always monitor your tests with the "top" command, so that you can see what happens. Try to use "export OMP_NUMB_THREAD 2" (or 4 or 8) and check timings. This uses 2 or 4 cores in all blas calls (large fraction of lapw1). I don't know why your mpi-job crashes in lapw2. There must be more info ... PBS error: obviously your PBS does not transfer the "environment". When you type: run_lapw, the system finds this command because it is in your PATH, which was defined in your .bashrc file. The PBS job does not take over your environment. Probably you can fix this by including "source ~/.bashrc" in the script. On 06/29/2017 07:49 AM, Yoji Kobayashi wrote: Dear Users, I have a some questions/problems regarding parallelization and PBS. I’m not sure if I’m really running parallel vs. serial, and my PBS script isn’t working. === My system info: Intel Xeon CPU E5-2630 v2 @2.6 GHz, 24 CPUS Memory: 32GB Running Wien2k_13, on Ubuntu 14.04.03 File system: ext4 (This is considered a single node with 24 processors?) === My first question is, am I really running a parallel calculation in a meaningful way? What I try: In w2web, a serial calculation (SCF only) for the TiC example (500 k points) takes about 25 sec. to converge. I do the same calculation (starting with a new case) but setting parallelization in w2web, with slightly different .machine files for each case: Case 1: 1:localhost Case 2 (i.e. 20 lines of below): 1:localhost 1:localhost … 1:localhost 1:localhost Case 3 1:localhost:20 (no lines referring to granularity, etc for now) What I get: Case 1 computes in about 54 sec; Case 2 computes in 1min23 sec.; Case 3 gives an error in runninglapw2, see thedayfile below: - Calculating YK-016-TiC in /home/milkbar/Yoji/YK-016-TiC on milkbar-computer with PID 18077 using WIEN2k_13.1 (Release 17/6/2013) in /home/milkbar/WIEN2k_13 start (2017å¹´ 6月 29æ—¥ 木曜日 14:23:39 JST) with lapw0 (40/99 to go) cycle 1 (2017å¹´ 6月 29æ—¥ 木曜日 14:23:39 JST)(40/99 to go) lapw0 -p (14:23:39) starting parallel lapw0 at 2017å¹´ 6月 29æ—¥ 木曜日 14:23:39 JST .machine0 : processors running lapw0 in single mode 1.7u 0.0s 0:01.84 98.3% 0+0k 16+440io 0pf+0w lapw1 -p (14:23:41) starting parallel lapw1 at 2017å¹´ 6月 29æ—¥ 木曜日 14:23:41 JST -> starting parallel LAPW1 jobs at 2017å¹´ 6月 29æ—¥ 木曜日 14:23:41 JST running LAPW1 in parallel mode (using .machines) 1 number_of_parallel_jobs localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost localhost(20) 20 total processes failed to start 0.0u 0.0s 0:00.20 10.0% 0+0k 8080+8io 23pf+0w Summary of lapw1para: localhost k=0 user=0 wallclock=0 0.0u 0.0s 0:02.10 0.9% 0+0k 8208+216io 24pf+0w lapw2 -p (14:23:43) running LAPW2 in parallel mode ** LAPW2 crashed! 0.0u 0.0s 0:00.07 28.5% 0+0k 32+104io 0pf+0w error: command /home/milkbar/WIEN2k_13/lapw2para lapw2.def failed stop error -- Is my “serial” calculation actually
Re: [Wien] Problem Regarding SLATER Calculations
Using WIEN2k 16.1 with the x_lapw.patch [1]? If not, perhaps try the patch and see if the Unmatched error goes away or not. [1] https://github.com/gsabo/WIEN2k-Patches/tree/master/16.1 On 6/29/2017 1:41 AM, t...@theochem.tuwien.ac.at wrote: The Slater potential is not calculated because the HF module is not executed. This is probably because of Unmatched " which I don't yet understand where it comes from. A few questions: Which solid are you considering? What is exactly the command that you used to start the calculation? What is the name of the directory? On Wednesday 2017-06-28 22:02, apa...@iitk.ac.in wrote: Date: Wed, 28 Jun 2017 22:02:38 From: apa...@iitk.ac.in Reply-To: A Mailing list for WIEN2k usersTo: wien@zeus.theochem.tuwien.ac.at Subject: Re: [Wien] Problem Regarding SLATER Calculations The STDOUT hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END STOP MIXER END in cycle 2ETEST: 0 CTEST: 0 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END STOP MIXER END in cycle 3ETEST: 0 CTEST: 0 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 4ETEST: .02503978 CTEST: .182651 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 5ETEST: .081043035000 CTEST: .089823 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 6ETEST: .05105681 CTEST: .018457 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 7ETEST: .01306470 CTEST: .002347 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 8ETEST: .002592665000 CTEST: .000702 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 9ETEST: .00043674 CTEST: .28 hup: Command not found. STOP LAPW0 END STOP LAPW0 END
Re: [Wien] symmetry broken for Cccm
Dear Igor, I looked into this subtle problem and came to the following conclusions: a) There is nothing wrong with the code. Calculations in i) I4/mmm (B-lattic, a a c), ii) Cccm (doubled unit cell, CXY, a*sqrt2,c,a*sqrt2)and the iii) Pma2 (primitive (again doubled) supercell, a+sqrt2,a*sqrt2,c) yield total energies of E, 2E and 4E within microRy precision, identical charges, b) with respect to band structures there seems to be a subtle difficulty in interpreting the back-folding, which occurs in these cases. I attach two plots for only a small (not over crowded) E-window to make the effects more clear. i) The first plot in the smallest cell (I4/mmm) shows the bands from Gamma-X, but shown actually from Gamma-AB(1/4,1/4,0) and X(labelled 2AB)(1/2,1/2,0)-AB(1/4,1/4,0), because this is what you will see when backfolding the BZ in the larger cell. ii) The other plot in Cmmc (doubled cell, rotated) shows the bands from C (0,0,1/2) - Gamma - A(1/2,0,0) - 2A(1,0,0). Obviously, the results of C-Gamma agree with the backfolded bands of i) (after overlaying them and mirroring). On the other hand, out of the 4 bands C-Gamma, only the 1st and 4th of Gamma-A agree, while the other two disagree. However, if I continue in this direction up to 2A, I can find in A-2A the 2 "missing bands". So actually the C-Gamma direction is equivalent to Gamma-2A, but the latter also contains some other backfolded direction of the original I4/mmm cell (which I'm too lazy to identify ...) So obviously, backfolding in these various centered cells is more difficult, but for sure consistently included. Best regards Peter On 06/27/2017 08:31 PM, mazin wrote: Hi, I am running a pretty standard calculation for the BaFe2As2 superconductor; have done zillions of those before. For testing purposes, I wanted to plot bands for the double-cell AF structure (.struct attached), but for the nonmagnetic case and, again, I do think I did the same before with no problems. Now I am using the 14.2, and it may be that I had used other versions before. Without magnetism, this structure is equivalent to I4/mmm (and WIEN2k does find this symmetry, if both Fe are made equivalent), so the resulting band must, up to numerical noise, possess full tetragonal symmetry. Yet, the bands along Gamm-X and Gamm-Y are noticeably different (note that in this setting X=(1,0,0), but Y=(0,0,1)). If I use the conventional cell (doubled, Pccm), the resulting bands have proper symmetry - even though the underlying unit cell is orthorhombic. So, the problem appears if the cell is base-centered. Thanks! ___ 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 -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at WWW: http://www.imc.tuwien.ac.at/TC_Blaha -- RUN1.spaghetti_ps.gz Description: GNU Zip compressed data tetra.spaghetti_ps.gz Description: GNU Zip compressed data ___ 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] Problem Regarding SLATER Calculations
The Slater potential is not calculated because the HF module is not executed. This is probably because of Unmatched " which I don't yet understand where it comes from. A few questions: Which solid are you considering? What is exactly the command that you used to start the calculation? What is the name of the directory? On Wednesday 2017-06-28 22:02, apa...@iitk.ac.in wrote: Date: Wed, 28 Jun 2017 22:02:38 From: apa...@iitk.ac.in Reply-To: A Mailing list for WIEN2k usersTo: wien@zeus.theochem.tuwien.ac.at Subject: Re: [Wien] Problem Regarding SLATER Calculations The STDOUT hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END STOP MIXER END in cycle 2ETEST: 0 CTEST: 0 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END STOP MIXER END in cycle 3ETEST: 0 CTEST: 0 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 4ETEST: .02503978 CTEST: .182651 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 5ETEST: .081043035000 CTEST: .089823 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 6ETEST: .05105681 CTEST: .018457 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 7ETEST: .01306470 CTEST: .002347 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 8ETEST: .002592665000 CTEST: .000702 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched ". STOP LAPW2 END Unmatched ". STOP CORE END STOP CORE END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP MIXER END in cycle 9ETEST: .00043674 CTEST: .28 hup: Command not found. STOP LAPW0 END STOP LAPW0 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP LAPW1 END STOP LAPW2 END Unmatched