fleur issues https://iffgit.fz-juelich.de/fleur/fleur/-/issues 2020-06-05T19:51:28Z https://iffgit.fz-juelich.de/fleur/fleur/-/issues/453 Confusion with LDA+U double counting and energy 2020-06-05T19:51:28Z Henning Janssen Confusion with LDA+U double counting and energy # Summary The definitions of the double counting corrections in LDA+U and the LDA+U energy in v_mmp.f90 are really confusing. I want to clear them up and move them out of v_mmp to be used in other places without having two separate definitions (see e.g. Hubbard 1 uses the double counting to set the occupation in the impurity solver) I have the following definitions for the FLL and AMF limit, which can be derived from the occupations being either 0 or 1 (FLL) or $\frac{1}{2l+1}N_\sigma$ (AMF): FLL: math E^{FLL}_{dc} = \frac{U}{2} N(N-1) - \frac{J}{2} \sum_\sigma N_\sigma(N_\sigma-1)  math V^{FLL,\sigma}_{dc} = U(N-\frac{1}{2}) - J(N_\sigma-\frac{1}{2})  AMF: math E^{AMF}_{dc} = Un_\uparrow n_\downarrow + \frac{l(n^2_\uparrow+n^2_\downarrow)}{2l+1}(U-J)  math V^{AMF,\sigma}_{dc} = U n_{-\sigma} + \frac{2l}{2l+1}(U-J)n_\sigma  There are a couple of things I noticed in v_mmp (the AMF values have to be reformulated in terms of these eta factors to compare): * There is/was an inconsistency in the AMF double counting potential (a missing factor 2), which I already patched up a while ago * For jspins=1 there is a piece of the double counting energy missing (the other spin), which is essentially again a factor 2 for the j part of the energy If you look at the v26 version of v_mmp these problems are not there, but its also relatively confusing. If I fix these issues I will have to change the energy values in the GaAsMultiForceXML test. For this reason I'm opening this issue so other people can have a look at it before changing a test. # Summary The definitions of the double counting corrections in LDA+U and the LDA+U energy in v_mmp.f90 are really confusing. I want to clear them up and move them out of v_mmp to be used in other places without having two separate definitions (see e.g. Hubbard 1 uses the double counting to set the occupation in the impurity solver) I have the following definitions for the FLL and AMF limit, which can be derived from the occupations being either 0 or 1 (FLL) or $\frac{1}{2l+1}N_\sigma$ (AMF): FLL: math E^{FLL}_{dc} = \frac{U}{2} N(N-1) - \frac{J}{2} \sum_\sigma N_\sigma(N_\sigma-1)  math V^{FLL,\sigma}_{dc} = U(N-\frac{1}{2}) - J(N_\sigma-\frac{1}{2})  AMF: math E^{AMF}_{dc} = Un_\uparrow n_\downarrow + \frac{l(n^2_\uparrow+n^2_\downarrow)}{2l+1}(U-J)  math V^{AMF,\sigma}_{dc} = U n_{-\sigma} + \frac{2l}{2l+1}(U-J)n_\sigma  There are a couple of things I noticed in v_mmp (the AMF values have to be reformulated in terms of these eta factors to compare): * There is/was an inconsistency in the AMF double counting potential (a missing factor 2), which I already patched up a while ago * For jspins=1 there is a piece of the double counting energy missing (the other spin), which is essentially again a factor 2 for the j part of the energy If you look at the v26 version of v_mmp these problems are not there, but its also relatively confusing. If I fix these issues I will have to change the energy values in the GaAsMultiForceXML test. For this reason I'm opening this issue so other people can have a look at it before changing a test. https://iffgit.fz-juelich.de/fleur/fleur/-/issues/448 Python tool for converting of input files 2020-06-03T12:02:56Z Jens Bröder Python tool for converting of input files Postcar, cif, xsf, vesta, ... Ohne AiiDA. Suggestion. build on pymatgen, for writting an input file for inpgen from an aiida structure see: https://github.com/JuDFTteam/aiida-fleur/blob/develop/aiida_fleur/calculation/fleurinputgen.py I have this external but not yet in the masci-tools repo @chand: do you already have something we can package? I have something half done. Postcar, cif, xsf, vesta, ... Ohne AiiDA. Suggestion. build on pymatgen, for writting an input file for inpgen from an aiida structure see: https://github.com/JuDFTteam/aiida-fleur/blob/develop/aiida_fleur/calculation/fleurinputgen.py I have this external but not yet in the masci-tools repo @chand: do you already have something we can package? I have something half done. https://iffgit.fz-juelich.de/fleur/fleur/-/issues/447 New Test infrastructure 2020-06-03T14:13:11Z Jens Bröder New Test infrastructure Here we collect features we want to have in a new test environment. This list is not ranked. * No unit-tests only regression tests needed * It should be easy to write new tests, tests templates for certain things * developer friendly * semi-automated way of generating tests * Should not introduce an external dependency * code coverage reports would be nice * it should run on linux, but also mac os. (windows prob not important) * We need flexibility on the test procedure. Sometimes we have to call Fleur multiple times, sometimes not even once. Depending on the test have different input files because some tests have everything in inp.xml while others use a sym.xml file. Depending on the test we are also interested in different output files. * The output of the reference run should be placed somewhere in the directory of the test. It may be useful for debugging. * The test infrastructure should impede the creation of invalid (ill-formed) tests. * Erros in the test-script should cause the tests to fail * we want to test different environments, with OMP, MPI, HDF, lib config * some level of verbosity on what goes wrong. Not just this test failed. * We should be able to identify whether a test fails because there is no SCALAPACK linked to Fleur. This should issue a special output + the test running in a serialized way * a trace from fleur in case of an error * should create a seperate stdout & stderr file Here we collect features we want to have in a new test environment. This list is not ranked. * No unit-tests only regression tests needed * It should be easy to write new tests, tests templates for certain things * developer friendly * semi-automated way of generating tests * Should not introduce an external dependency * code coverage reports would be nice * it should run on linux, but also mac os. (windows prob not important) * We need flexibility on the test procedure. Sometimes we have to call Fleur multiple times, sometimes not even once. Depending on the test have different input files because some tests have everything in inp.xml while others use a sym.xml file. Depending on the test we are also interested in different output files. * The output of the reference run should be placed somewhere in the directory of the test. It may be useful for debugging. * The test infrastructure should impede the creation of invalid (ill-formed) tests. * Erros in the test-script should cause the tests to fail * we want to test different environments, with OMP, MPI, HDF, lib config * some level of verbosity on what goes wrong. Not just this test failed. * We should be able to identify whether a test fails because there is no SCALAPACK linked to Fleur. This should issue a special output + the test running in a serialized way * a trace from fleur in case of an error * should create a seperate stdout & stderr file https://iffgit.fz-juelich.de/fleur/fleur/-/issues/420 (automatic) k-point convergence test? 2020-03-26T09:48:07Z Jens Bröder (automatic) k-point convergence test? Since we now 'quasi' allow several k-point sets in the inp.xml, maybe it would be nice to directly generate a second slightly denser mesh (purpose k-con-test) with inpgen and calculate again with this k-point set after the charge convergence (if some switch is set, as in the band structure case)? These results might be used to estimate if the quantities one is interested in are converged with respect to the k-mesh. Also Fleur could issue a warning that if the differences in the total energy per atom is to large. Is this with the current implementation easy to do? Drawback: optimal parallelization choice becomes harder to impossible. Of course in an aiida workflow we can do this convergence check with using several Fleur jobs, the last charge density would be copied in this case (or from scratch), leading also to more overhead in the database if we do it for every SCF we run. If one could do it within one job it would be nicer, but of course more work on the programming side. Since we now 'quasi' allow several k-point sets in the inp.xml, maybe it would be nice to directly generate a second slightly denser mesh (purpose k-con-test) with inpgen and calculate again with this k-point set after the charge convergence (if some switch is set, as in the band structure case)? These results might be used to estimate if the quantities one is interested in are converged with respect to the k-mesh. Also Fleur could issue a warning that if the differences in the total energy per atom is to large. Is this with the current implementation easy to do? Drawback: optimal parallelization choice becomes harder to impossible. Of course in an aiida workflow we can do this convergence check with using several Fleur jobs, the last charge density would be copied in this case (or from scratch), leading also to more overhead in the database if we do it for every SCF we run. If one could do it within one job it would be nicer, but of course more work on the programming side. https://iffgit.fz-juelich.de/fleur/fleur/-/issues/419 Make sure tests work without Scalapack 2020-04-06T21:43:54Z Matthias Redies Make sure tests work without Scalapack We have some tests, that are set to run with 2 MPIs as default, but have 3 k-points. These fail, if the binary doesn't have Scalapack:  4/31 Test #4: FLEUR_MPI:CuBulkXML .....................***Failed 3.08 sec   Program used 2 PE ***************ERROR*************** MPI parallelization failed ***************ERROR***************  Our test system should have a way of detecting the presence of eigenvalue parallelization and then choose the number of pe's so that it's a divisor of the number of k-points. We have some tests, that are set to run with 2 MPIs as default, but have 3 k-points. These fail, if the binary doesn't have Scalapack:  4/31 Test #4: FLEUR_MPI:CuBulkXML .....................***Failed 3.08 sec   Program used 2 PE ***************ERROR*************** MPI parallelization failed ***************ERROR***************  Our test system should have a way of detecting the presence of eigenvalue parallelization and then choose the number of pe's so that it's a divisor of the number of k-points. https://iffgit.fz-juelich.de/fleur/fleur/-/issues/410 Differences between old and new inpgen 2020-04-06T16:25:19Z Gregor Michalicek Differences between old and new inpgen Some default parameters are different between the release version inpgen and inpgen2 from the development version. We should check whether these are good changes or not. An example is shown below: old inpgen input: <pre> hydrogen monoxide molecule &input hybrid=t / &lattice latsys='cP', a=20.000 / 2 1.01 0.45 0.5 0.5 1.02 0.55 0.5 0.5 </pre> new inpgen input: <pre> hydrogen monoxide molecule &input hybinp=t / &lattice latsys='cP', a=20.000 / 2 1.01 0.45 0.5 0.5 1.02 0.55 0.5 0.5 </pre> old inp.xml file: xml <?xml version="1.0" encoding="UTF-8" standalone="no"?> <fleurInput fleurInputVersion="0.31"> <comment> hydrogen monoxide molecule </comment> <calculationSetup> <cutoffs Kmax="6.20000000" Gmax="18.50000000" GmaxXC="15.40000000" numbands="60"/> <scfLoop itmax="15" minDistance=".00001000" maxIterBroyd="25" imix="Anderson" alpha=".05000000" precondParam="0.0" spinf="2.00000000"/> <coreElectrons ctail="F" frcor="F" kcrel="0" coretail_lmax="0"/> <magnetism jspins="1" l_noco="F" swsp="F" lflip="F"/> <soc theta=".00000000" phi=".00000000" l_soc="F" spav="F"/> <prodBasis gcutm="5.70000000" tolerance=".00010000" ewaldlambda="3" lexp="16" bands="45"/> <expertModes gw="0" secvar="F"/> <geometryOptimization l_f="F" forcealpha="1.00000000" forcemix="BFGS" epsdisp=".00001000" epsforce=".00001000"/> <ldaU l_linMix="F" mixParam=".050000" spinf="1.000000"/> <bzIntegration valenceElectrons="2.00000000" mode="hist" fermiSmearingEnergy=".00100000"> <kPointMesh nx="4" ny="4" nz="4" gamma="T"/> <altKPointSet purpose="bands"> <kPointCount count=" 240" gamma="F"/> </altKPointSet> </bzIntegration> <energyParameterLimits ellow="-2.80000000" elup="11.00000000"/> </calculationSetup> <cell> <symmetryFile filename="sym.out"/> <bulkLattice scale="1.0000000000" latnam="squ"> <a1 scale="1.0000000000">20.0000000000</a1> <c scale="1.0000000000">20.0000000000</c> </bulkLattice> </cell> <xcFunctional name="pbe0" relativisticCorrections="F"/> <atomSpecies> <species name="H-1" element="H" atomicNumber="1" coreStates="0" magMom=".00000000" flipSpin="T"> <mtSphere radius=".98000000" gridPoints="323" logIncrement=".02500000"/> <atomicCutoffs lmax="6" lnonsphr="4"/> <energyParameters s="1" p="2" d="3" f="4"/> <prodBasis lcutm="4" lcutwf="6" select="4 0 4 2"/> </species> <species name="H-2" element="H" atomicNumber="1" coreStates="0" magMom=".00000000" flipSpin="T"> <mtSphere radius=".98000000" gridPoints="323" logIncrement=".02500000"/> <atomicCutoffs lmax="6" lnonsphr="4"/> <energyParameters s="1" p="2" d="3" f="4"/> <prodBasis lcutm="4" lcutwf="6" select="4 0 4 2"/> </species> </atomSpecies> <atomGroups> <atomGroup species="H-1"> <relPos label=" 1">9.000/20.000 1.000/2.000 1.000/2.000</relPos> <force calculate="F" relaxXYZ="TTT"/> </atomGroup> <atomGroup species="H-2"> <relPos label=" 2">-9.000/20.000 1.000/2.000 1.000/2.000</relPos> <force calculate="F" relaxXYZ="TTT"/> </atomGroup> </atomGroups> <output dos="F" band="F" vacdos="F" slice="F" mcd="F"> <checks vchk="F" cdinf="F"/> <densityOfStates ndir="0" minEnergy="-.50000000" maxEnergy=".50000000" sigma=".01500000"/> <vacuumDOS layers="0" integ="F" star="F" nstars="0" locx1=".00000" locy1=".00000" locx2=".00000" locy2=".00000" nstm="0" tworkf=".00000"/> <unfoldingBand unfoldBand="F" supercellX="1" supercellY="1" supercellZ="1"/> <plotting iplot="0" score="F" plplot="F"/> <chargeDensitySlicing numkpt="0" minEigenval=".00000000" maxEigenval=".00000000" nnne="0" pallst="F"/> <specialOutput eonly="F" bmt="F"/> <magneticCircularDichroism energyLo="-10.00000000" energyUp=".00000000"/> </output> <!-- We include the file relax.inp here to enable relaxations (see documentation) --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="relax.xml"> <xi:fallback/> </xi:include> </fleurInput>  new inp.xml file: xml <?xml version="1.0" encoding="UTF-8" standalone="no"?> <fleurInput fleurInputVersion="0.32"> <comment> hydrogen </comment> <calculationSetup> <cutoffs Kmax="4.50000000" Gmax="13.50000000" GmaxXC="13.50000000" numbands="60"/> <scfLoop itmax="15" minDistance=".00001000" maxIterBroyd="99" imix="Anderson" alpha=".05000000" precondParam="0.0" spinf="2.00000000"/> <coreElectrons ctail="F" frcor="F" kcrel="0" coretail_lmax="0"/> <magnetism jspins="1" l_noco="F" swsp="F" lflip="F" l_onlyMtStDen="F"/> <soc theta=".00000000" phi=".00000000" l_soc="F" spav="F"/> <prodBasis gcutm="4.00000000" tolerance=".00010000" ewaldlambda="3" lexp="16" bands="45"/> <expertModes gw="0" secvar="F"/> <geometryOptimization l_f="F" forcealpha="1.00000000" forcemix="BFGS" epsdisp=".00001000" epsforce=".00001000"/> <ldaU l_linMix="F" mixParam=".050000" spinf="1.000000"/> <bzIntegration valenceElectrons="2.00000000" mode="hist" fermiSmearingEnergy=".00100000"> <!-- k-points included here --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="kpts.xml"> </xi:include> </bzIntegration> <energyParameterLimits ellow="-2.80000000" elup="11.00000000"/> <!-- symmetry operations included here --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="sym.xml"> </xi:include> </calculationSetup> <cell> <bulkLattice scale="1.0000000000"> <bravaisMatrix> <row-1> 20.0000000000 0.0000000000 0.0000000000</row-1> <row-2> 0.0000000000 20.0000000000 0.0000000000</row-2> <row-3> 0.0000000000 0.0000000000 20.0000000000</row-3> </bravaisMatrix> </bulkLattice> </cell> <xcFunctional name="pbe0" relativisticCorrections="F"/> <atomSpecies> <species name="H-1" element="H" atomicNumber="1" flipSpinPhi=".00000000" flipSpinTheta=".00000000" flipSpinScale="F"> <mtSphere radius=".98000000" gridPoints="325" logIncrement=".02500000"/> <atomicCutoffs lmax="6" lnonsphr="4"/> <electronConfig> <coreConfig></coreConfig> <valenceConfig>(1s1/2)</valenceConfig> <stateOccupation state="(1s1/2)" spinUp=".50000000" spinDown=".50000000"/> </electronConfig> <energyParameters s="1" p="2" d="3" f="4"/> <prodBasis lcutm="4" lcutwf="6" select="4 0 4 2"/> </species> </atomSpecies> <atomGroups> <atomGroup species="H-1"> <relPos label=" 1">9.000/20.000 1.000/2.000 1.000/2.000</relPos> <force calculate="T" relaxXYZ="TTT"/> </atomGroup> <atomGroup species="H-1"> <relPos label=" 2">-9.000/20.000 1.000/2.000 1.000/2.000</relPos> <force calculate="T" relaxXYZ="TTT"/> </atomGroup> </atomGroups> <output dos="F" band="F" vacdos="F" slice="F" mcd="F"> <checks vchk="F" cdinf="F"/> <densityOfStates ndir="0" minEnergy="-.50000000" maxEnergy=".50000000" sigma=".01500000"/> <vacuumDOS layers="0" integ="F" star="F" nstars="0" locx1=".00000" locy1=".00000" locx2=".00000" locy2=".00000" nstm="0" tworkf=".00000"/> <unfoldingBand unfoldBand="F" supercellX="1" supercellY="1" supercellZ="1"/> <plotting iplot="0"/> <chargeDensitySlicing numkpt="0" minEigenval=".00000000" maxEigenval=".00000000" nnne="0" pallst="F"/> <specialOutput eonly="F" bmt="F"/> <magneticCircularDichroism energyLo="-10.00000000" energyUp=".00000000"/> </output> <!-- We include the file relax.inp here to enable relaxations (see documentation) --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="relax.xml"> <xi:fallback/> </xi:include> </fleurInput>  The important differences are: * Kmax, Gmax, GmaxXC, gcutm (probably all related to the change in Kmax) * maxIterBroyd (I think we changed this by pupose in the old release version) * force/@calculate ...I think this should be switched to T by default. * The two different hydrogen species are not made different any more. * The comment line is not complete. * The definition of the symmetry operations somehow moved to the calculationSetup section. I think they should be part of the cell section. Some default parameters are different between the release version inpgen and inpgen2 from the development version. We should check whether these are good changes or not. An example is shown below: old inpgen input: <pre> hydrogen monoxide molecule &input hybrid=t / &lattice latsys='cP', a=20.000 / 2 1.01 0.45 0.5 0.5 1.02 0.55 0.5 0.5 </pre> new inpgen input: <pre> hydrogen monoxide molecule &input hybinp=t / &lattice latsys='cP', a=20.000 / 2 1.01 0.45 0.5 0.5 1.02 0.55 0.5 0.5 </pre> old inp.xml file: xml <?xml version="1.0" encoding="UTF-8" standalone="no"?> <fleurInput fleurInputVersion="0.31"> <comment> hydrogen monoxide molecule </comment> <calculationSetup> <cutoffs Kmax="6.20000000" Gmax="18.50000000" GmaxXC="15.40000000" numbands="60"/> <scfLoop itmax="15" minDistance=".00001000" maxIterBroyd="25" imix="Anderson" alpha=".05000000" precondParam="0.0" spinf="2.00000000"/> <coreElectrons ctail="F" frcor="F" kcrel="0" coretail_lmax="0"/> <magnetism jspins="1" l_noco="F" swsp="F" lflip="F"/> <soc theta=".00000000" phi=".00000000" l_soc="F" spav="F"/> <prodBasis gcutm="5.70000000" tolerance=".00010000" ewaldlambda="3" lexp="16" bands="45"/> <expertModes gw="0" secvar="F"/> <geometryOptimization l_f="F" forcealpha="1.00000000" forcemix="BFGS" epsdisp=".00001000" epsforce=".00001000"/> <ldaU l_linMix="F" mixParam=".050000" spinf="1.000000"/> <bzIntegration valenceElectrons="2.00000000" mode="hist" fermiSmearingEnergy=".00100000"> <kPointMesh nx="4" ny="4" nz="4" gamma="T"/> <altKPointSet purpose="bands"> <kPointCount count=" 240" gamma="F"/> </altKPointSet> </bzIntegration> <energyParameterLimits ellow="-2.80000000" elup="11.00000000"/> </calculationSetup> <cell> <symmetryFile filename="sym.out"/> <bulkLattice scale="1.0000000000" latnam="squ"> <a1 scale="1.0000000000">20.0000000000</a1> <c scale="1.0000000000">20.0000000000</c> </bulkLattice> </cell> <xcFunctional name="pbe0" relativisticCorrections="F"/> <atomSpecies> <species name="H-1" element="H" atomicNumber="1" coreStates="0" magMom=".00000000" flipSpin="T"> <mtSphere radius=".98000000" gridPoints="323" logIncrement=".02500000"/> <atomicCutoffs lmax="6" lnonsphr="4"/> <energyParameters s="1" p="2" d="3" f="4"/> <prodBasis lcutm="4" lcutwf="6" select="4 0 4 2"/> </species> <species name="H-2" element="H" atomicNumber="1" coreStates="0" magMom=".00000000" flipSpin="T"> <mtSphere radius=".98000000" gridPoints="323" logIncrement=".02500000"/> <atomicCutoffs lmax="6" lnonsphr="4"/> <energyParameters s="1" p="2" d="3" f="4"/> <prodBasis lcutm="4" lcutwf="6" select="4 0 4 2"/> </species> </atomSpecies> <atomGroups> <atomGroup species="H-1"> <relPos label=" 1">9.000/20.000 1.000/2.000 1.000/2.000</relPos> <force calculate="F" relaxXYZ="TTT"/> </atomGroup> <atomGroup species="H-2"> <relPos label=" 2">-9.000/20.000 1.000/2.000 1.000/2.000</relPos> <force calculate="F" relaxXYZ="TTT"/> </atomGroup> </atomGroups> <output dos="F" band="F" vacdos="F" slice="F" mcd="F"> <checks vchk="F" cdinf="F"/> <densityOfStates ndir="0" minEnergy="-.50000000" maxEnergy=".50000000" sigma=".01500000"/> <vacuumDOS layers="0" integ="F" star="F" nstars="0" locx1=".00000" locy1=".00000" locx2=".00000" locy2=".00000" nstm="0" tworkf=".00000"/> <unfoldingBand unfoldBand="F" supercellX="1" supercellY="1" supercellZ="1"/> <plotting iplot="0" score="F" plplot="F"/> <chargeDensitySlicing numkpt="0" minEigenval=".00000000" maxEigenval=".00000000" nnne="0" pallst="F"/> <specialOutput eonly="F" bmt="F"/> <magneticCircularDichroism energyLo="-10.00000000" energyUp=".00000000"/> </output> <!-- We include the file relax.inp here to enable relaxations (see documentation) --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="relax.xml"> <xi:fallback/> </xi:include> </fleurInput>  new inp.xml file: xml <?xml version="1.0" encoding="UTF-8" standalone="no"?> <fleurInput fleurInputVersion="0.32"> <comment> hydrogen </comment> <calculationSetup> <cutoffs Kmax="4.50000000" Gmax="13.50000000" GmaxXC="13.50000000" numbands="60"/> <scfLoop itmax="15" minDistance=".00001000" maxIterBroyd="99" imix="Anderson" alpha=".05000000" precondParam="0.0" spinf="2.00000000"/> <coreElectrons ctail="F" frcor="F" kcrel="0" coretail_lmax="0"/> <magnetism jspins="1" l_noco="F" swsp="F" lflip="F" l_onlyMtStDen="F"/> <soc theta=".00000000" phi=".00000000" l_soc="F" spav="F"/> <prodBasis gcutm="4.00000000" tolerance=".00010000" ewaldlambda="3" lexp="16" bands="45"/> <expertModes gw="0" secvar="F"/> <geometryOptimization l_f="F" forcealpha="1.00000000" forcemix="BFGS" epsdisp=".00001000" epsforce=".00001000"/> <ldaU l_linMix="F" mixParam=".050000" spinf="1.000000"/> <bzIntegration valenceElectrons="2.00000000" mode="hist" fermiSmearingEnergy=".00100000"> <!-- k-points included here --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="kpts.xml"> </xi:include> </bzIntegration> <energyParameterLimits ellow="-2.80000000" elup="11.00000000"/> <!-- symmetry operations included here --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="sym.xml"> </xi:include> </calculationSetup> <cell> <bulkLattice scale="1.0000000000"> <bravaisMatrix> <row-1> 20.0000000000 0.0000000000 0.0000000000</row-1> <row-2> 0.0000000000 20.0000000000 0.0000000000</row-2> <row-3> 0.0000000000 0.0000000000 20.0000000000</row-3> </bravaisMatrix> </bulkLattice> </cell> <xcFunctional name="pbe0" relativisticCorrections="F"/> <atomSpecies> <species name="H-1" element="H" atomicNumber="1" flipSpinPhi=".00000000" flipSpinTheta=".00000000" flipSpinScale="F"> <mtSphere radius=".98000000" gridPoints="325" logIncrement=".02500000"/> <atomicCutoffs lmax="6" lnonsphr="4"/> <electronConfig> <coreConfig></coreConfig> <valenceConfig>(1s1/2)</valenceConfig> <stateOccupation state="(1s1/2)" spinUp=".50000000" spinDown=".50000000"/> </electronConfig> <energyParameters s="1" p="2" d="3" f="4"/> <prodBasis lcutm="4" lcutwf="6" select="4 0 4 2"/> </species> </atomSpecies> <atomGroups> <atomGroup species="H-1"> <relPos label=" 1">9.000/20.000 1.000/2.000 1.000/2.000</relPos> <force calculate="T" relaxXYZ="TTT"/> </atomGroup> <atomGroup species="H-1"> <relPos label=" 2">-9.000/20.000 1.000/2.000 1.000/2.000</relPos> <force calculate="T" relaxXYZ="TTT"/> </atomGroup> </atomGroups> <output dos="F" band="F" vacdos="F" slice="F" mcd="F"> <checks vchk="F" cdinf="F"/> <densityOfStates ndir="0" minEnergy="-.50000000" maxEnergy=".50000000" sigma=".01500000"/> <vacuumDOS layers="0" integ="F" star="F" nstars="0" locx1=".00000" locy1=".00000" locx2=".00000" locy2=".00000" nstm="0" tworkf=".00000"/> <unfoldingBand unfoldBand="F" supercellX="1" supercellY="1" supercellZ="1"/> <plotting iplot="0"/> <chargeDensitySlicing numkpt="0" minEigenval=".00000000" maxEigenval=".00000000" nnne="0" pallst="F"/> <specialOutput eonly="F" bmt="F"/> <magneticCircularDichroism energyLo="-10.00000000" energyUp=".00000000"/> </output> <!-- We include the file relax.inp here to enable relaxations (see documentation) --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="relax.xml"> <xi:fallback/> </xi:include> </fleurInput>  The important differences are: * Kmax, Gmax, GmaxXC, gcutm (probably all related to the change in Kmax) * maxIterBroyd (I think we changed this by pupose in the old release version) * force/@calculate ...I think this should be switched to T by default. * The two different hydrogen species are not made different any more. * The comment line is not complete. * The definition of the symmetry operations somehow moved to the calculationSetup section. I think they should be part of the cell section. https://iffgit.fz-juelich.de/fleur/fleur/-/issues/408 -inc all still creates kpts.xml 2020-03-25T10:24:56Z Matthias Redies -inc all still creates kpts.xml If I run:  redies@mb-redies ~/calculations/benchmark/Br [18:14:48] > $~/fleur/build/inpgen2/inpgen2 -inc all -overwrite -k gamma@nk=2 -f inp_Br Welcome to FLEUR - inpgen (www.flapw.de) MaX-Release 4.0 (www.max-centre.eu) ***************************************** Run finished successfully Stop message: All done ***************************************** Rank:0 used % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 350 100 69 100 281 482 1965 --:--:-- --:--:-- --:--:-- 2447 STOP OK redies@mb-redies ~/calculations/benchmark/Br [18:14:52] >$ ls default.econfig fort.77 inp.xml inp_Br kpts.xml out scratch struct.xsf usage.json  inpgen creates a kpts.xml even though i said -inc all. It's not used in the inp.xml it's just there. Could be confusing. [inp_Br](/uploads/f91ee939fbc2e1d98cfb3448ca0eecf0/inp_Br) [inp.xml](/uploads/e239fa60c1e70351ac010f544c3b08d7/inp.xml) [kpts.xml](/uploads/78e0b578d048c5dfe5e4094ba6dff7f8/kpts.xml) If I run:  redies@mb-redies ~/calculations/benchmark/Br [18:14:48] > $~/fleur/build/inpgen2/inpgen2 -inc all -overwrite -k gamma@nk=2 -f inp_Br Welcome to FLEUR - inpgen (www.flapw.de) MaX-Release 4.0 (www.max-centre.eu) ***************************************** Run finished successfully Stop message: All done ***************************************** Rank:0 used % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 350 100 69 100 281 482 1965 --:--:-- --:--:-- --:--:-- 2447 STOP OK redies@mb-redies ~/calculations/benchmark/Br [18:14:52] >$ ls default.econfig fort.77 inp.xml inp_Br kpts.xml out scratch struct.xsf usage.json  inpgen creates a kpts.xml even though i said -inc all. It's not used in the inp.xml it's just there. Could be confusing. [inp_Br](/uploads/f91ee939fbc2e1d98cfb3448ca0eecf0/inp_Br) [inp.xml](/uploads/e239fa60c1e70351ac010f544c3b08d7/inp.xml) [kpts.xml](/uploads/78e0b578d048c5dfe5e4094ba6dff7f8/kpts.xml) Daniel Wortmann Daniel Wortmann https://iffgit.fz-juelich.de/fleur/fleur/-/issues/328 Known issues with hybrid functionals in new fleur version 2020-03-25T10:27:49Z Gregor Michalicek Known issues with hybrid functionals in new fleur version I will create a list here of known issues with the hybrid functionals and known deviations from ancient fleur * HSE is not supported in new fleur version * EXX is not supported in new fleur version * There seems to be a dependence of the agreement between the old and new fleur versions on the lnonsph cutoff. Maybe this is related to the lcutwf parameter. * We obtain results differing from old fleur results if the basis set is smaller than the number of eigenfunctions to be calculated. I will create a list here of known issues with the hybrid functionals and known deviations from ancient fleur * HSE is not supported in new fleur version * EXX is not supported in new fleur version * There seems to be a dependence of the agreement between the old and new fleur versions on the lnonsph cutoff. Maybe this is related to the lcutwf parameter. * We obtain results differing from old fleur results if the basis set is smaller than the number of eigenfunctions to be calculated. https://iffgit.fz-juelich.de/fleur/fleur/-/issues/325 Experiences from the DFT lecture tutorial 2019 2020-01-28T13:22:32Z Gregor Michalicek Experiences from the DFT lecture tutorial 2019 This is going to be a list of issues that were observed during the DFT lecture tutorial 2019: * Converging Si with a certain MT radius, then changing the radius and converging it again with the same cdn.hdf file yields a wrong ground state (energy). We have to check whether the change in the setup is detected in the cdn.hdf IO. If not the outcome is probably due to a missing adaption of the stepfunction required by the new setup. This is going to be a list of issues that were observed during the DFT lecture tutorial 2019: * Converging Si with a certain MT radius, then changing the radius and converging it again with the same cdn.hdf file yields a wrong ground state (energy). We have to check whether the change in the setup is detected in the cdn.hdf IO. If not the outcome is probably due to a missing adaption of the stepfunction required by the new setup. https://iffgit.fz-juelich.de/fleur/fleur/-/issues/223 Normalization of pw_w and pw for densities and potentials should be the same ... 2018-12-19T09:15:54Z Gregor Michalicek Normalization of pw_w and pw for densities and potentials should be the same everywhere 1. At some points pw_w and pw is divided by stars%nstars, at other places not. The same normalization should be used in all places. 2. Both, pw and pw_w, should always be available. 1. At some points pw_w and pw is divided by stars%nstars, at other places not. The same normalization should be used in all places. 2. Both, pw and pw_w, should always be available. https://iffgit.fz-juelich.de/fleur/fleur/-/issues/143 Discussion on the layout of band.hdf file 2020-04-21T16:46:01Z Daniel Wortmann Discussion on the layout of band.hdf file We should have FLEUR generating nice files that can be used to plot bandstructures (later we should also talk about DOS). I suggest to: 1. Leave the text output untouched for the moment 2. Implement a new IO using HDF5 Here I would like to propose a structure of the this file in terms of HDF5 Groups(G),Attributes(A) and Datasets(D). HDF5 file containing all information useful to plot a bandstructure: **G:kpoints** * A: nkpt -- no of kpoints * D: k(3,nkpts) -- list of kpoints * D: dk(nkpts) -- scaled k-values (this is the x-value in current bands.1 files) * A: nspecial -- no of high symmetriy points * D: special_index(nspecial) -- index of special k-point label * D: special_name(nspecial) -- Name of special k-point **G:simple** * D:BS(2,*,jspins) -- array containing k-value (scaled), energy (as now in the bands.X files) **G:extended** * D: nbands(nkpt,jspins) -- no of bands for each k-point * D: energy(nbands,nkpt,jspins) -- energy * D: weights(weights,nbands,nkpt,jspins) -- weights of states (3 per atom, INT,VAC) (real) * D: sym(syms,nbands,nkpt,jspins) -- symmetry of bands (integer) **G:weights** * A: natoms * D: pos(natoms) * D: element(natoms) (integer) * A: extra_weights * D: extra_name(extra_weights) (string) (per default this should be INT,VAC) **G:sym** * A: nsyms * D: labels(nsyms) (strings) We should have FLEUR generating nice files that can be used to plot bandstructures (later we should also talk about DOS). I suggest to: 1. Leave the text output untouched for the moment 2. Implement a new IO using HDF5 Here I would like to propose a structure of the this file in terms of HDF5 Groups(G),Attributes(A) and Datasets(D). HDF5 file containing all information useful to plot a bandstructure: **G:kpoints** * A: nkpt -- no of kpoints * D: k(3,nkpts) -- list of kpoints * D: dk(nkpts) -- scaled k-values (this is the x-value in current bands.1 files) * A: nspecial -- no of high symmetriy points * D: special_index(nspecial) -- index of special k-point label * D: special_name(nspecial) -- Name of special k-point **G:simple** * D:BS(2,*,jspins) -- array containing k-value (scaled), energy (as now in the bands.X files) **G:extended** * D: nbands(nkpt,jspins) -- no of bands for each k-point * D: energy(nbands,nkpt,jspins) -- energy * D: weights(weights,nbands,nkpt,jspins) -- weights of states (3 per atom, INT,VAC) (real) * D: sym(syms,nbands,nkpt,jspins) -- symmetry of bands (integer) **G:weights** * A: natoms * D: pos(natoms) * D: element(natoms) (integer) * A: extra_weights * D: extra_name(extra_weights) (string) (per default this should be INT,VAC) **G:sym** * A: nsyms * D: labels(nsyms) (strings) https://iffgit.fz-juelich.de/fleur/fleur/-/issues/141 nonsymmorphic symmetries not yet implemented for films 2018-08-15T14:31:52Z Jens Bröder nonsymmorphic symmetries not yet implemented for films Just a reminder, please update if something changes here. Currently Fleur fails if started with any film input generated with nonsymmorphic symmetries. If you can think about a procedure to avoid generating these with inpgen in the film case. Would it be enough to translate all atoms in z-direction? Just a reminder, please update if something changes here. Currently Fleur fails if started with any film input generated with nonsymmorphic symmetries. If you can think about a procedure to avoid generating these with inpgen in the film case. Would it be enough to translate all atoms in z-direction? Gustav Bihlmayer Gustav Bihlmayer https://iffgit.fz-juelich.de/fleur/fleur/-/issues/122 EELS integration aspects 2017-07-14T17:41:40Z Gregor Michalicek EELS integration aspects I collect here code parts from the EELS code that need some discussion. (1.) In the subroutine corespec_dos the usage of the we array looks suspicious. I collect here code parts from the EELS code that need some discussion. (1.) In the subroutine corespec_dos the usage of the we array looks suspicious. https://iffgit.fz-juelich.de/fleur/fleur/-/issues/113 ntriad error for certain k point sets 2017-06-08T09:43:48Z Gregor Michalicek ntriad error for certain k point sets Soumyajyoti reports that he encountered the ntriad error if he tries to calculate for a film system a DOS (ndir=-1, DOS=t) for k point sets larger than a certain size. This error is thrown in the routine triang which at least assumes k points at every corner of the IBZ. Gustav mentioned that one has to adjust the k point set by hand such that the routine likes it. At least a gamma centered k point set should be used. This can be achieved by using a mesh with an odd number of k points in each direction. I performed tests and saw that this does not seem to be enough. For the given test system a mesh of 23x23x1 seems to be the largest that works. 25x25x1 leads to the ntriad error. I think we should make this routine failsafe. For HTC purposes manual adjustments of the k point set are not possible. I attach the relevant files Soumyajyoti sent me as well as a charge density file that can be used as a starting point for test calculations.[inp.working](/uploads/124b133538c3b351134521f6c5e98fd4/inp.working)[kpts.working](/uploads/af29d90fc96a0b08f60a00aac4ace4aa/kpts.working)[LOGFILE.working](/uploads/b8b2357d70fc53f4865c917143d4bf6c/LOGFILE.working)[inp.notworking](/uploads/20188ee37c14c5a7e1ea36e6bb4fe817/inp.notworking)[kpts.notworking](/uploads/019a13f5d274d15dab45988c700ce9d9/kpts.notworking)[LOGFILE.notworking](/uploads/34e4470a098afcd35656fe7aad88b3f5/LOGFILE.notworking)[cdn1](/uploads/880ce4b4f7a46df6c7f98e853d36399c/cdn1) Soumyajyoti reports that he encountered the ntriad error if he tries to calculate for a film system a DOS (ndir=-1, DOS=t) for k point sets larger than a certain size. This error is thrown in the routine triang which at least assumes k points at every corner of the IBZ. Gustav mentioned that one has to adjust the k point set by hand such that the routine likes it. At least a gamma centered k point set should be used. This can be achieved by using a mesh with an odd number of k points in each direction. I performed tests and saw that this does not seem to be enough. For the given test system a mesh of 23x23x1 seems to be the largest that works. 25x25x1 leads to the ntriad error. I think we should make this routine failsafe. For HTC purposes manual adjustments of the k point set are not possible. I attach the relevant files Soumyajyoti sent me as well as a charge density file that can be used as a starting point for test calculations.[inp.working](/uploads/124b133538c3b351134521f6c5e98fd4/inp.working)[kpts.working](/uploads/af29d90fc96a0b08f60a00aac4ace4aa/kpts.working)[LOGFILE.working](/uploads/b8b2357d70fc53f4865c917143d4bf6c/LOGFILE.working)[inp.notworking](/uploads/20188ee37c14c5a7e1ea36e6bb4fe817/inp.notworking)[kpts.notworking](/uploads/019a13f5d274d15dab45988c700ce9d9/kpts.notworking)[LOGFILE.notworking](/uploads/34e4470a098afcd35656fe7aad88b3f5/LOGFILE.notworking)[cdn1](/uploads/880ce4b4f7a46df6c7f98e853d36399c/cdn1) https://iffgit.fz-juelich.de/fleur/fleur/-/issues/107 Parameters never read from inp.xml file 2019-05-20T15:22:17Z Gregor Michalicek Parameters never read from inp.xml file Looking at the inp.xml file I realize that some parameters are never read. I collect them here: Attributes from AtomSpecies tag: magField, vcaAddCharge. Looking at the inp.xml file I realize that some parameters are never read. I collect them here: Attributes from AtomSpecies tag: magField, vcaAddCharge. Daniel Wortmann Daniel Wortmann https://iffgit.fz-juelich.de/fleur/fleur/-/issues/102 Tests of Fleur and its features 2018-08-15T14:30:18Z Jens Bröder Tests of Fleur and its features There are always not enough tests. Collect tests requests here, especially for features. (the test system might be adapted to which libraries Fleur was compiled with) So far there is no test for (correct me if I am wrong): 1. with HDF5 (should not be tested if compiled without) 2. General other external dependencies/libraries (LAPACK, ELPA, MAGMA, compilers?). We should somehow know if some changes in these 'break'/change something. I do not know what are sensible tests here. (Maybe for a 'general' check just run all the usual tests for different libraries linked in) Also that we can just tell users, not use this or this version. 3. Usability with AiiDA (so far I do not see a good way of doing this) 4. Out.xml schema: if the out.xml file applies to the schema? (if we do not test it there is no point in having one, because other tools can not rely on it) We should know if a commit breaks it, or if it has to be adapted. ... There are always not enough tests. Collect tests requests here, especially for features. (the test system might be adapted to which libraries Fleur was compiled with) So far there is no test for (correct me if I am wrong): 1. with HDF5 (should not be tested if compiled without) 2. General other external dependencies/libraries (LAPACK, ELPA, MAGMA, compilers?). We should somehow know if some changes in these 'break'/change something. I do not know what are sensible tests here. (Maybe for a 'general' check just run all the usual tests for different libraries linked in) Also that we can just tell users, not use this or this version. 3. Usability with AiiDA (so far I do not see a good way of doing this) 4. Out.xml schema: if the out.xml file applies to the schema? (if we do not test it there is no point in having one, because other tools can not rely on it) We should know if a commit breaks it, or if it has to be adapted. ... Daniel Wortmann Daniel Wortmann https://iffgit.fz-juelich.de/fleur/fleur/-/issues/61 Changes in out.xml for next official fleur version 2019-01-28T15:35:59Z Gregor Michalicek Changes in out.xml for next official fleur version I would like to collect here all the changes that have to enter the out.xml file in the next fleur version. At some point I will implement them all at once. Additions are welcome. 1. The output of the distance for the mixing of the density matrix is missing. This has to be added. 2. The DFT+U contribution to the total energy is provided in the xml element "dft+uCorrection". The special character "+" seems to be problematic for the XML code highlighting in some editors. This should be changed to something without special characters like, e.g., "dftPlusUCorrection". I would like to collect here all the changes that have to enter the out.xml file in the next fleur version. At some point I will implement them all at once. Additions are welcome. 1. The output of the distance for the mixing of the density matrix is missing. This has to be added. 2. The DFT+U contribution to the total energy is provided in the xml element "dft+uCorrection". The special character "+" seems to be problematic for the XML code highlighting in some editors. This should be changed to something without special characters like, e.g., "dftPlusUCorrection".