[Wien] Dense mesh calculation

[pluto]

Dear Prof. Blaha, dear All,

Thank you for your comments!

/SCRATCH directories on the older cluster that I am using are usually 
quite full (in some cases perhaps can be solved by writing some emails 
asking people to delete old stuff). New harddisk solution is considered, 
hopefully will be possible. In any case it's always good to have a 
solution to use less space.

In the meantime (after SCF and doing save_lapw) I reduced emin/emax 
ranges in in1c and inso and managed to calculate 100x100 mesh overnight 
on the /SCRATCH space that was available.

Best,
Lukasz



On 2018-08-19 07:16, Peter Blaha wrote:
> By choosing a local scratch directory  (like /scratch or /tmp or ...,
> this depends on your computers, you can then add -scratch /scratch to
> all wien2k run or x commands) and using massively k-parallelism (on as
> many different nodes as possible, you can distribute these large
> case.vector_xx files on many computers. (PS: otherwise a 2 or 4TB
> harddisk costs less than 100 $ !!??).
> 
> The case.vectorso_xx files are not needed for fermi surfaces (but of
> course they are needed for scf or optics, or ...) and can be reduced
> in size by selecting emin/emax in case.inso very narrow.
> 
> Another simple trick to save disk space would be:
> 
> Start x lapw1 -p -band -up/dn  and kill this after a few seconds. Do
> the same with  lapwso.
> 
> It will prepare a couple of uplapw1_xx.def and case.klist_xx files.
> 
> Now you run in a small loop (csh syntax):
> 
> foreach i (1 2 3 4)
>  lapw1c uplapw1_$i.def      # or lapw1 , depending on in1 or in1c)
>  lapw1c dnlapw1_$i.def
>  lapwso uplapwso_$i.def
>  rm case.vectorup_$i case.vectordn_$i
> end
> 
> This should produce only one vector file at the time and by choosing
> many cores, you can make them arbitrarily small.
> 
> Of course, this does not work when you need the vector files for other
> programs (lapw2, optics, ...)
> 
> 
> Am 18.08.2018 um 20:18 schrieb pluto:
>> Dear Gavin,
>> 
>> Thank you for your comments. This is what I was afraid.
>> 
>> I can glue output files by myself, no problem, hopefully they don't 
>> change the order of k-points. But one way to solve the disk-space 
>> issue would be to write a script that calculates SOC eigenvalues 
>> k-point by k-point. Then there would be no large vector files.
>> 
>> I am not feeling competent to modify and recompile WIEN2k, but perhaps 
>> I am able to solve it by the script.
>> 
>> Best,
>> Lukasz
>> 
>> 
>> 
>> On 8/18/2018 3:43 PM, Gavin Abo wrote:
>>> 
>>> From WIEN2k 18.2 UG page 126:
>>> 
>>> WFFIL: standard option, writes wave functions to file case.vector 
>>> (needed in lapw2)
>>> SUPWF: suppresses wave function calculation (faster for testing 
>>> eigenvalues only)
>>> WFPRI: prints eigenvectors to case.output1 and writes case.vector 
>>> (produces long outputs!)
>>> With SUPWF from above, it looks like case.vector* files are not 
>>> written by lapw1 unless WFFIL or WFPRI are used instead.  Since Table 
>>> 4.3 shows case.vector* files are required for lapwso, it may be that 
>>> you cannot workaround not using them.
>>> 
>>> As far as I know, there is no built in WIEN2k program to combine the 
>>> .output* files.  That is why the multiple recent and past posts about 
>>> it, such as:
>>> 
>>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17847.html 
>>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17829.html 
>>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg00508.html 
>>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg02057.html 
>>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg02055.html 
>>> (awk)
>>> http://www.democritos.it/pipermail/xcrysden/2015-September/001731.html
>>> http://www.democritos.it/pipermail/xcrysden/2015-December/001788.html
>>> 
>>> Though, I don't see why you couldn't automate it yourself either 
>>> using a job script (e.g., by adding the "cat case.outputso_1* > 
>>> case.output1up" to it), by writing your own script (e.g., bash script 
>>> containing your run[sp]_lapw and "cat case.outputso_1* > 
>>> case.output1up" commands), or by modifying the WIEN2k source code.
>>> 
>>> On 8/18/2018 5:07 AM, pluto wrote:
>>>> Dear All, dear Prof. Blaha,
>>>> 
>>>> I used SUPWF in case.in1c to limit the size of output files.
>>>> 
>>>> Then I used:
>>>> 
>>>> x lapw1 -band -up -p -c
>>>> x lapw1 -band -dn -p -c
>>>> x lapwso -up -p -c
>>>> 
>>>> There are no errors, but lapwso does not seem to calculate 
>>>> eigenvalues.
>>>> 
>>>> I use 4 parallel cores, so I have 4 output files. Output files 
>>>> without SOC look OK, they contain eigenvalues (files 
>>>> case.output1up_1 to 4, same for dn).  But SOC output files 
>>>> (outputso_1 to 4) do not contain any eigenvalues, and I don't see 
>>>> any other output files.
>>>> 
>>>> Am I doing something wrong? Manual in Table 4.3 says that lapwso 
>>>> needs vector files, which are of course missing here. Is there a way 
>>>> out?
>>>> 
>>>> Also, is there a way to automatically "glue" output files to have 
>>>> just one large output file?
>>>> 
>>>> Best,
>>>> Lukasz
>>> 
>>> 
>>> _______________________________________________
>>> 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
>> 
>>