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@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@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@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