[Wien] PES issues
Pavel Ondračka
pavel.ondracka at email.cz
Fri Mar 13 15:27:30 CET 2020
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
> >
More information about the Wien
mailing list