[Wien] DFTD3 stop error

Tue Jun 14 20:37:01 CEST 2016

Hi F. Tran, Gavin Abo,
Thanks for the replies. I've tried both of your suggestions, with mixed 
results. Uncommenting the three lines in  three lines in dftd3.f and 
recompiling  changes the binary, but not the issue. Adding the below 
line to x_lapw allowed me to progress beyond lapw1 but didn't solve the 
issue.

With or without the extra line in x_lapw and the recompiled dftd3, the 
contents of my case.scfdftd3 are:
dftd3 <coord filename> [-options]
  options:
  -func <functional name in TM style>
  -grad
  -anal (pair analysis)
       file <fragemt> with atom numbers
       is read for a fragement based
       analysis (one fragment per line,
       atom ranges (e.g. 1-14 17-20) are allowed)
  -noprint
  ...
  if -func is used, -zero or -bj or -old is required!"

This matches the output of simply executing 'dftd3' from the shell, so 
it appears that dftd3 is not being passed the parameters it needs (which 
I don't know how to address) and isn't running as expected. When running 
an scf cycle with the dftd3 option, lapw0, dftd3, lapw1, lapw2 and core 
all run but
mixer -dftd3 fails with:
forrtl: severe (24): end-of-file during read, unit 80, file 
/global/scratch/tld927/BN-h/.EDISP
since the .EDISP file isn't being created, presumably due to dftd3 not 
executing properly.
Any suggestions for how I could address this?
Regards,
Tristan
On 2016-05-20 2:22 AM, tran at theochem.tuwien.ac.at wrote:
> Hi,
>
> Thanks for the report.
> Yes indeed the new version of DFTD3 (V3.1 Rev 1) does not create .EDISP
> anymore. So, as suggested by Gavin, either uncomment these three lines
> in dftd3.f (and recompile):
>
> !      open(unit=1,file='.EDISP')
> !      write(1,*) disp
> !      close(1)
>
> or, what will be done for the next WIEN2k release, add this line
>
> grep "Edisp /kcal,au,eV:" $file.scfdftd3 | cut -c -43 | cut -c 31- > .EDISP
>
> in x_lapw just before this part:
>
> if (!(-e .EDISP)) then
>    echo "Error in DFTD3: file .EDISP is not present" > dftd3.error
>    exit(9)
> else
>    touch dftd3.error
> endif
>
> F. Tran
>
>
> On Friday 2016-05-20 05:55, Gavin Abo wrote:
>
>> Date: Fri, 20 May 2016 05:55:14
>> From: Gavin Abo <gsabo at crimson.ua.edu>
>> Reply-To: A Mailing list for WIEN2k users
>> <wien at zeus.theochem.tuwien.ac.at>
>> To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at>
>> Subject: Re: [Wien] DFTD3 stop error
>>
>> Does your file dftd3.error contain:
>>
>> Error in DFTD3: file .EDISP is not present
>>
>> I'm not familiar with the versions of dftd3.  My guess is that the
>> WIEN2k 14.2 x_lapw script was coded to work with an older version of
>> dftd3, where .EDISP was outputted by dftd3.
>>
>> In the current one (V3.1 Rev 1) at
>>
>> http://www.thch.uni-bonn.de/tc/index.php?section=downloads&subsection=getd3&lang=english
>>
>>
>> it looks like .EDISP is no longer outputted, because code is commented
>> out so that it does not write the .EDISP file as you can see in dftd3.f:
>>
>> !      open(unit=1,file='.EDISP')
>> !      write(1,*) disp
>> !      close(1)
>>
>> So a solution might be to remove the .EDISP code in x_lapw or
>> uncomment the above three lines in dftd3.f.  However, it is best to
>> confirm that with the developers of the dftd3 code.
>>
>> On 5/19/2016 5:29 PM, Tristan de Boer wrote:
>>> Hi,
>>> I'm attempting to calculate the interlayer spacing of h-BN with and
>>> without DFT-D3 corrections as a proof of concept (to reproduce the
>>> example on page 20 of F. Tran's presentation at the 22nd WIEN2k
>>> workshop). I'm using WIEN2k 14.2, and the most recent version of
>>> DFTD3, both complied with ifort. If I run:
>>> run_lapw -dftd3 -i 400 -ec 0.0001 -cc 0.001 -NI
>>> I get in my dayfile:
>>>     start     (Thu May 19 18:06:55 CDT 2016) with lapw0 (400/99 to go)
>>>
>>>     cycle 1     (Thu May 19 18:06:55 CDT 2016)     (400/99 to go)
>>>
>>> >   lapw0     (18:06:55) 1.605u 0.036s 0:01.65 98.7%    0+0k 0+584io
>>> 0pf+0w
>>> >   struct2poscar    (18:06:57) 0.000u 0.002s 0:00.00 0.0% 0+0k
>>> 0+16io 0pf+0w
>>> >   dftd3    (18:06:57) 0.000u 0.002s 0:00.00 0.0%    0+0k 0+8io 0pf+0w
>>>
>>> >   stop error
>>> No .error files are generated. STDOUT also says
>>> LAPW0 END
>>> >  stop error
>>> Running without the -dftd3 option gives no problems, as does x lapw0,
>>> x lapw1, x dftd3. I'm at a bit of a loss as to why this might be the
>>> case. Does anyone have any suggestions or things I could test to get
>>> to the bottom of this?
>>> Regards,
>>> Tristan
>> _______________________________________________
>> Wien mailing list
>> Wien at 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
>>
> _______________________________________________
> Wien mailing list
> Wien at 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
_______________________________________________
Wien mailing list
Wien at 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