Re: [Wien] Wien2k 19.1 with linux+gfortran benchmarks

2019-12-12 Thread Hemza
thank you, Peter and Pavel, for the clarifications. On Thu, 12 Dec 2019 at 14:06, Pavel Ondračka wrote: > I concur. > > In general for the serial test case on modern CPU (avx2 instructions) > your runtime should be around or below 30seconds for single thread. > > However as this is almost 10

Re: [Wien] Wien2k 19.1 with linux+gfortran benchmarks

2019-12-12 Thread Pavel Ondračka
I concur. In general for the serial test case on modern CPU (avx2 instructions) your runtime should be around or below 30seconds for single thread. However as this is almost 10 years old mobile CPU with just avx instructions the total runtime of slightly above 1 minute is expected. Regarding

Re: [Wien] Wien2k 19.1 with linux+gfortran benchmarks

2019-12-12 Thread Peter Blaha
It is perfectly ok for your hardware. The cpu time is not so important for you, what counts is the WALL-time (this is the time it really takes until it finishes). You can see that Hamilt parallelizes fairly well (3.7 vs. 12.3 seconds / speedup factor 3.3), HNS is not so good (3.8 vs. 8.8 s /

Re: [Wien] 24k points on 36processors ??. (a Fractional k-point per core)

2019-12-12 Thread Pavel Ondračka
I'm neither a PBS or csh expert but to me it looks like you are spawning just a single kpoint job for each node and also for the lapw0 just a single process per node. If you run just a single k-point job at the node and there is still not enough memory than you probably need MPI. Or maybe the

Re: [Wien] more on LAPW2 weight and Fermi

2019-12-12 Thread Peter Blaha
Yes, this is probably the problem. EF is "manually" increased to process in some other programs also states which are above EF (but have a small occupancy in such broadening methods). This increase is done internally for Gauss and TETRA (0.5), but for TEMP the printed EF has it variable

[Wien] Wien2k 19.1 with linux+gfortran benchmarks

2019-12-12 Thread Hemza
Hi everybody: I just finished updating my wien2k installation to 19.1 with openMP support (linux (4.19.88), gfortran (9.2.0), openblas-lapack-openmp (0.3.7), fftw3 (3.3.8), libxc (4.3.4)), and patches from " https://github.com/gsabo/WIEN2k-Patches;. I intend to use it for relatively small cases

Re: [Wien] 24k points on 36processors ??. (a Fractional k-point per core)

2019-12-12 Thread Ashwani Kumar
Dear Sir, Hyper-threading is disabled (just checked with facility expert). So 12 physical cores per node (intel xeon nehalem based arch.). Available Memory 4gb/core (48gb/node). Lapw1 stops with error "insufficient virtual memory". So i thought better to use 36 cores for 24k

Re: [Wien] 24k points on 36processors ??. (a Fractional k-point per core)

2019-12-12 Thread Pavel Ondračka
Hi, do you have hyperthreading or not (in other words does this number of 12 already mean there are 6 physical CPUs and 12 virtuals, or 12 physical)? This would influence the advice maybe a bit... Otherwise you need to experiment, the optimal setting is heavily dependent on your specific CPU,

[Wien] 24k points on 36processors ??. (a Fractional k-point per core)

2019-12-12 Thread Ashwani Kumar
Hi, This is related to no. of k-points which we provide during the initilization. No. of k-gen points given ; 120 with shifted mesh. Irr. k-points : 24k points. Running job on 3 nodes (12 x3 processors, 48 gb x 3 Ram). Job running on 24 processors only (with granularity: 1, extrafine:1 in

Re: [Wien] All cpus are not running for a single calculation

2019-12-12 Thread Gavin Abo
a) Don't confuse a thread and a CPU (e.g. with multiple processor cores): https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18964.html b) I suggest you search the mailing list archive, there is probably many good examples that have been posted in the past. For example, one of