subject:"\[Wien\] gfortran compilation and run problems for 19.1"

Re: [Wien] gfortran compilation and run problems for 19.1

2019-07-14 Thread tran


Hi,

This is due to a bug. To fix it, you need to make three changes in
hfpara_lapw ($WIENROOT/hfpara_lapw):

1) Below "set redklist", add the line "set so"

2) Replace
set so = 'so'
by
set so = '-so'

3) Replace
$bin/x sumhfpara $cmplxm $updn1 $band $gw $nmrhf $redklist $vnonloc -d
by
$bin/x sumhfpara $cmplxm $updn1 $band $gw $nmrhf $redklist $so $vnonloc -d


Thanks for the bug report,

F. Tran

On Tuesday 2019-07-09 14:34, Mikhail Nestoklon wrote:


Date: Tue, 9 Jul 2019 14:34:02
From: Mikhail Nestoklon 
Reply-To: A Mailing list for WIEN2k users 
To: A Mailing 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 hybrid potentials (spin-orbit included, 
reduced k-mesh), the code stops after HF on a first iteration with an error
"STOP error with energyhf_rbz files".

What can be the source of this error?

Note that on one machine hybrid potentials work without problems.

Sincerely yours,
Mikhail Nestoklon



 Среда, 26 июня 2019, 11:16 +03:00 от Peter Blaha 
:

 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 go down until you find

   15,'GaAs.tmp', 'scratch','unformatted',0

 and delete it.

 (I will later on put an open of unit 15 in the rare cases we need it).


 On 6/26/19 12:52 AM, Mikhail Nestoklon wrote:
 > 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 update information it is mentioned that case.tmp is removed now.
 > However,
 >
 > $ cat lapw2.def
 > ...
 > 15,'GaAs.tmp', 'scratch','unformatted',0
 > ...
 >
 >
 > Sincerely
 > Mikhail
 >
 >
 >
 >
 >
 > Вторник, 25 июня 2019, 12:54 +03:00 от Peter Blaha
 > :
 >
 > 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 with OMP_NUM_THREAD > 1 (and goes away if you
 > explicitly set OMP_NUM_THREAD to 1).
 >
 > Together with Pavel Ondracka we have found a fix for the problem. It
 > happens only with OMP_NUM_THREAD >1 (more than one core) and only in
 > cases where the matrix size is that small as compared to the blocksize
 > (128), that the iouter-loop in hamilt.F is executed not by all
 > requested
 > cores, but only one (or a few) and the free core jumps immediately to
 > the "omp single" section (which was introduced to avoid idling of the
 > "last" core).
 >
 > I attach a patched hamilt.F for WIEN2k_19 / release 12.6.19
 >
 > A patched WIEN2k_19 /release 25.6.19. will be on the web shortly.
 >
 > Best regards
 >
 > On 6/24/19 11:45 PM, Mikhail Nestoklon wrote:
 > > 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 problems again.
 > >
 > > First, the new 19.1 version does not compile with gfortran
 > (7.4.0) with
 > > the error during lapw0 compilation
 > > > inputpars.F:664:8:
 > > >   if(read_vhalf .eq. .true.) then
 > > >    1
 > > > Error: Logicals at (1) must be compared with .eqv. instead of .eq.
 > > If I fix the file in accordance with gfortran rules, it compiles.
 > > According to gcc, this is the ifort extension not working on "more
 > > standard" implementations.
 > >
 > > Second, when the code is

Re: [Wien] gfortran compilation and run problems for 19.1

2019-07-09 Thread Mikhail Nestoklon

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 iteration with an error 
"STOP error with energyhf_rbz files".

What can be the source of this error?

Note that on one machine hybrid potentials work without problems. 

Sincerely yours,
Mikhail Nestoklon



