One of my nodes died last night. It's got a Corsair GS700, AsRock 990FX Extreme 3 mobo and an AMD FX 8150 cpu. The mobo and PSU are 2 years old, whereas the CPU is over three.
In it's full configuration, it refuses to turn on. There's no indication that there's any power. No lights, no fan movements, no beeps.
I checked the PSU, and it's fine.
I then discovered that if I only plug in the 24-pin motherboard PSU connector, but don't attach the 8-pin EDS CPU power, the computer behaves as if there's power i.e. all fans, including on PIC-E VGA card, spin etc.
There's no output though, and no POST beeps.
Plugging in the EDS/ATX12V1 cable again leads to a dead system.
Removing the CPU or RAM still yields a dead system (not sure what a mobo without a CPU is supposed to do i.e. whether it's supposed to POST. Either way, it's dead).
The CMOS battery tests fine with a DMM. The EDS/ATX12V1 output yields 12 V on all four yellow pins.
The power button is obviously working given that the system 'turns on' when the EDS cable is unplugged.
So it's down to the MOBO or CPU being faulty.
I've ordered a POST card and a CPU socket tester, and will update when I've done further diagnostics.
UPDATE 18/11: I put an old Phenom II in the socket. System still won't light up. This points towards the motherboard being dead. That's not a bad thing as the mobo might still be under warranty.
Lindqvist - a blog about Linux and Science. Mostly.
12 November 2015
15 October 2015
624. Gaussian fails with "traps: l502.exe[12449] general protection ip:d75df7 sp:7f7de40dcce0 error:0 in l502.exe[400000+dc8000]" on i7-5820K
Update:
* The systems is rock solid with nwchem and ADF. Only G09 crashes
* Gaussian has now released G09E, and the release notes say: "A Sandybridge/Haswell binary distribution is also available". Remains to be found out if this new version solves the issue. I can't check, as I don't have access to that version.
Update 18 Oct 2015:
TL;DR version: G09D (EM64T and AMD64) crash within the first 30 min to 4 hours. An NWChem job has so far run 6 days without crashing and is still going strong.
Original post:
This isn't much of a post yet. I'm mostly posting this so that people searching online will see that they aren't alone.
I just built a new node:
AU$559 Intel BX80648I75820K 6 Core i7-5820K 3.3Ghz 15MB LGA-2011-V3 (No Heatsink)
AU$407 Gigabyte X99-SLI Intel X99 S2011-3 8xDDR4/4xPCI-E/Intel GBLan/ATX Motherboard
AU$50 DeepCool FrostWin v2.0 CPU cooler
AU$155x2 Patriot 16G Kit (8Gx2) DDR4 2133 Desktop RAM
AU$185 Antec HCG-900 High Current Gamer Gaming PSU
AU$39 Gigabyte N210SL-1GI 1GB GT210 PCI-E VGA Card
AU$68 Seagate 3.5" Barracuda 1TB ST1000DM003 SATA3 7200RPM 64MB HDD (carbon)
AU$76 Antec GX500B-W Dominator Window USB3.0 Gaming Case without PSU
I've got an installation of up-to-date Jessie on it, with the following kernel: Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) x86_64 GNU/Linux.
When running G09D rev. 01 EM64T I keep getting random errors along these lines (these are collected over a couple of days and between restarts):
Sometimes the crashes happen after 30 minutes, sometimes after 3 hours. Most happen within four hours. I seem to remember that one ran up to 12 hours, but nothing's gone beyond that. Some short (1h 30 min) calculations have managed to run to completion.
I've checked each RAM stick with memtest+ -- they are fine -- and they are distributed as recommended in the motherboard manual.
The temperature is running below 40 degrees Celsius.
The harddrive is fine according to SMART.
I log everything every two minutes, and so can go back and look at what happened right before the crash, but there's nothing odd.
My current best three hypotheses are:
* There's an issue with G09D EM64T and the new generation of LGA2011-v3 i7 intel cpus specifically
* There's an issue with any version of G09D and the new generation of LGA2011-v3 i7 intel cpus
* There's an issue with my system which is independent of G09D.
To test, I'll be:
* Do runs with G09D rev. 01 AMD64
Done -- this also crashed.
* Do runs with NWChem 6.5 (ifort, mkl)
Running -- 6 days so far without a crash!
* Update the BIOS (long shot)
* Remove CPU and check for bent pins (long, arduous shot)
I'll be posting updates...
* The systems is rock solid with nwchem and ADF. Only G09 crashes
* Gaussian has now released G09E, and the release notes say: "A Sandybridge/Haswell binary distribution is also available". Remains to be found out if this new version solves the issue. I can't check, as I don't have access to that version.
Update 18 Oct 2015:
TL;DR version: G09D (EM64T and AMD64) crash within the first 30 min to 4 hours. An NWChem job has so far run 6 days without crashing and is still going strong.
Original post:
This isn't much of a post yet. I'm mostly posting this so that people searching online will see that they aren't alone.
I just built a new node:
AU$559 Intel BX80648I75820K 6 Core i7-5820K 3.3Ghz 15MB LGA-2011-V3 (No Heatsink)
AU$407 Gigabyte X99-SLI Intel X99 S2011-3 8xDDR4/4xPCI-E/Intel GBLan/ATX Motherboard
AU$50 DeepCool FrostWin v2.0 CPU cooler
AU$155x2 Patriot 16G Kit (8Gx2) DDR4 2133 Desktop RAM
AU$185 Antec HCG-900 High Current Gamer Gaming PSU
AU$39 Gigabyte N210SL-1GI 1GB GT210 PCI-E VGA Card
AU$68 Seagate 3.5" Barracuda 1TB ST1000DM003 SATA3 7200RPM 64MB HDD (carbon)
AU$76 Antec GX500B-W Dominator Window USB3.0 Gaming Case without PSU
I've got an installation of up-to-date Jessie on it, with the following kernel: Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) x86_64 GNU/Linux.
When running G09D rev. 01 EM64T I keep getting random errors along these lines (these are collected over a couple of days and between restarts):
[100433.566789] traps: l703.exe[11236] general protection ip:df18ca sp:7fc96f595268 error:0 in l703.exe[400000+a46000] [ 2587.899019] traps: l703.exe[3727] general protection ip:9c9757 sp:7fa6fc436ce0 error:0 in l703.exe[400000+a46000] [26439.755347] traps: l502.exe[3235] general protection ip:ab8a55 sp:7ffe29504c10 error:0 in l502.exe[400000+dc8000] [43030.457126] traps: l502.exe[427] general protection ip:11565a7 sp:7f2ec1fff268 error:0 in l502.exe[400000+dc8000] [ 2587.899019] traps: l703.exe[3727] general protection ip:9c9757 sp:7fa6fc436ce0 error:0 in l703.exe[400000+a46000] [37460.207608] traps: l703.exe[14649] general protection ip:a38ae0 sp:7f1a813cf8c0 error:0 in l703.exe[400000+a46000] [ 8865.403861] traps: l502.exe[12449] general protection ip:d75df7 sp:7f7de40dcce0 error:0 in l502.exe[400000+dc8000]
Sometimes the crashes happen after 30 minutes, sometimes after 3 hours. Most happen within four hours. I seem to remember that one ran up to 12 hours, but nothing's gone beyond that. Some short (1h 30 min) calculations have managed to run to completion.
I've checked each RAM stick with memtest+ -- they are fine -- and they are distributed as recommended in the motherboard manual.
The temperature is running below 40 degrees Celsius.
The harddrive is fine according to SMART.
I log everything every two minutes, and so can go back and look at what happened right before the crash, but there's nothing odd.
My current best three hypotheses are:
* There's an issue with G09D EM64T and the new generation of LGA2011-v3 i7 intel cpus specifically
* There's an issue with any version of G09D and the new generation of LGA2011-v3 i7 intel cpus
* There's an issue with my system which is independent of G09D.
To test, I'll be:
* Do runs with G09D rev. 01 AMD64
Done -- this also crashed.
* Do runs with NWChem 6.5 (ifort, mkl)
Running -- 6 days so far without a crash!
* Update the BIOS (long shot)
* Remove CPU and check for bent pins (long, arduous shot)
I'll be posting updates...
28 August 2015
623. Comparing frequency calculations in G09 and NWChem -- the importance of grid density
The vibrational entropy term will differ between calculations done in gaussian and nwchem unless you use "grid xfine" in nwchem. That the grid density is important is nothing new, but the magnitude of the effect on the entropy surprised me.
The difference can be large -- 30 cal/molK for [PPh4]+ at pbe0/cc-pvdz -- which becomes quite significant when multiplied by T (e.g. 298.15 K).
Note that the rotational entropy term also may differ, but that this would be due to different uses of symmetry in the calculations: http://molecularmodelingbasics.blogspot.com.au/2012/12/conformational-and-rotational-entropy.html
If you turn off symmetry (noautosym) in nwchem the rotational entropy will not be corrected. I've noticed that Gaussian, on the other hand, will sneakily apply correction if it finds an acceptable symmetry even if you request nosymm, so make sure that you scan through the output carefully.
Either way, vibrational entropy is not symmetry dependent. Instead you will have to worry about the grid fine-ness when comparing outputs.
If your molecule is very small, such as benzene or tetramethylphosphonium, it seems that you don't have to worry about this. However, even fairly small molecules such as [PPh4]+ will be affected.
Conv. Dens. = Convergence Density
F=fine. X=Extrafine. U=Ultrafine.
S(rot) values in blue are symmetry corrected. That's completely normal.
With "grid fine" NWChem gives a very different result to G09.
You can see the difference in the predicted IR spectra as well.
Fine (NWChem) (blue rings) vs G09 (red circles):
"grid xfine" (NWChem) (blue rings) vs G09 (red circles):
The difference can be large -- 30 cal/molK for [PPh4]+ at pbe0/cc-pvdz -- which becomes quite significant when multiplied by T (e.g. 298.15 K).
Note that the rotational entropy term also may differ, but that this would be due to different uses of symmetry in the calculations: http://molecularmodelingbasics.blogspot.com.au/2012/12/conformational-and-rotational-entropy.html
If you turn off symmetry (noautosym) in nwchem the rotational entropy will not be corrected. I've noticed that Gaussian, on the other hand, will sneakily apply correction if it finds an acceptable symmetry even if you request nosymm, so make sure that you scan through the output carefully.
Either way, vibrational entropy is not symmetry dependent. Instead you will have to worry about the grid fine-ness when comparing outputs.
If your molecule is very small, such as benzene or tetramethylphosphonium, it seems that you don't have to worry about this. However, even fairly small molecules such as [PPh4]+ will be affected.
Conv. Dens. = Convergence Density
| Code | Symm | Grid | Conv. Dens. | DFT Energy | ZPE | HCorr | S(tot) | S(trans) | S(rot) | S(vib) |
| G09 | N | F | 1E-8 | -1266.58424152 | 0.370516 | 0.389751 | 147.076 | 43.358 | 35.009 | 68.708 |
| G09 | N | U | 1E-8 | -1266.58430374 | 0.370464 | 0.389691 | 146.829 | 43.358 | 35.009 | 68.461 |
| NW | N | X | 1E-8 | -1266.58455223 | 0.370348 | 0.389549 | 146.697 | 43.339 | 34.994 | 68.365 |
| NW | N | X | 1E-5 | -1266.58455222 | 0.370348 | 0.389549 | 146.704 | 43.339 | 34.994 | 68.371 |
| NW | Y | F | 1E-5 | -1266.58453684 | 0.370034 | 0.385683 | 118.023 | 43.339 | 33.617 | 41.067 |
| NW | Y | F | 1E-8 | -1266.58453684 | 0.370034 | 0.385683 | 118.023 | 43.339 | 33.617 | 41.067 |
| NW | N | F | 1E-5 | -1266.58454928 | 0.370034 | 0.385683 | 119.394 | 43.339 | 34.994 | 41.062 |
| NW | N | F | 1E-8 | -1266.58454929 | 0.370034 | 0.385683 | 119.394 | 43.339 | 34.994 | 41.061 |
| NW | Y | X | 1E-5 | -1266.58455274 | 0.370348 | 0.389549 | 145.331 | 43.339 | 33.617 | 68.376 |
| NW | Y | X | 1E-8 | -1266.58455275 | 0.370348 | 0.389549 | 145.337 | 43.339 | 33.617 | 68.382 |
F=fine. X=Extrafine. U=Ultrafine.
S(rot) values in blue are symmetry corrected. That's completely normal.
With "grid fine" NWChem gives a very different result to G09.
You can see the difference in the predicted IR spectra as well.
Fine (NWChem) (blue rings) vs G09 (red circles):
21 August 2015
622. Crude comparison of a simple frequency calculation in different computational packages
I've given the input files at the bottom of the post.
The job is a simple benzene frequency calculation at PBE0/def2-tzvp. The jobs were run on an AMD FX 8150 with 32 gb ram (debian jessie 64 bit linux)
Orca 3.0.3 and G09 (AM64L rev D.01) were supplied as precompiled binaries.
Nwchem 6.5 and Gamess US 5 Dec 2014 (R1) were compiled by me, and the poor performance of either code may thus be due solely to something that I've done. Both codes were linked against ACML 5.3.1 and compiled with gfortran.
I'm also not familiar with orca and gamess, and so I don't know how to get the best performance from either code. I defined the basis set explicitly in all codes.
Also note that for other frequency calculations Orca seems orders of magnitude slower than NWChem -- in fact they are so slow that I haven't let them finish after waiting for a week, when in Nwchem they take a day.
Basically, my empirical but poorly-supported-by-data view is that G09 is by far the fastest, then Nwchem, then Orca and finally Gamess. In the case of Gamess this may well be due to how I compiled it.
Nwchem was compiled roughly as was shown here: http://verahill.blogspot.com.au/2014/09/593-nwchem-65-on-debian-jessie-and.html
I'll post the compilation of Gamess US 5/12/2014 R1 later.
Results
Note: Orca used a symmetry number of 3 in the calculation of S(rot). I've 'corrected' it back to the non-symmetry corrected value so that it can be compared with the output from the other codes. Likewise, I've divided the entropy terms from Orca by 298.15 K.
Overall the results agree very well across the codes although the electronic energy in Orca is noticably different from the others.
G09 input:
Orca input
nwchem input
gamess US input:
The job is a simple benzene frequency calculation at PBE0/def2-tzvp. The jobs were run on an AMD FX 8150 with 32 gb ram (debian jessie 64 bit linux)
Orca 3.0.3 and G09 (AM64L rev D.01) were supplied as precompiled binaries.
Nwchem 6.5 and Gamess US 5 Dec 2014 (R1) were compiled by me, and the poor performance of either code may thus be due solely to something that I've done. Both codes were linked against ACML 5.3.1 and compiled with gfortran.
I'm also not familiar with orca and gamess, and so I don't know how to get the best performance from either code. I defined the basis set explicitly in all codes.
Also note that for other frequency calculations Orca seems orders of magnitude slower than NWChem -- in fact they are so slow that I haven't let them finish after waiting for a week, when in Nwchem they take a day.
Basically, my empirical but poorly-supported-by-data view is that G09 is by far the fastest, then Nwchem, then Orca and finally Gamess. In the case of Gamess this may well be due to how I compiled it.
Nwchem was compiled roughly as was shown here: http://verahill.blogspot.com.au/2014/09/593-nwchem-65-on-debian-jessie-and.html
I'll post the compilation of Gamess US 5/12/2014 R1 later.
Results
Note: Orca used a symmetry number of 3 in the calculation of S(rot). I've 'corrected' it back to the non-symmetry corrected value so that it can be compared with the output from the other codes. Likewise, I've divided the entropy terms from Orca by 298.15 K.
Overall the results agree very well across the codes although the electronic energy in Orca is noticably different from the others.
| Code | Runtime | 'DFT' energy (H) | ZPE (H) | Hcorr (H) | S(tot) (Cal) | S(trans) (Cal) | S(rot) (Cal) | S(vib) (Cal) |
| G09 | 12 min | -232.04511372 | 0.100682 | 0.106028 | 69.033 | 38.979 | 25.625 | 4.428 |
| Orca | 17 min | -232.04530127 | 0.100605 | 0.105960 | 69.062 | 38.974 | 25.628 | 4.461 |
| Nwchem | 41 min | -232.04516624 | 0.100836 | 0.106162 | 68.950 | 38.962 | 25.614 | 4.375 |
| Gamess | 76 min | -232.04517728 | 0.100701 | 0.10604 | 69.011 | 38.979 | 25.625 | 4.407 |
G09 input:
%nprocshared=8
%Mem=3500000000
%Chk=benzene_freq.chk
#P rPBE1PBE/GEN 5D 7F Freq=() NoSymm Integral(UltraFine ) Punch=(MO) Pop=()
benzene freq
0 1 ! charge and multiplicity
C 1.20188 0.693923 0.00000
C 9.00000e-06 1.38776 0.00000
C -1.20188 0.693842 0.00000
C -1.20188 -0.693933 0.00000
C -1.60000e-05 -1.38777 0.00000
C 1.20188 -0.693829 0.00000
H 2.14078 1.23611 0.00000
H 5.10000e-05 2.47197 0.00000
H -2.14085 1.23591 0.00000
H -2.14082 -1.23604 0.00000
H -2.60000e-05 -2.47197 0.00000
H 2.14082 -1.23594 0.00000
C 0
S 6 1.00
13575.34968200 0.00022246
2035.23336800 0.00172327
463.22562359 0.00892557
131.20019598 0.03572798
42.85301589 0.11076260
15.58418577 0.24295628
S 2 1.00
6.20671385 0.41440263
2.57648965 0.23744969
S 1 1.00
0.57696339 1.00000000
S 1 1.00
0.22972831 1.00000000
S 1 1.00
0.09516444 1.00000000
P 4 1.00
34.69723224 0.00533337
7.95826228 0.03586411
2.37808269 0.14215873
0.81433208 0.34270472
P 1 1.00
0.28887547 1.00000000
P 1 1.00
0.10056824 1.00000000
D 1 1.00
1.09700000 1.00000000
D 1 1.00
0.31800000 1.00000000
F 1 1.00
0.76100000 1.00000000
****
H 0
S 3 1.00
34.06134100 0.00602520
5.12357460 0.04502109
1.16466260 0.20189726
S 1 1.00
0.32723041 1.00000000
S 1 1.00
0.10307241 1.00000000
P 1 1.00
0.80000000 1.00000000
****
Orca input
%pal nprocs 8 end ! DFT pbe0 def2-tzvp printbasis ! freq %basis newgto H S 3 1 34.0613410 0.60251978E-02 2 5.1235746 0.45021094E-01 3 1.1646626 0.20189726 S 1 1 0.32723041 1.0000000 S 1 1 0.10307241 1.0000000 P 1 1 0.8000000 1.0000000 end newgto C S 6 1 13575.3496820 0.22245814352E-03 2 2035.2333680 0.17232738252E-02 3 463.22562359 0.89255715314E-02 4 131.20019598 0.35727984502E-01 5 42.853015891 0.11076259931 6 15.584185766 0.24295627626 S 2 1 6.2067138508 0.41440263448 2 2.5764896527 0.23744968655 S 1 1 0.57696339419 1.0000000 S 1 1 0.22972831358 1.0000000 S 1 1 0.95164440028E-01 1.0000000 P 4 1 34.697232244 0.53333657805E-02 2 7.9582622826 0.35864109092E-01 3 2.3780826883 0.14215873329 4 0.81433208183 0.34270471845 P 1 1 0.28887547253 1.0000000 P 1 1 0.10056823671 1.0000000 D 1 1 1.09700000 1.0000000 D 1 1 0.31800000 1.0000000 F 1 1 0.76100000 1.0000000 end end * xyz 0 1 C 0.03998 -1.38721 0.00000 C 1.22135 -0.65898 0.00000 C 1.18137 0.72823 0.00000 C -0.03998 1.38721 0.00000 C -1.22135 0.65898 0.00000 C -1.18137 -0.72823 0.00000 H 0.07121 -2.47097 0.00000 H 2.17552 -1.17381 0.00000 H 2.10431 1.29715 0.00000 H -0.07121 2.47097 0.00000 H -2.17552 1.17381 0.00000 H -2.10431 -1.29715 0.00000 *
nwchem input
cratch_dir /home/me/scratch
Title "benzene freq"
Start freq
echo
charge 0
geometry noautosym units angstrom
C 1.20188 0.693923 0.00000
C 9.00000e-06 1.38776 0.00000
C -1.20188 0.693842 0.00000
C -1.20188 -0.693933 0.00000
C -1.60000e-05 -1.38777 0.00000
C 1.20188 -0.693829 0.00000
H 2.14078 1.23611 0.00000
H 5.10000e-05 2.47197 0.00000
H -2.14085 1.23591 0.00000
H -2.14082 -1.23604 0.00000
H -2.60000e-05 -2.47197 0.00000
H 2.14082 -1.23594 0.00000
end
basis "ao basis" spherical print
H S
34.061341000000 0.006025197800
5.123574600000 0.045021094000
1.164662600000 0.201897260000
H S
0.327230410000 1.000000000000
H S
0.103072410000 1.000000000000
H P
0.800000000000 1.000000000000
C S
13575.349682000000 0.000222458144
2035.233368000000 0.001723273825
463.225623590000 0.008925571531
131.200195980000 0.035727984502
42.853015891000 0.110762599310
15.584185766000 0.242956276260
C S
6.206713850800 0.414402634480
2.576489652700 0.237449686550
C S
0.576963394190 1.000000000000
C S
0.229728313580 1.000000000000
C S
0.095164440028 1.000000000000
C P
34.697232244000 0.005333365781
7.958262282600 0.035864109092
2.378082688300 0.142158733290
0.814332081830 0.342704718450
C P
0.288875472530 1.000000000000
C P
0.100568236710 1.000000000000
C D
1.097000000000 1.000000000000
C D
0.318000000000 1.000000000000
C F
0.761000000000 1.000000000000
END
dft
mult 1
direct
XC pbe0
grid xfine
convergence density 1e-08
mulliken
end
task dft energy
task dft freq
gamess US input:
$SYSTEM MWORDS=3500 $END $CONTRL RUNTYP=Hessian $END $CONTRL SCFTYP=RHF $END $DFT DFTTYP=PBE0 $END $CONTRL ICHARG=0 MULT=1 $END $CONTRL ISPHER=1 $END $SCF DIRSCF=.TRUE. $END $BASIS EXTFIL=.TRUE. GBASIS=DEF2TZVP $END $DATA Benzene C1 C 6.000000 0.039980 -1.387210 0.000000 C 6.000000 1.221350 -0.658980 0.000000 C 6.000000 1.181370 0.728230 0.000000 C 6.000000 -0.039980 1.387210 0.000000 C 6.000000 -1.221350 0.658980 0.000000 C 6.000000 -1.181370 -0.728230 0.000000 H 1.000000 0.071210 -2.470970 0.000000 H 1.000000 2.175520 -1.173810 0.000000 H 1.000000 2.104310 1.297150 0.000000 H 1.000000 -0.071210 2.470970 0.000000 H 1.000000 -2.175520 1.173810 0.000000 H 1.000000 -2.104310 -1.297150 0.000000 $END
17 August 2015
621. Very briefly: comparison of different hardware for a single G09 calculation
And another update:
* I've set up an Amazon EC2/AWS instance and have done some benchmarking there too: http://verahill.blogspot.com.au/2016/01/626-briefly-gaussian-g09d-with-slurm-on.html
Exciting stuff.
Another update:
* I turned off hyperthreading on the i7-4930K to see whether it improved performance. The geometry optimisation took 2 min (4%) longer but the overall runtime was 2 min (2%) shorter. This is probably within the reproducibility error for the measurement.
* I've also added results for an i7-5820K without hyperthreading
Update: I spotted a few mistakes
* the L5430 job ran on a dual-socket machine, so I've multiplied the passmark by two and have replotted
* the X3480 job use the EM64T version of gaussian, not AMD64. I don't have a license to test that system using AMD64.
Original post:
There are lots of potential flaws when comparing the performance of a computational package on different hardware. Thus, it can be difficult to find examples online comparing different hardware using computational chemistry packages which makes it challenging to decide on what hardware to budget for.
So here's a simple comparison of a few different types of hardware for a geovib calculation in Gaussian.
All systems have spinning (7200 rpm) disks and use debian jessie (64). The systems haven't been optimised in any way.
All systems used G09D rev 01 AMD 64 unless otherwise indicated. The amount of time the geometry optimisation took is given within [].
CPU Benchmarks:
i7-4930K 13059
i7-5820K 12999
i7-7700 10817
i7-6700 10011
FX 8350 8943
FX 8150 7626
i5-2400 5910
X3480 5732
PH2 X6 4998
Performance:
2h 15 min. [1h 14 min.] Intel i7-4930K/ 32 Gb ram/ 12 threads
2h 23 min. [1h 25 min.] Intel i7-5820K/ 32 Gb ram/ 6 threads (HT turned off, NOTE)
2h 28 min [1h 15 min] Intel i7-7700/ 16 Gb ram/ 8 threads (w/ HT)
2h 49 min [1h 37 min] Intel i7-6700/ 16Gb ram/ 6 threads (w/ HT)
3h 49 min. [2h 12 min.] AMD FX 8350/ 8 Gb ram/ 8 threads
4h 12 min. [2h 19 min.] Intel i5-2400/ 16 Gb ram/ 4 threads
4h 16 min. [2h 24 min.] AMD Phenom II X6 1055T/ 8 Gb ram/ 6 threads
4h 28 min. [2h 16 min.] dual-socket Intel Xeon L5430/ 16 Gb ram/ 8 threads-- rev A.02
4h 43 min. [2h 47 min.] AMD FX 8150/ 32 Gb ram/ 8 threads
9h 26 min. [5h 18 min.] AMD Athlon II X3 445/ 8 Gb ram/ 3 threads
I also tried the EM64T version of G09D rev 01 and got:
1h 43 min. [57 min.] i7-4930K/ 32 Gb ram/ 12 threads
1h 59 min [1h 7 min] i7-6700/ 16 Gb ram/6 threads (w/ HT)
2h 12 min [1h 7 min] i7-7700/ 16 Gb ram/8 threads (w/ HT)
3h 03 min. [1h 44 min.] i5-2400/16 Gb ram/ 4 threads
4h 21 min. [2h 27 min.] Xeon X3480/ 8 Gb ram/ 8 threads -- rev B.01
Just by switching from the AMD64 to the EM64T version we thus cut the calculation down to 75% of the time for the i7.
I also turned off hyperthreading for the i7-4930K and ran with six threads using the EM64T version:
1h 41 min. [59 min.] i7-4930K/ 32 Gb ram/ 6 threads
1h 35 min. [58 min.] i7-5820K/ 32 Gb ram/ 6 threads (NOTE)
2h 9 min. [1h 11 min.] i7-7700/ 16Gb ram/ 4 threads
Here's a plot of the run times vs Passmark benchmarks (I've multiplied the Xeon L5430 passmark by 2):
Note that the Xeon L5430 and Xeon X340 store the job files on an NFS (scratch files are local) and are not using G09 rev D.01.
It'd be tempting to draw a line through the Athlon II to the I7-4930K, in which case the Phenom II X6 and the I5-2400 perform much, much better than they should based on the CPU Passmark alone.
Either way, these are my observations. No interpretations or opinion attached.
So what's the benchmarking job that I used? I actually prefer not to reveal it, as it'd eventually point towards my identity (and you're not supposed to publish gaussian benchmarks...)
Suffice to say that it uses:
rpbe/def2-svp and 459 functions/759 primitives (46 atoms) with opt=(verytight) and integral(ultrafine)
* I've set up an Amazon EC2/AWS instance and have done some benchmarking there too: http://verahill.blogspot.com.au/2016/01/626-briefly-gaussian-g09d-with-slurm-on.html
Exciting stuff.
Another update:
* I turned off hyperthreading on the i7-4930K to see whether it improved performance. The geometry optimisation took 2 min (4%) longer but the overall runtime was 2 min (2%) shorter. This is probably within the reproducibility error for the measurement.
* I've also added results for an i7-5820K without hyperthreading
Update: I spotted a few mistakes
* the L5430 job ran on a dual-socket machine, so I've multiplied the passmark by two and have replotted
* the X3480 job use the EM64T version of gaussian, not AMD64. I don't have a license to test that system using AMD64.
Original post:
There are lots of potential flaws when comparing the performance of a computational package on different hardware. Thus, it can be difficult to find examples online comparing different hardware using computational chemistry packages which makes it challenging to decide on what hardware to budget for.
So here's a simple comparison of a few different types of hardware for a geovib calculation in Gaussian.
All systems have spinning (7200 rpm) disks and use debian jessie (64). The systems haven't been optimised in any way.
All systems used G09D rev 01 AMD 64 unless otherwise indicated. The amount of time the geometry optimisation took is given within [].
CPU Benchmarks:
i7-4930K 13059
i7-5820K 12999
i7-7700 10817
i7-6700 10011
FX 8350 8943
FX 8150 7626
i5-2400 5910
X3480 5732
PH2 X6 4998
Performance:
2h 15 min. [1h 14 min.] Intel i7-4930K/ 32 Gb ram/ 12 threads
2h 23 min. [1h 25 min.] Intel i7-5820K/ 32 Gb ram/ 6 threads (HT turned off, NOTE)
2h 28 min [1h 15 min] Intel i7-7700/ 16 Gb ram/ 8 threads (w/ HT)
2h 49 min [1h 37 min] Intel i7-6700/ 16Gb ram/ 6 threads (w/ HT)
3h 49 min. [2h 12 min.] AMD FX 8350/ 8 Gb ram/ 8 threads
4h 12 min. [2h 19 min.] Intel i5-2400/ 16 Gb ram/ 4 threads
4h 16 min. [2h 24 min.] AMD Phenom II X6 1055T/ 8 Gb ram/ 6 threads
4h 28 min. [2h 16 min.] dual-socket Intel Xeon L5430/ 16 Gb ram/ 8 threads-- rev A.02
4h 43 min. [2h 47 min.] AMD FX 8150/ 32 Gb ram/ 8 threads
9h 26 min. [5h 18 min.] AMD Athlon II X3 445/ 8 Gb ram/ 3 threads
I also tried the EM64T version of G09D rev 01 and got:
1h 43 min. [57 min.] i7-4930K/ 32 Gb ram/ 12 threads
1h 59 min [1h 7 min] i7-6700/ 16 Gb ram/6 threads (w/ HT)
2h 12 min [1h 7 min] i7-7700/ 16 Gb ram/8 threads (w/ HT)
3h 03 min. [1h 44 min.] i5-2400/16 Gb ram/ 4 threads
4h 21 min. [2h 27 min.] Xeon X3480/ 8 Gb ram/ 8 threads -- rev B.01
Just by switching from the AMD64 to the EM64T version we thus cut the calculation down to 75% of the time for the i7.
I also turned off hyperthreading for the i7-4930K and ran with six threads using the EM64T version:
1h 41 min. [59 min.] i7-4930K/ 32 Gb ram/ 6 threads
1h 35 min. [58 min.] i7-5820K/ 32 Gb ram/ 6 threads (NOTE)
2h 9 min. [1h 11 min.] i7-7700/ 16Gb ram/ 4 threads
Here's a plot of the run times vs Passmark benchmarks (I've multiplied the Xeon L5430 passmark by 2):
It'd be tempting to draw a line through the Athlon II to the I7-4930K, in which case the Phenom II X6 and the I5-2400 perform much, much better than they should based on the CPU Passmark alone.
Either way, these are my observations. No interpretations or opinion attached.
So what's the benchmarking job that I used? I actually prefer not to reveal it, as it'd eventually point towards my identity (and you're not supposed to publish gaussian benchmarks...)
Suffice to say that it uses:
rpbe/def2-svp and 459 functions/759 primitives (46 atoms) with opt=(verytight) and integral(ultrafine)
620. Very Short: Setting up ORCA (comp. chem.) on debian jessie
Nothing odd here, but providing instructions is never a bad idea. Note that ORCA is binaries only i.e. no source code. It's one reason why I wouldn't want to rely on it as my main code for computational chemistry. However, I am interested in using it to compare select results from nwchem and g09, especially in cases where g09 and nwchem produce differing results.
Either way,. to download ORCA you need to join the ORCA forum:
https://orcaforum.cec.mpg.de/portal.php
Once you've joined you can go to Downloads and, well, download. I went for https://orcaforum.cec.mpg.de/downloads.php?view=detail&df_id=43
The symmlink is there because debian already has a binary called orca.
And that's that installed. To add /opt/orca/orca_3_0_3_linux_x86-64 to PATH do
To test, try one of the jobs on https://www.sharcnet.ca/help/index.php/ORCA#Parallel_ORCA_job and run using
Either way,. to download ORCA you need to join the ORCA forum:
https://orcaforum.cec.mpg.de/portal.php
Once you've joined you can go to Downloads and, well, download. I went for https://orcaforum.cec.mpg.de/downloads.php?view=detail&df_id=43
sudo mkdir /opt/orca sudo chown $USER /opt/orca cp ~/Downloads/orca_3_0_3_linux_x86-64.tbz /opt/orca cd /opt/orca tar xvf orca_3_0_3_linux_x86-64.tbz cd orca_3_0_3_linux_x86-64 ln -s orca orca_cc
The symmlink is there because debian already has a binary called orca.
And that's that installed. To add /opt/orca/orca_3_0_3_linux_x86-64 to PATH do
echo 'export PATH=$PATH:/opt/orca/orca_3_0_3_linux_x86-64' >> ~/.bashrc
To test, try one of the jobs on https://www.sharcnet.ca/help/index.php/ORCA#Parallel_ORCA_job and run using
/opt/orca/orca_3_0_3_linux_x86-64/orca_cc test.inp***************** * O R C A * ***************** --- An Ab Initio, DFT and Semiempirical electronic structure package --- ####################################################### # -***- # # Department of molecular theory and spectroscopy # # Directorship: Frank Neese # # Max Planck Institute for Chemical Energy Conversion # # D-45470 Muelheim/Ruhr # # Germany # # # # All rights reserved # # -***- # ####################################################### Program Version 3.0.3 - RELEASE - [..] ************************************************************ * Program running with 2 parallel MPI-processes * * working on a common directory * ************************************************************ ------------------------------------------------------------------------------ [..] ------------------------------------------------------------------------------ ORCA ELECTRIC PROPERTIES CALCULATION ------------------------------------------------------------------------------ Dipole Moment Calculation ... on Quadrupole Moment Calculation ... off Polarizability Calculation ... off GBWName ... test.gbw Electron density file ... test.scfp.tmp ------------- DIPOLE MOMENT ------------- X Y Z Electronic contribution: 0.00000 -0.00000 -0.00000 Nuclear contribution : -0.00000 0.00000 -0.00000 ----------------------------------------- Total Dipole Moment : -0.00000 0.00000 -0.00000 ----------------------------------------- Magnitude (a.u.) : 0.00000 Magnitude (Debye) : 0.00000 Timings for individual modules: Sum of individual times ... 45.891 sec (= 0.765 min) GTO integral calculation ... 5.511 sec (= 0.092 min) 12.0 % SCF iterations ... 26.269 sec (= 0.438 min) 57.2 % SCF Gradient evaluation ... 13.957 sec (= 0.233 min) 30.4 % Geometry relaxation ... 0.154 sec (= 0.003 min) 0.3 % ****ORCA TERMINATED NORMALLY**** TOTAL RUN TIME: 0 days 0 hours 0 minutes 50 seconds 359 msec
01 August 2015
619. Making libreoffice look a bit nicer
...and by the title I actually refer to making it look like MS office...we can discuss the merits or lack thereof of that, but not here and now.
NOTE: you can install a few alternative icons themes directly from the debian repos by installing the libreoffice-style-* packages.
Anyway, we're commiting sacriledge by making our libreoffice look like MS office. You can obviously use the instructions here to pick a less controversial look.
Icons:
First go to http://charliecnr.deviantart.com/art/Office-2013-theme-for-LibreOffice-512127527 or use wget:
Then in libreoffice go to Tools/Options/Libreoffice:view and pick your theme:
Menu bar:
This is a weird one. Go to Tools/Options/Libreoffice:personalisation and under Firefox themes select own theme, and Visit Firefox Themes.
Then paste the URL of the theme you want. I used this URL: https://addons.mozilla.org/en-US/firefox/addon/office2010-edit/
And this is how libreoffice writer looks now:
NOTE: you can install a few alternative icons themes directly from the debian repos by installing the libreoffice-style-* packages.
Anyway, we're commiting sacriledge by making our libreoffice look like MS office. You can obviously use the instructions here to pick a less controversial look.
Icons:
First go to http://charliecnr.deviantart.com/art/Office-2013-theme-for-LibreOffice-512127527 or use wget:
wget http://orig11.deviantart.net/e10d/f/2015/059/7/3/office_2013_theme_for_libreoffice_by_charliecnr-d8gwo4n.zip mv office_2013_theme_for_libreoffice_by_charliecnr-d8gwo4n.zip images_office2013.zip sudo mv images_office2013.zip /usr/lib/libreoffice/share/config/
Then in libreoffice go to Tools/Options/Libreoffice:view and pick your theme:
This is a weird one. Go to Tools/Options/Libreoffice:personalisation and under Firefox themes select own theme, and Visit Firefox Themes.
Then paste the URL of the theme you want. I used this URL: https://addons.mozilla.org/en-US/firefox/addon/office2010-edit/
And this is how libreoffice writer looks now:
28 July 2015
618. Modifying ECCE to work with slurm
Sun Gridengine has been removed from debian jessie (it's in wheezy and sid). This has given me a good excuse to explore setting up SLURM on my debian cluster. So I did: http://verahill.blogspot.com.au/2015/07/617-slurm-on-debian-jessie-and.html
My setup is very simple, with each node having it's own working directory that they export via NFS to the main node. Also, I never run jobs across several nodes. Because of that, each node has it's own queue. Not how beowulf clusters were supposed to work, but it's the best solution for me (e.g. ROCKS does the opposite -- exports the user dir from the main node, but that makes reading and writing slow where it counts i.e. on the work nodes).
I've currently got this slurm.conf:
and sinfo returnsControlMachine=beryllium ControlAddr=192.168.1.1 MpiDefault=none ProctrackType=proctrack/pgid ReturnToService=2 SlurmctldPidFile=/var/run/slurm-llnl/slurmctld.pid SlurmdPidFile=/var/run/slurm-llnl/slurmd.pid SlurmdSpoolDir=/var/lib/slurm/slurmd SlurmUser=slurm StateSaveLocation=/var/lib/slurm/slurmctld SwitchType=switch/none TaskPlugin=task/none FastSchedule=1 SchedulerType=sched/backfill SelectType=select/linear AccountingStorageType=accounting_storage/filetxt AccountingStorageLoc=/var/log/slurm/accounting ClusterName=rupert JobAcctGatherType=jobacct_gather/none SlurmctldLogFile=/var/log/slurm/slurmctld.log SlurmdLogFile=/var/log/slurm/slurmd.log NodeName=beryllium NodeAddr=192.168.1.1 NodeName=neon NodeAddr=192.168.1.120 state=unknown NodeName=tantalum NodeAddr=192.168.1.150 state=unknown NodeName=magnesium NodeAddr=192.168.1.200 state=unknown NodeName=carbon NodeAddr=192.168.1.190 state=unknown NodeName=oxygen NodeAddr=192.168.1.180 state=unknown PartitionName=All Nodes=neon,beryllium,tantalum,oxygen,magnesium,carbon default=yes maxtime=infinite state=up PartitionName=mpi4 Nodes=tantalum maxtime=infinite state=up PartitionName=mpi12 Nodes=carbon maxtime=infinite state=up PartitionName=mpi8 Nodes=neon maxtime=infinite state=up PartitionName=mpix8 Nodes=oxygen maxtime=infinite state=up PartitionName=mpix12 Nodes=magnesium maxtime=infinite state=up PartitionName=mpi1 Nodes=beryllium maxtime=infinite state=up
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST All* up infinite 6 idle beryllium,carbon,magnesium,neon,oxygen,tantalum mpi4 up infinite 1 idle tantalum mpi12 up infinite 1 idle carbon mpi8 up infinite 1 idle neon mpix8 up infinite 1 idle oxygen mpix12 up infinite 1 idle magnesium mpi1 up infinite 1 idle beryllium
The first step was to figure out what files to edit:
grep -rs "qsub"apps/siteconfig/QueueManagers:SGE|submitCommand: qsub ##script##grep -rs "SGE"apps/scripts/eccejobmonitor: &MsgSendUp("SGE job id '$id' in state '$state'"); [..] apps/siteconfig/Queues:magnesium|queueMgrName: SGE
Here are the files I edited:
apps/siteconfig/QueueManagers:
apps/scripts/eccejobmonitor:12 QueueManagers: LoadLeveler \ 13 Maui \ 14 EASY \ 15 PBS \ 16 LSF \ 17 Moab \ 18 SGE \ 19 Shell\ 20 Slurm185 Shell|jobIdParseExpression: \ [0-9]+ 186 187 ############################################################################### 188 # SLURM 189 # Simple Linux Utility for Resource Management 190 # 191 # 192 Slurm|submitCommand: sbatch ##script## 193 Slurm|cancelCommand: scancel ##id## 194 Slurm|queryJobCommand: squeue 195 Slurm|queryMachineCommand: sinfo -p ##queue## 196 Slurm|queryQueueCommand: squeue -a 197 Slurm|queryDiskUsageCommand: df -k 198 Slurm|jobIdParseExpression: .* 199 Slurm|jobIdParseLeadingText: job
2124 LogMsg "Globus status from eccejobstore: $state"; 2125 } 2126 elsif ($q eq 'slurm') 2127 { 2128 $cmd = "squeue 2>&1"; 2129 if (open(QUERY, "$cmd |")) 2130 { 2131 $gotState = 0; 2132 while () 2133 { 2134 LogMsg "JobCheck: Slurm qstat line: $_"; 2135 if (/^\s*$id/) 2136 { 2137 my $state = (split)[5]; 2138 2139 &MsgSendUp("Slurm job id '$id' in state '$state'"); 2140 2141 if (grep {$state eq $_} qw{R 2142 t}) 2143 { 2144 $status = $JOB_STATE_RUNNING; 2145 } 2146 elsif (grep {$state eq $_} qw{PD}) 2147 { 2148 $status = $JOB_STATE_PENDING; 2149 } 2150 $gotState = 1; 2151 last; 2152 } 2153 } 2154 if ($gotState == 0) 2155 { 2156 if ($gJobCheckState != $JOB_STATE_NONE) 2157 { 2158 $status = $JOB_STATE_DONE; 2159 } 2160 } 2161 close QUERY;
Next set up a new machine (or queue) using ecce -admin. Set up a queue -- you won't be able to select Slurm, so select e.g. PBS. Edit the apps/siteconfig/CONFIG.machinename file to e.g.
Next, edit apps/siteconfig/Queues -- in my case the machine I created is called neon-slurm:1 NWChem: /opt/nwchem/Nwchem/bin/LINUX64/nwchem 2 Gaussian-03: /opt/gaussian/g09d/g09/g09 3 perlPath: /usr/bin/ 4 qmgrPath: /usr/bin/ 5 xappsPath: /usr/bin/ 6 7 Slurm { 8 #!/bin/csh 9 #SBATCH -p mpi8 10 #SBATCH --time=$walltime 11 #SBATCH --output=slurm.out 12 #SBATCH --job-name=$submitFile 13 } 14 15 NWChemEnvironment { 16 PYTHONPATH /opt/nwchem/Nwchem/contrib/python 17 } 18 19 NWChemFilesToRemove{ core *.aoints.* *.gridpts.* } 20 21 NWChemCommand { 22 setenv PATH "/bin:/usr/bin:/sbin:/usr/sbin" 23 setenv LD_LIBRARY_PATH "/usr/lib/openmpi/lib:/opt/openblas/lib:/opt/acml/acml5.3.1/gfortran64_fma4_int64/lib:/opt/acml/acml5.3.1/gfortran64_int64/lib:/opt/intel/mkl/lib/intel64" 24 hostname 25 mpirun -n $totalprocs /opt/nwchem/Nwchem/bin/LINUX64/nwchem $infile > $outfile 26 } 27 28 Gaussian-03FilesToRemove{ core *.rwf } 29 30 Gaussian-03Command{ 31 set path = ( /opt/nbo6/bin $path ) 32 setenv GAUSS_SCRDIR /home/me/scratch 33 setenv GAUSS_EXEDIR /opt/gaussian/g09d/g09/bsd:/opt/gaussian/g09d/g09/local:/opt/gaussian/g09d/g09/extras:/opt/gaussian/g09d/g09 34 /opt/gaussian/g09d/g09/g09< $infile > $outfile 35 echo 0 36 } 37 38 Wrapup{ 39 dmesg|tail 40 find ~/scratch/* -name "*" -user me|xargs -I {} rm {} -rf 41 }
And that's all. You should now be able to submit jobs via slurm. There's obviously a lot more than can be done and configured with SLURM, but this was enough to get me up and running, so that I'm now 'future-proofed' in case SGE never comes back into debian stable.neon-slurm|queueMgrName: Slurm neon-slurm|queueMgrVersion: 2.0~ neon-slurm|prefFile: neon-slurm.Q
And here's what it looks like when my ecce-submitted jobs are running:
squeueJOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 30 mpi8 In_monom me PD 0:00 1 (Resources) 29 mpi8 b_monome me R 16:12 1 neon 31 mpix12 tl_dimer me R 34:28 1 magnesium
617. SLURM on debian jessie (and compiling Jürgen Rinas' sinfo)
Two issues:
* Sun GridEngine (now Oracle GridEngine) is missing from Debian Jessie. I need a queue manager for my cluster. For now the wheezy package runs fine in debian jessie, but I'd be happier with a supported solution. SLURM is a good alternative here, and I've used it at the TACC.
* SLURM conflicts with Jürgen Rinas' sinfo package, which I use to keep an eye on my cluster. Until this has been resolved, I'll compile and use my own version of sinfo -- basically, I'll rename sinfo and sinfod to sinfo_jr and sinfod_jr. I can't live without sinfo.
Compiling sinfo
Change
Then edit debian/control and change
I launch sinfodjr at boot by putting the following in /etc/rc.local:
SLURM:
I had a look at this post: https://paolobertasi.wordpress.com/2011/05/24/how-to-install-slurm-on-debian/
It looked to easy to be true.
Here's what I ended up doing:
On the MASTER node:
Note the lack of spaces between beryllium and neon in the Nodes= directive.
On neon (and later on each node):
Install slurmd and slurm-client as shown below, then copy the /etc/munge/munge.key from the master node to the execute node. Do the same with /etc/slurm-llnl/slurm.conf. Then enable and restart the services.
On the main host (beryllium) I checked that everything was well:
* Sun GridEngine (now Oracle GridEngine) is missing from Debian Jessie. I need a queue manager for my cluster. For now the wheezy package runs fine in debian jessie, but I'd be happier with a supported solution. SLURM is a good alternative here, and I've used it at the TACC.
* SLURM conflicts with Jürgen Rinas' sinfo package, which I use to keep an eye on my cluster. Until this has been resolved, I'll compile and use my own version of sinfo -- basically, I'll rename sinfo and sinfod to sinfo_jr and sinfod_jr. I can't live without sinfo.
Compiling sinfo
mkdir ~/tmp/sinfo -p cd ~/tmp/sinfo
sudo apt-get install build-essential
sudo apt-get autoremove sinfo
apt-get source sinfo cd sinfo-0.0.47/ vim debian/rules
Change
to16 dh_auto_configure -- --enable-SIMPLE_USER_CACHE --enable-CPUNO_ADJUST 21 rm $(CURDIR)/debian/sinfo/usr/bin/sshallsinfo 22 rm $(CURDIR)/debian/sinfo/usr/share/man/man1/sshallsinfo.1 25 rm $(CURDIR)/debian/sinfo/usr/lib/*/sinfo/*.la 37 chmod 755 $(CURDIR)/debian/sinfo/usr/share/sinfo/sinfo.pl.cgi
That's jr for Jürgen Rinas.16 dh_auto_configure -- --enable-SIMPLE_USER_CACHE --enable-CPUNO_ADJUST --program-suffix=_jr 21 rm $(CURDIR)/debian/sinfojr/usr/bin/sshallsinfo_jr 22 rm $(CURDIR)/debian/sinfojr/usr/share/man/man1/sshallsinfo_jr.1 25 rm $(CURDIR)/debian/sinfojr/usr/lib/*/sinfo/*.la 37 chmod 755 $(CURDIR)/cgi/sinfo.pl.cgi
Then edit debian/control and change
to12 Package: sinfo 15 Conflicts: slurm-client, slurm-llnl (<< 14.03.8-1)
12 Package: sinfojr
15 Conflicts:
Build:
dpkg-buildpackage -us -uc cd ../ sudo dpkg -i sinfo_0.0.47-3_amd64.deb
I launch sinfodjr at boot by putting the following in /etc/rc.local:
su verahill -c '/usr/sbin/sinfodjr --bcast 192.168.1.255' &
SLURM:
I had a look at this post: https://paolobertasi.wordpress.com/2011/05/24/how-to-install-slurm-on-debian/
It looked to easy to be true.
Here's what I ended up doing:
On the MASTER node:
sudo apt-get install slurm-wlm slurmctld slurmdopen file:///usr/share/doc/slurmctld/slurm-wlm-configurator.easy.html[..] Generating a pseudo-random key using /dev/urandom completed. Please refer to /usr/share/doc/munge/README.Debian for instructions to generate more secure key. Setting up slurm-client (14.03.9-5) ... Setting up slurm-wlm-basic-plugins (14.03.9-5) ... Setting up slurmd (14.03.9-5) ... Setting up slurmctld (14.03.9-5) ... Setting up slurm-wlm (14.03.9-5) ... [..]
Copy the above block to /etc/slurm-llnl/slurm.conf# slurm.conf file generated by configurator easy.html. # Put this file on all nodes of your cluster. # See the slurm.conf man page for more information. # ControlMachine=beryllium ControlAddr=192.168.1.1 # #MailProg=/bin/mail MpiDefault=none #MpiParams=ports=#-# ProctrackType=proctrack/pgid ReturnToService=2 SlurmctldPidFile=/var/run/slurm-llnl/slurmctld.pid #SlurmctldPort=6817 SlurmdPidFile=/var/run/slurm-llnl/slurmd.pid #SlurmdPort=6818 SlurmdSpoolDir=/var/lib/slurm/slurmd SlurmUser=slurm #SlurmdUser=root StateSaveLocation=/var/lib/slurm/slurmctld SwitchType=switch/none TaskPlugin=task/none # # # TIMERS #KillWait=30 #MinJobAge=300 #SlurmctldTimeout=120 #SlurmdTimeout=300 # # # SCHEDULING FastSchedule=1 SchedulerType=sched/backfill #SchedulerPort=7321 SelectType=select/linear # # # LOGGING AND ACCOUNTING AccountingStorageType=accounting_storage/none ClusterName=rupert #JobAcctGatherFrequency=30 JobAcctGatherType=jobacct_gather/none #SlurmctldDebug=3 SlurmctldLogFile=/var/log/slurm/slurmctld.log #SlurmdDebug=3 SlurmdLogFile=/var/log/slurm/slurmd.log # # # COMPUTE NODES NodeName=beryllium NodeAddr=192.168.1.1 NodeName=neon NodeAddr=192.168.1.120 PartitionName=All Nodes=beryllium,neon
Note the lack of spaces between beryllium and neon in the Nodes= directive.
scontrol show daemonsslurmctldsudo /usr/sbin/create-munge-keyThe munge key /etc/munge/munge.key already exists Do you want to overwrite it? (y/N) y Generating a pseudo-random key using /dev/urandom completed.
sudo systemctl enable slurmctld.service sudo ln -s /var/lib/slurm-llnl /var/lib/slurm sudo systemctl start slurmctld.service sudo systemctl status slurmctld.serviceAlso, add yourself to the group slurm and chmod g+r /var/log/slurm/accounting.● slurmctld.service - Slurm controller daemon Loaded: loaded (/lib/systemd/system/slurmctld.service; enabled) Active: active (running) since Tue 2015-07-21 11:16:18 AEST; 40s ago Process: 19958 ExecStart=/usr/sbin/slurmctld $SLURMCTLD_OPTIONS (code=exited, status=0/SUCCESS) Main PID: 19960 (slurmctld) CGroup: /system.slice/slurmctld.service └─19960 /usr/sbin/slurmctldsudo systemctl status munge.service● munge.service - MUNGE authentication service Loaded: loaded (/lib/systemd/system/munge.service; disabled) Active: active (running) since Wed 2015-07-08 00:11:18 AEST; 1 weeks 6 days ago Docs: man:munged(8) Main PID: 25986 (munged) CGroup: /system.slice/munge.service └─25986 /usr/sbin/munged
On neon (and later on each node):
Install slurmd and slurm-client as shown below, then copy the /etc/munge/munge.key from the master node to the execute node. Do the same with /etc/slurm-llnl/slurm.conf. Then enable and restart the services.
sudo apt-get install slurmd slurm-client sudo ln -s /var/lib/slurm-llnl /var/lib/slurm sudo systemctl enable slurmd.service sudo systemctl restart slurmd.service sudo systemctl enable munge.service sudo systemctl restart munge.service sudo systemctl status slurmd.service
On the main host (beryllium) I checked that everything was well:
sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST All up infinite 1 idle* beryllium, neon
26 July 2015
616. SIESTA on debian jessie with debian blacs, scalapack and SIESTA blas
Three posts showing slightly different ways of building SIESTA on debian may seem a bit excessive, but I figured I'd do a post on a simple 'bullet-proof' way of building SIESTA on debian jessie.
For ACML, see http://verahill.blogspot.com.au/2015/07/614-siesta-with-mpi-on-debian-jessie.html
For MKL (not all MKL versions work using that post): http://verahill.blogspot.com.au/2015/07/615-siesta-on-debian-jessie-with-intel.html
See those posts for detailed build instructions. I'll only give you the arch.make here -- for the rest, see either of the above posts.
I've got a node with intel mkl 2013.sp1.3.174 which hasn't got the blacs openmpi libs, so I ended up building SIESTA with the SIESTA BLAS and LAPACK libraries, and using the debian BLACS and SCALAPACK libs.
Install the libs with
Here's the arch.make:
For ACML, see http://verahill.blogspot.com.au/2015/07/614-siesta-with-mpi-on-debian-jessie.html
For MKL (not all MKL versions work using that post): http://verahill.blogspot.com.au/2015/07/615-siesta-on-debian-jessie-with-intel.html
See those posts for detailed build instructions. I'll only give you the arch.make here -- for the rest, see either of the above posts.
I've got a node with intel mkl 2013.sp1.3.174 which hasn't got the blacs openmpi libs, so I ended up building SIESTA with the SIESTA BLAS and LAPACK libraries, and using the debian BLACS and SCALAPACK libs.
Install the libs with
sudo apt-get install libblacs-openmpi1 libopenmpi-dev libscalapack-openmpi1 libblacs-mpi-dev libscalapack-mpi-dev
Here's the arch.make:
At some point in the future, when my nodes are free, I might do a bit of basic performance testing using the different versions.# # This file is part of the SIESTA package. # # Copyright (c) Fundacion General Universidad Autonoma de Madrid: # E.Artacho, J.Gale, A.Garcia, J.Junquera, P.Ordejon, D.Sanchez-Portal # and J.M.Soler, 1996- . # # Use of this software constitutes agreement with the full conditions # given in the SIESTA license, as signed by all legitimate users. # .SUFFIXES: .SUFFIXES: .f .F .o .a .f90 .F90 SIESTA_ARCH=x86_64-unknown-linux-gnu--unknown FPP= FPP_OUTPUT= FC=mpif90 RANLIB=ranlib SYS=nag SP_KIND=4 DP_KIND=8 KINDS=$(SP_KIND) $(DP_KIND) FFLAGS=-g -O2 FPPFLAGS= -DMPI -DFC_HAVE_FLUSH -DFC_HAVE_ABORT LDFLAGS= ARFLAGS_EXTRA= FCFLAGS_fixed_f= FCFLAGS_free_f90= FPPFLAGS_fixed_F= FPPFLAGS_free_F90= BLAS_LIBS= LAPACK_LIBS= BLACS_LIBS=-L/usr/lib -lblacs-openmpi SCALAPACK_LIBS=-L/usr/lib -lscalapack-openmpi COMP_LIBS=dc_lapack.a liblapack.a libblas.a NETCDF_LIBS= NETCDF_INTERFACE= MPI_LIBS=-L/usr/lib/openmpi/lib -lmpi -lmpi_f90 -lmpi_f77 LIBS=$(SCALAPACK_LIBS) $(BLACS_LIBS) $(LAPACK_LIBS) $(BLAS_LIBS) $(NETCDF_LIBS) $(MPI_LIBS) -lpthread #SIESTA needs an F90 interface to MPI #This will give you SIESTA's own implementation #If your compiler vendor offers an alternative, you may change #to it here. MPI_INTERFACE=libmpi_f90.a MPI_INCLUDE=. #Dependency rules are created by autoconf according to whether #discrete preprocessing is necessary or not. .F.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $< .F90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_free_F90) $< .f.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_fixed_f) $< .f90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_free_f90) $<
25 July 2015
615. SIESTA on debian jessie with intel mkl and ifort
It's pretty similar to what I described in http://verahill.blogspot.com.au/2015/07/614-siesta-with-mpi-on-debian-jessie.html, with the main differences being the SCALAPACK, FC, BLACS and BLAS settings in arch.make
I presume that (the sadly no longer free for non-US academics) MKL was set up as shown here: http://verahill.blogspot.com.au/2013/06/465-intel-mkl-math-kernel-library-on.html
I haven't run all the tests on the build yet, but most of the ones that I tried worked, with the exception of the benzene test which came out with "Failure to converge standard eigenproblem", which is described here: http://departments.icmab.es/leem/siesta/Documentation/Manuals/manual-2.0/node47.html and isn't due to the build parameters.
NOTE: this doesn't work on mkl version 2013.sp1.3.174 as the blacs openmpi lib is missing. It does work on 2013.3.163, which is the version I used below. I have no idea why the libraries supplied with mkl are so different.
Follow
Edit arch.make:
You can edit Tests/test.mk to make sure that it's pointing to your siesta executable (or make a symlink to siesta in /opt/siest/siesta-3.2-pl-5/) and that it uses mpirun and the appropriate number of threads.
Then run make in Tests/ to run all the tests.
I presume that (the sadly no longer free for non-US academics) MKL was set up as shown here: http://verahill.blogspot.com.au/2013/06/465-intel-mkl-math-kernel-library-on.html
I haven't run all the tests on the build yet, but most of the ones that I tried worked, with the exception of the benzene test which came out with "Failure to converge standard eigenproblem", which is described here: http://departments.icmab.es/leem/siesta/Documentation/Manuals/manual-2.0/node47.html and isn't due to the build parameters.
NOTE: this doesn't work on mkl version 2013.sp1.3.174 as the blacs openmpi lib is missing. It does work on 2013.3.163, which is the version I used below. I have no idea why the libraries supplied with mkl are so different.
Follow
sudo apt-get install libopenmpi-dev sudo mkdir /opt/siesta sudo chown $USER /opt/siesta cd /opt/siesta wget http://departments.icmab.es/leem/siesta/CodeAccess/Code/siesta-3.2-pl-5.tgz tar xvf siesta-3.2-pl-5.tgz cd siesta-3.2-pl-5/Obj sh ../Src/obj_setup.sh ../Src/./configure --enable-mpi
Edit arch.make:
Then build:# # This file is part of the SIESTA package. # # Copyright (c) Fundacion General Universidad Autonoma de Madrid: # E.Artacho, J.Gale, A.Garcia, J.Junquera, P.Ordejon, D.Sanchez-Portal # and J.M.Soler, 1996- . # # Use of this software constitutes agreement with the full conditions # given in the SIESTA license, as signed by all legitimate users. # .SUFFIXES: .SUFFIXES: .f .F .o .a .f90 .F90 SIESTA_ARCH=x86_64-unknown-linux-gnu--unknown FPP= FPP_OUTPUT= FC=ifort RANLIB=ranlib SYS=nag SP_KIND=4 DP_KIND=8 KINDS=$(SP_KIND) $(DP_KIND) FFLAGS=-g -O2 FPPFLAGS= -DMPI -DFC_HAVE_FLUSH -DFC_HAVE_ABORT LDFLAGS= ARFLAGS_EXTRA= FCFLAGS_fixed_f= FCFLAGS_free_f90= FPPFLAGS_fixed_F= FPPFLAGS_free_F90= BLAS_LIBS=-L/opt/intel/mkl/lib/intel64 -lmkl_intel_lp64 -lmkl_core -lmkl_sequential LAPACK_LIBS=dc_lapack.a liblapack.a BLACS_LIBS=/opt/intel/mkl/lib/intel64/libmkl_blacs_openmpi_lp64.a SCALAPACK_LIBS=-L/opt/intel/mkl/lib/intel64 -lmkl_scalapack_lp64 COMP_LIBS=dc_lapack.a liblapack.a libblas.a NETCDF_LIBS= NETCDF_INTERFACE= MPI_LIBS= -L/usr/lib/openmpi/lib -lmpi -lmpi_f90 -lmpi_f77 LIBS=$(SCALAPACK_LIBS) $(BLACS_LIBS) $(LAPACK_LIBS) $(BLAS_LIBS) $(NETCDF_LIBS) $(MPI_LIBS) -lpthread #SIESTA needs an F90 interface to MPI #This will give you SIESTA's own implementation #If your compiler vendor offers an alternative, you may change #to it here. MPI_INTERFACE=libmpi_f90.a MPI_INCLUDE=/usr/lib/openmpi/include #Dependency rules are created by autoconf according to whether #discrete preprocessing is necessary or not. .F.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $< .F90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_free_F90) $< .f.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_fixed_f) $< .f90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_free_f90) $<
make
You can edit Tests/test.mk to make sure that it's pointing to your siesta executable (or make a symlink to siesta in /opt/siest/siesta-3.2-pl-5/) and that it uses mpirun and the appropriate number of threads.
Then run make in Tests/ to run all the tests.
24 July 2015
614. SIESTA with MPI and acml on debian jessie
One of my students might be using SIESTA for some simulations, and a first step towards that is to set it up on my cluster.
This isn't an optimised build -- right now I'm just looking at having a simple parallell build that runs.
I had a look at http://www.pa.msu.edu/people/tomanek/SIESTA-installation.html and http://pelios.csx.cam.ac.uk/~mc321/siesta.html.
NOTE: don't use the int64 acml or openblas BLAS libs, or you'll get SIGSEV due to invalid memory reference when running. NWChem is the complete opposite, and for some reason both the int64 and regulat acml libs have the same names. Not sure how that's supposed to work out on a system with nwchem, which needs the int64 libs.
See here for acml on debian. I've got /opt/acml/acml5.3.1/gfortran64_int64/lib in my /etc/ld.so.conf.d/acml.conf on behalf of nwchem.
Being lazy, I opted for the debian scalapack and libblacs packages:
To get the link to the SIESTA code, go to http://departments.icmab.es/leem/siesta/CodeAccess/selector.html
Then, if you're an academic, you can do:
I added /opt/siesta/siesta-3.2-pl-5 to $PATH.
To test, edit /opt/siesta/siesta-3.2-pl-5/test.mk:
Also, look at work/h3po4_2.out:
This isn't an optimised build -- right now I'm just looking at having a simple parallell build that runs.
I had a look at http://www.pa.msu.edu/people/tomanek/SIESTA-installation.html and http://pelios.csx.cam.ac.uk/~mc321/siesta.html.
NOTE: don't use the int64 acml or openblas BLAS libs, or you'll get SIGSEV due to invalid memory reference when running. NWChem is the complete opposite, and for some reason both the int64 and regulat acml libs have the same names. Not sure how that's supposed to work out on a system with nwchem, which needs the int64 libs.
See here for acml on debian. I've got /opt/acml/acml5.3.1/gfortran64_int64/lib in my /etc/ld.so.conf.d/acml.conf on behalf of nwchem.
Being lazy, I opted for the debian scalapack and libblacs packages:
sudo apt-get install libscalapack-mpi-dev libblacs-mpi-dev libopenmpi-dev
To get the link to the SIESTA code, go to http://departments.icmab.es/leem/siesta/CodeAccess/selector.html
Then, if you're an academic, you can do:
sudo mkdir /opt/siesta sudo chown $USER /opt/siesta cd /opt/siesta wget http://departments.icmab.es/leem/siesta/CodeAccess/Code/siesta-3.2-pl-5.tgz tar xvf siesta-3.2-pl-5.tgz cd siesta-3.2-pl-5/Obj sh ../Src/obj_setup.shEdit arch.make:*** Compilation setup done. *** Remember to copy an arch.make file or run configure as: ../Src/configure [configure_options]../Src/./configure --help`configure' configures siesta 2.0 to adapt to many kinds of systems. Usage: ./configure [OPTION]... [VAR=VALUE]... [..] Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] By default, `make install' will install all the files in `/usr/local/bin', `/usr/local/lib' etc. You can specify an installation prefix other than `/usr/local' using `--prefix', for instance `--prefix=$HOME'. [..] --enable-mpi Compile the parallel version of SIESTA --enable-debug Compile with debugging support --enable-fast Compile with best known optimization flags Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --with-netcdf=<lib> use NetCDF library../Src/./configure --enable-mpi--with-siesta-blas use BLAS library packaged with SIESTA --with-blas=<lib> use BLAS library --with-siesta-lapack use LAPACK library packaged with SIESTA --with-lapack=<lib> use LAPACK library --with-blacs=<lib> use BLACS library --with-scalapack=<lib> use ScaLAPACK library [..] checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu [..] checking for mpifc... no checking for mpxlf... no checking for mpif90... mpif90 checking for MPI_Init... no checking for MPI_Init in -lmpi... yes [..] checking for sgemm in /opt/openblas/lib/libopenblas.so... yes checking LAPACK already linked... yes checking LAPACK includes divide-and-conquer routines... yes configure: using DC_LAPACK routines packaged with SIESTA due to bug in library. Linker flag might be needed to avoid duplicate symbols configure: creating ./config.status config.status: creating arch.make
# # This file is part of the SIESTA package. # # Copyright (c) Fundacion General Universidad Autonoma de Madrid: # E.Artacho, J.Gale, A.Garcia, J.Junquera, P.Ordejon, D.Sanchez-Portal # and J.M.Soler, 1996- . # # Use of this software constitutes agreement with the full conditions # given in the SIESTA license, as signed by all legitimate users. # .SUFFIXES: .SUFFIXES: .f .F .o .a .f90 .F90 SIESTA_ARCH=x86_64-unknown-linux-gnu--unknown FPP= FPP_OUTPUT= FC=mpif90 RANLIB=ranlib SYS=nag SP_KIND=4 DP_KIND=8 KINDS=$(SP_KIND) $(DP_KIND) FFLAGS=-g -O2 FPPFLAGS= -DMPI -DFC_HAVE_FLUSH -DFC_HAVE_ABORT LDFLAGS= ARFLAGS_EXTRA= FCFLAGS_fixed_f= FCFLAGS_free_f90= FPPFLAGS_fixed_F= FPPFLAGS_free_F90= BLAS_LIBS=-L/opt/acml/acml5.3.1/gfortran64/lib -lacml LAPACK_LIBS= BLACS_LIBS=-L/usr/lib -lblacs-openmpi -lblacsCinit-openmpi SCALAPACK_LIBS=-L/usr/lib -lscalapack-openmpi COMP_LIBS=dc_lapack.a NETCDF_LIBS= NETCDF_INTERFACE= MPI_LIBS= -L/usr/lib/openmpi/lib -lmpi -lmpi_f90 LIBS=$(SCALAPACK_LIBS) $(BLACS_LIBS) $(LAPACK_LIBS) $(BLAS_LIBS) $(NETCDF_LIBS) $(MPI_LIBS) -lpthread #SIESTA needs an F90 interface to MPI #This will give you SIESTA's own implementation #If your compiler vendor offers an alternative, you may change #to it here. MPI_INTERFACE=libmpi_f90.a MPI_INCLUDE=. #Dependency rules are created by autoconf according to whether #discrete preprocessing is necessary or not. .F.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $< .F90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_free_F90) $< .f.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_fixed_f) $< .f90.o: $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_free_f90) $<
make cd ../ ln -s Obj/siesta siesta
I added /opt/siesta/siesta-3.2-pl-5 to $PATH.
To test, edit /opt/siesta/siesta-3.2-pl-5/test.mk:
Then6 #SIESTA=../../../siesta 7 SIESTA=mpirun -n 2 ../../../siesta
cd /opt/siesta/siesta-3.2-pl-5/Tests/h3po4_2
export LD_LIBRARY_CONFIG=/opt/acml/acml5.3.1/gfortran64/lib
make>>>> Running h3po4_2 test... ==> Copying pseudopotential file for H... ==> Copying pseudopotential file for O... ==> Copying pseudopotential file for P... ==> Running SIESTA as mpirun -n 2 ../../../siesta ===> SIESTA finished successfully
Also, look at work/h3po4_2.out:
* Running on 2 nodes in parallel
>> Start of run: 24-JUL-2015 21:58:13
***********************
* WELCOME TO SIESTA *
***********************
reinit: Reading from standard input
[..]
elaps: optical 1 0.000 0.000 0.00
>> End of run: 24-JUL-2015 21:58:20
07 July 2015
613. Debian Jessie: Turn off update pop-ups in gnome, and switching to lxterminal, nemo and ksnapshot
I originally installed the OS on my desktop back 2010 (Lenny) and haven't treated it very nicely (mixed releases, repos and have in general been installing, uninstalling and replacing packages with my own compiled ones -- and have fiddled with a few too many things) so when I was beginning to have issues on my desktop when compiling ECCE -- issues that weren't present on any other systems that were freshly installed -- I decided to start over again and install debian anew. I went straight for Debian Jessie, although I had many reasons to stay with Wheezy, such as systemd and, more importantly, the fact that Sun GridEngine is completely missing in Debian Jessie! See here.
Luckily the debian wheezy package works quite well on jessie -- but that's pure luck. I'm currently on the fence between hoping that SGE continues to work well until the SID version trickles down to backports (IF it does), or whether to learn how to set up SLURM instead.
Either way, here are a few things that annoyed me in Jessie (more specifically they annoyed me in GNOME) and that had to be fixed:
* Turn off update notifications
I hate being bugged by notifications about updating/upgrading my system. I'm not running windows -- it's unbecoming of a linux desktop to behave like that.
To fix it, go to Settings, Personal/Notifications and untick Package Updater
(simple -- you just need to know it's there)
* Nautilus doesn't do extra pane anymore. Bye bye nautilus.
Instead, install nemo, which is the rigthful heir to nautilus. It pulls in a lot of dependencies, but it's worth it.
To make nemo default do
Instead, install lx-terminal. To set it as default in both the OS and gnome, in the terminal do
I also felt compelled to install firefox and add it to the list over available applications in gnome so I could set it as the default browser Edit /var/lib/dpkg/alternatives/x-www-browser so that it reads
For thunderbird, I only followed the latter post.
* To disable screen saver completely:
* Note that dragging windows no longer works with Alt+left click -- instead use the windows key (Super key). Why this old standard behaviour got nuked I don't understand.
* I installed ksnapshot and set it as the default for prtn scrn instead of the crippled gnome-screenshot. Yes, it pulls in a lot of dependencies, but it's worth it.
Looking at the list above I'm slowly realising that it's probably time to say goodby to gnome for good. It's not going to a place where I want to follow it.
Pity.
There are a few things that I like about gnome 3. Well, there's a single thing that I like that got introduced: quickly searching for programs in the Activities Overview. Turns out that the applications menu wasn't that necessary after all.
The removal of features from nautilus, screenshot, terminal etc annoys me a lot though. Same goes for the removal of the minimize button.
Finally, I only find gnome useable once I've installed the gnome extensions by frippery. Stock gnome is useless to me.
Luckily the debian wheezy package works quite well on jessie -- but that's pure luck. I'm currently on the fence between hoping that SGE continues to work well until the SID version trickles down to backports (IF it does), or whether to learn how to set up SLURM instead.
Either way, here are a few things that annoyed me in Jessie (more specifically they annoyed me in GNOME) and that had to be fixed:
* Turn off update notifications
I hate being bugged by notifications about updating/upgrading my system. I'm not running windows -- it's unbecoming of a linux desktop to behave like that.
To fix it, go to Settings, Personal/Notifications and untick Package Updater
(simple -- you just need to know it's there)
* Nautilus doesn't do extra pane anymore. Bye bye nautilus.
Instead, install nemo, which is the rigthful heir to nautilus. It pulls in a lot of dependencies, but it's worth it.
To make nemo default do
* Gnome-terminal doesn't do transparency anymore. Bye bye gnome-terminal.me@beryllium:$ xdg-mime query default inode/directory org.gnome.Nautilus.desktop me@beryllium:$ xdg-mime default nemo.desktop inode/directory application/x-gnome-saved-search me@beryllium:$ xdg-mime query default inode/directory nemo.desktop
Instead, install lx-terminal. To set it as default in both the OS and gnome, in the terminal do
* Adding firefox and thunderbird to default applicationsgsettings set org.cinnamon.desktop.default-applications.terminal exec lxterminalsudo update-alternatives --config x-terminal-emulator
I also felt compelled to install firefox and add it to the list over available applications in gnome so I could set it as the default browser Edit /var/lib/dpkg/alternatives/x-www-browser so that it reads
I also followed this post: http://verahill.blogspot.com.au/2013/11/530-briefly-adding-new-entry-to-default.htmlauto /usr/bin/x-www-browser x-www-browser.1.gz /usr/share/man/man1/x-www-browser.1.gz /usr/bin/chromium 40 /usr/bin/firefox-bin 70 /usr/bin/iceweasel 70 /usr/share/man/man1/iceweasel.1.gz
For thunderbird, I only followed the latter post.
* To disable screen saver completely:
* I've got no idea how to elegantly exorcise bijiben-shell-search-provider, which keeps making my CPU usage spike. It's not nice.gsettings set org.gnome.settings-daemon.plugins.power active false
* Note that dragging windows no longer works with Alt+left click -- instead use the windows key (Super key). Why this old standard behaviour got nuked I don't understand.
* I installed ksnapshot and set it as the default for prtn scrn instead of the crippled gnome-screenshot. Yes, it pulls in a lot of dependencies, but it's worth it.
Looking at the list above I'm slowly realising that it's probably time to say goodby to gnome for good. It's not going to a place where I want to follow it.
Pity.
There are a few things that I like about gnome 3. Well, there's a single thing that I like that got introduced: quickly searching for programs in the Activities Overview. Turns out that the applications menu wasn't that necessary after all.
The removal of features from nautilus, screenshot, terminal etc annoys me a lot though. Same goes for the removal of the minimize button.
Finally, I only find gnome useable once I've installed the gnome extensions by frippery. Stock gnome is useless to me.
09 June 2015
612. Randomly Rebooting Router (E2500-AU v1.0 w/ TomatoUSB)
Rolling update:
* 24 June 2015: 7 days uptime with wifi working perfectly. Did reboot it last night because my work computer lost contact with the router somehow (connects via reverse tunnel). The issue with the Randomly Rebooting Router can be considered solved. Obviously, it's solved by crippling the router by turning off the 5 GHz band and tkip (the latter may not be related though).
* Submitted a bug report: http://tomato.groov.pl/?page_id=334&bugerator_nav=display&bug_project=1&issue=1833
* 16 June 2015 12:42 AEST. The router has been up for two days and four hours (and counting) in spite of heavy use of our phones. Seems like turning off 5 GHz and/or switching from AES to TKIP has worked. A fair criticism is that I don't have much of a baseline to compare with when it comes to reboots, but subjectively there's a lot less swearing over crappy wifi the past two days.
* 14 June 2015 08:05 AEST. After two days of uptime when radio-silence was enforced, we turned our phones back on. The router rebooted later that night. Same thing happened the next night. After briefly putting dd-wrt on the router, I put tomatousb back on it, turned off 5 GHz and changed from AES to TKIP. The router has been up since 9.30 pm last night (10 h and counting)
Found this bug report: http://tomato.groov.pl/?page_id=334&bugerator_nav=display&bug_project=1&issue=1813
Also read this with interest: http://movingpackets.net/2013/11/18/linksys-e2500-deserves-no-airplay/
I've seen posts that find that dd-wrt doesn't have the randomly rebooting issue. dd-wrt doesn't support dual band, at least on e2500. I was surprised that v1 of the cisco linksys firmware had the same exact issue (random reboots when 5 GHz is on). It's all pointing in a specific direction.
Not sure why using the 5 GHz channel with my laptop doesn't trigger the reboots, but maybe they did -- but happened less frequently due to the lower number of 5 GHz capable devices prior to us getting the phones.
* 10 June 2015 16:24 AEST. Since turning off wifi on the Samsung Galaxy S4 phones (but using the two laptops and the tablet listed below) the router has stayed up for 24 hours 8 hours and 11 minutes, and counting. The night between Monday and Tuesday, when we were using our phones, the router rebooted at least twice.
This is another one of those posts that don't offer a solution, but rather states a problem. I'm doing this in the hope that others who are making similar observations as I am will see this and...well, feel slightly less alone at the very least. In the best case, someone will have a solution and offer it as a comment.
So, here's the issue:
* I have a Linksys E2500-AU v1.0 that is running TomatoUSB (howto)
* For a long time it, and its predecessor (a WRT-54GL), were running just fine. The predecessor got replaced due to a fried power supply.
* Over the past six-seven months there have been issues with the wireless signal dropping. It isn't just the wireless transmission being stopped and restarted, but the router actually reboots (according to uptime).
* We used to have the following wireless devices: Fujitsu lifebook (v100?), Thinkpad SL410, Google Nexus One and a HTC Legend. At some point we also got a Samsung Galaxy Tab 2. This configuration was running for a few years.
* Coinciding roughly with the perceived start of the rebooting issue was me purchasing a Samsung Galaxy S4 (i9505).
* The issue got a lot worse recently.
* Recently my partner also got a Samsung Galaxy S4 (i9505).
* I have an almost identical router (v2) at work, and the current uptime is 140 days. I do connect very occasionally via wireless to it using my Samsung Galaxy S4. However, this router has a "Broadcom BCM5357 chip rev 1 pkg 8".
What seems to be happening:
The Samsung Galaxy S4 phones seem to be destabilising the router and causing reboots. No, wait, hear me out. It shouldn't happen, and the adage about 'correlation vs causation' may well be true in this case too, but there are precendents (apparently) when it comes to Intel wireless devices:
On http://www.linksysinfo.org/index.php?threads/tomatousb-keeps-resetting-the-router.33208/ from 2010
and
The Samsung Galaxy S4 has a Qualcomm Snapdragon 600 APQ8064AB, with is a system-on-a-chip. The Nexus One and HTC Legend also had snapdragons, but obviously much older models. The Galaxy Tab 2 seems to have a Texas Instrument chip (TI OMAP 4430).
Could it be that the phones are causing the issues?
Luckily it's something that's reasonably easy to test, so I'm looking forward to reporting back in a couple of days (of enforced radio silence).
A different test will be to swap routers (but not power supplies) between work and home and see if the behaviour is location dependent. That will take a lot more effort though due to the very specific set-ups.
As the logs get erased on reboot I'm tracking the uptime from now on using autossh and logging from a work computer that's always on.
Some more:
Below is a post regarding iphones, and rebooting routers.
While that post is not related to 5GHz causing issues, it's got me thinking that as neither the Fujitsu, Galaxy Tab, Nexus One or HTC legend support 5 GHz but the Samsung Galaxy S4 phones do, the issue may be possibly related to that. There is obviously quite a lot of things to test.
Tomato Anon
Somehow the Spontaneously Rebooting Router doesn't show up here, while the stable one does: http://anon.groov.pl/index.php?country=Australia
Either way, the anon database is a great way of quickly finding out what Tomato version you can put on your router.
* 24 June 2015: 7 days uptime with wifi working perfectly. Did reboot it last night because my work computer lost contact with the router somehow (connects via reverse tunnel). The issue with the Randomly Rebooting Router can be considered solved. Obviously, it's solved by crippling the router by turning off the 5 GHz band and tkip (the latter may not be related though).
* Submitted a bug report: http://tomato.groov.pl/?page_id=334&bugerator_nav=display&bug_project=1&issue=1833
* 16 June 2015 12:42 AEST. The router has been up for two days and four hours (and counting) in spite of heavy use of our phones. Seems like turning off 5 GHz and/or switching from AES to TKIP has worked. A fair criticism is that I don't have much of a baseline to compare with when it comes to reboots, but subjectively there's a lot less swearing over crappy wifi the past two days.
* 14 June 2015 08:05 AEST. After two days of uptime when radio-silence was enforced, we turned our phones back on. The router rebooted later that night. Same thing happened the next night. After briefly putting dd-wrt on the router, I put tomatousb back on it, turned off 5 GHz and changed from AES to TKIP. The router has been up since 9.30 pm last night (10 h and counting)
Found this bug report: http://tomato.groov.pl/?page_id=334&bugerator_nav=display&bug_project=1&issue=1813
Also read this with interest: http://movingpackets.net/2013/11/18/linksys-e2500-deserves-no-airplay/
I've seen posts that find that dd-wrt doesn't have the randomly rebooting issue. dd-wrt doesn't support dual band, at least on e2500. I was surprised that v1 of the cisco linksys firmware had the same exact issue (random reboots when 5 GHz is on). It's all pointing in a specific direction.
Not sure why using the 5 GHz channel with my laptop doesn't trigger the reboots, but maybe they did -- but happened less frequently due to the lower number of 5 GHz capable devices prior to us getting the phones.
* 10 June 2015 16:24 AEST. Since turning off wifi on the Samsung Galaxy S4 phones (but using the two laptops and the tablet listed below) the router has stayed up for 24 hours 8 hours and 11 minutes, and counting. The night between Monday and Tuesday, when we were using our phones, the router rebooted at least twice.
This is another one of those posts that don't offer a solution, but rather states a problem. I'm doing this in the hope that others who are making similar observations as I am will see this and...well, feel slightly less alone at the very least. In the best case, someone will have a solution and offer it as a comment.
So, here's the issue:
* I have a Linksys E2500-AU v1.0 that is running TomatoUSB (howto)
Tomato v1.28.0000 MIPSR2-128 K26 USB Max ======================================================== Welcome to the Linksys E2500 v1.0 [TomatoUSB] Uptime: 08:14:26 up 1 min Load average: 0.52, 0.18, 0.06 Mem usage: 28.4% (used 17.06 of 59.96 MB) WAN : 192.168.1.100/24 @ 58:6D:8F:D3:XX:XX LAN : 192.168.2.1/24 @ DHCP: 192.168.2.2 - 192.168.2.202 WL0 : volatile @ channel: AU13 @ 58:6D:8F:D3:XX:XX WL1 : volatile50 @ channel: AU153 @ 00:01:36:1F:XX:XX ========================================================* It has a "Broadcom BCM5357 chip rev 2 pkg 8"
* For a long time it, and its predecessor (a WRT-54GL), were running just fine. The predecessor got replaced due to a fried power supply.
* Over the past six-seven months there have been issues with the wireless signal dropping. It isn't just the wireless transmission being stopped and restarted, but the router actually reboots (according to uptime).
* We used to have the following wireless devices: Fujitsu lifebook (v100?), Thinkpad SL410, Google Nexus One and a HTC Legend. At some point we also got a Samsung Galaxy Tab 2. This configuration was running for a few years.
* Coinciding roughly with the perceived start of the rebooting issue was me purchasing a Samsung Galaxy S4 (i9505).
* The issue got a lot worse recently.
* Recently my partner also got a Samsung Galaxy S4 (i9505).
* I have an almost identical router (v2) at work, and the current uptime is 140 days. I do connect very occasionally via wireless to it using my Samsung Galaxy S4. However, this router has a "Broadcom BCM5357 chip rev 1 pkg 8".
What seems to be happening:
The Samsung Galaxy S4 phones seem to be destabilising the router and causing reboots. No, wait, hear me out. It shouldn't happen, and the adage about 'correlation vs causation' may well be true in this case too, but there are precendents (apparently) when it comes to Intel wireless devices:
On http://www.linksysinfo.org/index.php?threads/tomatousb-keeps-resetting-the-router.33208/ from 2010
Hrm...routers used to spontaneously reboot when the wireless driver failed on Tomato as a result of an Intel (mobile) wireless driver bug on Windows. Maybe similar?On http://www.linksysinfo.org/index.php?threads/random-reboots.21020/ from 2007
Currently using DD-wrt V24, it's been up for 25 days I can confirm it has something to do with the broadcom wireless drivers.
and
What kind of wireless device does your laptop have? Is it Intel 2100/2200 by any chance?And in the end the thread concludes that it was due to users with Intel 2100/2200 cards.
The Samsung Galaxy S4 has a Qualcomm Snapdragon 600 APQ8064AB, with is a system-on-a-chip. The Nexus One and HTC Legend also had snapdragons, but obviously much older models. The Galaxy Tab 2 seems to have a Texas Instrument chip (TI OMAP 4430).
Could it be that the phones are causing the issues?
Luckily it's something that's reasonably easy to test, so I'm looking forward to reporting back in a couple of days (of enforced radio silence).
A different test will be to swap routers (but not power supplies) between work and home and see if the behaviour is location dependent. That will take a lot more effort though due to the very specific set-ups.
As the logs get erased on reboot I'm tracking the uptime from now on using autossh and logging from a work computer that's always on.
Some more:
Below is a post regarding iphones, and rebooting routers.
While that post is not related to 5GHz causing issues, it's got me thinking that as neither the Fujitsu, Galaxy Tab, Nexus One or HTC legend support 5 GHz but the Samsung Galaxy S4 phones do, the issue may be possibly related to that. There is obviously quite a lot of things to test.
ADDITIONAL INFORMATION: in the mean time we have been checking and elimination as well. We have been trying to connect certain wireless devices to the network through the DAP and something odd has come up. We have been trying mobile phones (smartphones) at first. My own telephone (Samsung Galaxy S3) seems to cause no troubles. With that phone connected for a whole day, internet connection does not fail once (the router does not reboot). I have been trying both 5Ghz and 2.4 Ghz. bands, both worked okay. One colleague also wanted to connect his Apple Iphone 3G (S?) to the network. I told him he could but this phone could not find the 5Ghz network, so I have switched back to 2.4Ghz again. The iPhone connected and within 5 minutes the connection interrupted. I have set the network back to 5Ghz (so the iPhone could no longer connect) and changed the network settings again. This morning I switched back to 2.4 with only my phone connected. Not a problem. This afternoon I let my colleague connect his phone again and disconnected my Samsung. Within 5 minutes the router started to reboot! After I had the iPhone disconnected again and let another colleague connect his phone, a Samsung Galaxy S(1). So far no problems.
Tomato Anon
Somehow the Spontaneously Rebooting Router doesn't show up here, while the stable one does: http://anon.groov.pl/index.php?country=Australia
Either way, the anon database is a great way of quickly finding out what Tomato version you can put on your router.
05 June 2015
611. Building ecce on debian jessie
NOTE:
* I've confirmed that ECCE built like this installs and works perfectly on a Thinkpad SL410 with intel graphics
* It also compiles and runs perfectly on a home built desktop with external nvidia card (GF119) using the binary non-free nvidia drivers
* It also compiles and runs perfectly on a home built desktop with onboard nvidia (GeForce 7025/nForce 630a) using the nouveau drivers. I had issues on this desktop before, but reinstalled debian jessie from scratch. Before that I used nvidia-legacy drivers, which may or may not (probably not) have had something to do with it not working.
* UPDATE: instead of putting
* UPDATE: If you're having issues with undetected -lGL and -lGLU in the wxwidgets step, it's because
needs to be changed to
I wouldn't have spotted this bug otherwise.
* Another error from my debian wheezy nvidia system: if you get
* Finally, I'm currently working on fixing minor things that have been nagging me in ecce. One is the basis set quicklist (in src/dsm/edsiimpl/ICalcUtils.C), but obviously that's a personal preference. A more serious one is the 256 character limit for csh commands:
I've also added two basis sets to ECCE, and have tinkered with the exchange-correlation functionals.
I'll try to push the fixes back upstreams when I'm ready if they'll accept them; otherwise I'll create my own github/sourceforge repo.
THE POST:
Building ECCE on debian wheezy was a breeze. Building ECCE on debian jessie was painful.
In the end it boiled down to two things:
*freetype headers are no longer in freetype2/freetype/ but in freetype2/
*-Wformat-security is turned on by default
As usual I'm not 100% sure when it comes to the necessary packages. libfl-dev might not be needed.
Download the ECCE source code and put the ecce-v7.0-src.tar.bz2 file in ~/tmp/ecce_compile. Put the patch_script.sh file (see below in this post for the code) in ~/tmp/ecce_compile. Then do
You'll now step through a list over programs and libraries that are needed and what ECCE can find. If you're having issues with e.g. javac and java being different versions, use sudo update-alternative --config javac.
At the end you'll be asked whether to skip these checks next time -- answer y(es).
Next do
If all went well you've managed to build the ecce binaries. If not, go through wxpython.log and check for errors relating to format-security statements. Then go through ecce.log and look for issues with freetype.
What to do with the binaries? Follow one of the many ECCE installation posts on this blog, e.g. http://verahill.blogspot.com.au/2013/08/487-version-70-of-ecce-out-now.html
NOTE that if you get ''Invalid null command." trying to execute install_ecce.v7.0.csh, install tcsh and do
The patch_script.sh file -- when copying, make sure to check that the lines end where they are supposed to and not broken up.
What I found during troubleshooting:
In files such as:
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_core_wrap.cpp
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_gdi_wrap.cpp
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_windows_wrap.cpp
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_controls_wrap.cpp
there are sections which look like this:
* I've confirmed that ECCE built like this installs and works perfectly on a Thinkpad SL410 with intel graphics
* It also compiles and runs perfectly on a home built desktop with external nvidia card (GF119) using the binary non-free nvidia drivers
* It also compiles and runs perfectly on a home built desktop with onboard nvidia (GeForce 7025/nForce 630a) using the nouveau drivers. I had issues on this desktop before, but reinstalled debian jessie from scratch. Before that I used nvidia-legacy drivers, which may or may not (probably not) have had something to do with it not working.
* UPDATE: instead of putting
the recommended method is to use#include <freetype.h>
I've updated the patch_script.sh below accordingly. Same goes for ftoutln.h vs FT_OUTLINE_H, but the latter didn't work (error saying #include must use "" or <>)#include FT_FREETYPE_H
* UPDATE: If you're having issues with undetected -lGL and -lGLU in the wxwidgets step, it's because
667 endif
668 cat configure.orig | sed -e 's%^SEARCH_INCLUDE="\\%SEARCH_INCLUDE="$ECCE_HOME/${ECCE_SYSDIR}3rdparty/mesa/include \\%' >! configure
669 chmod a+x configure
670
needs to be changed to
667 endif
668 cat configure.orig | sed -e 's%^SEARCH_INCLUDE="\\%SEARCH_INCLUDE="$ECCE_HOME/${ECCE_SYSDIR}3rdparty/mesa/include $ECCE_HOME/${ECCE_SYSDIR}3rdparty/mesa/lib \\%' >! configure
669 chmod a+x configure
670
I had this issue on a debian wheezy system with the vendor nvidia libraries.I wouldn't have spotted this bug otherwise.
* Another error from my debian wheezy nvidia system: if you get
then make sure you're not using autoconf2.13, which is an obsolete version. I think I have it due to my system originally being installed back in 2010.checking how to run the C preprocessor... x86_64-linux-gnu-gcc -E ./configure: line 2880: syntax error near unexpected token `Using' ./configure: line 2880: ` AC_MSG_NOTICE(Using external PCRE library from $PCRE_CONFIG)'
* Finally, I'm currently working on fixing minor things that have been nagging me in ecce. One is the basis set quicklist (in src/dsm/edsiimpl/ICalcUtils.C), but obviously that's a personal preference. A more serious one is the 256 character limit for csh commands:
Note that this isn't the C shell complaining -- this is a built-in limit in ecce (in src/comm/rcommand/RCommand.C). I've changed that limit to 16384 characters (the real limit is much, much higher)Exceeds maximum C shell command length of 256 characters
I've also added two basis sets to ECCE, and have tinkered with the exchange-correlation functionals.
I'll try to push the fixes back upstreams when I'm ready if they'll accept them; otherwise I'll create my own github/sourceforge repo.
THE POST:
Building ECCE on debian wheezy was a breeze. Building ECCE on debian jessie was painful.
In the end it boiled down to two things:
*freetype headers are no longer in freetype2/freetype/ but in freetype2/
*-Wformat-security is turned on by default
mkdir ~/tmp/ecce_compile -p cd ~/tmp/ecce_compile sudo apt-get install bzip2 build-essential autoconf libtool ant pkg-config sudo apt-get install gtk+-2.0-dev libxt-dev csh gfortran openjdk-7-jdk python-dev sudo apt-get install libjpeg-dev imagemagick xterm libfreetype6-dev libfl-dev libtool-bin
As usual I'm not 100% sure when it comes to the necessary packages. libfl-dev might not be needed.
Download the ECCE source code and put the ecce-v7.0-src.tar.bz2 file in ~/tmp/ecce_compile. Put the patch_script.sh file (see below in this post for the code) in ~/tmp/ecce_compile. Then do
tar xvf ecce-v7.0-src.tar.bz2 cd ecce-v7.0/ export ECCE_HOME=`pwd` cd build/ ./build_ecce
You'll now step through a list over programs and libraries that are needed and what ECCE can find. If you're having issues with e.g. javac and java being different versions, use sudo update-alternative --config javac.
At the end you'll be asked whether to skip these checks next time -- answer y(es).
Next do
./build_ecce|tee xerxes.log && ./build_ecce |tee mesa.log && ./build_ecce |tee wxwidgets.log
sh ../../patch_script.sh && ./build_ecce|tee wxpython.log
./build_ecce|tee httpd.log && ./build_ecce|tee ecce.log
If all went well you've managed to build the ecce binaries. If not, go through wxpython.log and check for errors relating to format-security statements. Then go through ecce.log and look for issues with freetype.
What to do with the binaries? Follow one of the many ECCE installation posts on this blog, e.g. http://verahill.blogspot.com.au/2013/08/487-version-70-of-ecce-out-now.html
NOTE that if you get ''Invalid null command." trying to execute install_ecce.v7.0.csh, install tcsh and do
tcsh install_ecce.v7.0.csh
The patch_script.sh file -- when copying, make sure to check that the lines end where they are supposed to and not broken up.
#!/bin/bash cp ${ECCE_HOME}/build/3rdparty-dists/wxPython-src-2.8.12.1.tar.bz2 ${ECCE_HOME}/3rdparty/build/ cd ${ECCE_HOME}/3rdparty/build/ tar xvf wxPython-src-2.8.12.1.tar.bz2 rm wxPython-src-2.8.12.1.tar.bz2 cd ${ECCE_HOME}/3rdparty/build/wxPython-src-2.8.12.1/wxPython grep -rsl "PyErr_Format(PyExc_RuntimeError, mesg)" *|xargs -I {} sed -i 's/PyErr_Format(PyExc_RuntimeError, mesg)/PyErr_Format(PyExc_RuntimeError, "%s", mesg)/g' {} cd ${ECCE_HOME}/3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/ sed -i 's/wxLogFatalError(m)/wxLogFatalError("%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogError(m)/wxLogError("%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogWarning(m)/wxLogWarning("%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogMessage(m)/wxLogMessage("%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogInfo(m)/wxLogInfo("%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogDebug(m)/wxLogDebug("%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogVerbose(m)/wxLogVerbose("%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogStatus(pFrame, m)/wxLogStatus(pFrame, "%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogStatus(m)/wxLogStatus("%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogSysError(m)/wxLogSysError("%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogGeneric(level, m)/wxLogGeneric(level, "%s", m.c_str())/g' _misc_wrap.cpp sed -i 's/wxLogTrace(mask, m)/wxLogTrace(mask, "%s", m.c_str())/g' _misc_wrap.cpp cd ${ECCE_HOME}/src grep -srl "<freetype/freetype.h>" |xargs -I {} sed -i 's,<freetype/freetype.h>,FT_FREETYPE_H,g' {} grep -srl "freetype/" |xargs -I {} sed -i 's,freetype/,,g' {} cd ${ECCE_HOME}/build
What I found during troubleshooting:
In files such as:
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_core_wrap.cpp
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_gdi_wrap.cpp
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_windows_wrap.cpp
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_controls_wrap.cpp
there are sections which look like this:
Compiling with -Wformat-security means that you'll have to patch all those expression to863 } else { 864 PyErr_Format(PyExc_RuntimeError, mesg); 865 }
There were similar issue with wxLog*(m) statements in other files, e.g.863 } else { 864 PyErr_Format(PyExc_RuntimeError, "%s", mesg); 865 }
3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_misc_wrap.cpp -> ("%s", m.c_str()) 3093 m.Replace(wxT("%"), wxT("%%")); 3094 wxLogFatalError(m); 3095 } .. 3177 m.Replace(wxT("%"), wxT("%%")); 3178 wxLogTrace(mask, m); 3179 }
04 June 2015
610. Opening G09 output files in ECCE. A rough method
Update: Note that one thing that's not recognised at the moment are the MOs. Somehow I don't think that should be too difficult. Likewise, I think one should be able to import nwchem files by a little bit of editing like below.
Original post:
When opening a gaussian output file with the ECCE viewer:
* a symlink to the file is put in a subdirectory of /tmp
* the file is parsed for indications as to what the file type is:
Here's a successful example, in the sense that ECCE found that it was a Gaussian 03 file:
However, it fails to detect that Gaussian-03.expt is present and executable (both of which are true).
[SOLUTION]
To sort that out and to enable G09 detection, edit apps/data/client/cap/Gaussian-03.edml:
My ecce_env is fine and my runtime_setup.sh file is called by bash, but somehow it wouldn't find the Gaussian-03.expt file. Maybe it has something to do with the use of csh -f
NOTE that the file isn't imported -- it's just opened. It would've been nice if you could actually import the calculation into ECCE. Still, being able to view it is a nice start.
Original post:
When opening a gaussian output file with the ECCE viewer:
* a symlink to the file is put in a subdirectory of /tmp
* the file is parsed for indications as to what the file type is:
That's easy enough to fool by simply putting a Gaussian 03 line in the output (assuming that the G09 and G03 output are similar enough).+go+cd /tmp/ecce_me/jobs/Gaussian03__HEa24c +go+ln -s /home/me/calcs/test/Outputs/g03.g03out g03.g03out; echo CMDSTAT=$status CMDSTAT=0 +go+grep "Gaussian 98, Revision" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "Gaussian 94, Revision" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "Gaussian 03, Revision" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "%begin%input" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "%begin%input" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "Northwest Computational Chemistry Package" /home/me/test/Outputs/g03.g03out; echo CMDSTAT=$status
Here's a successful example, in the sense that ECCE found that it was a Gaussian 03 file:
CMDSTAT=0 +go+grep "Gaussian 98, Revision" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "Gaussian 94, Revision" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "Gaussian 03, Revision" g03.g03out; echo CMDSTAT=$status Gaussian 03, Revision CMDSTAT=0 +go+if (-w /tmp/ecce_me/jobs/Gaussian03__7491Sb) echo TRUE TRUE +go+echo $PATH; echo CMDSTAT=$status Word too long. +go+if (-x Gaussian-03.expt) echo TRUE +go+exit; echo GOODBYE exit; echo GOODBYE
However, it fails to detect that Gaussian-03.expt is present and executable (both of which are true).
[SOLUTION]
To sort that out and to enable G09 detection, edit apps/data/client/cap/Gaussian-03.edml:
465 <output mimetype="chemical/x-gaussian03-output" type="parse" verifypattern="Gaussian 09, Revision">g03.g03out</output> 466 <output mimetype="chemical/x-gaussian-03-output" type="parse" verifypattern="Gaussian 09, Revision">g03.out</output> 467 <output mimetype="chemical/x-gaussian03-output" type="parse" verifypattern="Gaussian 03, Revision">g03.g03out</output> 468 <output mimetype="chemical/x-gaussian-03-output" type="parse" verifypattern="Gaussian 03, Revision">g03.out</output> .. 480 <importer>${ECCE_HOME}/scripts/parsers/Gaussian-03.expt </importer>
Your G09 files should now open properly (most of the time).
My ecce_env is fine and my runtime_setup.sh file is called by bash, but somehow it wouldn't find the Gaussian-03.expt file. Maybe it has something to do with the use of csh -f
NOTE that the file isn't imported -- it's just opened. It would've been nice if you could actually import the calculation into ECCE. Still, being able to view it is a nice start.
609. NBO6 on a debian cluster (/w g09)
Curse blogspot and the lack of revision control and backups! I lost my post when it was almost finished.
So here's a briefer version. I have bought NBO6 and I want to integrate it with gaussian G09 rev. D (you can't use it directly with earlier binary versions)
My 'instructions' are basically copy/pasted from the NBO6 installation instructions -- this is a tl;dr version.
So here's a briefer version. I have bought NBO6 and I want to integrate it with gaussian G09 rev. D (you can't use it directly with earlier binary versions)
My 'instructions' are basically copy/pasted from the NBO6 installation instructions -- this is a tl;dr version.
Edit:sudo cp nbo6.0-bin-linux-x86_64.tar.gz /opt/ cd /opt/ sudo tar xvf nbo6.0-bin-linux-x86_64.tar.gz sudo chown $USER:$USER nbo6 -R vim nbo6/bin/gaunbo6
In your queue file add3 set INT = i8 4 set BINDIR = /opt/nbo6/bin
In my case, as I use ECCE I edited my apps/siteconfig/CONFIG.node files:set path = ( /opt/nbo6/bin $path )
I then tested it by running a basic gaussian calculation:Gaussian-03Command{ set path = ( /opt/nbo6/bin $path ) setenv GAUSS_SCRDIR /home/me/scratch setenv GAUSS_EXEDIR /opt/gaussian/g09d/g09/bsd:/opt/gaussian/g09d/g09/local:/opt/gaussian/g09d/g09/extras:/opt/gaussian/g09d/g09 /opt/gaussian/g09d/g09/g09< $infile > $outfile echo 0 }
and got%Chk=H2O_631g.chk #P rOPBE/6-31G 6D 10F SCRF=(PCM,Solvent=water) Punch=(MO) pop=(nbo6) H2O 6-31G 0 1 ! charge and multiplicity O 0.00000 0.00000 0.118491 H 0.00000 0.754898 -0.473964 H 0.00000 -0.754898 -0.473964
... 411 fchk file "/home/me/scratch/Gau-24659.EFC" 412 mat. el file "/home/me/scratch/Gau-24659.EUF" 413 414 Writing Wrt12E file "/home/me/scratch/Gau-24659.EUF" 415 Gaussian matrix elements Version 1 NLab= 7 Len12L=8 Len4L=8 416 Write GAUSSIAN SCALARS from file 501 offset 0 to matrix element file. .. 429 Write ALPHA FOCK MATRIX from file 10536 offset 0 to matrix element file. 430 No 2e integrals to process. 431 Perform NBO analysis... 432 433 *********************************** NBO 6.0 *********************************** 434 N A T U R A L A T O M I C O R B I T A L A N D 435 N A T U R A L B O N D O R B I T A L A N A L Y S I S 436 ********************* Me ********************* .. 447 Filename set to /home/me/scratch/Gau-24659 .. 620 ------------------------------- 621 Total Lewis 9.99612 ( 99.9612%) 622 Valence non-Lewis 0.00029 ( 0.0029%) 623 Rydberg non-Lewis 0.00358 ( 0.0358%) 624 ------------------------------- 625 Total unit 1 10.00000 (100.0000%) 626 Charge unit 1 0.00000 627 628 $CHOOSE 629 LONE 1 2 END 630 BOND S 1 2 S 1 3 END 631 $END 632 633 Maximum scratch memory used by NBO was 62605 words 634 Maximum scratch memory used by G09NBO was 9032 words ...
29 May 2015
608. Bruker Topspin on Debian Jessie
Here's a more extensive description of how to install Bruker Topspin (student version):
Very briefly:
Here are screenshots from the installation process:
The only thing that remained was to install the license.dat file that Bruker had issued to my student:
And finally:
Very briefly:
[I was doing this while logged in via ssh -XC to the student's computer, and without a pdf reader installed. If a pdf opens, close it to continue the installation. Don't worry about the errors.]$ wget http://bruker.telemaxx.net/student/linux-topspin.sh $ sudo dpkg --add-architecture i386 $ sudo apt-get update $ sudo apt-get install libxft2:i386 libxtst6:i386 perl-tk libcups2:i386 openjdk-7-jdk $ su - # xauth merge /home/user/.Xauthority # exit $ sh linux-topspin.sh $ ~/carbon/topspin$ sh linux-topspin.sh Verifying archive integrity... All good. Uncompressing TopSpin 3.2.............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. NOTE: no display found - trying localhost:11.0 Using TCL_LIBRARY=/tmp/selfgz29293/linux/tcl-8.5.11/lib/tcl8.5 Using TK_LIBRARY=/tmp/selfgz29293/linux/tk-8.5.11/lib/tk8.5 Please enter root password if prompted for it. Password: Starting /tmp/selfgz29293/linux/tk-8.5.11/bin/wish8.5 -f /tmp/selfgz29293/xwinstall.d/swim/lib/xwinstall.tcl -- Using log file: /tmp/install.log Error while displaying /tmp/selfgz29293/rellet.pdf with /tmp/swim-29462/prog/bin/xpdf : /tmp/swim-29462/prog/bin/xpdf: error while loading shared libraries: libSM.so.6: cannot open shared object file: No such file or directory Using log file: /opt/topspin3.2/install.log Error: Cannot create user account flexlm: useradd flexlm: useradd: group flexlm exists - if you want to add this user to that group, use -g. Errors occurred during installation: Error: Cannot create user account flexlm: useradd flexlm: useradd: group flexlm exists - if you want to add this user to that group, use -g.
Here are screenshots from the installation process:
And then we were able to start topspin:sudo mv /usr/local/flexlm/Bruker/licenses/license.dat /usr/local/flexlm/Bruker/licenses/license.bak sudo cp ~/carbon/topspin/license.dat /usr/local/flexlm/Bruker/licenses/license.dat
Subscribe to:
Posts (Atom)