@SREERAMPK:

The number of Wyckoff positions does not directly tell us how many atoms you have in the unit cell. Wyckoff positions also have a multiplicity. For the computational effort the actual number of atoms in the unit cell you want to use for the simulation is a better indicator. What is that number?

To your questions:

1. How much computational resources you actually need depends on many aspects. For finite displacement calculations you need to perform calculations on supercells of the actual unit cell. For some systems a 2x2x2 supercell may be enough, for others the convergence with supercell size is much slower. DFT calculations for 2x2x2 supercells will surely work on your computational resources, for a 5x5x5 supercell you might get problems. For DFPT calculations there is a similar convergence aspect, when it comes to the number of k-points that you need. I suggest you start with a small and simple system to get a feeling for the required computational resources and then slowly go to larger and larger systems. You might also use such tests to get a feeling on what kind of parallelization setup you should use: How many nodes, how many MPI processes, how many OpenMP threads? This is not as trivial as it sounds. We often enough see that calculations from users take way too much time, because the parallelization setup is unfortunate. There might also be issues in Job scripts and so on. Thomas gave you an indication on the unit cell sizes we have experience with. If your unit cells are way larger, you are also the first person who can get experience with those. As far as I know, for the calculations Thomas performed, a cluster of similar size as your cluster was absolutely sufficient.

2. For DFT calculations you can invoke our input generator with certain parameter setup profiles, e.g., with a command line argument like "-profile moderate". That particular choice gives you a rather high precision parametrization, with the exception of the k-point set, which is not controlled by this profile. For DFPT calculations these profiles have the drawback that they make use of many local orbitals. We saw for a few systems that this can have bad effects on DFPT phonon calculations. So, don't use such a profile for such calculations. But you can use the profiles as a reference for calculations without too many local orbitals, e.g., calculate the equilibrium lattice constant once with the profile and once without. If the two lattice constants agree with high precision, either setup is good. Of course, it is also possible to automate FLEUR calculations to explicitly check which parameters have to be used. For such purposes we suggest to combine FLEUR with AiiDA and write small Python scrips to automatize this. For the calculation of the Birch-Murnaghan Equation of state, i.e., the determination of the lattice constant, There already is a command line way of starting such a workflow in the AiiDA-FLEUR interface. It is described in our interactive Docker-Tutorial in section F3. The HTML transcription of that tutorial section is available at https://www.flapw.de/MaX-7.0/future/F3/ , though we suggest that you actually use the real Docker FLEUR tutorial, see https://www.flapw.de/MaX-7.0/tutorial_docker/ for details. To actually automate you calculations with AiiDA you have to overcome some barriers. If you prefer to use shell scripts, it is also possible to do that. Just implement a loop in such a script that replaces certain values in the FLEUR input file with "sed" or similar tools. You can also invoke FLEUR with a special command line argument (-xmlPath) that replaces certain values in the input file by those that you provide in the respective commad line. An example for this is also available in the F3 tutoral I linked to. Also an example for such shells scripts is available in that tutorial.

I hope this helps.

Dear Roger,

The outputs that you show actually indicate that the Fleur Calculation failed. You can see that in the line

        &#9474;   &#9492;&#9472;&#9472; FleurCalculation<333> Finished [302]
 
 

If you see there a Finished with a nonzero number that indicates an error. You also see nonzero numbers for processes that are at a higher point in the hierarchy, but those are a consequence of what you see here.

You should have a look at exactly this failed Fleur calculation to se what is going on. I think, you can do that with

verdi calcjob gotocomputer 333
 
 

The 333 is the "PK" also mentioned in the line that reports this error. With that command you get to the directory in which the calculation actually took place and you will see some files there that give you more insights into the error.

Of course, if some calculations of a workflow fail, the whole workflow fails, because in the final stages of the workflow some data is not available.

If you provide the input file I could have a look at it. Maybe I see a problem in the setup.

I shortly discussed this with one of the authors of that paper. To me it sounded like their approach relies on some postprocessing code that is not openly available. I suggest that you get into direct contact with them.

What version of FLEUR are you using?

"inpgen2" nowadays is just "inpgen".

Just add another line like

&kpt nkpt=100 path='gamma=0,0,0;x=0.5,0.5,0.5' /
 
 

to your inpgen input to define another k-point set that is a path. If that is available the input generator will not try to generate a default path. If you add such a line you essentially define 2 kpoint sets in your inpgen input.

Of course, the naming of special points I chose in that path is random and not related to reality.

Dear Mohammad,

This is not so simple. Every unit cell you describe with FLEUR is periodically repeated. This implies that a finite overall charge of a unit cell translates into an infinite charge for the whole crystal and thus the Coulomb energy diverges. But you can employ certain tricks to perform such calculation nevertheless. These are, however, not accessible via our input and thus you have to modify the code itself. Gustav will get in contact with you to explain to you what options there actually are.

Dear Terry,

This is a problem with our k-point set generator. I assume that you want to perform the calculation at the Gamma point only. If so, you can overcome the issue by changing the last line of your inpgen input to

&kpt div1=1 div2=1 div3=1 gamma=T /
 
 

Let me also add that FLEUR might not be the perfect choice for calculating properties of molecules. FLEUR is a code for crystals, thin films, and for surfaces of crystals. Calculations on single molecules in large boxes are computationally extraordinarily expensive with it. A more natural choice for such systems would be the Siesta code.
If you nevertheless want to perform these calculations with FLEUR, you probably need several nodes of a compute cluster and it might also be a good idea to link FLEUR to the ChASE eigensolver and try that one out (maybe via linking to ELSI), though I am unsure whether calculations over multiple compute nodes can be performed with that code path at the moment. The ChASE eigensolver has strengths when the number of eigenfunctions you want to calculate is very small in comparison to the number of basis functions. Single atoms or molecules in a large box are a prototype example for this.