>Среда, 26 июня 2019, 11:16 +03:00 от Peter Blaha 
>:
>
>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 go down until you find
>
>  15,'GaAs.tmp', 'scratch','unformatted',0
>
>and delete it.
>
>(I will later on put an open of unit 15 in the rare cases we need it).
>
>
>On 6/26/19 12:52 AM, Mikhail Nestoklon wrote:
>> 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 update information it is mentioned that case.tmp is removed now. 
>> However,
>> 
>> $ cat lapw2.def
>> ...
>> 15,'GaAs.tmp', 'scratch','unformatted',0
>> ...
>> 
>> 
>> Sincerely
>> Mikhail
>> 
>> 
>> 
>> 
>> 
>> Вторник, 25 июня 2019, 12:54 +03:00 от Peter Blaha
>> < pbl...@theochem.tuwien.ac.at >:
>> 
>> 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 with OMP_NUM_THREAD > 1 (and goes away if you
>> explicitly set OMP_NUM_THREAD to 1).
>> 
>> Together with Pavel Ondracka we have found a fix for the problem. It
>> happens only with OMP_NUM_THREAD >1 (more than one core) and only in
>> cases where the matrix size is that small as compared to the blocksize
>> (128), that the iouter-loop in hamilt.F is executed not by all
>> requested
>> cores, but only one (or a few) and the free core jumps immediately to
>> the "omp single" section (which was introduced to avoid idling of the
>> "last" core).
>> 
>> I attach a patched hamilt.F for WIEN2k_19 / release 12.6.19
>> 
>> A patched WIEN2k_19 /release 25.6.19. will be on the web shortly.
>> 
>> Best regards
>> 
>> On 6/24/19 11:45 PM, Mikhail Nestoklon wrote:
>>  > 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 problems again.
>>  >
>>  > First, the new 19.1 version does not compile with gfortran
>> (7.4.0) with
>>  > the error during lapw0 compilation
>>  > > inputpars.F:664:8:
>>  > >   if(read_vhalf .eq. .true.) then
>>  > >    1
>>  > > Error: Logicals at (1) must be compared with .eqv. instead of .eq.
>>  > If I fix the file in accordance with gfortran rules, it compiles.
>>  > According to gcc, this is the ifort extension not working on "more
>>  > standard" implementations.
>>  >
>>  > Second, when the code is compiled, running simple (GaAs) example
>> which
>>  > works perfectly
>>  > at least in WIEN2k 16, 17, 18 gives the error
>>  > $ init_lapw -b
>>  > $ run_lapw
>>  > STOP  LAPW0 END
>>  > STOP SECLR4 - Error
>>  >
>>  > What possibly may go wrong here? I have no idea how to debug this
>> problem.
>>  >
>>  > Sincerely yours,
>>  > Mikhail Nestoklon
>>  >
>>  > ___
>>  > Wien mailing list
>>  >  Wien@zeus.theochem.tuwien.ac.at
>> 
>>  >  http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>  > SEARCH the MAILING-LIST at:
>>  http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>>  >
>> 
>> -- 
>> 
>>     P.Blaha
>> 
>> --
>> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
>> Phone:  +43-1-58801-165300 FAX:  +43-1-58801-165982
>> Email:  bl...@theochem.tuwien.ac.at
>>  WIEN2k:

Re: [Wien] gfortran compilation and run problems for 19.1

2019-06-26 Thread Peter Blaha

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 go down until you find

 15,'GaAs.tmp', 'scratch','unformatted',0

and delete it.

(I will later on put an open of unit 15 in the rare cases we need it).

On 6/26/19 12:52 AM, Mikhail Nestoklon wrote:

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 update information it is mentioned that case.tmp is removed now. 
However,

$ cat lapw2.def
...
15,'GaAs.tmp', 'scratch','unformatted',0
...

Sincerely
Mikhail

Вторник, 25 июня 2019, 12:54 +03:00 от Peter Blaha
:

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 with OMP_NUM_THREAD > 1 (and goes away if you
explicitly set OMP_NUM_THREAD to 1).

Together with Pavel Ondracka we have found a fix for the problem. It
happens only with OMP_NUM_THREAD >1 (more than one core) and only in
cases where the matrix size is that small as compared to the blocksize
(128), that the iouter-loop in hamilt.F is executed not by all
requested
cores, but only one (or a few) and the free core jumps immediately to
the "omp single" section (which was introduced to avoid idling of the
"last" core).

I attach a patched hamilt.F for WIEN2k_19 / release 12.6.19

A patched WIEN2k_19 /release 25.6.19. will be on the web shortly.

Best regards

On 6/24/19 11:45 PM, Mikhail Nestoklon wrote:
 > 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 problems again.
 >
 > First, the new 19.1 version does not compile with gfortran
