[Wien] PES issues
Pavel Ondračka
pavel.ondracka at email.cz
Mon Mar 16 15:51:03 CET 2020
Thanks for the comments.
I played with it a bit more today and indeed the c) looks the most
probable. In fact the fit is very unstable (as expected), when I change
the DOS a bit (for example a slightly different broadening) the fitted
values can change significantly. But hard to tell for sure without
actually seeing the correlation matrix.
Best regards
Pavel
On Fri, 2020-03-13 at 15:41 +0100, Peter Blaha wrote:
> 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
> >
More information about the Wien
mailing list