This is the user forum of the DFT FLAPW code FLEUR. It is meant to be used as a place to asks questions to other users and the developers, to provide feedback and suggestions. The documentation of the code can be found at the FLEUR homepage.
The code runs smoothly and ultimately tells me that the plots have been generated. When I look inside the .xsf files they look fine (see attached file) but I fail to plot them in xcrysden: I tried playing with the datagrid options in xcrysden but I cannot manage to get the desired plots out.
I'm wondering if it's a FLEUR issue, an xcrysden issue or (more than likely) a gap in my knowledge! Any help is well appreciated
Find one of the generated .xsf files attached to the thread
I'm in the middle of responding to some referees about a DFT paper done using FLEUR and I have two small questions:
When doing calculations involving SOC, the activation of the "l_soc" flag automatically implies that SOC is going to be treated in second variation right?
The treatment of SOC in first variation is done when activating the flags "l_noco". Do I understand this correctly?
I read the FLEUR manual, but I would like to be 100% sure,
I'm dealing with thin film systems and I'm interested I using the force theorem. Unfrotunately though, after converging the desired density with MPI parallelization, the force theorem part of the calculation fails yielding the following error message:
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL STOP ERROR: xml hierarchy too deep! elementName Forcetheorem_Loop attributeNames calculationTypeNo attributeValues MAE 1 elementList elementName Forcetheorem_Loop attributeNames calculationTypeNo attributeValues MAE 1 elementList elementName Forcetheorem_Loop attributeNames calculationTypeNo attributeValues MAE 1 elementList elementName Forcetheorem_Loop attributeNames calculationTypeNo attributeValues MAE 1 elementList elementName Forcetheorem_Loop attributeNames calculationTypeNo attributeValues MAE 1 elementList elementName Forcetheorem_Loop attributeNames calculationTypeNo attributeValues MAE 1 elementList
If I run the calculation without MPI parallelization everything runs smoothly. Is there an optimal way to do these type of calculations? Thanks in advance
I am currently interested in plotting an orbital resolved DOS using masci-tools. Unfortunately, when I use the FleurORBCOMP hdf5 reader and suggest my banddos.hdf file, python complains that some parameters are not specified:
HDF5 input file /home/adriano/.config/calculations/Max5/Work/no_soc/O_top_Fe/HfO2_fe_Interface_setup0/relax6/DOS/banddos.hdf has no Dataset at /Orbcomp/DOS/energyGrid.
Do I need to specify a special DOS mode calculation in the inp.xml file? Sorry for the rather basic question, but I can't seem to figure it out from the documentation alone!
I am currently investigating interfacial magnetic properties of MgO/CoFe multilayers (see inp.xml file and input.txt in the attachments for reference). and I would like to perform calculations using the DMI + SOC mode of the FLEUR code. Unfortunately, after the inclusion of SOC, the program complains with the following error message:
"Spin spiral + SOC does not work porperly for more than one atom per type" (see slurm file for complete message)
Does this have to do with the fact that we are using more than one magnetic atom in the setup? I tried eliminating the SOC treatment for the Cobalt atoms with socscale=0.0, but the error persists.
Does anyone with more experience on the DMI mode have an idea about the restrictions of this aspect of the code? Can a way to make it work be achieved?
After a very fast and problem free structural relaxation in a MgO/CoFe multilayer setup, I am experiencing a dramatic slow down as soon as I include SOC in the calculation. I am aware that SOC reduces the speed of the SCF loop, however I am currently working on a cluster and I run the simulation on 40 cores in parallel. (Since I am interested in calculating magnetic properties such as magentic anisotropy and possibly DMI, I explicitly broke as many symmetries as possible in the inp file by specifying an arbitrary quantization axis via the line /soc 0.37 0.10) I am aware of the optimized parallelization schemes offered by OpenMP, but in this particular instance they do not seem to provide the usual dramatic speedup.
Other simulations with similar size unit cells and structure displayed a much more bening convergence behavior after the inclusion of SOC. My questions:
1) Is the reduction in speed of SOC calculations caused by atom-specific parameters or does it only depend on the symmetry of the unit cell?
2) Could you show me a typical parallelization scheme you would run on your cluster?
As a ballpark value for the duration of 1 iteration : it takes about 15 minutes.
I will include the inp.xml and out.xml for your consideration as well as the sbatch file for you to compare and maybe suggest some better parallelization schemes.
After several months of problem free use of Fleur_5.1 I am faced with some installation issues following an OS reinstallation procedure needed to fix some other problems. After reinstalling the OS I proceeded to reinstall all the necessary additional software for my setup:
- Blas and Lapack libraries - XML parser - HDF5 - Parallel compilers to install FLEUR_MPI
When I run the configure script, the confuguration is correct but gives an error relative to mpi (see Configure_out.txt file). When I change to the build directory and run the "make" command, the procedure aborts at some point and yields the following error (see screenshot FLEUR_build.png). I attached the Configure.out file as well as the error message. Did anyone have the same problem at some point? Any help is deeply appreciated,
I indeed think this is the way to go. One simply has to specify fractional atomic numbers in the input file to get one atomic species per layer. I'll keep you updated on whether the yielded results are good.
Indeed this "layer resolved MAE" is simply defined in the literature as the difference between in plane energy and out of plane energy of a certain layer of the material (see the extract from the article). As far as I can tell though, the "socscale" parameter can only be adjusted for specific atom types and not really for different atomic layers in a thin film setup. Does this add up to you to?
One thing that could help is the following: I found this analysis in a PhD theses written in your group some time ago (see figure). From the wording used, it seems the user was able to switch SOC in selected layers to compare the energy contributions. I am not aware of ways to do thin is FLEUR but perhaps I miss something
In many literature articles I see DFT calculations that lead to a layer resolved mangnetic anisotropy energy in thin film setups (see the figure as an example). I'm sure Fleur has this information stored in the out.xml file but I'm having trouble interpreting the file and locating exactly where this information is stored.
My steps so far have been:
1) Converge the film setup without SOC
2) Include SOC and add the MAE_force theorem part in the inp.xml file to calculate the total energy in the out of plane and in plane SQA (Phi = 0.0 , 0.5 , Theta = 0.0 , 0.0)
My thinking was that I could then subtract the energy of the in plane configuration from the energy of the out of plane. I'm not entirely sure about where this "atom by atom energy contribution" is stored in the out.xml file Does this methodology make any sense with FLEUR or am I missing something?
The good results obtained with FLEUR actually fostered my institution to buy a new workstation optimized for DFT. I was wondering if you guys had an idea of what the important specs for a FLEUR optimized workstation might be. A few specifics on my current setup
I run FLEUR using the parallel version and most of my calculations end up involving spin orbit coupling as I treat magnetic systems. Any advice is warmly welcomed,