(7.4.0) with
 > the error during lapw0 compilation
 > > inputpars.F:664:8:
 > >   if(read_vhalf .eq. .true.) then
 > >    1
 > > Error: Logicals at (1) must be compared with .eqv. instead of .eq.
 > If I fix the file in accordance with gfortran rules, it compiles.
 > According to gcc, this is the ifort extension not working on "more
 > standard" implementations.
 >
 > Second, when the code is compiled, running simple (GaAs) example
which
 > works perfectly
 > at least in WIEN2k 16, 17, 18 gives the error
 > $ init_lapw -b
 > $ run_lapw
 > STOP  LAPW0 END
 > STOP SECLR4 - Error
 >
 > What possibly may go wrong here? I have no idea how to debug this
problem.
 >
 > Sincerely yours,
 > Mikhail Nestoklon
 >
 > ___
 > Wien mailing list
 > Wien@zeus.theochem.tuwien.ac.at

 > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
 > SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
 >

-- 

    P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: bl...@theochem.tuwien.ac.at
 WIEN2k: http://www.wien2k.at
WWW: http://www.imc.tuwien.ac.at/TC_Blaha
--
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at 
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

--
Mikhail Nestoklon

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

--

  P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone:

Re: [Wien] gfortran compilation and run problems for 19.1

2019-06-26 Thread Gavin Abo

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 
]:


username@computername:~/Desktop/test$ cat logicaltest.f
  program logicaltest
   implicit none
!
! test ==, .eq., .eqv.
!
   logical   a, b, c

   a=.true.
   b=.true.

   if(a == b) then
  write(6,*) 'a == b'
   end if

   if(a .eq. b) then
  write(6,*) 'a .eq. b'
   end if

   if(a .eqv. b) then
  write(6,*) 'a .eqv. b'
   end if

  end

username@computername:~/Desktop/test$ ifort -v
ifort version 19.0.4.243
username@computername:~/Desktop/test$ ifort logicaltest.f -o logicaltest
username@computername:~/Desktop/test$ ./logicaltest
 a == b
 a .eq. b
 a .eqv. b


username@computername:~/Desktop/test$ gfortran --version
GNU Fortran (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

username@computername:~/Desktop/test$ gfortran logicaltest.f -o logicaltest
logicaltest.f:11:10:

    if(a == b) then
  1
Error: Logicals at (1) must be compared with .eqv. instead of ==
logicaltest.f:15:10:

    if(a .eq. b) then
  1
Error: Logicals at (1) must be compared with .eqv. instead of .eq.


username@computername:~/Desktop/test$ ifort logicaltest.f -o logicaltest 
-stand
logicaltest.f(1): warning #7373: Fixed form source is an obsolescent 
feature in Fortran 2008.

  program logicaltest
^
logicaltest.f(11): warning #6297: Fortran 2008 does not allow a LOGICAL 
data type in this context.   [A]

   if(a == b) then
--^
logicaltest.f(11): warning #6297: Fortran 2008 does not allow a LOGICAL 
data type in this context.   [B]

   if(a == b) then
---^
logicaltest.f(15): warning #6297: Fortran 2008 does not allow a LOGICAL 
data type in this context.   [A]

   if(a .eq. b) then
--^
logicaltest.f(15): warning #6297: Fortran 2008 does not allow a LOGICAL 
data type in this context.   [B]

   if(a .eq. b) then
-^


On 6/25/2019 11:42 PM, Fecher, Gerhard wrote:

Dear Gavin,
Sorry my question was probably to short, it should read
  Does anyone know whether "== " works with gfortran ?

With ifort the following test works well, but I cannot test it with gfortran
The answer in the Intel forum that you quote does not include "=="

  program logicaltest
   implicit none
!
! test ==, .eq., .eqv.
!
   logical   a, b, c

   a=.true.
   b=.true.

   if(a == b) then
  write(6,*) 'a = b'
   end if

   if(a .eq. b) then
  write(6,*) 'a .eq. b'
   end if

   if(a .eqv. b) then
  write(6,*) 'a .eqv. b'
   end if
   
   end



Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz
and
Max Planck Institute for Chemical Physics of Solids
01187 Dresden
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] gfortran compilation and run problems for 19.1

2019-06-26 Thread Mikhail Nestoklon



No, it understands the intention of the person who wrote the code but this is 
an error.

@ gfortran 7.4.0
if(a == b) then
1
Error: Logicals at (1) must be compared with .eqv. instead of ==
gfort_test.f:15:9:
if(a .eq. b) then
1
Error: Logicals at (1) must be compared with .eqv. instead of .eq.

