[Wien] band character plotting with eece

Dear Wien2k mailing list, is this enough for spaghetti with band character for onsite hybrids? x lapw1 (-up/-dn) -orb -band x lapw2 (-up/-dn) -qtl -band or do I need also -eece -orb switches for lapw2? Best regards Pavel ___ Wien mailing list

Re: [Wien] Few questions about onsite hybrids and so

Dear prof. Blaha, wow, thanks a lot for such a detailed answer. This was very helpful indeed. Best regards Pavel "Hi, Here are my comments. Most of them similar to what Laurence said. > I'm trying to calculate a band structure of Tb3Ga5O12 magneto-optical > crystal (cubic Ia-3d, 80

Re: [Wien] Few questions about onsite hybrids and so

On Mon, 2024-02-12 at 20:57 +0800, Laurence Marks wrote: > With an RMT for Tb of 2.43 the O2p will leak into the Tb sphere. I > used 2.02. You may want to use -ecut .995 or simioar rather than a > fixed energy. Will try, thanks. > If your Ga & Tb positions are fixed then I guess -so might work

Re: [Wien] Few questions about onsite hybrids and so

PhysRevMaterials.5.125002, > 10.1021/acs.inorgchem.2c04107 Note that the XPS is dominated (cross- > sections) by the 4f, and in TbScO3 that are at the Fermi edge (if it > is Tb3+, Tb4+ will be simpler). This is very exhaustive list, thanks. Will definitely read through it. Best

[Wien] Few questions about onsite hybrids and so

Dear Wien2k mailing list, I'm trying to calculate a band structure of Tb3Ga5O12 magneto-optical crystal (cubic Ia-3d, 80 atoms). While I consider myself quite experienced Wien2k user, I've always managed to stay away from f block elements, so my experience here is none. So besides the few

Re: [Wien] Speeding up calculations in parallel mose

Dear Viktor, at 54 atoms, you should have enough k-points to run k-parallel which is probably going to be the fastest option. So lapw1 + lapw2 k-parallel and the rest OpenMP parallelized. An example .machines file for your 8 cores could look like this: 1:localhost 1:localhost 1:localhost

Re: [Wien] FFTW compiling

Besides what Gavin mentioned, even if you get the correct fftw-openmpi (or elpa-mpi) package, Red Hat distros don't install mpi stuff by default into /usr/lib64. The reason is that more that one MPI runtime can be installed (like MPICH vs OpenMPI) and the mpi libraries are MPI- runtime specific.

Re: [Wien] compilation of Wien2k with GNU OpenMPI, but with MKL library ?

I believe it should be possible, at least the MKL link time advisor  https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl-link-line-advisor.html definitely allows to select GNU compiler and OpenMPI. But yeah, it might be more painful than going either fully Intel® oneAPI or GNU

Re: [Wien] Wien2k access outside local area network

Hello Chithra, it all depends on you network settings, in theory all you need is a public IP and open ports. But this forum is not the good place to ask, check with you local area network admin (who will also surely talk you through the potential security risks). Best regards Pavel On Fri,

Re: [Wien] benchmark test withi9-12900k

Hi Sandeep, > > I have a query regarding this. > While performing serial or parallel calculations, on increasing  omp > from 1 to 8 , %age use of cpu's does not increase in the same scale > (omp=2, 170to 180% , omp=4 ,300 to 330%  omp=8 only 500 to 550%). > is something wrong in configuring or

Re: [Wien] How to find the exact value of infinte epsilon?

Dear Atefe Marasi, to add on top of what Xavier said, and thus similarly to him I'm also assuming that by "infinite epsilon, i.e., dielectric constant at high frequency" you mean the electronic part the dielectric tensor. Or in other words the part from the electronic excitations. That you can

