[Wien] PES issues
Peter Blaha
pblaha at theochem.tuwien.ac.at
Fri Mar 13 15:41:44 CET 2020
It looks a bit strange if this is a simple supercell without changes.
a) You should increase the limit for the fit (after the first fit,
changes are limited to +-0.20, with "l" you can redo the fit with a
larger limit until the "optimized weight" does not improve anymore.
b) In particular the N-s states look strange. These are well separated
bands of almost only 2s character. Thus the total DOS in this region
should be perfectly well represented by the sum of the renormalized-PDOS.
c) It could be that the fit is not unique, since without changes, all
PDOS of the different atoms should have the same shape and one can
probably have the same total DOS with some "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 the new version. It seems to be working now (I've also
> included the N2s states). The V states seem to be too strong with
> respect to my experimental measurements, but maybe this is just a
> problem with the crossections, I'll try to play with it a bit. What
> I've however noticed is that the optimized q_sphere differ
> significantly between different atoms of the same type:
>
> Optimize q_sphere by fitting total DOS?(Y/n)
> Y
> Mean deviation of (total-DOS - sum(PDOS))**2 using
> outputst-weights: optimized weights: with limit:
> 12672.3980 1069.0124 +-0.20
> Partial Orbital Case.outputst Optimized
> V 4s 0.13429999 0.33429998
> V 4p 1.00000000 0.80000001
> V 3d 0.81809998 0.99000001
> V 4s 0.13429999 0.33429998
> V 4p 1.00000000 0.80000001
> V 3d 0.81809998 0.99000001
> V 4s 0.13429999 0.23524959
> V 4p 1.00000000 0.80000001
> V 3d 0.81809998 0.99000001
> V 4s 0.13429999 0.33429998
> V 4p 1.00000000 0.80000001
> V 3d 0.81809998 0.81147813
> N 2s 0.80360001 0.99000001
> N 2p 0.73790002 0.93790001
> N 2s 0.80360001 0.60360003
> N 2p 0.73790002 0.53790003
> N 2s 0.80360001 0.60360003
> N 2p 0.73790002 0.53790003
> N 2s 0.80360001 0.99000001
> N 2p 0.73790002 0.93790001
> N 2s 0.80360001 0.99000001
> N 2p 0.73790002 0.93790001
> N 2s 0.80360001 0.87147462
> N 2p 0.73790002 0.60641075
>
> This is kinda unexpected as this is in fact a perfect cubic VN
> supercell (with single named atom for core-hole calculations, but no
> core hole yet in this case).
>
> Is the fitting working as expected?
>
> Best regards
> Pavel
>
> On Fri, 2020-03-13 at 14:14 +0100, 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
>>>
>
> _______________________________________________
> 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
--------------------------------------------------------------------------
More information about the Wien
mailing list