As far as I remember,some time ago to make the fortran code which compiles with 
ifort compile with gfortran the good starting point was to switch on all flags 
which control the strict use of the standard, unfortunately I have no access to 
ifort  right now and can not check the proper combination, probably it was just 
"-std90".  
By default, ifort compiles the non-standard code it is able to understand while 
the  default gfortran behavior is to treat it as an error. This particular case 
is far beyond the standard, so I do not know if it is even possible to force 
gfortran to compile this code.

Sincerely,
Mikhail 




>Среда, 26 июня 2019, 8:43 +03:00 от "Fecher, Gerhard" :
>
>Dear Gavin, 
>Sorry my question was probably to short, it should read
> Does anyone know whether "== " works with gfortran ?
>
>With ifort the following test works well, but I cannot test it with gfortran
>The answer in the Intel forum that you quote does not include "=="
>
> program logicaltest
>  implicit none
>!
>! test ==, .eq., .eqv.
>!
>  logical   a, b, c
>
>  a=.true.
>  b=.true.
>
>  if(a == b) then
> write(6,*) 'a = b'
>  end if
>
>  if(a .eq. b) then
> write(6,*) 'a .eq. b'
>  end if
>
>  if(a .eqv. b) then
> write(6,*) 'a .eqv. b'
>  end if
>  
>  end
>
>
>Ciao
>Gerhard
>
>DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
>"I think the problem, to be quite honest with you,
>is that you have never actually known what the question is."
>
>
>Dr. Gerhard 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 Abo 
>[gs...@crimson.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 [  
>https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/274462
> ]:
>
>"The real trouble with making assumptions about the internal value of LOGICALs 
>is when you try testing them for "equality" against another logical 
>expression. The way many Fortran programmers would naturally do this is as 
>follows:
>
>IF (LOGVAL1 .EQ. LOGVAL2) ...
>
>but the results of this can vary depending on the internal representation. The 
>Fortran language defines two operators exclusively for use on logical values, 
>.EQV. ("equivalent to") and .NEQV. ("not equivalent to"). So the above test 
>would be properly written as:
>
>IF (LOGVAL1 .EQV. LOGVAL2) ..."
>
>On 6/25/2019 3:14 PM, Fecher, Gerhard wrote:
>
>Does == work ?
>
>Ciao
>Gerhard
>
>DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
>"I think the problem, to be quite honest with you,
>is that you have never actually known what the question is."
>
>
>Dr. Gerhard 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<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>]
> im Auftrag von Sam Trickey [tric...@qtp.ufl.edu<mailto:tric...@qtp.ufl.edu>]
>Gesendet: Dienstag, 25. 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. operator (although I never 
>"understood" what that should be good for ...).
>
>Keeps computer scientists occupied introducing needless and annoying 
>distinctions.
>
>peace, Sam
>
>
>--
>Samuel B. Trickey
>QTP, Depts. of Physics and Chemistry
>2324 Physics Building
&

Re: [Wien] gfortran compilation and run problems for 19.1

2019-06-25 Thread Fecher, Gerhard

Dear Gavin, 
Sorry my question was probably to short, it should read
 Does anyone know whether "== " works with gfortran ?

With ifort the following test works well, but I cannot test it with gfortran
The answer in the Intel forum that you quote does not include "=="

 program logicaltest
  implicit none
!
! test ==, .eq., .eqv.
!
  logical   a, b, c

  a=.true.
  b=.true.

  if(a == b) then
 write(6,*) 'a = b'
  end if

  if(a .eq. b) then
 write(6,*) 'a .eq. b'
  end if

  if(a .eqv. b) then
 write(6,*) 'a .eqv. b'
  end if
  
  end


Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard 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 Abo 
[gs...@crimson.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 [ 
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/274462
 ]:

"The real trouble with making assumptions about the internal value of LOGICALs 
is when you try testing them for "equality" against another logical expression. 
The way many Fortran programmers would naturally do this is as follows:

IF (LOGVAL1 .EQ. LOGVAL2) ...

but the results of this can vary depending on the internal representation. The 
Fortran language defines two operators exclusively for use on logical values, 
.EQV. ("equivalent to") and .NEQV. ("not equivalent to"). So the above test 
would be properly written as:

IF (LOGVAL1 .EQV. LOGVAL2) ..."

On 6/25/2019 3:14 PM, Fecher, Gerhard wrote:

Does == work ?

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard 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<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>]
 im Auftrag von Sam Trickey [tric...@qtp.ufl.edu<mailto:tric...@qtp.ufl.edu>]
