[Wien] PES issues

Fri Mar 13 15:18:18 CET 2020

I think I've also fixed the gfortran issue. However, since this requires 
changes in x_lapw, I cannot put this into the repository.

As mentioned, there is a new version in the download area of 
www.wien2k.at. Under files you can download SRC_pes.tar.gz

For gfortran you should in addition replace the two attached files
periodic_table.f and estimate_cross.f

AND  change the pes: section in x_lapw to:

case pes:
set exe = pes
cat << theend > $def
2, '$WIENROOT/SRC_pes/Crosssections/', 'unknown','formatted',0
4, '$WIENROOT/SRC_pes/Crosssections/cross.txt','old','formatted',0
23, 'pes.template',      'unknown',    'formatted',0                <--
24, 'valence.reconfig',      'unknown',    'formatted',0            <--
....

On 3/13/20 2:14 PM, Peter Blaha wrote:
> Daer Pavel,
> 
> Thanks for your report.
> 
> I tried to reproduce it, but my version of pes has already been changed 
> significantly. In particular optimize_charge.f is now quite different.
> 
> However, when compiling with -C I detected another problem with the 
> variable "start" (never set to zero) and in read_dos.f.
> 
> I've uploaded SRC_pes.tar.gz into the "files" directory of the 
> wien2k-download and you can download it from there, if interested.
> 
> PS: I've not fixed the gfortran problem yet, but will try to do it soon. 
> So if it is not 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 may give nonsense.
> 
> Best regards
> Peter
> 
> 
> On 3/13/20 11:58 AM, Pavel Ondračka wrote:
>> 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 eventually makes it to
>> the list as well.)
>>
>> There is out of bounds write during optimization of q_spheres:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x000000000040d494 in optimize_charge () at optimize_charge.f:95
>> 95                 temp(l,recon_counter)=temp(l,j)+temp(l,i)
>> (gdb) print recon_counter
>> $1 = 27
>> (gdb) print output_counter
>> $2 = 24
>> (it tries to write at index 27) but the size is just 24 (defined
>> by output_counter)
>>
>> The files needed to reproduce this and the terminal output (together
>> with the manual keyboard input needed to reproduce the crash) are at
>> https://drive.google.com/open?id=1NZ8lSkfrgigtdQZrDZLp8Y-mFf4uSyk_
>> . I'm not a regular user of the pes program so there is a high
>> chance that there is something wrong with my input.
>>
>> BTW While taking a quick look I spotted some likely unrelated small
>> issues, for instance pes is also influenced by the well known issue
>> with gfortran using the units 5 and 6 (have to change it manually to
>> something else otherwise stdin and stdout doesn't work) and there are
>> some valgrind warnings even before the crash, for example:
>>
>> ==57304== Conditional jump or move depends on uninitialised value(s)
>> ==57304==    at 0x419919: abs_smooth_ (SPLINE.f:173)
>> ==57304==    by 0x41852E: setup_ (SPLINE.f:91)
>> ==57304==    by 0x4199FE: spline_ (SPLINE.f:16)
>> ==57304==    by 0x41582B: read_database2_ (read_database2.f:124)
>> ==57304==    by 0x403FE7: MAIN__ (pes.f:151)
>> ==57304==    by 0x4066FF: main (pes.f:3)
>> ==57304==  Uninitialised value was created by a stack allocation
>> ==57304==    at 0x4199B3: spline_ (SPLINE.f:1)
>>
>> SPLINE.f:173
>>     if (x >= delta_x) then
>> The unuinitialized variable is the delta_x which was passed from setup
>> (SPLINE.f:91):
>> call abs_smooth(m4 - m3, delta_x, w1)
>> and was itself allocated on the stack at the beginning of spline but is
>> not initialized anywhere as far as I can see. So I set it to 0.0d0 (the
>> default for ifort).
>>
>> and one more which should be harmless...
>> ==57389== Conditional jump or move depends on uninitialised value(s)
>> ==57389==    at 0x47213EC5: bcmp (vg_replace_strmem.c:1113)
>> ==57389==    by 0x474A3B7A: _gfortran_compare_string
>> (string_intrinsics_inc.c:98)
>> ==57389==    by 0x41677F: read_outputst_ (read_outputst.f:37)
>> ==57389==    by 0x4048E2: MAIN__ (pes.f:222)
>> ==57389==    by 0x4066FF: main (pes.f:3)
>> ==57389==  Uninitialised value was created by a stack allocation
>> ==57389==    at 0x416559: read_outputst_ (read_outputst.f:1)
>>
>> Best regards
>> Pavel
>>
>> _______________________________________________
>> 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
>>
> 

-- 

                                       P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300             FAX: +43-1-58801-165982
Email: blaha at theochem.tuwien.ac.at    WIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/TC_Blaha
--------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: periodic_table.f
Type: text/x-fortran
Size: 12754 bytes
Desc: not available
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20200313/f99c4453/attachment.f>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: estimate_cross.f
Type: text/x-fortran
Size: 7021 bytes
Desc: not available
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20200313/f99c4453/attachment-0001.f>