Re: [Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

Hi Gavin, I think steps 1-5 (more or less the first 6 pages) can simplified to something like "sudo apt instal libxc-dev openblas-openmp-dev libscalapack-openmpi-dev openmpi-common libopenmpi-dev libfftw3-dev libfftw3-mpi-dev ...". (I just googled the package names as I'm not Ubuntu user, but I

Re: [Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

Hi David, this is as good as it goes I guess, the HAMILT was speed up by ~30%, but it is not so noticeable, because it actually scales much better with the thread number than the rest (so it is actually running much faster than the other parts at 4 threads, therefore further improvements are not

Re: [Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

;DHAVE_LIBMVEC" {} \; > yields nothing in my Wien2k source directory. > > David > > Am 24.11.2021 um 14:43 schrieb Pavel Ondračka: >   > > Dear David, > > > > nice, ~30 seconds instead of ~150 :-) > > BTW is this already with &quo

Re: [Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

vid Holec > Computational Materials Science group > Department of Materials Science > Montanuniversität Leoben > > > > Franz-Josef-Strasse 18, A-8700 Leoben, Austria > tel. +43-(0)3842-4024211 > fax. +43-(0)3842-4024202 > materials.unileoben.ac.at > cms.unileoben.

Re: [Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

-bit > Byte Order:  Little Endian > Vendor ID:   GenuineIntel > CPU family:  6 > Model:   26 > Model name:  Intel(R) Xeon(R) CPU   W3550 >  @ 3.07GHz > ) > > >

Re: [Wien] Compiling Wien2k 21.1 on Ubuntu 20.04 with gfortran

Hi David, as you said it works for you, so feel free to ignore, but I have some further tips if you are interested. Ubuntu switches between the different blas and lapack using the "alternatives", so its difficult to say if you actually link with the correct one. "ldd lapw1" in WIENROOT should

Re: [Wien] generalized regular k-point grids

VASP KPOINTS format... Best regards Pavel > > Peter Blaha > > Am 10/14/21 um 2:52 PM schrieb Pavel Ondračka: > > Dear Wien2k mailing list, > > > > Is Wien2k ready for a general k-point grid or is some part of the > > code > > assuming regular grid? >

[Wien] generalized regular k-point grids

Dear Wien2k mailing list, Is Wien2k ready for a general k-point grid or is some part of the code assuming regular grid? I was reading some papers about how the generalized regular k-point grids have better efficiency over the standard Monkhorst-Pack ones... For example this paper has also an

Re: [Wien] install WIEN2k_21.1 on Ubuntu 21.04

Dear Viktor, I don't think that the Intel® oneAPI Base Toolkit actually includes the fortran compiler, at least not according to: https://software.intel.com/content/www/us/en/develop/tools/oneapi/all-toolkits.html#hpc-kit I think you need Intel® oneAPI HPC Toolkit to get ifort. BTW in general

Re: [Wien] segmentation fault in lapwso

er cases. > > > > An alternative is to switch back to zheevx (commented in the code). > > > > Peter Blaha > > > > Am 18.08.2021 um 20:01 schrieb Pavel Ondračka: > > > Right, I think that the reason deallocate is failing because the > > memory > &g

Re: [Wien] segmentation fault in lapwso

ometimes this is better. Or use other things > > like debuggers or valgrind. > > > > On Wed, Aug 18, 2021 at 10:47 AM Pavel Ondračka > > wrote: > > > I'm CCing the list back as the crash was now diagnosed to a > > > likely > > > MKL > > >

Re: [Wien] segmentation fault in lapwso

I'm CCing the list back as the crash was now diagnosed to a likely MKL problem, see below for more details. > > > > So just to be clear, explicitly setting OMP_STACKSIZE=1g does not > > help > > to solve the issue? > > > > > Right! OMP_STACKSIZE=1g with OMP_NUM_THREADS=4 does not solve the >

Re: [Wien] segmentation fault in lapwso

Dear Luis, one very easy thing to try could be to set environment variable OMP_STACKSIZE to something large like "1g", i.e., "export OMP_STACKSIZE=1g" before run_lapw. Small OpenMP stacksize caused issues for us previously so could be the case here as well. The only explicit omp loop in hsocalc.F

Re: [Wien] Installing WIEN2k, w2web not running

On Wed, 2021-04-14 at 06:12 +, delamora wrote: > Thank you Pavel > > I do a search > dnf search perl-Sys-Hostname > and I get; > perl-Sys-Hostname-Long.noarch : Try every conceivable way to get full > hostname > I will try it I'm not sure about the perl-Sys-Hostname-Long.noarch package. On

Re: [Wien] Installing WIEN2k, w2web not running

Hi Pablo, there is a difference between the package with hostname utility and the missing perl package with Sys::Hostname module. The proper package should be perl-Sys-Hostname. Best regards Pavel On Tue, 2021-04-13 at 23:21 +, delamora wrote: > I have a comment at the end > Dear WIEN2k

Re: [Wien] consistent RKmax and sphere size settings

0.5, then interpolate using a straight line. > This is similar. > > On Wed, Apr 7, 2021 at 3:24 PM Pavel Ondračka > wrote: > > Dear Wien2k mailing list, > > > > I have a series of TiN and TiON amorphous-like structures where I > > have > > some large

[Wien] consistent RKmax and sphere size settings

Dear Wien2k mailing list, I have a series of TiN and TiON amorphous-like structures where I have some large differences in spheres sizes for N atoms. In most of the structures the smallest N sphere is around 1.6-1.7, however in some I have few N atoms with 1.3 (the structures should be OK, this

Re: [Wien] convergence criteria in scf file?

On Wed, 2020-11-04 at 07:30 +, Tran, Fabien wrote: > Is the grep of :ENE, :DIS and :FOR not useful enough? Right, this is what one would expect, but just to be 100% certain, the scf is stopped when the change between :ENE, :DIS and (maximum change?) in :FOR in the last ?two? iterations is

[Wien] convergence criteria in scf file?

Dear Wien2k mailing list, I'm looking at some old saved calculations, where I don't have the dayfile (but I vaguely remember some convergence troubles). So I'm now looking at the scf file and wondering if it is possible to tell from the scf file, what was the final convergence of energy, charge

Re: [Wien] finding density of states for individual bands

The problematic part is that while joint claims it can give you a DOS for just one band (with the switch 2), this is actually not a DOS of a single band but of a single band index. This will be the same thing only if there is no band crossing (the difference will be obvious if you do energy band

[Wien] NOMAD and Wien2k

Dear Wien2k mailing list, I'm experimenting with the NOMAD database (nomad-lab.eu) and since I remembered some old post from prof. Blaha on this topic, I just thought I would ask here for user experience, because so far its not really working that well for me. So first of all the most annoying

Re: [Wien] parallel instalation of Wien2k: elpa, fftw

gt; nobody else has thought", Albert Szent-Gyorgi > www.numis.northwestern.edu > > On Mon, Sep 14, 2020, 07:26 Pavel Ondračka > wrote: > > On Mon, 2020-09-14 at 06:08 -0600, Gavin Abo wrote: > > > See that "./configure --enable-mpi" was used. > > &g

Re: [Wien] parallel instalation of Wien2k: elpa, fftw

On Mon, 2020-09-14 at 06:08 -0600, Gavin Abo wrote: > See that "./configure --enable-mpi" was used. > > Of note, sometimes -gcc-sys is needed: > > https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18664.html Out of interest I went through the link and I don't see how the linker

Re: [Wien] parallel instalation of Wien2k: elpa, fftw

On Mon, 2020-09-14 at 06:51 -0500, Laurence Marks wrote: > ? > > I have never used dynamic fftw, and never had a problem so I doubt > that is the issue. I also don't have any issues with static linking but I do fix the Makefiles manually when siteconfig fails me. If you have a way how to link

Re: [Wien] parallel instalation of Wien2k: elpa, fftw

I think I see the issue, libfftw3_mpi.a is a static library Please build FFTW with something like --enable-dynamic, or so, to get the dynamic libraries as well (I don't remember the exact switch, but ./configure --help will list you all the options, so just find it there). If you have

Re: [Wien] error in mixer

> forrtl: severe (168): Program Exception - illegal instruction Did you compile Wien2k on different machine than you run it now on? What were your compilation options? This looks like your lapw1 binary was compiled with some instructions which are not available on the machine... Best regards

Re: [Wien] Why the GAP appeared in DOS plot is lower than the GAP obtained during "Analysis"

Another option is that you applied some broadening to your DOS, the gap in the DOS than would look smaller. Best regards Pavel On Thu, 2020-04-23 at 08:12 +, Tran, Fabien wrote: > The gap shown in Analysis is :GAP in case.scf. If a different k-mesh > (than the one used during the SCF

Re: [Wien] Lapw.2 error

Not directly related to this thread, but since reports of this bug (and some others with known fixes) keeps reappearing, how about making a 19.2 (or 19.1.1) bugfix release (just 19.1 code + fixes from Gavins repo)? Unless next major version is already round the corner. Just my two cents Best

Re: [Wien] fold2Bolch - gfortran

Hi, gfotran should in theory compile anything what ifort does (assuming the code is a valid standard fortran, which might not be a case for stuff which is only used/tested with ifort). Just set the compiler to gfortran instead of ifort, use the same flags as for Wien2k ("-ffree- form

Re: [Wien] TELNES calculation

Dear Ali, please do core holes only for atoms with multiplicity 1 (otherwise you add multiple core hole at once, and you will get interaction between them, which is what you want to avoid with the supercell in the first place)! Just name (number) one oxygen atom for every non-equivalent oxygen

Re: [Wien] PES issues

"arbitrarily" chosen > weights. > After all you fit: Y = x1*A + x2*A (A is the identical PDOS of > atom 1 > and 2). Then x1 and x2 are are not uniquely defined. > > > On 3/13/20 3:27 PM, Pavel Ondračka wrote: > > Dear Peter, > > > > thanks for th

Re: [Wien] PES issues

timely, you can also wait with the download until > this > is also fixed. > > PPS: Since you have N-s basis and it is used in the fit, you must > include its PDOS also. Thus you must include the PDOS for lower > energy, > such that the N-s band is included. Otherwise the fit m

[Wien] PES issues

Dear Wien2k mailing list, I'm experiencing a crash when trying to calculate valence band spectra for VN. (This is a resend of previous email which is stuck in the queue due to being slightly over the size limit, now with a link instead. I apologize for double posting if the original one

Re: [Wien] Ask for help

Dear Siham, yes, you can get a full dielectric tensor from Wien2k, just select the appropriate components in case.inop and case.injoint files. If I remember correctly the orientation of the tensor is that the xx direction of the dielectric tensor is in the direction of the a lattice parameter,

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

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] 24k points on 36processors ??. (a Fractional k-point per core)

ow to set the omp_thread in *.machine > file. (jobscript file attached for your reference). > > thanks, > A. kumar > > On Thu, Dec 12, 2019 at 2:55 PM Pavel Ondračka < > pavel.ondra...@email.cz> wrote: > > Hi, > > > > do you have hyperthreading or no

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

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,

Re: [Wien] Issues with Wien2k installation

On Wed, 2019-12-04 at 06:29 +, Vidit Zala wrote: > Dear Sir, > I am using Wien2k version 19.1 on a thinkstation with i7 processor, > having ubuntu installed in it. I have just installed Wien2k in the > machine. The gfortran compiler and gcc are used. > After the installation, I have made a

Re: [Wien] lapw2 crashed error

Hi, I can't comment on the lapw2 error but just a small note about the .machines file. The four "100:localhost" lines mean that you run the lapw1, lapw2 and hf parallel over kpoints (in four separate processes). The "omp_global:4" line means that every Wien2k process will try to use 4 threads.

[Wien] possible overload/underload with OpenMP or threading in general

Dear Wien2k mailing list, in some recent discussion with profs. Marks and Blaha it was shown that under some circumstances the threading parallelization in Wien2k and its interaction with threaded BLAS/LAPACK environment variable (MKL but possibly also OpenBLAS and others) might have unexpected

Re: [Wien] apw2c tries to read an anomalous amount of data

If you see a linear scaling for maximum used memory of lapw1c process as a number of threads even at low thread number than there is something strange going on. In fact the most memory consuming diagonalization part should more or less take the same amount of memory independent of the number of

Re: [Wien] lapw2c tries to read an anomalous amount of data

The easiest solution to reduce memory pressure is to reduce the number of k-points run in parallel... You should experiment with other parallelization options. If running 4 kpoints in parallel does not fit in your memory (or is slow), try to run for example just with two but with 2 OpenMP threads

Re: [Wien] 3p or 4p PDOS for 3d transition metal

If I remember correctly I had some some similar problems in the past if the deep lying states width was too thin (with respect to the energy step). Try to reduce the energy step in tetra, or maybe increase the broadening... Best regards Pavel On Fri, 2019-07-12 at 15:30 +0800, 杨柯 wrote: > Thanks

Re: [Wien] FFTW compiling

Maybe Gavin can clarify but I'm not actually sure if the instructions in the mentioned email are 100% correct. FFTW there is compiled with the default static libs (libfftw3.a and libfftw3_mpi.a), but the actual -lfftw3 -lfftw3_mpi flags used for linking are for the dynamic library (libfftw3.so and

Re: [Wien] lapw2c tries to read an anomalous amount of data

Just out of curiosity, how do you measure the current disc usage per process? Also, how large is your memory consumption? Very high disc IO (and bad speed in general) can also be associated with swapping. lapw2 can be the most memory intensive part of the scf cycle. Best regards Pavel On Tue,

Re: [Wien] core-hole calculation in a molecule

ppy with the calculations now, except for the speed ;-) Best regards Pavel On Fri, 2019-06-21 at 07:39 +0200, Pavel Ondračka wrote: > On Wed, 2019-06-19 at 16:25 +0200, Peter Blaha wrote: > > This is certainly interesting. > > > > For a molecule an alternative i

Re: [Wien] core-hole calculation in a molecule

On Wed, 2019-06-19 at 16:25 +0200, Peter Blaha wrote: > This is certainly interesting. > > For a molecule an alternative is to remove one electron and then use > E-tot(N) - E_tot(N-1) as binding energy. However, in this case due > to > the charged cells, I'd expect quite some dependency on the

[Wien] core-hole calculation in a molecule

Dear Wien2k mailing list, I'm trying to calculate core electron binding energies using the Slaters transition state approach (half electron removed from the core compensated by the background charge) in an organic molecule. As part of the usual convergence checking I did four calculations with

Re: [Wien] compiling error of lapw1_mpi

h to say how its intended to work. Hopefully prof. Blaha can confirm this is the correct solution. Best regards Pavel On Fri, 2019-06-14 at 11:31 +0200, Wien2k User wrote: > YES, we have compiling lapw1_mpi just with intel MPI without ELPA > > Le ven. 14 juin 20

Re: [Wien] compiling error of lapw1_mpi

I'll make a guess that this is with MPI but without ELPA? The DLCOLHS and the others are defined inside "#ifdef ELPA" block #ifdef ELPA lcolhs, dlcolhs, elpa_switch, scala_switch, elpa_mem_default #else but used also in "#ifdef parallel" blocks (specifically the one

Re: [Wien] System configuration

Right, as was written in the previous email, the provided config is a weird mix of ifort and gfortran options, also at some point in siteconfig you did chose that you want parallel build which now fails. > SRC_dstart/compile.msg:make: *** [para] Error 2 All the errors which I have seen up to

Re: [Wien] System configuration

If you dont mind you can access my pc through team viewer.  On Thu, May 23, 2019 at 7:50 PM Pavel Ondračka mailto:pavel.ondra...@email.cz)> wrote: "Well, first we need to figure out why is your serial lapw so slow... You definitely don't have the libmvec patches, howeve

Re: [Wien] System configuration

e help me. > > Thanking you > > Indranil > > On Thu, May 23, 2019 at 11:22 AM Pavel Ondračka < > pavel.ondra...@email.cz> wrote: > > Hi Indranil, > > > > While the k-point parallelization is usually the most efficient > > (provided you have suffic

Re: [Wien] System configuration

Hi Indranil, While the k-point parallelization is usually the most efficient (provided you have sufficient number of k-points) and does not need any extra libraries, for 100atoms case it might be problematic to fit 12 processes into 32GB of memory. I assume you are already using it since you

Re: [Wien] Wien2k on AVX512 CPUs

On Wed, 2019-02-27 at 06:54 -0600, Laurence Marks wrote: > The script I used is below, works fine with versions 19.0.2.187 > 20190117. You might have wanring/issues with the compilation of their > test programs; I hacked configure.ac to remove them. > > I suspect the issue with HAMILT is

Re: [Wien] Wien2k on AVX512 CPUs

gt; > DIAG =27.0 > > > TIME HAMILT (WALL) = 2.6, HNS = 1.0, > > HORB = > > > 0.0, > > > DIAG = 3.5 > > > - > > &

[Wien] Wien2k on AVX512 CPUs

Dear mailing list, just out of curiosity has anyone any experience running Wien2k on a AVX512 capable machine (eg. the KNL accelerators or recent Intel skylake-avx512 CPUs)? Recently my cluster updated to this skylake-avx512 machines however I'm unable to get any better performance for Wien2k.

[Wien] expand script name clash with the GNU coreutils utility expand

Dear Wien2k mailing list, this is not a bugreport per se but it might be wise to remove the short "expand" symlink to the expand_lapw script from the Wien2k package. There is actually a name clash with the "expand" utility from GNU coreutils (

Re: [Wien] N1s binding energy in TiN

On Thu, 2019-01-17 at 09:28 +0100, Peter Blaha wrote: > Sorry for the confusion. The quoted values in the pdf are probably > from > a lousy calculation and are ment only to demonstrate the effect (if > I > remember correctly, only a 4x bigger P supercell, but for sure not > converged, I also

Re: [Wien] N1s binding energy in TiN

ried to align the experimental spectra to the valence band maximum for comparison with calculations which sort of works but introduces extra uncertainties. Anyway thank you for the thoughts. Best regards Pavel Ondračka > > _ > Professor Laurence Marks > "Research is to see what ev

[Wien] N1s binding energy in TiN

Dear Wien2k mailing list, I'm looking for some advice regarding the calculation of core level binding energies (to compare with XPS experiments). First of all there is this nice lecture where prof. Blaha actually shows some calculations

Re: [Wien] non-zero value of epsilon 2 below the energy band gap

Dear Anup Pradhan Sakhya, this probably just due to the broadening procedure. If you set broadening to zero in kram, than you show have no absorption below the band gap (with plain optic and no scissor). Or just take a look at the output from joint which should contain the unbroadened imaginary

Re: [Wien] "OpenBlas" package instead of default "blas"

On Mon, 2018-11-19 at 23:54 +0530, Ashwani Kumar wrote: > Dear Dr. Pavel Ondracka, > In previous thread, > https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18098.html > > you advised to use OpenBlas package to extract best performance from > processor. Since i was having

[Wien] crash in tetra -enefile

Dear Wien2k mailing list, there is a small bug in tetra -enefile which could occasionally result in a crash like this: x tetra -enefile Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Segmentation fault (core dumped) 0.023u 0.389s 0:00.56

Re: [Wien] Help Request for making WIEN2K (ver18.2) programs executable.

It would be probably reasonable to add the "-ffpe-summary=none" to the default gfortran flags to not scare a new users (as this "issue") is being brought up over and over again  (hint to prof. Blaha). In fact, I tried quite hard to debug lot of those things and in general to hunt down the

Re: [Wien] Fwd: Help Request for making WIEN2K (ver18.2) programs executable.

Dear Ashwani, the problem is that the libxc modules are not installed in /usr/include on Fedora (and some other distros). This is kinda stupid (but the rationale being that the mod files are not headers in the standard sense, but rather a binary (compiler and arch dependent) files). The are in

[Wien] OpenMP parallelization in lapw0

Dear Wien2k mailing list, there is some ongoing work to use OpenMP in lapw0 to provide another level of parallelization in addition to the MPI (which parallelizes over atoms). The current version should be almost production ready and was already tested with some standard stuff (LDA,PBE,sp,etc.)

Re: [Wien] $DEC! NOOPTIMIZE equivalents in gfortran?

I can look at the gfortran, what is your testcase? I tried to take a quick look with the full mixer using one random TiO2 case. I put a breakpoint after some random Kahan sum (specifically this was at charge.f:150 in Wien2k 18.2) and I looked for the differences between O0 and O2. I was actually

Re: [Wien] crash with -it

On Wed, 2018-07-11 at 11:21 +0200, Peter Blaha wrote: > I've been able to reproduce the problem with gfortran, and also made > a > fix, which according to my tests seems to work. > > Please try the attached jacdavblock.F file. > > This fix is not necessary if ifort is used, but should not harm

Re: [Wien] compilation problems in the new pes module

te this to a simple test case it works, so there is some subtle bug going on. Converting the code to doubles fixes this particular case. But this is more of a workaround than a fix, I'll report when I have more idea what is going on, thanks for all the help. Best regards Pavel > > Am 10.0

Re: [Wien] compilation problems in the new pes module

the O-total dos and Ti-total dos in addition to the O-s, O-p, Ti-s, Ti-d? Would you be so kind to share some example case as I believe it might save some further explanation? BTW can the [Bagheri and Blaha 2018] manuscript be already accessed somewhere? Best regards Pavel Ondračka &quo

Re: [Wien] compilation problems in the new pes module

So after applying the suggested compilation fixes (+ the one uninitialized variable fix suggested later) I started to test the pes program. My testcase was simple anatase TiO2. The program finishes fine, however the spectrum is strange (looks like the Ti3p peak is almost invisible). So I run with

[Wien] crash with -it

Dear Wien2k mailing, so I noticed that the old crash with -it (with gfortran only of course) is still present in the 18.1 version: At line 140 of file jacdavblock_tmp_.F (unit = 200, file = './case.storeHinv_1_proc_0') Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker,

Re: [Wien] supported ELPA versions?

mory it actually wants... Best regards Pavel > Kind regards, > Thomas > ________ > Von: Wien im Auftrag von > Pavel Ondračka > Gesendet: Montag, 09. Juli 2018 15:26 > An: wien@zeus.theochem.tuwien.ac.at > Betreff: [Wien] supported ELPA versio

Re: [Wien] compilation problems in the new pes module

Thanks for the fixes, the code compiles now. I've prepared a patch so that other users don't have to patch by hand, and also for Gavin if he continues the great work of collecting fixes in his repo. Copy to the SRC_pes folder and apply with patch -p1 < pes-patch.txt Best regards Pavel On Tue,

[Wien] supported ELPA versions?

Dear Wien2k mailing list, what is the recommended ELPA version? I've tried the 2017.05.003 and 2018.05.001 versions with no luck (missing mod_blacs_infrastructure.mod file). Best regards Pavel ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at

[Wien] compilation problems in the new pes module

Dear Wien2k mailing list, I'm interested in the new pes module. Unfortunately, the compilation of the module faces some problems with gfortran, specifically: - pes.f:114:19: read (*,'(I)') database 1 Error: Nonnegative width required in format string at

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

n 05/29/2018 12:36 PM, Pavel Ondračka wrote: > > On Wed, 2018-05-09 at 14:17 -0500, Laurence Marks wrote: > > > You are right, this is a bug (potentially severe). In my local > > > version I replaced somm with a more standard integration as somm > >

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

rds Pavel > > On Wed, May 9, 2018 at 2:11 PM, Pavel Ondračka cz> wrote: > > -- Původní e-mail -- > > Od: Laurence Marks > > Komu: A Mailing list for WIEN2k users > .at> > > Datum: 9. 5. 2018 18:18:21 > > Předmět: Re: [Wien] IEEE_UNDER

Re: [Wien] Problems when trying to plot E vs c/a

Riyajul Islam píše v Pá 18. 05. 2018 v 19:25 +0530: > I also have the same problem with E vs c/a plot. Then when I replace > optimize.pl your attached one the I get an error > Failed to exec /home/dipraj/wien2k/SRC_w2web/htdocs/exec/optimize.pl > : Permission denied Dear Riyajul, you probably

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

-- Původní e-mail -- Od: Laurence Marks Komu: A Mailing list for WIEN2k users Datum: 9. 5. 2018 21:18:20 Předmět: Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL " You are right, this is a bug (potentially severe). In my

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

ks "Research is to see what everybody else has seen, and to think what nobody else has thought", Albert Szent-Gyorgi www.numis.northwestern.edu(http://www.numis.northwestern.edu) On Wed, May 9, 2018, 10:42 AM Pavel Ondračka <pavel.ondra...@email.cz (mailto:pavel.ondra...@email.cz)> wro

Re: [Wien] IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

Laurence Marks píše v St 09. 05. 2018 v 11:51 +: > This appears to be due to a silly approach in gfortran, and almost > certainly is not an error/problem and can be ignored -- see https://s > tackoverflow.com/questions/44308577/ieee-underflow-flag-ieee- > denormal-in-fortran-77. > While I do

Re: [Wien] Installation with MPI and GNU compilers

ll openblas fftw elpa etc... and have the siteconfig autodetect it via the usual means (pkgconfig). I have few ideas for siteconfig improvements, will try to come up with some patches, but I'll start a new thread for that later. Best regards Pavel > On Wed, May 2, 2018, 16:05 Pavel Ondra

Re: [Wien] Installation with MPI and GNU compilers

-- Původní e-mail -- Od: Fecher, Gerhard <fec...@uni-mainz.de> Komu: Pavel Ondračka <pavel.ondra...@email.cz>, wien@zeus.theochem.tuwien. ac.at <wien@zeus.theochem.tuwien.ac.at> Datum: 2. 5. 2018 16:08:06 Předmět: AW: [Wien] Installation with MPI and GNU com

Re: [Wien] Installation with MPI and GNU compilers

regards, Pavel > Best regards, > Rui Costa. > > On 30 April 2018 at 20:57, Pavel Ondračka <pavel.ondra...@email.cz> > wrote: > > -- Původní e-mail -- > > Od: Rui Costa <ruicosta@gmail.com> > > Komu: A Mailing list for WIEN2k

Re: [Wien] Installation with MPI and GNU compilers

-- Původní e-mail -- Od: Rui Costa Komu: A Mailing list for WIEN2k users Datum: 30. 4. 2018 19:39:44 Předmět: Re: [Wien] Installation with MPI and GNU compilers " I was able to install wien2k with gfortran+MKL. Apparently

Re: [Wien] Installation with MPI and GNU compilers

Laurence Marks píše v St 04. 04. 2018 v 16:01 +: > I confess to being rather doubtful that gfortran+... is comparable to > ifort+... for Intel cpu, it might be for AMD. While the mkl vector > libraries are useful in a few codes such as aim, they are minor for > the main lapw[0-2]. Well, some

Re: [Wien] Installation with MPI and GNU compilers

Rui Costa píše v St 04. 04. 2018 v 14:21 +0100: > I will see what I can do about the Intel compilers. I've had a > question about this, supposedly the intel compilers are the fastest > [https://www.mail- > archive.com/wien@zeus.theochem.tuwien.ac.at/msg13021.html], but how > much faster are they

  1   2   >