Gesendet: Dienstag, 25. Juni 2019 15:13
An: wien@zeus.theochem.tuwien.ac.at<mailto: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. operator (although I never 
"understood" what that should be good for ...).

Keeps computer scientists occupied introducing needless and annoying 
distinctions.

peace, Sam


--
Samuel B. Trickey
QTP, Depts. of Physics and Chemistry
2324 Physics Building
Box 118435
Univ. of Florida
Gainesville, FL 32611-8435
Vox: 352-392-6978 (direct)
Vox: 352-392-1597 (receptionist)
Fax: 352-392-8722
http://www.qtp.ufl.edu/ofdft
http://users.clas.ufl.edu/trickey


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] gfortran compilation and run problems for 19.1

2019-06-25 Thread Gavin Abo

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 [
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/274462
]:

"The real trouble with making assumptions about the internal value of
LOGICALs is when you try testing them for "equality" against another
logical expression. The way many Fortran programmers would naturally do
this is as follows:

IF (LOGVAL1 .EQ. LOGVAL2) ...

but the results of this can vary depending on the internal
representation. The Fortran language defines two operators exclusively
for use on logical values, .EQV. ("equivalent to") and .NEQV. ("not
equivalent to"). So the above test would be properly written as:

IF (LOGVAL1 .EQV. LOGVAL2) ..."

On 6/25/2019 3:14 PM, Fecher, Gerhard wrote:

Does == work ?

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."

Dr. Gerhard 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 Sam Trickey
[tric...@qtp.ufl.edu]
Gesendet: Dienstag, 25. 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. operator (although I never "understood" what
that should be good for ...).

Keeps computer scientists occupied introducing needless and annoying
distinctions.

peace, Sam

--
Samuel B. Trickey
QTP, Depts. of Physics and Chemistry
2324 Physics Building
Box 118435
Univ. of Florida
Gainesville, FL 32611-8435
Vox: 352-392-6978 (direct)
Vox: 352-392-1597 (receptionist)
Fax: 352-392-8722
http://www.qtp.ufl.edu/ofdft
http://users.clas.ufl.edu/trickey
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] gfortran compilation and run problems for 19.1

2019-06-25 Thread Mikhail Nestoklon

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 update information it is 
mentioned that case.tmp is removed now. However, 
$ cat lapw2.def
...
15,'GaAs.tmp', 'scratch','unformatted',0
...
Sincerely
Mikhail





>Вторник, 25 июня 2019, 12:54 +03:00 от Peter Blaha 
>:
>
>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 with OMP_NUM_THREAD > 1 (and goes away if you 
>explicitly set OMP_NUM_THREAD to 1).
>
>Together with Pavel Ondracka we have found a fix for the problem. It 
>happens only with OMP_NUM_THREAD >1 (more than one core) and only in 
>cases where the matrix size is that small as compared to the blocksize 
>(128), that the iouter-loop in hamilt.F is executed not by all requested 
>cores, but only one (or a few) and the free core jumps immediately to 
>the "omp single" section (which was introduced to avoid idling of the 
>"last" core).
>
>I attach a patched   hamilt.F  for WIEN2k_19 / release 12.6.19
>
>A patched WIEN2k_19 /release 25.6.19. will be on the web shortly.
>
>Best regards
>
>On 6/24/19 11:45 PM, Mikhail Nestoklon wrote:
>> 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 problems again.
>> 
>> First, the new 19.1 version does not compile with gfortran (7.4.0) with 
>> the error during lapw0 compilation
>>  > inputpars.F:664:8:
>>  >   if(read_vhalf .eq. .true.) then
>>  >    1
>>  > Error: Logicals at (1) must be compared with .eqv. instead of .eq.
>> If I fix the file in accordance with gfortran rules, it compiles.
>> According to gcc, this is the ifort extension not working on "more 
>> standard" implementations.
>> 
>> Second, when the code is compiled, running simple (GaAs) example which 
>> works perfectly
>> at least in WIEN2k 16, 17, 18 gives the error
>> $ init_lapw -b
>> $ run_lapw
>> STOP  LAPW0 END
>> STOP SECLR4 - Error
>> 
>> What possibly may go wrong here? I have no idea how to debug this problem.
>> 
>> Sincerely yours,
>> Mikhail Nestoklon
>> 
>> ___
>> Wien mailing list
>>  Wien@zeus.theochem.tuwien.ac.at
>>  http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at:  
>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>> 
>
>-- 
>
>   P.Blaha
>--
>Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
>Phone:  +43-1-58801-165300 FAX:  +43-1-58801-165982
>Email:  bl...@theochem.tuwien.ac.at WIEN2k:  http://www.wien2k.at
>WWW:  http://www.imc.tuwien.ac.at/TC_Blaha
>--
>___
>Wien mailing list
>Wien@zeus.theochem.tuwien.ac.at
>http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>SEARCH the MAILING-LIST at:  
>http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html


