ling list for WIEN2k users
Subject: Re: [Wien] gfortran compilation and run problems for 19.1
Dear Prof Blaha,
Thank you for the solution.
Now standard calculations (with spinorbit also) work. k-Parallel version also
work, until I try hybrid potentials.
When I run k-parallel calculations with hyb
Dear Prof Blaha,
Thank you for the solution.
Now standard calculations (with spinorbit also) work. k-Parallel version also
work, until I try hybrid potentials.
When I run k-parallel calculations with hybrid potentials (spin-orbit included,
reduced k-mesh), the code stops after HF on a first
I can confirm the lapw2 problem with gfortran.
According to the Fortran standard, you can specify status=scratch, but
then you MUST NOT specify a "FILE=...". (ifort can handle this easily).
You can edit x_lapw and remove the line with unit 15 in the lapw2:
section (search for lapw2:, then
Interesting, it does compile and run with ifort but does not compile
with gfortran. The -stand option could be used with ifort so that it
gives a compiler message similar to gfortran [
https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-stand
]:
rd H. Fecher
>Institut of Inorganic and Analytical Chemistry
>Johannes Gutenberg - University
>55099 Mainz
>and
>Max Planck Institute for Chemical Physics of Solids
>01187 Dresden
>____
>Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Gavin Ab
ua.edu]
Gesendet: Mittwoch, 26. Juni 2019 03:37
An: wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] gfortran compilation and run problems for 19.1
The == should work for C/C++ language. I don't recall ever seeing that being
used for Fortran.
A quote from a HP Doctor Fortran article [
ht
uni 2019 15:13
An: wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] gfortran compilation and run problems for 19.1
See below
On 6/25/19 5:47 AM, Peter Blaha wrote:
Hi,
I can confirm the fix for inputpars.F. Of course, according to fortran standards a
logical if should have an
Thank you.
LAPW1 seem to work with default 4 threads.
Now run_lapw stops at the next step:
STOP LAPW0 END
STOP LAPW1 END
STOP LAPW2 - Error. Check file lapw2.error
$ cat lapw2.error
'LAPW2' - can't open unit: 15
'LAPW2' - filename: GaAs.tmp
'LAPW2' - status: scratch form: unformatted In the
Juni 2019 15:13
An: wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] gfortran compilation and run problems for 19.1
See below
On 6/25/19 5:47 AM, Peter Blaha wrote:
Hi,
I can confirm the fix for inputpars.F. Of course, according to fortran
standards a logical if should have an .eqv
See below
On 6/25/19 5:47 AM, Peter Blaha wrote:
Hi,
I can confirm the fix for inputpars.F. Of course, according to
fortran standards a logical if should have an .eqv. operator (although
I never "understood" what that should be good for ...).
Keeps computer scientists occupied
Hi,
I can confirm the fix for inputpars.F. Of course, according to
fortran standards a logical if should have an .eqv. operator (although I
never "understood" what that should be good for ...).
Also your second problem I have most likely recently seen myself. I
guess it happens only
Dear wien2k community,
I am trying to run the new version of the code on a fresh install of Ubuntu
18.04.2 LTS.
It is serial (with OMP) compilation with no libxc, fftw, scalapack, elpa.
Since WIEN2k_16 it was more or less Ok to compile the code with gfortran,
but with new version there are
12 matches
Mail list logo