-- 
Mikhail Nestoklon
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] gfortran compilation and run problems for 19.1

2019-06-25 Thread Fecher, Gerhard

Does == work ?

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard 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 Sam Trickey 
[tric...@qtp.ufl.edu]
Gesendet: Dienstag, 25. 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. operator (although I never 
"understood" what that should be good for ...).

Keeps computer scientists occupied introducing needless and annoying 
distinctions.

peace, Sam


--
Samuel B. Trickey
QTP, Depts. of Physics and Chemistry
2324 Physics Building
Box 118435
Univ. of Florida
Gainesville, FL 32611-8435
Vox: 352-392-6978 (direct)
Vox: 352-392-1597 (receptionist)
Fax: 352-392-8722
http://www.qtp.ufl.edu/ofdft
http://users.clas.ufl.edu/trickey


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] gfortran compilation and run problems for 19.1

2019-06-25 Thread Sam Trickey


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 introducing needless and annoying 
distinctions.


peace, Sam

--
Samuel B. Trickey
QTP, Depts. of Physics and Chemistry
2324 Physics Building
Box 118435
Univ. of Florida
Gainesville, FL 32611-8435
Vox: 352-392-6978 (direct)
Vox: 352-392-1597 (receptionist)
Fax: 352-392-8722
http://www.qtp.ufl.edu/ofdft
http://users.clas.ufl.edu/trickey

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] gfortran compilation and run problems for 19.1

2019-06-25 Thread Peter Blaha

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 with OMP_NUM_THREAD > 1 (and goes away if you 
explicitly set OMP_NUM_THREAD to 1).

Together with Pavel Ondracka we have found a fix for the problem. It 
happens only with OMP_NUM_THREAD >1 (more than one core) and only in 
cases where the matrix size is that small as compared to the blocksize 
(128), that the iouter-loop in hamilt.F is executed not by all requested 
cores, but only one (or a few) and the free core jumps immediately to 
the "omp single" section (which was introduced to avoid idling of the 
"last" core).

I attach a patched   hamilt.F  for WIEN2k_19 / release 12.6.19

A patched WIEN2k_19 /release 25.6.19. will be on the web shortly.

Best regards

On 6/24/19 11:45 PM, Mikhail Nestoklon wrote:

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 problems again.

First, the new 19.1 version does not compile with gfortran (7.4.0) with 
the error during lapw0 compilation

 > inputpars.F:664:8:
 >   if(read_vhalf .eq. .true.) then
 >    1
 > Error: Logicals at (1) must be compared with .eqv. instead of .eq.
If I fix the file in accordance with gfortran rules, it compiles.
According to gcc, this is the ifort extension not working on "more 
standard" implementations.

Second, when the code is compiled, running simple (GaAs) example which 
works perfectly

at least in WIEN2k 16, 17, 18 gives the error
$ init_lapw -b
$ run_lapw
STOP  LAPW0 END
STOP SECLR4 - Error

What possibly may go wrong here? I have no idea how to debug this problem.

Sincerely yours,
Mikhail Nestoklon

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

--

  P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/TC_Blaha
--
  SUBROUTINE HAMILT(LTOP,NAT,NV,U,UP,DU,DUP,MULT,R,POS,V,VOLUME,CHN,E,INS)
!
#ifdef Parallel
  use matrices, only : H, S,HSROWS, KZZ, XK, YK, ZK, RK
#else
  use matrices, only : HS, HSDIAG, HSROWS, KZZ, XK, YK, ZK, RK
#endif
  use loabc, only : ALO, BLO, CLO, ELO, PLO, DPLO, PELO, &
DPELO, PEILO, PI12LO, PE12LO,pilolo,nloat_new,LOSECDER
  use parallel, only : ICTXTALL, DESCHS,DESCZ, NPE, MYID,  &
   NPROW, NPCOL, MYROWHS, MYCOLHS, &
   BLOCKSIZE, LDHS, LCOLHS, LCOLZ, &
   INIT_PARALLEL, BARRIER, CLOSE_PARALLEL
  use lapw_timer, only : time_albl, time_loop260, time_phase,   &
time_legendre, time_step_function, time_h,   &
	   time_us, time_loop210, time_loop230,   &
  		   time_loop240, time_overlap, time_lo,   &
  		   START_TIMER, STOP_TIMER, READ_CPU_TIME, READ_wall_TIME, &
   init_all_timer,time_distiouter
  use lolog, only : nlo, loor, lapw, ilo
  use rotmat, only: ROTIJ, ROTLOC
  use struk, only : NDF,multmax
  use out, only   : WARP
  use albl
  use stdmath
!  use out, only   : WARP1, WARP2, WARP3
  IMPLICIT NONE
  INCLUDE 'param.inc'
!
!Parameters
!
  DOUBLE PRECISION   ONE, TOL, UTOP, ZERO, HALF
  DOUBLE PRECISION   TWO, THREE, FOUR
  PARAMETER  (ONE=1.0D+0, TOL=1.0D-8)
  PARAMETER  (TWO=2.0D+0, THREE=3.0D0, FOUR=4.0D0)
  PARAMETER  (HALF=0.5D0)
  PARAMETER  (UTOP=0.999D+0, ZERO=0.0D+0)
  DOUBLE COMPLEX CIMAG
  PARAMETER  (CIMAG = (0.0D0,1.0D0))
  DOUBLE COMPLEX CZERO
  PARAMETER  (CZERO=(0.0D0,0.0D0))
  DOUBLE COMPLEX CONE
  PARAMETER  (CONE=(1.0d0,0.0d0))
!
!Arguments
!
  INTEGERINS, LTOP
  INTEGER, INTENT(IN) :: NAT, NV
  INTEGERMULT(NAT)
  DOUBLE PRECISION   VOLUME
  DOUBLE PRECISION, INTENT(IN) :: R(NAT)
  DOUBLE PRECISION   CHN(0:LMAX-1,NAT), DU(0:LMAX-1,NAT)
  DOUBLE PRECISION   DUP(0:LMAX-1,NAT), E(0:LMAX-1,NAT)
  DOUBLE PRECISION, INTENT(IN) ::  POS(3,NDF), V(NAT)

[Wien] gfortran compilation and run problems for 19.1

2019-06-24 Thread Mikhail Nestoklon

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 problems again.

First, the new 19.1 version does not compile with gfortran (7.4.0) with the 
error during lapw0 compilation 
> inputpars.F:664:8:
>   if(read_vhalf .eq. .true.) then
>    1
> Error: Logicals at (1) must be compared with .eqv. instead of .eq.
If I fix the file in accordance with gfortran rules, it compiles.
According to gcc, this is the ifort extension not working on "more standard" 
implementations.

Second, when the code is compiled, running simple (GaAs) example which works 
perfectly
at least in WIEN2k 16, 17, 18 gives the error 
$ init_lapw -b
$ run_lapw
STOP  LAPW0 END
STOP SECLR4 - Error

What possibly may go wrong here? I have no idea how to debug this problem.

Sincerely yours, 
Mikhail Nestoklon___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] gfortran compilation and run problems for 19.1

Re: [Wien] gfortran compilation and run problems for 19.1

Re: [Wien] gfortran compilation and run problems for 19.1

Re: [Wien] gfortran compilation and run problems for 19.1

Re: [Wien] gfortran compilation and run problems for 19.1

Re: [Wien] gfortran compilation and run problems for 19.1

Re: [Wien] gfortran compilation and run problems for 19.1

Re: [Wien] gfortran compilation and run problems for 19.1

Re: [Wien] gfortran compilation and run problems for 19.1

Re: [Wien] gfortran compilation and run problems for 19.1

Re: [Wien] gfortran compilation and run problems for 19.1

[Wien] gfortran compilation and run problems for 19.1

12 matches

Site Navigation

Mail list logo

Footer information