Re: [Wien] contradictory band gap in case.scf and band.agr

[Dr. K. C. Bhamu]

> 2. You had too small a k-mesh for the scf, the fine one for the bands
> shows a metal.
>

I was working to help a student. I assumed that She has optimized the
structure well.
I just finished a case starting from optimization. With a finer k-mesh
(25x25x25), band gap in case.scf and case.bands.agr are same.
Thanks for your detailed response.


Regards
Bhamu
___
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

Re: [Wien] contradictory band gap in case.scf and band.agr

[Dr. K. C. Bhamu]

Dear Gavin

Thanks for your reply.
I have checked with both the approaches and I am having same problem in
both the cases.

On Sat, Sep 10, 2022, 4:24 PM Gavin Abo  wrote:

> I have probably overlooked in your conversion when you mentioned whether
> you were using a shifted or non-shifted k-mesh; If you happened to have
> used a shifted k-mesh in your perovskites calculation, then you might try
> the calculation again with a non-shifted k-mesh during "x kgen":
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15445.html
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg19427.html
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15445.html
>
> Kind Regards,
> Gavin
> WIEN2k user
>
> On 9/10/2022 4:20 AM, Dr. K. C. Bhamu wrote:
>
> Thanks Prof. Marks for your suggestions.
>
> My system is non-sp and non-SO type.
>
> I didn't do any mistake with k-path as Its a cubic system and its
> brillouin zone is very simple.
>
> I do agree with the k-mesh as with very fine mesh narrow band gap systems
> may show metallic character.
> In one of my case it is happening.
>
>
> But in a separate case where I didn't change the k-mesh after SCF for band
> structure calculation, the band structure should show the same band gap as
> I am getting with the grep command. No?
>
> Thanks
> Bhamu
>
> On Sat, Sep 10, 2022, 3:11 PM Laurence Marks 
> wrote:
>
>> I can think this can occur in numerous ways, all a minor mistake:
>>
>> 1. You forgot to include -orb when you did the bands.
>> 2. You had too small a k-mesh for the scf, the fine one for the bands
>> shows a metal.
>> 3. Your grep showed just the "up" spin, not both.
>> 4. You did not fully converge.
>> 5. You forgot -so in the band.
>> 6. You have a mistake in your k-mesh for the bands.
>> 7. Something else similar.
>>
>> Just my guesses, I suggest you check carefully. Number 7 is most likely.
>>
>> --
>> Professor Laurence Marks
>> Department of Materials Science and Engineering, Northwestern University
>> www.numis.northwestern.edu
>> "Research is to see what everybody else has seen, and to think what
>> nobody else has thought" Albert Szent-Györgyi
>>
>> On Fri, Sep 9, 2022, 10:45 PM Dr. K. C. Bhamu 
>> wrote:
>>
>>> Dear Users
>>>
>>> Greetings,
>>>
>>> I am trying to compute the band structure of some ABX3 perovskites
>>> systems with Wien2k_19.2 compiled with intel compilers.
>>> When I grep the band gap from case.scf, I am getting some values
>>> (~0.7eV) while when I plot the band structure, the VBM is significantly
>>> crossing the Fermi level and the gap between CBM and VBM is much lesser
>>> than the one I grepped from case.scf file.
>>> In some case, VBM and VBM are overlapping while case.scf file is showing
>>> a clear band gap.
>>>
>>> I have updated Fermi energy in case.insp files.
>>>
>>> I never faced such an issue in the past.
>>>
>>> I am wondering if you would like to help me out.
>>>
>>> Regards
>>> Bhamu
>>>
>> ___
> 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

Re: [Wien] contradictory band gap in case.scf and band.agr

[Dr. K. C. Bhamu]

Thanks Prof. Marks for your suggestions.

My system is non-sp and non-SO type.

I didn't do any mistake with k-path as Its a cubic system and its brillouin
zone is very simple.

I do agree with the k-mesh as with very fine mesh narrow band gap systems
may show metallic character.
In one of my case it is happening.


But in a separate case where I didn't change the k-mesh after SCF for band
structure calculation, the band structure should show the same band gap as
I am getting with the grep command. No?

Thanks
Bhamu

On Sat, Sep 10, 2022, 3:11 PM Laurence Marks 
wrote:

> I can think this can occur in numerous ways, all a minor mistake:
>
> 1. You forgot to include -orb when you did the bands.
> 2. You had too small a k-mesh for the scf, the fine one for the bands
> shows a metal.
> 3. Your grep showed just the "up" spin, not both.
> 4. You did not fully converge.
> 5. You forgot -so in the band.
> 6. You have a mistake in your k-mesh for the bands.
> 7. Something else similar.
>
> Just my guesses, I suggest you check carefully. Number 7 is most likely.
>
> --
> Professor Laurence Marks
> Department of Materials Science and Engineering, Northwestern University
> www.numis.northwestern.edu
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought" Albert Szent-Györgyi
>
> On Fri, Sep 9, 2022, 10:45 PM Dr. K. C. Bhamu  wrote:
>
>> Dear Users
>>
>> Greetings,
>>
>> I am trying to compute the band structure of some ABX3 perovskites
>> systems with Wien2k_19.2 compiled with intel compilers.
>> When I grep the band gap from case.scf, I am getting some values (~0.7eV)
>> while when I plot the band structure, the VBM is significantly crossing the
>> Fermi level and the gap between CBM and VBM is much lesser than the one I
>> grepped from case.scf file.
>> In some case, VBM and VBM are overlapping while case.scf file is showing
>> a clear band gap.
>>
>> I have updated Fermi energy in case.insp files.
>>
>> I never faced such an issue in the past.
>>
>> I am wondering if you would like to help me out.
>>
>> Regards
>> Bhamu
>>
>>
>>
>> ___
>> 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

[Wien] contradictory band gap in case.scf and band.agr

[Dr. K. C. Bhamu]

Dear Users

Greetings,

I am trying to compute the band structure of some ABX3 perovskites systems
with Wien2k_19.2 compiled with intel compilers.
When I grep the band gap from case.scf, I am getting some values (~0.7eV)
while when I plot the band structure, the VBM is significantly crossing the
Fermi level and the gap between CBM and VBM is much lesser than the one I
grepped from case.scf file.
In some case, VBM and VBM are overlapping while case.scf file is showing a
clear band gap.

I have updated Fermi energy in case.insp files.

I never faced such an issue in the past.

I am wondering if you would like to help me out.

Regards
Bhamu
___
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

Re: [Wien] FINDLOC issue with latest version of Wien2k with fortran v.15

[Dr. K. C. Bhamu]

Thanks Gavin,
I have tried with the bash tool kit as well.

I will write in the oneapi forum. Thanks for the suggestion.


Regards
Bhamu

On Wed, Feb 16, 2022 at 5:54 PM Gavin Abo  wrote:

> Intel oneAPI has its own support forums such as "Intel oneAPI
> Registration" and "Toolkits & SDKs" at [1].  The group in the forums over
> there is likely to be more experienced with oneAPI installations.
>
> In your previous post, it looked like you were installing the oneAPI HPC
> Toolkit (i.e., l_HPCKit_p_2022.1.2.117_offline.sh).  OneAPI has multiple
> toolkits [2].  One possibility is that the missing Sqlite SQL might be part
> of the oneAPI Base Toolkit such that you might have to install it first
> before installing the oneAPI HPC Toolkit.
> [1]
> https://community.intel.com/t5/Developer-Software-Forums/ct-p/developer-software-forums
> [2]
> https://www.intel.com/content/www/us/en/developer/tools/oneapi/toolkits.html
>
> On 2/16/2022 4:34 AM, Dr. K. C. Bhamu wrote:
>
> Dear Gavin,
> Thanks for your detailed reply.
> I have followed your suggestion but the problem still persists.
> I have three directories: installercache  oneapi  packagemanager
>
> kcbhamu@kcbhamu:~$ls oneapi/installer/lib
> libQt6Core5Compat.solibQt6QmlModels.so
> libQt6QuickLayouts.so   libQt6XcbQpa.so  libxcb-render.so
>   libxcb-sync.solibxcb-xkb.so
> libQt6Core5Compat.so.6  libQt6QmlModels.so.6
> libQt6QuickLayouts.so.6 libQt6XcbQpa.so.6libxcb-render.so.0
>   libxcb-sync.so.1  libxcb-xkb.so.1
> libQt6Core5Compat.so.6.1.3  libQt6QmlModels.so.6.1.3
> libQt6QuickLayouts.so.6.1.3 libQt6XcbQpa.so.6.1.3
>  libxcb-render.so.0.0.0   libxcb-sync.so.1.0.0  libxcb-xkb.so.1.0.0
> libQt6Core.so   libQt6Qml.so
> libQt6QuickShapes.solibxcb-icccm.so
>  libxcb-render-util.solibxcb-util.solibxkbcommon.so
> libQt6Core.so.6 libQt6Qml.so.6
> libQt6QuickShapes.so.6  libxcb-icccm.so.4
>  libxcb-render-util.so.0  libxcb-util.so.1  libxkbcommon.so.0
> libQt6Core.so.6.1.3 libQt6Qml.so.6.1.3
> libQt6QuickShapes.so.6.1.3  libxcb-icccm.so.4.0.0
>  libxcb-render-util.so.0.0.0  libxcb-util.so.1.0.0
>  libxkbcommon.so.0.0.0
> libQt6DBus.so   libQt6QmlWorkerScript.so
> libQt6Quick.so  libxcb-image.so  libxcb-shape.so
>libxcb-xfixes.so  libxkbcommon-x11.so
> libQt6DBus.so.6 libQt6QmlWorkerScript.so.6
> libQt6Quick.so.6libxcb-image.so.0libxcb-shape.so.0
>libxcb-xfixes.so.0libxkbcommon-x11.so.0
> libQt6DBus.so.6.1.3 libQt6QmlWorkerScript.so.6.1.3
> libQt6Quick.so.6.1.3libxcb-image.so.0.0.0
>  libxcb-shape.so.0.0.0libxcb-xfixes.so.0.0.0
>  libxkbcommon-x11.so.0.0.0
> libQt6Gui.solibQt6QuickControls2Impl.so
>  libQt6QuickTemplates2.solibxcb-keysyms.solibxcb-shm.so
>libxcb-xinerama.so
> libQt6Gui.so.6  libQt6QuickControls2Impl.so.6
>  libQt6QuickTemplates2.so.6  libxcb-keysyms.so.1  libxcb-shm.so.0
>libxcb-xinerama.so.0
> libQt6Gui.so.6.1.3  libQt6QuickControls2Impl.so.6.1.3
>  libQt6QuickTemplates2.so.6.1.3  libxcb-keysyms.so.1.0.0
>  libxcb-shm.so.0.0.0  libxcb-xinerama.so.0.0.0
> libQt6Network.solibQt6QuickControls2.so
>  libQt6Widgets.solibxcb-randr.so  libxcb.so
>libxcb-xinput.so
> libQt6Network.so.6  libQt6QuickControls2.so.6
>  libQt6Widgets.so.6  libxcb-randr.so.0libxcb.so.1
>libxcb-xinput.so.0
> libQt6Network.so.6.1.3  libQt6QuickControls2.so.6.1.3
>  libQt6Widgets.so.6.1.3  libxcb-randr.so.0.1.0libxcb.so.1.1.0
>libxcb-xinput.so.0.1.0
>
>
> Thank you very much
> Bhamu
>
>
> On Wed, Feb 16, 2022 at 4:30 PM Gavin Abo  wrote:
>
>> With your offline install [1] command below, it will likely try to
>> install it in Intel's default location (/opt/intel) which is typically for
>> root permissions.
>>
>> You would need to install it in a user directory that you have user
>> permission to.  That might be for example /home/username/intel.  As seen
>> at [2], the --install-dir option may need to be added to your command:
>>
>> bash ./l_HPCKit_p_2022.1.2.117_offline.sh  -s -a --silent --eula accept 
>> --install-dir
>> /home/username/intel
>>
>> According to [3], before executing the above command, you might also need
>> to set $HOME as well, for example in the terminal with:
>>
>> export HOME=/home/username/intel

Re: [Wien] FINDLOC issue with latest version of Wien2k with fortran v.15

[Dr. K. C. Bhamu]

Dear Gavin,
Thanks for your detailed reply.
I have followed your suggestion but the problem still persists.
I have three directories: installercache  oneapi  packagemanager

kcbhamu@kcbhamu:~$ls oneapi/installer/lib
libQt6Core5Compat.solibQt6QmlModels.so
libQt6QuickLayouts.so   libQt6XcbQpa.so  libxcb-render.so
  libxcb-sync.solibxcb-xkb.so
libQt6Core5Compat.so.6  libQt6QmlModels.so.6
libQt6QuickLayouts.so.6 libQt6XcbQpa.so.6libxcb-render.so.0
  libxcb-sync.so.1  libxcb-xkb.so.1
libQt6Core5Compat.so.6.1.3  libQt6QmlModels.so.6.1.3
libQt6QuickLayouts.so.6.1.3 libQt6XcbQpa.so.6.1.3
 libxcb-render.so.0.0.0   libxcb-sync.so.1.0.0  libxcb-xkb.so.1.0.0
libQt6Core.so   libQt6Qml.so
libQt6QuickShapes.solibxcb-icccm.so
 libxcb-render-util.solibxcb-util.solibxkbcommon.so
libQt6Core.so.6 libQt6Qml.so.6
libQt6QuickShapes.so.6  libxcb-icccm.so.4
 libxcb-render-util.so.0  libxcb-util.so.1  libxkbcommon.so.0
libQt6Core.so.6.1.3 libQt6Qml.so.6.1.3
libQt6QuickShapes.so.6.1.3  libxcb-icccm.so.4.0.0
 libxcb-render-util.so.0.0.0  libxcb-util.so.1.0.0
 libxkbcommon.so.0.0.0
libQt6DBus.so   libQt6QmlWorkerScript.so
libQt6Quick.so  libxcb-image.so  libxcb-shape.so
   libxcb-xfixes.so  libxkbcommon-x11.so
libQt6DBus.so.6 libQt6QmlWorkerScript.so.6
libQt6Quick.so.6libxcb-image.so.0libxcb-shape.so.0
   libxcb-xfixes.so.0libxkbcommon-x11.so.0
libQt6DBus.so.6.1.3 libQt6QmlWorkerScript.so.6.1.3
libQt6Quick.so.6.1.3libxcb-image.so.0.0.0
 libxcb-shape.so.0.0.0libxcb-xfixes.so.0.0.0
 libxkbcommon-x11.so.0.0.0
libQt6Gui.solibQt6QuickControls2Impl.so
 libQt6QuickTemplates2.solibxcb-keysyms.solibxcb-shm.so
   libxcb-xinerama.so
libQt6Gui.so.6  libQt6QuickControls2Impl.so.6
 libQt6QuickTemplates2.so.6  libxcb-keysyms.so.1  libxcb-shm.so.0
   libxcb-xinerama.so.0
libQt6Gui.so.6.1.3  libQt6QuickControls2Impl.so.6.1.3
 libQt6QuickTemplates2.so.6.1.3  libxcb-keysyms.so.1.0.0
 libxcb-shm.so.0.0.0  libxcb-xinerama.so.0.0.0
libQt6Network.solibQt6QuickControls2.so
 libQt6Widgets.solibxcb-randr.so  libxcb.so
   libxcb-xinput.so
libQt6Network.so.6  libQt6QuickControls2.so.6
 libQt6Widgets.so.6  libxcb-randr.so.0libxcb.so.1
   libxcb-xinput.so.0
libQt6Network.so.6.1.3  libQt6QuickControls2.so.6.1.3
 libQt6Widgets.so.6.1.3  libxcb-randr.so.0.1.0libxcb.so.1.1.0
   libxcb-xinput.so.0.1.0


Thank you very much
Bhamu


On Wed, Feb 16, 2022 at 4:30 PM Gavin Abo  wrote:

> With your offline install [1] command below, it will likely try to install
> it in Intel's default location (/opt/intel) which is typically for root
> permissions.
>
> You would need to install it in a user directory that you have user
> permission to.  That might be for example /home/username/intel.  As seen
> at [2], the --install-dir option may need to be added to your command:
>
> bash ./l_HPCKit_p_2022.1.2.117_offline.sh  -s -a --silent --eula accept 
> --install-dir
> /home/username/intel
>
> According to [3], before executing the above command, you might also need
> to set $HOME as well, for example in the terminal with:
>
> export HOME=/home/username/intel
>
> You may also need to ask your administrative staff what user directories
> are available and what free disk space is available for each of them.  For
> an all component install, the Intel webpage at [4] shows upwards of about
> 30 GB (=24 GB  for components + 6 GB temporary space) is needed.  Though at
> [2], there is a --components option that you might be able to use to
> install a minimized set of components [5] such as Intel Fortran Compiler
> Classic (intel.oneapi.lin.ifort-compiler) in the oneAPI HPC Toolkit and
> Intel MKL (intel.oneapi.lin.mkl.devel) in the oneAPI Base Toolkit.
> [1] https://www.youtube.com/watch?v=VC_ucczGR_Y
> [2]
> https://www.intel.com/content/www/us/en/develop/documentation/installation-guide-for-intel-oneapi-toolkits-linux/top/installation/install-with-command-line.html
> [3]
> https://community.intel.com/t5/Intel-oneAPI-Registration/oneAPI-installation-fails/td-p/1299826
> [4]
> https://www.intel.com/content/www/us/en/developer/articles/system-requirements/intel-oneapi-base-toolkit-system-requirements.html
> [5] https://oneapi-src.github.io/oneapi-ci/#linux-web-installer
>
> On 2/15/2022 9:00 PM, Dr. K. C. Bhamu wrote:
>
> Dear Prof. Peter,
> I have tried to install oneapi but getting another error of SQL:
> bash ./l_HPCKit_p_2022.1.2.117_offline.sh  -s -a --silent --eula accept
&

Re: [Wien] FINDLOC issue with latest version of Wien2k with fortran v.15

[Dr. K. C. Bhamu]

Dear Prof. Peter,
I have tried to install oneapi but getting another error of SQL:
bash ./l_HPCKit_p_2022.1.2.117_offline.sh  -s -a --silent --eula accept
Checking system requirements...
Done.
Wait while the installer is preparing...
Done.
Launching the installer...
Installer failed with the error Sqlite SQL execution failed.
#

and I do not see any compilers in oneapi directory.

#---
>From SQL installation procedure, I see it needs a root access:
https://phoenixnap.com/kb/sql-server-linux


Any help will be appreciated.

Regards
Bhamu





On Mon, Feb 7, 2022 at 4:13 PM Peter Blaha 
wrote:

> You probably can install it. root is not required. Try it.
> Am 07.02.2022 um 11:31 schrieb Dr. K. C. Bhamu:
>
> Thanks Prof. Peter.
>
> But unfortunately I can not install this version in cluster. Admistrative
> staff also denied as they are moved on GPU so not helping for CPU
> calculations.
>
>
> Regards
> Bhamu
>
> On Mon, Feb 7, 2022, 7:27 PM Peter Blaha 
> wrote:
>
>> It does not work with an old compiler.
>>
>> The intel compiler is now free.
>> Am 07.02.2022 um 11:02 schrieb Dr. K. C. Bhamu:
>>
>> A gentle reminder for the help.
>>
>>
>> Regards
>> Bhamu
>>
>> On Fri, Feb 4, 2022 at 8:10 AM Dr. K. C. Bhamu 
>> wrote:
>>
>>> Dear Experts,
>>> I am facing an issue [1] with a recent version of Wien2k installation
>>> with Fortran v.15 "composer_xe_2015.2.164".
>>> Earlier reported issue was resolved by upgrading the Fortran version.
>>> But for me, I have no choice of updating the intel compilers.
>>>
>>> Could someone please help me to resolve this issue?
>>>
>>> [1].
>>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg21006.html
>>>
>>> Please let me know what else information you need.
>>>
>>> Regards
>>> Bhamu
>>>
>>
>> ___
>> Wien mailing 
>> listw...@zeus.theochem.tuwien.ac.athttp://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
>>
>> --
>> ---
>> Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
>> Phone: +43-158801165300
>> Email: peter.bl...@tuwien.ac.at
>> WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.at
>> -
>>
>> ___
>> 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 
> listw...@zeus.theochem.tuwien.ac.athttp://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
>
> --
> ---
> Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-158801165300
> Email: peter.bl...@tuwien.ac.at
> WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.at
> -
>
> ___
> 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

Re: [Wien] FINDLOC issue with latest version of Wien2k with fortran v.15

[Dr. K. C. Bhamu]

Thank you very much.
I will try it and let you know.


Bhamu

On Mon, Feb 7, 2022 at 4:13 PM Peter Blaha 
wrote:

> You probably can install it. root is not required. Try it.
> Am 07.02.2022 um 11:31 schrieb Dr. K. C. Bhamu:
>
> Thanks Prof. Peter.
>
> But unfortunately I can not install this version in cluster. Admistrative
> staff also denied as they are moved on GPU so not helping for CPU
> calculations.
>
>
> Regards
> Bhamu
>
> On Mon, Feb 7, 2022, 7:27 PM Peter Blaha 
> wrote:
>
>> It does not work with an old compiler.
>>
>> The intel compiler is now free.
>> Am 07.02.2022 um 11:02 schrieb Dr. K. C. Bhamu:
>>
>> A gentle reminder for the help.
>>
>>
>> Regards
>> Bhamu
>>
>> On Fri, Feb 4, 2022 at 8:10 AM Dr. K. C. Bhamu 
>> wrote:
>>
>>> Dear Experts,
>>> I am facing an issue [1] with a recent version of Wien2k installation
>>> with Fortran v.15 "composer_xe_2015.2.164".
>>> Earlier reported issue was resolved by upgrading the Fortran version.
>>> But for me, I have no choice of updating the intel compilers.
>>>
>>> Could someone please help me to resolve this issue?
>>>
>>> [1].
>>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg21006.html
>>>
>>> Please let me know what else information you need.
>>>
>>> Regards
>>> Bhamu
>>>
>>
>> ___
>> Wien mailing 
>> listw...@zeus.theochem.tuwien.ac.athttp://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
>>
>> --
>> ---
>> Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
>> Phone: +43-158801165300
>> Email: peter.bl...@tuwien.ac.at
>> WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.at
>> -
>>
>> ___
>> 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 
> listw...@zeus.theochem.tuwien.ac.athttp://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
>
> --
> ---
> Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-158801165300
> Email: peter.bl...@tuwien.ac.at
> WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.at
> -
>
> ___
> 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

Re: [Wien] FINDLOC issue with latest version of Wien2k with fortran v.15

[Dr. K. C. Bhamu]

Thanks Prof. Peter.

But unfortunately I can not install this version in cluster. Admistrative
staff also denied as they are moved on GPU so not helping for CPU
calculations.


Regards
Bhamu

On Mon, Feb 7, 2022, 7:27 PM Peter Blaha 
wrote:

> It does not work with an old compiler.
>
> The intel compiler is now free.
> Am 07.02.2022 um 11:02 schrieb Dr. K. C. Bhamu:
>
> A gentle reminder for the help.
>
>
> Regards
> Bhamu
>
> On Fri, Feb 4, 2022 at 8:10 AM Dr. K. C. Bhamu 
> wrote:
>
>> Dear Experts,
>> I am facing an issue [1] with a recent version of Wien2k installation
>> with Fortran v.15 "composer_xe_2015.2.164".
>> Earlier reported issue was resolved by upgrading the Fortran version.
>> But for me, I have no choice of updating the intel compilers.
>>
>> Could someone please help me to resolve this issue?
>>
>> [1].
>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg21006.html
>>
>> Please let me know what else information you need.
>>
>> Regards
>> Bhamu
>>
>
> ___
> Wien mailing 
> listw...@zeus.theochem.tuwien.ac.athttp://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
>
> --
> ---
> Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-158801165300
> Email: peter.bl...@tuwien.ac.at
> WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.at
> -
>
> ___
> 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

Re: [Wien] FINDLOC issue with latest version of Wien2k with fortran v.15

[Dr. K. C. Bhamu]

A gentle reminder for the help.


Regards
Bhamu

On Fri, Feb 4, 2022 at 8:10 AM Dr. K. C. Bhamu  wrote:

> Dear Experts,
> I am facing an issue [1] with a recent version of Wien2k installation with
> Fortran v.15 "composer_xe_2015.2.164".
> Earlier reported issue was resolved by upgrading the Fortran version.
> But for me, I have no choice of updating the intel compilers.
>
> Could someone please help me to resolve this issue?
>
> [1].
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg21006.html
>
> Please let me know what else information you need.
>
> Regards
> Bhamu
>
___
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] FINDLOC issue with latest version of Wien2k with fortran v.15

[Dr. K. C. Bhamu]

Dear Experts,
I am facing an issue [1] with a recent version of Wien2k installation with
Fortran v.15 "composer_xe_2015.2.164".
Earlier reported issue was resolved by upgrading the Fortran version.
But for me, I have no choice of updating the intel compilers.

Could someone please help me to resolve this issue?

[1].
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg21006.html

Please let me know what else information you need.

Regards
Bhamu
___
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

Re: [Wien] Non-self consistent energy (not just W2k)

[Dr. K. C. Bhamu]

for a A2B2C2 type system with QE:
 total energy  =   -1357.88091041 Ry
 total energy  =   -1357.85377314 Ry
 total energy  =   -1357.86434311 Ry
 total energy  =   -1357.86441629 Ry
 total energy  =   -1357.86446505 Ry
 total energy  =   -1357.86446579 Ry
 total energy  =   -1357.86446651 Ry
 total energy  =   -1357.86446653 Ry
 total energy  =   -1357.86446655 Ry
 total energy  =   -1357.86446655 Ry
 total energy  =   -1357.86446655 Ry
*!total energy  =   -1357.86446655 Ry# Final Energy*

On Tue, Feb 1, 2022 at 1:46 AM Tran, Fabien 
wrote:

> Same with VASP (diamond with PBE):
>   free energyTOTEN  =-1.21275660 eV
>   free energyTOTEN  =   -18.71976229 eV
>   free energyTOTEN  =   -18.82704051 eV
>   free energyTOTEN  =   -18.82722009 eV
>   free energyTOTEN  =   -18.82722027 eV
>   free energyTOTEN  =   -18.34948885 eV
>   free energyTOTEN  =   -18.18874460 eV
>   free energyTOTEN  =   -18.19001031 eV
>   free energyTOTEN  =   -18.19002618 eV
>   free energyTOTEN  =   -18.19003899 eV
>   free energyTOTEN  =   -18.19003886 eV
>   free energyTOTEN  =   -18.19003886 eV
>
> 
> From: Wien  on behalf of Peter
> Blaha 
> Sent: Monday, January 31, 2022 4:53 PM
> To: wien@zeus.theochem.tuwien.ac.at
> Subject: Re: [Wien] Non-self consistent energy (not just W2k)
>
> In WIEN2k the total energy does not go to a minimum during scf, but even
> more negative values can occur during scf.
>
> It would be interesting to know if this is the same in other codes or not.
>
> grep :ene 5_default.scf
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.61390837 <
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50214748
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50211022
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50200377
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50748913
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51004385
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51010217
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51073277
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51072611
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51066136
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51216359 <
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51034576
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50887600
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840575
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840424
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840424 <
>
>
> Am 31.01.2022 um 15:23 schrieb Laurence Marks:
> In Wien2k the total energy is calculated in part from the current density,
> in part from the density of the orbitals that solve the KS equation. As
> such it is not a true variational energy except when the density is
> converged. [1]
>
> For other dft codes (not wavefunction codes [2]), is it the same, e.g.
> Vasp, QE, ab-init? Responses welcome, either via the list of directly.
>
> [1] There are technically ways one could calculate some form of
> variational energy, but it would require extra steps and to my knowledge
> has never looked useful so is not in the code.
> [2] In wavefunction codes where one varies the occupancy the energy is
> typically variational I think.
>
> --
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought" Albert Szent-Györgyi
>
>
>
> ___
> 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
>
>
> --
> ---
> Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-158801165300
> Email: peter.bl...@tuwien.ac.at
> WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.at
> -
> ___
> 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

Re: [Wien] Non-self consistent energy (not just W2k)

[Dr. K. C. Bhamu]

VASP (SiGe2N4):
  free energyTOTEN  =   290.13702589 eV
  free energyTOTEN  =   -76.80006711 eV
  free energyTOTEN  =   -97.38095302 eV
  free energyTOTEN  =   -97.83342560 eV
  free energyTOTEN  =   -97.84185451 eV
  free energyTOTEN  =   -97.84222510 eV
  free energyTOTEN  =   -97.84223081 eV
  free energyTOTEN  =   -97.84223105 eV
  free energyTOTEN  =   -97.84223106 eV
  free energyTOTEN  =   -97.84223106 eV

On Tue, Feb 1, 2022 at 1:46 AM Tran, Fabien 
wrote:

> Same with VASP (diamond with PBE):
>   free energyTOTEN  =-1.21275660 eV
>   free energyTOTEN  =   -18.71976229 eV
>   free energyTOTEN  =   -18.82704051 eV
>   free energyTOTEN  =   -18.82722009 eV
>   free energyTOTEN  =   -18.82722027 eV
>   free energyTOTEN  =   -18.34948885 eV
>   free energyTOTEN  =   -18.18874460 eV
>   free energyTOTEN  =   -18.19001031 eV
>   free energyTOTEN  =   -18.19002618 eV
>   free energyTOTEN  =   -18.19003899 eV
>   free energyTOTEN  =   -18.19003886 eV
>   free energyTOTEN  =   -18.19003886 eV
>
> 
> From: Wien  on behalf of Peter
> Blaha 
> Sent: Monday, January 31, 2022 4:53 PM
> To: wien@zeus.theochem.tuwien.ac.at
> Subject: Re: [Wien] Non-self consistent energy (not just W2k)
>
> In WIEN2k the total energy does not go to a minimum during scf, but even
> more negative values can occur during scf.
>
> It would be interesting to know if this is the same in other codes or not.
>
> grep :ene 5_default.scf
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.61390837 <
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50214748
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50211022
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50200377
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50748913
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51004385
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51010217
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51073277
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51072611
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51066136
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51216359 <
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51034576
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50887600
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840575
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840424
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840424 <
>
>
> Am 31.01.2022 um 15:23 schrieb Laurence Marks:
> In Wien2k the total energy is calculated in part from the current density,
> in part from the density of the orbitals that solve the KS equation. As
> such it is not a true variational energy except when the density is
> converged. [1]
>
> For other dft codes (not wavefunction codes [2]), is it the same, e.g.
> Vasp, QE, ab-init? Responses welcome, either via the list of directly.
>
> [1] There are technically ways one could calculate some form of
> variational energy, but it would require extra steps and to my knowledge
> has never looked useful so is not in the code.
> [2] In wavefunction codes where one varies the occupancy the energy is
> typically variational I think.
>
> --
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought" Albert Szent-Györgyi
>
>
>
> ___
> 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
>
>
> --
> ---
> Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-158801165300
> Email: peter.bl...@tuwien.ac.at
> WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.at
> -
> ___
> 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

Re: [Wien] Non-self consistent energy (not just W2k)

[Dr. K. C. Bhamu]

In quantum espresso, it reach the minimum energy.

I run few calculations with VASP as well and I noticed minimum energy at
the end.

I am having similar experience with Wien2k.
I didn't ask the form as I was observing this trend for most the systems so
I thought it is related with approach used in the Wien2k .

Regards
Bhamu
On Tue, Feb 1, 2022, 12:53 AM Peter Blaha 
wrote:

> In WIEN2k the total energy does not go to a minimum during scf, but even
> more negative values can occur during scf.
>
> It would be interesting to know if this is the same in other codes or not.
>
> grep :ene 5_default.scf
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.61390837 <
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50214748
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50211022
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50200377
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50748913
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51004385
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51010217
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51073277
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51072611
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51066136
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51216359 <
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.51034576
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50887600
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840575
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840424
> :ENE  : ** TOTAL ENERGY IN Ry =   -14900.50840424 <
>
> Am 31.01.2022 um 15:23 schrieb Laurence Marks:
>
> In Wien2k the total energy is calculated in part from the current density,
> in part from the density of the orbitals that solve the KS equation. As
> such it is not a true variational energy except when the density is
> converged. [1]
>
> For other dft codes (not wavefunction codes [2]), is it the same, e.g.
> Vasp, QE, ab-init? Responses welcome, either via the list of directly.
>
> [1] There are technically ways one could calculate some form of
> variational energy, but it would require extra steps and to my knowledge
> has never looked useful so is not in the code.
> [2] In wavefunction codes where one varies the occupancy the energy is
> typically variational I think.
>
> --
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought" Albert Szent-Györgyi
>
> ___
> Wien mailing 
> listw...@zeus.theochem.tuwien.ac.athttp://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
>
> --
> ---
> Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-158801165300
> Email: peter.bl...@tuwien.ac.at
> WWW:   http://www.imc.tuwien.ac.at  WIEN2k: http://www.wien2k.at
> -
>
> ___
> 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

Re: [Wien] mstar: Error: dM is not finite

[Dr. K. C. Bhamu]

Thanks Gavin,
I will double check it.

Regards
Bhamu

On Mon, Dec 6, 2021, 8:16 PM Gavin Abo  wrote:

> Based on the error message, it looks like it is/was caused by a typo.
>
> Probably there is
>
> WIEN2k after May 2020 (the case.mommat2 file is not a fixed format)
>
> However, it may be missing the ! to be a comment line
>
> ! WIEN2k after May 2020 (the case.mommat2 file is not a fixed format)
> On 12/6/2021 2:34 AM, Dr. K. C. Bhamu wrote:
>
> Thanks Gavin,
>
> If I change those lines and compile them, then I am getting the below
> mentioned syntax error. I think I did not make any mistake about the line
> indent.
>
> read_mommat_pij.f90(47): error #5082: Syntax error, found IDENTIFIER
> 'AFTER' when expecting one of: ( : % [ . = =>
> WIEN2k after May 2020 (the case.mommat2 file is not a fixed format)
> ---^
> compilation aborted for read_mommat_pij.f90 (code 1)
> make: *** [read_mommat_pij.o] Error 1
>
> Regards
> Bhamu
>
> On Mon, Dec 6, 2021 at 12:53 AM Gavin Abo  wrote:
>
>> According to the README.md at [1], read_mommat_pij.f90 has to be modified
>> for WIEN2k 19.1.  Did you do that?  If you didn't do that it might explain
>> why your dEij(n,k) and dEij(m,k) values are both zero.
>>
>> In the mstar.f90 source code (from lines 422 and 423) [2], you can see
>> that dE needs to be non-zero to have a computed value for dM.  If dE is
>> zero then it causes a divide by zero [3] that is an incomputable computer
>> mathematical operation such that dM would be undefined (which is why the
>> "Error: dM is not finite").
>>
>> line 422: dE = -dEij(n,k)/2 -dEij(m,k)/2
>> line 423: dM = p2/dE
>> [1] https://github.com/rubel75/mstar
>> [2] https://github.com/rubel75/mstar/blob/master/mstar.f90
>> [3] https://www.math.utah.edu/~pa/math/0by0.html
>>
>> On 12/5/2021 1:30 AM, Dr. K. C. Bhamu wrote:
>>
>> Dear Prof. Oleg,
>> I am running mstar with Wien2k_19.1 with PBE+SO (2 kpt, rkmax=8, lvns
>> =6).
>> I am getting ebelow error:
>>
>>  KP: 1876 bands: 856 progress:  75%
>>  KP: 1877 bands: 854 progress:  75%
>>  ikpt =  1878
>>  n =39
>>  k =40
>>  m =39
>>  alpha = 1
>>  beta = 1
>>  pij(alpha,n,k) = (-3.6972599E-06,1.5258900E-06)
>>  pij(beta,k,m) = (-3.6972599E-06,-1.5258900E-06)
>>  pij(beta,n,k) = (-3.6972599E-06,1.5258900E-06)
>>  pij(alpha,k,m) = (-3.6972599E-06,-1.5258900E-06)
>>  dEij(n,k) =  0.000E+00
>>  dEij(m,k) =  0.000E+00
>>  dM =  (-Infinity,NaN)
>>  dE =   0.000E+00
>>  p2 =  (3.1996142E-11,0.000E+00)
>> Error: dM is not finite
>>
>> Should I do a fresh calculation with less number of k-points or the error
>> is about something else?
>> Let me know if I need to share any files.
>>
>> Thanks and regards
>> Bhamu
>>
>> ___
> 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

Re: [Wien] mstar: Error: dM is not finite

[Dr. K. C. Bhamu]

with dEtol = 1e-3 I could finish it.

Thanks

On Mon, Dec 6, 2021 at 2:12 AM Rubel, Oleg  wrote:

> dE = 0 is very strange. This should no happen. Degenerate states (or
> nearly degenerate |dE| < dEtol) are sorted out from the beginning and
> treated separately within a degenerate perturbation theory to avoid "dM =
> p2/dE".
>
> What is your dEtol? (A meaningful value is 1e-4 ... 1e-6 Ry).  What
> happens if you raise dEtol? Do you mind sharing a link with the mommat file?
>
> Thank you
> Oleg
>
> 
> From: Wien  on behalf of
> Laurence Marks 
> Sent: Sunday, December 5, 2021 14:41
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] mstar: Error: dM is not finite
>
> Obviously the line should be something like
> dM = p2*dE/(dE*dE+1D-16)
>
> ---
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu<http://www.numis.northwestern.edu>
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought" Albert Szent-Györgyi
>
> On Sun, Dec 5, 2021, 7:23 PM Gavin Abo  gabo13...@gmail.com>> wrote:
>
> According to the README.md at [1], read_mommat_pij.f90 has to be modified
> for WIEN2k 19.1.  Did you do that?  If you didn't do that it might explain
> why your dEij(n,k) and dEij(m,k) values are both zero.
>
> In the mstar.f90 source code (from lines 422 and 423) [2], you can see
> that dE needs to be non-zero to have a computed value for dM.  If dE is
> zero then it causes a divide by zero [3] that is an incomputable computer
> mathematical operation such that dM would be undefined (which is why the
> "Error: dM is not finite").
>
> line 422: dE = -dEij(n,k)/2 -dEij(m,k)/2
> line 423: dM = p2/dE
>
> [1] https://github.com/rubel75/mstar<
> https://urldefense.com/v3/__https://github.com/rubel75/mstar__;!!Dq0X2DkFhyF93HkjWTBQKhk!A1M4TMzDqdChWXiSrMbJ6jpLdUmIOs0RXkqPT-_6ags-PpPXOBVrkJMCVKaWO_6TYYaogQ$
> >
> [2] https://github.com/rubel75/mstar/blob/master/mstar.f90<
> https://urldefense.com/v3/__https://github.com/rubel75/mstar/blob/master/mstar.f90__;!!Dq0X2DkFhyF93HkjWTBQKhk!A1M4TMzDqdChWXiSrMbJ6jpLdUmIOs0RXkqPT-_6ags-PpPXOBVrkJMCVKaWO_66qkrE4g$
> >
> [3] https://www.math.utah.edu/~pa/math/0by0.html<
> https://urldefense.com/v3/__https://www.math.utah.edu/*pa/math/0by0.html__;fg!!Dq0X2DkFhyF93HkjWTBQKhk!A1M4TMzDqdChWXiSrMbJ6jpLdUmIOs0RXkqPT-_6ags-PpPXOBVrkJMCVKaWO_5w-17Opg$
> >
>
> On 12/5/2021 1:30 AM, Dr. K. C. Bhamu wrote:
> Dear Prof. Oleg,
> I am running mstar with Wien2k_19.1 with PBE+SO (2 kpt, rkmax=8, lvns
> =6).
> I am getting ebelow error:
>
>  KP: 1876 bands: 856 progress:  75%
>  KP: 1877 bands: 854 progress:  75%
>  ikpt =  1878
>  n =39
>  k =40
>  m =39
>  alpha = 1
>  beta = 1
>  pij(alpha,n,k) = (-3.6972599E-06,1.5258900E-06)
>  pij(beta,k,m) = (-3.6972599E-06,-1.5258900E-06)
>  pij(beta,n,k) = (-3.6972599E-06,1.5258900E-06)
>  pij(alpha,k,m) = (-3.6972599E-06,-1.5258900E-06)
>  dEij(n,k) =  0.000E+00
>  dEij(m,k) =  0.000E+00
>  dM =  (-Infinity,NaN)
>  dE =   0.000E+00
>  p2 =  (3.1996142E-11,0.000E+00)
> Error: dM is not finite
>
> Should I do a fresh calculation with less number of k-points or the error
> is about something else?
> Let me know if I need to share any files.
>
> Thanks and regards
> Bhamu
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at<mailto:Wien@zeus.theochem.tuwien.ac.at>
>
> https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!A1M4TMzDqdChWXiSrMbJ6jpLdUmIOs0RXkqPT-_6ags-PpPXOBVrkJMCVKaWO_7JRfDjLw$
> SEARCH the MAILING-LIST at:
> https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!A1M4TMzDqdChWXiSrMbJ6jpLdUmIOs0RXkqPT-_6ags-PpPXOBVrkJMCVKaWO_6th4E_9Q$
> ___
> 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

Re: [Wien] mstar: Error: dM is not finite

[Dr. K. C. Bhamu]

Thanks Gavin,

If I change those lines and compile them, then I am getting the below
mentioned syntax error. I think I did not make any mistake about the line
indent.

read_mommat_pij.f90(47): error #5082: Syntax error, found IDENTIFIER
'AFTER' when expecting one of: ( : % [ . = =>
WIEN2k after May 2020 (the case.mommat2 file is not a fixed format)
---^
compilation aborted for read_mommat_pij.f90 (code 1)
make: *** [read_mommat_pij.o] Error 1

Regards
Bhamu

On Mon, Dec 6, 2021 at 12:53 AM Gavin Abo  wrote:

> According to the README.md at [1], read_mommat_pij.f90 has to be modified
> for WIEN2k 19.1.  Did you do that?  If you didn't do that it might explain
> why your dEij(n,k) and dEij(m,k) values are both zero.
>
> In the mstar.f90 source code (from lines 422 and 423) [2], you can see
> that dE needs to be non-zero to have a computed value for dM.  If dE is
> zero then it causes a divide by zero [3] that is an incomputable computer
> mathematical operation such that dM would be undefined (which is why the 
> "Error:
> dM is not finite").
>
> line 422: dE = -dEij(n,k)/2 -dEij(m,k)/2
> line 423: dM = p2/dE
> [1] https://github.com/rubel75/mstar
> [2] https://github.com/rubel75/mstar/blob/master/mstar.f90
> [3] https://www.math.utah.edu/~pa/math/0by0.html
>
> On 12/5/2021 1:30 AM, Dr. K. C. Bhamu wrote:
>
> Dear Prof. Oleg,
> I am running mstar with Wien2k_19.1 with PBE+SO (2 kpt, rkmax=8, lvns
> =6).
> I am getting ebelow error:
>
>  KP: 1876 bands: 856 progress:  75%
>  KP: 1877 bands: 854 progress:  75%
>  ikpt =  1878
>  n =39
>  k =40
>  m =39
>  alpha = 1
>  beta = 1
>  pij(alpha,n,k) = (-3.6972599E-06,1.5258900E-06)
>  pij(beta,k,m) = (-3.6972599E-06,-1.5258900E-06)
>  pij(beta,n,k) = (-3.6972599E-06,1.5258900E-06)
>  pij(alpha,k,m) = (-3.6972599E-06,-1.5258900E-06)
>  dEij(n,k) =  0.000E+00
>  dEij(m,k) =  0.000E+00
>  dM =  (-Infinity,NaN)
>  dE =   0.000E+00
>  p2 =  (3.1996142E-11,0.000E+00)
> Error: dM is not finite
>
> Should I do a fresh calculation with less number of k-points or the error
> is about something else?
> Let me know if I need to share any files.
>
> Thanks and regards
> Bhamu
>
> ___
> 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

Re: [Wien] mstar: Error: dM is not finite

[Dr. K. C. Bhamu]

Thanks Prof Oleg,
See my inlined answers.
On Mon, Dec 6, 2021 at 2:12 AM Rubel, Oleg  wrote:

>
> What is your dEtol? (A meaningful value is 1e-4 ... 1e-6 Ry).

I am using dEtol=1e-5


> What happens if you raise dEtol?

Let me check it. It takes nearly 1 hr to finish the post-processing and the
mommat file is 74GB large so I do not think I can share it with you by any
means.


Regards
Bhamu


Do you mind sharing a link with the mommat file?
>
> Thank you
> Oleg
>
> 
> From: Wien  on behalf of
> Laurence Marks 
> Sent: Sunday, December 5, 2021 14:41
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] mstar: Error: dM is not finite
>
> Obviously the line should be something like
> dM = p2*dE/(dE*dE+1D-16)
>
> ---
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu<http://www.numis.northwestern.edu>
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought" Albert Szent-Györgyi
>
> On Sun, Dec 5, 2021, 7:23 PM Gavin Abo  gabo13...@gmail.com>> wrote:
>
> According to the README.md at [1], read_mommat_pij.f90 has to be modified
> for WIEN2k 19.1.  Did you do that?  If you didn't do that it might explain
> why your dEij(n,k) and dEij(m,k) values are both zero.
>
> In the mstar.f90 source code (from lines 422 and 423) [2], you can see
> that dE needs to be non-zero to have a computed value for dM.  If dE is
> zero then it causes a divide by zero [3] that is an incomputable computer
> mathematical operation such that dM would be undefined (which is why the
> "Error: dM is not finite").
>
> line 422: dE = -dEij(n,k)/2 -dEij(m,k)/2
> line 423: dM = p2/dE
>
> [1] https://github.com/rubel75/mstar<
> https://urldefense.com/v3/__https://github.com/rubel75/mstar__;!!Dq0X2DkFhyF93HkjWTBQKhk!A1M4TMzDqdChWXiSrMbJ6jpLdUmIOs0RXkqPT-_6ags-PpPXOBVrkJMCVKaWO_6TYYaogQ$
> >
> [2] https://github.com/rubel75/mstar/blob/master/mstar.f90<
> https://urldefense.com/v3/__https://github.com/rubel75/mstar/blob/master/mstar.f90__;!!Dq0X2DkFhyF93HkjWTBQKhk!A1M4TMzDqdChWXiSrMbJ6jpLdUmIOs0RXkqPT-_6ags-PpPXOBVrkJMCVKaWO_66qkrE4g$
> >
> [3] https://www.math.utah.edu/~pa/math/0by0.html<
> https://urldefense.com/v3/__https://www.math.utah.edu/*pa/math/0by0.html__;fg!!Dq0X2DkFhyF93HkjWTBQKhk!A1M4TMzDqdChWXiSrMbJ6jpLdUmIOs0RXkqPT-_6ags-PpPXOBVrkJMCVKaWO_5w-17Opg$
> >
>
> On 12/5/2021 1:30 AM, Dr. K. C. Bhamu wrote:
> Dear Prof. Oleg,
> I am running mstar with Wien2k_19.1 with PBE+SO (2 kpt, rkmax=8, lvns
> =6).
> I am getting ebelow error:
>
>  KP: 1876 bands: 856 progress:  75%
>  KP: 1877 bands: 854 progress:  75%
>  ikpt =  1878
>  n =39
>  k =40
>  m =39
>  alpha = 1
>  beta = 1
>  pij(alpha,n,k) = (-3.6972599E-06,1.5258900E-06)
>  pij(beta,k,m) = (-3.6972599E-06,-1.5258900E-06)
>  pij(beta,n,k) = (-3.6972599E-06,1.5258900E-06)
>  pij(alpha,k,m) = (-3.6972599E-06,-1.5258900E-06)
>  dEij(n,k) =  0.000E+00
>  dEij(m,k) =  0.000E+00
>  dM =  (-Infinity,NaN)
>  dE =   0.000E+00
>  p2 =  (3.1996142E-11,0.000E+00)
> Error: dM is not finite
>
> Should I do a fresh calculation with less number of k-points or the error
> is about something else?
> Let me know if I need to share any files.
>
> Thanks and regards
> Bhamu
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at<mailto:Wien@zeus.theochem.tuwien.ac.at>
>
> https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!A1M4TMzDqdChWXiSrMbJ6jpLdUmIOs0RXkqPT-_6ags-PpPXOBVrkJMCVKaWO_7JRfDjLw$
> SEARCH the MAILING-LIST at:
> https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!A1M4TMzDqdChWXiSrMbJ6jpLdUmIOs0RXkqPT-_6ags-PpPXOBVrkJMCVKaWO_6th4E_9Q$
> ___
> 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] mstar: Error: dM is not finite

[Dr. K. C. Bhamu]

Dear Prof. Oleg,
I am running mstar with Wien2k_19.1 with PBE+SO (2 kpt, rkmax=8, lvns
=6).
I am getting ebelow error:

 KP: 1876 bands: 856 progress:  75%
 KP: 1877 bands: 854 progress:  75%
 ikpt =  1878
 n =39
 k =40
 m =39
 alpha = 1
 beta = 1
 pij(alpha,n,k) = (-3.6972599E-06,1.5258900E-06)
 pij(beta,k,m) = (-3.6972599E-06,-1.5258900E-06)
 pij(beta,n,k) = (-3.6972599E-06,1.5258900E-06)
 pij(alpha,k,m) = (-3.6972599E-06,-1.5258900E-06)
 dEij(n,k) =  0.000E+00
 dEij(m,k) =  0.000E+00
 dM =  (-Infinity,NaN)
 dE =   0.000E+00
 p2 =  (3.1996142E-11,0.000E+00)
Error: dM is not finite

Should I do a fresh calculation with less number of k-points or the error
is about something else?
Let me know if I need to share any files.

Thanks and regards
Bhamu
___
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

Re: [Wien] Doubts regarding the volume optimization of a triclinic cell

[Dr. K. C. Bhamu]

Dear Anupriya,
I would first do a full optimization (vc-relax) in other code (VASP/QE) for
such a large system and then using this fully optimized structure, I will
do an ion relaxation (run_lapw  -min) in Wien2k.

If you want to do everything using Wien2k, please follow Prof. Peter's
response.

Happy computing

Regards
Bhamu

On Sat, Oct 23, 2021, 3:27 AM Peter Blaha 
wrote:

> A full optimization of a bigger triclinic structure is hardly possible
> with WIEN2k.
>
> It depends a lot on what the purpose of your calculations is, but:
>
> a) Most importantly, optimize the position of the atoms using the
> forces:   run_lapw  -min ...
>
> b)  eventually I'd next do a volume optimization (x optimize, option 1)
> Do not forget the   -min switch in run_lapw, otherwise the results are
> nonsense. Volume changes give the largest change in E-tot.
> Note, that other separate options of x optimize are rather useless for
> this purpose. One cannot optimize alpha,beta,gamma for fixed a,b,c. This
> is nonsense.
>
> c) eventually you may use   optimize_abc_lapw -t 3 ...
> This optimizes a,b,c independently but simultaneously. Again don't
> forget the -min switch.
>
> For such a large cell, such calculations can be very time consuming when
> you do not use well adapted parameters (RKmax, k-points) and a good
> parallelization strategy on a sufficient number of cores.
>
> Am 22.10.2021 um 04:54 schrieb Anupriya Nyayban:
> > Dear users and experts,
> >
> > I have a triclinic structure (P1 space group) with lattice parameters
> > a=18.508, b=39.835, c=40.199 Bohr; α = 119.701 ◦ , β = 103.309 ◦ , γ =
> > 90.0 ◦.  I have the following doubts
> > 1) The volume obtained with these lattice parameters as well angles
> > (with the formula for triclinic cell) is not the same as the volume
> > (24823.466 Bohr^3) found in the scf file (VOL).
> > 2) The mailing list suggests volume optimization by a) varying a, b, c
> > while α, β, γ are constant; b) varying α, β, γ with fixed a, b, c. I
> > have done volume optimization by varying volume with constant a:b:c. But
> > I am not able to find the suitable switch for the case b) in the
> > optimize.job script.
> > Your valuable suggestion is highly appreciated!!
> >
> > Thank you!!
> > --
> > With regards
> > Anupriya Nyayban
> > Ph.D. Scholar
> > Department of Physics
> > NIT Silchar
> >
> > ___
> > 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
> >
>
> --
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
> Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
> WWW:   http://www.imc.tuwien.ac.at
> -
> ___
> 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

Re: [Wien] Top surface layer seems to be isolated from the rest of the system

[Dr. K. C. Bhamu]

Dear Prof. Marks,
I got the detailed information from my experimental colleague later got to
know that the stoichiometry of my system is WO_(3-x) not WO_3. Having some
Oxygen deficiency on the surface layer stabilized the surface. There are
similar reports available in the literature as well which supports my
calculations.
Thanks for all of your responses.
My reply is just to update the thread so that later it can be useful for
someone who deals similar problem.

Regards
Bhamu




On Fri, Jun 25, 2021 at 11:40 PM Laurence Marks 
wrote:

> Agreed, although to make the bulk truncation valence neutral involves W 5+
> which is unusual. As you say, the O "sticking out" is unreal, as it would
> be 1-. If it moves closer to the W below that becomes 7+ which is silly.
>
> The first thing to do is work out what the actual experimental conditions
> are -- air, UHV, some catalytic gas mix, unknown. Then you can start to
> construct relevant models.It is easy to construct bad models!
>
> N.B., remember that STO/LAO is constrained, and forced to be different if
> there are no O vacancies.
>
> On Fri, Jun 25, 2021 at 9:20 AM Peter Blaha 
> wrote:
>
>> A W atom could have other formal valencies than 6+ and an electronic
>> reconstruction is not impossible (remember the famous LAO/STO interface)
>>
>> Of course the surface depends a lot on the preparation conditions and on
>> the vacuum / O partial pressure, H2O traces (or even "water") ...
>> There could be several possible surface reconstructions. Thus you can
>> try various supercells with W vacancies to reduce the formal 2+ charge)
>> or some O on top (but I don't like this "sticking out").
>> Finally do the thermodynamics and calculate a surface phase diagram as
>> function of O partial pressure.
>>
>> In any case, I hope you have followed what Ludmilla said and use the
>> theoretical lattice parameter (just in case- it could be much larger
>> with PBE than experiment).
>>
>> And clear is: if the surface layer lifts off, it is a clear indication
>> that your model is very "unrealistic".
>>
>> Am 25.06.2021 um 14:43 schrieb Laurence Marks:
>> > Sorry Peter, that is also wrong.
>> >
>> > The valence of a WO2 layer is 2+ ; of the O layer 2-. A valence neutral
>> > surface comes from
>> > a) Adding OH above every W -- 1-
>> > b) Add 1/2 the O above, and letting the structure relax in a 2x1 cell
>> > (or larger) -- the last layer has a valence of 1- per 1x1
>> > c) Adjusting a top WO2 layer so it has a valence of 1+ per 1x1 (tricky)
>> >
>> > Note: a) is for wet samples (in air); b) more common for dry but only
>> if
>> > the top O can adequately bond; c) less common but not impossible. There
>> > is some literature, but I expect many of the existing calculations are
>> > dodgy.
>> >
>> > _
>> > Professor Laurence Marks
>> > "Research is to see what everybody else has seen, and to think what
>> > nobody else has thought", Albert Szent-Györgyi
>> > http://www.numis.northwestern.edu 
>> >
>> > On Fri, Jun 25, 2021, 07:16 Peter Blaha > > > wrote:
>> >
>> > Remove the O atoms, which are sticking out of the lower surface.
>> > This makes the system inversion symmetric and more realistic.
>> > Since you are now not stoichiometric anymore, eventually test with
>> more
>> > than 5 layers .
>> >
>> >
>
> --
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought" Albert Szent-Györgyi
> ___
> 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

Re: [Wien] Activation Energy

[Dr. K. C. Bhamu]

Dear Shamik,

Please check with CI-NEB. Well implemented with Quantum Espresso.
You may need to read some literature as well.

Regards
Bhamu

On Tue, Jul 20, 2021, 8:33 PM Laurence Marks 
wrote:

> No, very very no!
>
> Please look up what activation energy is.
> _
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Györgyi
> www.numis.northwestern.edu
>
> On Tue, Jul 20, 2021, 06:26 shamik chakrabarti 
> wrote:
>
>> Dear Prof. Laurence,
>>
>> Thank you for your response. If I know the initial &
>> final step & if we just check the difference in energy of those two steps,
>> whether the difference in energy can be taken as activation energy?
>>
>> with regards,
>>
>> On Tue, 20 Jul 2021 at 16:51, Laurence Marks 
>> wrote:
>>
>>> If you can isolate the transition state, e.g. by symmetry, then you can
>>> do it directly. Otherwise there is no NEB currently in Wien2k.
>>>
>>> _
>>> Professor Laurence Marks
>>> "Research is to see what everybody else has seen, and to think what
>>> nobody else has thought", Albert Szent-Györgyi
>>> www.numis.northwestern.edu
>>>
>>> On Tue, Jul 20, 2021, 06:03 shamik chakrabarti 
>>> wrote:
>>>
 Dear Wien2k users,

 Is it possible to compute the activation energy of
 hopping of Li/Na in an electrode material by using wien2k?

 Any response will be appreciated.

 with regards,

 --
 Dr. Shamik Chakrabarti
 Research Fellow
 Department of Physics
 Indian Institute of Technology Patna
 Bihta-801103
 Patna
 Bihar, India
 ___
 Wien mailing list
 Wien@zeus.theochem.tuwien.ac.at

 https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!E-mAlwcdz4l5Zw6rqxsiqF3rXp9BBUcjH2BJpyTJDU2Q1dqsN7eEuGEK2n7lU-wnXPdfCg$
 SEARCH the MAILING-LIST at:
 https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!E-mAlwcdz4l5Zw6rqxsiqF3rXp9BBUcjH2BJpyTJDU2Q1dqsN7eEuGEK2n7lU-wSHLR63g$

>>> ___
>>> 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
>>> 
>>>
>>
>>
>> --
>> Dr. Shamik Chakrabarti
>> Research Fellow
>> Department of Physics
>> Indian Institute of Technology Patna
>> Bihta-801103
>> Patna
>> Bihar, India
>> ___
>> Wien mailing list
>> Wien@zeus.theochem.tuwien.ac.at
>>
>> https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!Gq7L9mqAtTCwzBhpqGJvnCwpydqJl72PuAxNJly-vI8CfdR9HnBoJkj_g4SG19Ryisd69Q$
>> SEARCH the MAILING-LIST at:
>> https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!Gq7L9mqAtTCwzBhpqGJvnCwpydqJl72PuAxNJly-vI8CfdR9HnBoJkj_g4SG19RvTUXigw$
>>
> ___
> 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

Re: [Wien] Top surface layer seems to be isolated from the rest of the system

[Dr. K. C. Bhamu]

Thank you Prof. Peter for your good suggestion.

I have tried with passivating the bottom oxygen atoms that I consider equal
to removing those oxygen atoms.

I tried with 6 layers as well. I don't think more than 6 layers will fix
the problem.

Thank you,
Bhamu

On Fri, Jun 25, 2021, 9:16 PM Peter Blaha 
wrote:

> Remove the O atoms, which are sticking out of the lower surface.
> This makes the system inversion symmetric and more realistic.
> Since you are now not stoichiometric anymore, eventually test with more
> than 5 layers .
>
> Am 25.06.2021 um 13:42 schrieb Dr. K. C. Bhamu:
> > Dear Prof. L. Marks,
> > Thanks for your suggestions.  Yes, WO3 is an insulator.
> >
> > I am facing the same issue for WC (SG: 187).
> >
> > I have worked on Ni(OH)2 and ZnO surfaces and I did not face any
> > difficulties there. Ni(OH) surface is also polar.
> >
> > For the present case, I do not have much choice. I was asked to provide
> > the absorbance of some molecules on the (100) surface of WO3. The
> > experimental group is not using any substrate/support for it.
> >
> > I will read up on oxide surfaces.
> >
> > Thank you very much,
> > Bhamu
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Jun 25, 2021 at 12:46 PM Laurence Marks
> > mailto:laurence.ma...@gmail.com>> wrote:
> >
> > N.B., your cell is polar, and you are not satisfying valence
> > neutrality or Pauling's rules. It will never occur in reality, and
> > any results you obtain with it will move science backwards.
> >
> > Read up on oxide surfaces, much is known.
> >
> > _
> > Professor Laurence Marks
> > "Research is to see what everybody else has seen, and to think what
> > nobody else has thought", Albert Szent-Györgyi
> > www.numis.northwestern.edu <http://www.numis.northwestern.edu>
> >
> > On Fri, Jun 25, 2021, 01:59 Laurence Marks  > <mailto:laurence.ma...@gmail.com>> wrote:
> >
> > Did you check:
> > a) The BVS, to ensure that you do not have a GIGO surface?
> > b) Whether the system has a decent gap or not -- I believe WO3
> > should be an insulator.
> > c) Whether you are satisfying valence neutrality at the surface.
> >
> > I expect you have a GIGO surface, 99.99% probability. You cannot
> > just create an oxide supercell and expect it to lead to a
> > realistic surface. Fixing layers won't help, and is flawed
> thinking.
> >
> > GIGO.
> >
> > _
> > Professor Laurence Marks
> > "Research is to see what everybody else has seen, and to think
> > what nobody else has thought", Albert Szent-Györgyi
> > www.numis.northwestern.edu <http://www.numis.northwestern.edu>
> >
> > On Fri, Jun 25, 2021, 01:31 Dr. K. C. Bhamu  > <mailto:kcbham...@gmail.com>> wrote:
> >
> > Dear Wien2k Users,
> >
> > I am trying to relax the WO3 surface structure (1x1x5 with
> > 15 Ang vacuum). The bulk structure crystallizes in  221 SG.
> > Then I created the 1x1x5 layered structure and relaxed the
> > top two layers with the bottom three layers kept fixed.
> > I see after relaxation, the top layer detached from the
> > system (the W-O bond length increased from 1.9 to 2.3 Ang),
> > you can see from the PDF provided with this email.
> > I have tried with QE as well and the same problem I faced
> there.
> > I am wondering if someone has faced a similar experience and
> > would like to share his/her experience with me to tackle
> > this issue.
> >
> > I have used a different strategy: with U, with U, with
> > dipole correction, without dipole correction, vacuum up
> > to 30Ang.
> >
> > As the bulk system is a high symmetry system, is it the
> > reason due to the symmetry? If so then how one can handle it?
> >
> > I am providing the required information here in the tar
> > file  (PLEASE DOWNLOAD FROM HERE
> > <
> https://urldefense.com/v3/__https://we.tl/t-0vedkrUS54__;!!Dq0X2DkFhyF93HkjWTBQKhk!Day7KZQBXQaPn8HGxSpldvOiJzObtS73z_8I17izzlA5ZmuvSj27rMzSsjCo-bt6MCzNAQ$
> >).
> >
> > I would appreciate it if someone shares their experience

Re: [Wien] Top surface layer seems to be isolated from the rest of the system

[Dr. K. C. Bhamu]

Dear Prof. L. Marks,
Thanks for your suggestions.  Yes, WO3 is an insulator.

I am facing the same issue for WC (SG: 187).

I have worked on Ni(OH)2 and ZnO surfaces and I did not face any
difficulties there. Ni(OH) surface is also polar.

For the present case, I do not have much choice. I was asked to provide the
absorbance of some molecules on the (100) surface of WO3. The experimental
group is not using any substrate/support for it.

I will read up on oxide surfaces.

Thank you very much,
Bhamu








On Fri, Jun 25, 2021 at 12:46 PM Laurence Marks 
wrote:

> N.B., your cell is polar, and you are not satisfying valence neutrality or
> Pauling's rules. It will never occur in reality, and any results you obtain
> with it will move science backwards.
>
> Read up on oxide surfaces, much is known.
>
> _
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Györgyi
> www.numis.northwestern.edu
>
> On Fri, Jun 25, 2021, 01:59 Laurence Marks 
> wrote:
>
>> Did you check:
>> a) The BVS, to ensure that you do not have a GIGO surface?
>> b) Whether the system has a decent gap or not -- I believe WO3 should be
>> an insulator.
>> c) Whether you are satisfying valence neutrality at the surface.
>>
>> I expect you have a GIGO surface, 99.99% probability. You cannot just
>> create an oxide supercell and expect it to lead to a realistic surface.
>> Fixing layers won't help, and is flawed thinking.
>>
>> GIGO.
>>
>> _
>> Professor Laurence Marks
>> "Research is to see what everybody else has seen, and to think what
>> nobody else has thought", Albert Szent-Györgyi
>> www.numis.northwestern.edu
>>
>> On Fri, Jun 25, 2021, 01:31 Dr. K. C. Bhamu  wrote:
>>
>>> Dear Wien2k Users,
>>>
>>> I am trying to relax the WO3 surface structure (1x1x5 with 15 Ang
>>> vacuum). The bulk structure crystallizes in  221 SG.
>>> Then I created the 1x1x5 layered structure and relaxed the top two
>>> layers with the bottom three layers kept fixed.
>>> I see after relaxation, the top layer detached from the system (the W-O
>>> bond length increased from 1.9 to 2.3 Ang), you can see from the PDF
>>> provided with this email.
>>> I have tried with QE as well and the same problem I faced there.
>>> I am wondering if someone has faced a similar experience and would like
>>> to share his/her experience with me to tackle this issue.
>>>
>>> I have used a different strategy: with U, with U, with dipole
>>> correction, without dipole correction, vacuum up to 30Ang.
>>>
>>> As the bulk system is a high symmetry system, is it the reason due to
>>> the symmetry? If so then how one can handle it?
>>>
>>> I am providing the required information here in the tar file  (PLEASE
>>> DOWNLOAD FROM HERE
>>> <https://urldefense.com/v3/__https://we.tl/t-0vedkrUS54__;!!Dq0X2DkFhyF93HkjWTBQKhk!Day7KZQBXQaPn8HGxSpldvOiJzObtS73z_8I17izzlA5ZmuvSj27rMzSsjCo-bt6MCzNAQ$>
>>> ).
>>>
>>> I would appreciate it if someone shares their experience with me.
>>>
>>> Regards
>>> Bhamu
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Wien mailing list
>>> Wien@zeus.theochem.tuwien.ac.at
>>>
>>> https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!Day7KZQBXQaPn8HGxSpldvOiJzObtS73z_8I17izzlA5ZmuvSj27rMzSsjCo-btL6FGi9Q$
>>> SEARCH the MAILING-LIST at:
>>> https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!Day7KZQBXQaPn8HGxSpldvOiJzObtS73z_8I17izzlA5ZmuvSj27rMzSsjCo-btzLCeneQ$
>>>
>> ___
> 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] Top surface layer seems to be isolated from the rest of the system

[Dr. K. C. Bhamu]

Dear Wien2k Users,

I am trying to relax the WO3 surface structure (1x1x5 with 15 Ang vacuum).
The bulk structure crystallizes in  221 SG.
Then I created the 1x1x5 layered structure and relaxed the top two layers
with the bottom three layers kept fixed.
I see after relaxation, the top layer detached from the system (the W-O
bond length increased from 1.9 to 2.3 Ang), you can see from the PDF
provided with this email.
I have tried with QE as well and the same problem I faced there.
I am wondering if someone has faced a similar experience and would like to
share his/her experience with me to tackle this issue.

I have used a different strategy: with U, with U, with dipole correction,
without dipole correction, vacuum up to 30Ang.

As the bulk system is a high symmetry system, is it the reason due to
the symmetry? If so then how one can handle it?

I am providing the required information here in the tar file  (PLEASE
DOWNLOAD FROM HERE ).

I would appreciate it if someone shares their experience with me.

Regards
Bhamu
___
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

Re: [Wien] about the mstar program

[Dr. K. C. Bhamu]

Hii Ramazan
You can search my recent query about mstar.
Maybe you will find sufficient information there.

Regards
Bhamu


On Wed, Mar 24, 2021 at 9:47 AM Ramazan KATIRCI 
wrote:

> Dear Wien2k users
>
> I read the article of "Perturbation approach to ab initio effective mass
> calculations" completely and carefully. I implemented all the instructions
> in it to compare the results. But the data I acquired in minv-ij-up.data is
> different from the data presented in the article. Firstly I used default
> parameters in the bash file of mstar (E-max = 7  .inso file and Emax =10 in
> .in1 file). As I say the outputs in the minv_ij-up is completely different.
> Later, I changed the parameters of E-max=5 Ry .inso file and E-max=5  .in1
> file as specified in the article. the outputs is  different again. Although
> I used the the same parameters as the article, why the results are so
> different. Actually I want this method to compare the effective mass with
> parabolic approximation method.
>
> I have the other question. When I examined the minv_d-up.data and
> minv_c-up files, How can I understant which k points and band corresponding
> to the lowest conduction band and highest valance band.
>
> The bash and minv-ij-up files were shared with this link above;
>
>
> https://drive.google.com/drive/folders/1wkOCXyz__oLWz98cgrGUk3cLP2NCfzVB?usp=sharing
>
>
> Thank you in advance for your help
>
> Best regards
> Ramazan Katırcı
> ___
> 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

Re: [Wien] about effective mass

[Dr. K. C. Bhamu]

You can use Wien2k_19.1 too. You need to specify the path of mstar code.

Bhamu

On Fri, Mar 19, 2021 at 9:43 AM Ramazan KATIRCI 
wrote:

> Sorry, I forgot to send th name of the article: Its name is "Perturbation
> approach to ab initio e ective mass calculations"
>
> - Original Message -
> From: "Ramazan KATIRCI" 
> To: "wien" 
> Sent: Friday, March 19, 2021 7:11:57 AM
> Subject: Re: [Wien] about effective mass
>
> In the article below, it says hat WIEN2k version 20.1 wasused. This
> version is not availabe on the website. I could not find this version.
> Where can I find it.
>
> Best regards
>
>
> - Original Message -
> From: "Rubel, Oleg" 
> To: "wien" 
> Sent: Thursday, March 18, 2021 11:27:40 PM
> Subject: Re: [Wien] about effective mass
>
> It can be related to "WIEN2k compatibility note" in README.md (
> https://github.com/rubel75/mstar)
>
> 
> From: Wien  on behalf of Ramazan
> KATIRCI 
> Sent: Thursday, March 18, 2021 13:36
> To: wien
> Subject: Re: [Wien] about effective mass
>
> Hello,
>
> Thank you so much, your suggesions about the scratch solved my problem.
> But another problem emerged. I added the bash output error below. This
> problem emerged when the mstar program run. The other script (scf, optic
> etc.) completed normally. Thank you in advance for your help.
>
> The bash output:
>  The input file w2_3.mommat2up was found.
>   number of lines in mommat file = 327804
>  Entering the main loop...
>  ERROR reading the line from mommat file containing
>   1   1-0.129114E-16-0.348249E-10 0.671895E-17-0.174125E-10
> 0.313031E-16-0.174125E-10   0.
> line number 5
>  while expecting something like this
>   1  32 0.270604E-02 0.659085E-03
> 0.555417E-03-0.308709E-02-0.132694E-11-0.600436E-11   2.35217055
> (base) -bash-4.2$
>
>
> Sincerely
> Ramazan
> ___
> 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
>
___
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

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Dear Prof. Oleg
Thank you for your patience for my query.
Here is my script to calculate mstar [1] from a successfully finished mstar
calculation.

This is for Si only. For other systems, some parameters need to be tuned.
I am not a good programmer, so the script may not look in good format.

[1]. https://we.tl/t-SYldxNNner


Thank you
Bhamu


On Thu, Mar 11, 2021 at 4:26 AM Rubel, Oleg  wrote:

> I am glad Si worked out. Sorry, Bhamu. You need to figure it out even if
> it takes more time. When searching through eigenvalues, keep in mind the
> number of digits. For instance, 0.383706 from case.scf can appear as
> 0.3837058 in the eigenvalue file.
>
> All the best
> Oleg
>
> 
> From: Wien  on behalf of Dr. K.
> C. Bhamu 
> Sent: Wednesday, March 10, 2021 11:50
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Oleg
> I tried to follow your advice and it worked for Si case. I found VBM at
> #KP1 and CBM at #KP15. The band index edges were matched with the
> particular KP in case.energyso.
>
> But In my case, I could not find the VBM/CBM edges either in case.eneryso
> or in case.bands.agr/spagetti_ene.
>
> I finished two different calculations (with shifted k-mesh and unshifted
> k-mesh) and both can be downloaded from [1].
> [1] https://we.tl/t-Mhv6nv4Zlf
>
> I would be grateful to you, if you can suggest me #KP's with respect to
> VBM/CBM.
> CBM is not exactly on high-symmetry  k-point.
>
>
> Thank you
> Bhamu
>
>
> On Tue, Mar 9, 2021 at 11:13 PM Rubel, Oleg  rub...@mcmaster.ca>> wrote:
> Dear Bhamu,
>
> to get a VBM k-point index, you would need to look for "0.383706" in your
> case.energyso and see which k-point this eigenvalue belongs to. For CBE,
> look for "0.401998" (it can be a different k-point).
>
> In Si VBM is at Gamma, and CBM is far away from Gamma. Thus we have two
> different k-points. After some trials, I found that 7x7x7 unshifted k-mesh
> "hits" CBM of Si quite precisely.
>
> Of course you need to be confident that the selected k-mesh "hits" the
> relevant extremum (extrema) of your band structure. For instance if you
> need Gamma, do not select a shifted mesh. When the extremum is away from
> the high-symmetry points and coordinates are known, it might be easier to
> use case.klist_band and target the point(s) of interest.
>
> I hope it helps
> Oleg
>
> 
> From: Wien  wien-boun...@zeus.theochem.tuwien.ac.at>> on behalf of Dr. K. C. Bhamu <
> kcbham...@gmail.com<mailto:kcbham...@gmail.com>>
> Sent: Tuesday, March 9, 2021 08:15
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Oleg
> Sorry for the late reply. As we have the opposite time zone so I am
> replying according to your office time.
>
> My previous information was from pbe.spaghetti_ene.
>
> Here is the relevant part from case.scf.
>
>  Bandranges (emin - emax) and occupancy:
> :BAN00066:  660.2189000.284902  1.
> :BAN00067:  670.2817550.322256  1.
> :BAN00068:  680.2817550.322256  1.
> :BAN00069:  690.2879140.335582  1.
> :BAN00070:  700.2879140.335582  1.
> :BAN00071:  710.2941570.351734  1.
> :BAN00072:  720.2941570.351734  1.
> :BAN00073:  730.3010710.368987  1.
> :BAN00074:  740.3010710.368987  1.
> :BAN00075:  750.3400590.383706  1.
> :BAN00076:  760.3400590.383706  1.  VBM
> :BAN00077:  770.4019980.551266  0.  CBM
> :BAN00078:  780.4019980.551266  0.
> :BAN00079:  790.4728340.603663  0.
> :BAN00080:  800.4728340.603663  0.
> :BAN00081:  810.5567370.634231  0.
> Energy to separate low and high energystates:   -0.57035
>
> Just above this part, I see
> :KPT   :  NUMBER OF K-POINTS: 40
>0.0   0.0 angle (M,z), angle (M,x) deg
>
> SPIN-ORBIT EIGENVALUES:
>  K=   0.14286   0.14286   0.14286 1  (In case of "Si" it is 0 0 0
> so you took KP =1?)
>   MATRIX SIZE=  552   WEIGHT= 8.00
>
> Does it mean that I should look for #KP 1? and then of course, bandinxed
> 75,76 for VBM and CBM, respectively.
> But in case of Si, you took #KP =1 for VBM and #KP=15 for CBM.
> So now the band index is clear to me.
>
> My next query is, how can I know #KP for VBM and CBM?
>
> Sorry for the long conversation.
>
> Thank you
> Bhamu
>
> On Mon, Mar 8, 2021 at 

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

I believe I have figured it out.
Will update you.

Thank you
Bhamu

On Thu, Mar 11, 2021 at 4:26 AM Rubel, Oleg  wrote:

> I am glad Si worked out. Sorry, Bhamu. You need to figure it out even if
> it takes more time. When searching through eigenvalues, keep in mind the
> number of digits. For instance, 0.383706 from case.scf can appear as
> 0.3837058 in the eigenvalue file.
>
> All the best
> Oleg
>
> 
> From: Wien  on behalf of Dr. K.
> C. Bhamu 
> Sent: Wednesday, March 10, 2021 11:50
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Oleg
> I tried to follow your advice and it worked for Si case. I found VBM at
> #KP1 and CBM at #KP15. The band index edges were matched with the
> particular KP in case.energyso.
>
> But In my case, I could not find the VBM/CBM edges either in case.eneryso
> or in case.bands.agr/spagetti_ene.
>
> I finished two different calculations (with shifted k-mesh and unshifted
> k-mesh) and both can be downloaded from [1].
> [1] https://we.tl/t-Mhv6nv4Zlf
>
> I would be grateful to you, if you can suggest me #KP's with respect to
> VBM/CBM.
> CBM is not exactly on high-symmetry  k-point.
>
>
> Thank you
> Bhamu
>
>
> On Tue, Mar 9, 2021 at 11:13 PM Rubel, Oleg  rub...@mcmaster.ca>> wrote:
> Dear Bhamu,
>
> to get a VBM k-point index, you would need to look for "0.383706" in your
> case.energyso and see which k-point this eigenvalue belongs to. For CBE,
> look for "0.401998" (it can be a different k-point).
>
> In Si VBM is at Gamma, and CBM is far away from Gamma. Thus we have two
> different k-points. After some trials, I found that 7x7x7 unshifted k-mesh
> "hits" CBM of Si quite precisely.
>
> Of course you need to be confident that the selected k-mesh "hits" the
> relevant extremum (extrema) of your band structure. For instance if you
> need Gamma, do not select a shifted mesh. When the extremum is away from
> the high-symmetry points and coordinates are known, it might be easier to
> use case.klist_band and target the point(s) of interest.
>
> I hope it helps
> Oleg
>
> 
> From: Wien  wien-boun...@zeus.theochem.tuwien.ac.at>> on behalf of Dr. K. C. Bhamu <
> kcbham...@gmail.com<mailto:kcbham...@gmail.com>>
> Sent: Tuesday, March 9, 2021 08:15
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Oleg
> Sorry for the late reply. As we have the opposite time zone so I am
> replying according to your office time.
>
> My previous information was from pbe.spaghetti_ene.
>
> Here is the relevant part from case.scf.
>
>  Bandranges (emin - emax) and occupancy:
> :BAN00066:  660.2189000.284902  1.
> :BAN00067:  670.2817550.322256  1.
> :BAN00068:  680.2817550.322256  1.
> :BAN00069:  690.2879140.335582  1.
> :BAN00070:  700.2879140.335582  1.
> :BAN00071:  710.2941570.351734  1.
> :BAN00072:  720.2941570.351734  1.
> :BAN00073:  730.3010710.368987  1.
> :BAN00074:  740.3010710.368987  1.
> :BAN00075:  750.3400590.383706  1.
> :BAN00076:  760.3400590.383706  1.  VBM
> :BAN00077:  770.4019980.551266  0.  CBM
> :BAN00078:  780.4019980.551266  0.
> :BAN00079:  790.4728340.603663  0.
> :BAN00080:  800.4728340.603663  0.
> :BAN00081:  810.5567370.634231  0.
> Energy to separate low and high energystates:   -0.57035
>
> Just above this part, I see
> :KPT   :  NUMBER OF K-POINTS: 40
>0.0   0.0 angle (M,z), angle (M,x) deg
>
> SPIN-ORBIT EIGENVALUES:
>  K=   0.14286   0.14286   0.14286 1  (In case of "Si" it is 0 0 0
> so you took KP =1?)
>   MATRIX SIZE=  552   WEIGHT= 8.00
>
> Does it mean that I should look for #KP 1? and then of course, bandinxed
> 75,76 for VBM and CBM, respectively.
> But in case of Si, you took #KP =1 for VBM and #KP=15 for CBM.
> So now the band index is clear to me.
>
> My next query is, how can I know #KP for VBM and CBM?
>
> Sorry for the long conversation.
>
> Thank you
> Bhamu
>
> On Mon, Mar 8, 2021 at 8:48 PM Rubel, Oleg  rub...@mcmaster.ca><mailto:rub...@mcmaster.ca<mailto:rub...@mcmaster.ca>>>
> wrote:
> Dear Bhamu,
>
> it seems you have k-point index=38, band index=653. To be on a safe side,
> I would look for band ranges (":BANXXX

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Dear Prof. Oleg,
Before sending my last email to the mailing list, I checked with the digits
too.
Also, a simple grep command can grep the nearest number from all the files
present in the working directory and I used this trick too.

I don't really don't know where is the mistake.

Regards
Bhamu




On Thu, Mar 11, 2021, 07:56 Rubel, Oleg  wrote:

> I am glad Si worked out. Sorry, Bhamu. You need to figure it out even if
> it takes more time. When searching through eigenvalues, keep in mind the
> number of digits. For instance, 0.383706 from case.scf can appear as
> 0.3837058 in the eigenvalue file.
>
> All the best
> Oleg
>
> 
> From: Wien  on behalf of Dr. K.
> C. Bhamu 
> Sent: Wednesday, March 10, 2021 11:50
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Oleg
> I tried to follow your advice and it worked for Si case. I found VBM at
> #KP1 and CBM at #KP15. The band index edges were matched with the
> particular KP in case.energyso.
>
> But In my case, I could not find the VBM/CBM edges either in case.eneryso
> or in case.bands.agr/spagetti_ene.
>
> I finished two different calculations (with shifted k-mesh and unshifted
> k-mesh) and both can be downloaded from [1].
> [1] https://we.tl/t-Mhv6nv4Zlf
>
> I would be grateful to you, if you can suggest me #KP's with respect to
> VBM/CBM.
> CBM is not exactly on high-symmetry  k-point.
>
>
> Thank you
> Bhamu
>
>
> On Tue, Mar 9, 2021 at 11:13 PM Rubel, Oleg  rub...@mcmaster.ca>> wrote:
> Dear Bhamu,
>
> to get a VBM k-point index, you would need to look for "0.383706" in your
> case.energyso and see which k-point this eigenvalue belongs to. For CBE,
> look for "0.401998" (it can be a different k-point).
>
> In Si VBM is at Gamma, and CBM is far away from Gamma. Thus we have two
> different k-points. After some trials, I found that 7x7x7 unshifted k-mesh
> "hits" CBM of Si quite precisely.
>
> Of course you need to be confident that the selected k-mesh "hits" the
> relevant extremum (extrema) of your band structure. For instance if you
> need Gamma, do not select a shifted mesh. When the extremum is away from
> the high-symmetry points and coordinates are known, it might be easier to
> use case.klist_band and target the point(s) of interest.
>
> I hope it helps
> Oleg
>
> 
> From: Wien  wien-boun...@zeus.theochem.tuwien.ac.at>> on behalf of Dr. K. C. Bhamu <
> kcbham...@gmail.com<mailto:kcbham...@gmail.com>>
> Sent: Tuesday, March 9, 2021 08:15
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Oleg
> Sorry for the late reply. As we have the opposite time zone so I am
> replying according to your office time.
>
> My previous information was from pbe.spaghetti_ene.
>
> Here is the relevant part from case.scf.
>
>  Bandranges (emin - emax) and occupancy:
> :BAN00066:  660.2189000.284902  1.
> :BAN00067:  670.2817550.322256  1.
> :BAN00068:  680.2817550.322256  1.
> :BAN00069:  690.2879140.335582  1.
> :BAN00070:  700.2879140.335582  1.
> :BAN00071:  710.2941570.351734  1.
> :BAN00072:  720.2941570.351734  1.
> :BAN00073:  730.3010710.368987  1.
> :BAN00074:  740.3010710.368987  1.
> :BAN00075:  750.3400590.383706  1.
> :BAN00076:  760.3400590.383706  1.  VBM
> :BAN00077:  770.4019980.551266  0.  CBM
> :BAN00078:  780.4019980.551266  0.
> :BAN00079:  790.4728340.603663  0.
> :BAN00080:  800.4728340.603663  0.
> :BAN00081:  810.5567370.634231  0.
> Energy to separate low and high energystates:   -0.57035
>
> Just above this part, I see
> :KPT   :  NUMBER OF K-POINTS: 40
>0.0   0.0 angle (M,z), angle (M,x) deg
>
> SPIN-ORBIT EIGENVALUES:
>  K=   0.14286   0.14286   0.14286 1  (In case of "Si" it is 0 0 0
> so you took KP =1?)
>   MATRIX SIZE=  552   WEIGHT= 8.00
>
> Does it mean that I should look for #KP 1? and then of course, bandinxed
> 75,76 for VBM and CBM, respectively.
> But in case of Si, you took #KP =1 for VBM and #KP=15 for CBM.
> So now the band index is clear to me.
>
> My next query is, how can I know #KP for VBM and CBM?
>
> Sorry for the long conversation.
>
> Thank you
> Bhamu
>
> On Mon, Mar 8, 2021 at 8:48 PM Rubel, Oleg  rub...@mcmaster.ca>&l

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Dear Prof. Oleg
I tried to follow your advice and it worked for Si case. I found VBM at
#KP1 and CBM at #KP15. The band index edges were matched with the
particular KP in case.energyso.

But In my case, I could not find the VBM/CBM edges either in case.eneryso
or in case.bands.agr/spagetti_ene.

I finished two different calculations (with shifted k-mesh and unshifted
k-mesh) and both can be downloaded from [1].
[1] https://we.tl/t-Mhv6nv4Zlf

I would be grateful to you, if you can suggest me #KP's with respect to
VBM/CBM.
CBM is not exactly on high-symmetry  k-point.


Thank you
Bhamu


On Tue, Mar 9, 2021 at 11:13 PM Rubel, Oleg  wrote:

> Dear Bhamu,
>
> to get a VBM k-point index, you would need to look for "0.383706" in your
> case.energyso and see which k-point this eigenvalue belongs to. For CBE,
> look for "0.401998" (it can be a different k-point).
>
> In Si VBM is at Gamma, and CBM is far away from Gamma. Thus we have two
> different k-points. After some trials, I found that 7x7x7 unshifted k-mesh
> "hits" CBM of Si quite precisely.
>
> Of course you need to be confident that the selected k-mesh "hits" the
> relevant extremum (extrema) of your band structure. For instance if you
> need Gamma, do not select a shifted mesh. When the extremum is away from
> the high-symmetry points and coordinates are known, it might be easier to
> use case.klist_band and target the point(s) of interest.
>
> I hope it helps
> Oleg
>
> 
> From: Wien  on behalf of Dr. K.
> C. Bhamu 
> Sent: Tuesday, March 9, 2021 08:15
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Oleg
> Sorry for the late reply. As we have the opposite time zone so I am
> replying according to your office time.
>
> My previous information was from pbe.spaghetti_ene.
>
> Here is the relevant part from case.scf.
>
>  Bandranges (emin - emax) and occupancy:
> :BAN00066:  660.2189000.284902  1.
> :BAN00067:  670.2817550.322256  1.
> :BAN00068:  680.2817550.322256  1.
> :BAN00069:  690.2879140.335582  1.
> :BAN00070:  700.2879140.335582  1.
> :BAN00071:  710.2941570.351734  1.
> :BAN00072:  720.2941570.351734  1.
> :BAN00073:  730.3010710.368987  1.
> :BAN00074:  740.3010710.368987  1.
> :BAN00075:  750.3400590.383706  1.
> :BAN00076:  760.3400590.383706  1.  VBM
> :BAN00077:  770.4019980.551266  0.  CBM
> :BAN00078:  780.4019980.551266  0.
> :BAN00079:  790.4728340.603663  0.
> :BAN00080:  800.4728340.603663  0.
> :BAN00081:  810.5567370.634231  0.
> Energy to separate low and high energystates:   -0.57035
>
> Just above this part, I see
> :KPT   :  NUMBER OF K-POINTS: 40
>0.0   0.0 angle (M,z), angle (M,x) deg
>
> SPIN-ORBIT EIGENVALUES:
>  K=   0.14286   0.14286   0.14286 1  (In case of "Si" it is 0 0 0
> so you took KP =1?)
>   MATRIX SIZE=  552   WEIGHT= 8.00
>
> Does it mean that I should look for #KP 1? and then of course, bandinxed
> 75,76 for VBM and CBM, respectively.
> But in case of Si, you took #KP =1 for VBM and #KP=15 for CBM.
> So now the band index is clear to me.
>
> My next query is, how can I know #KP for VBM and CBM?
>
> Sorry for the long conversation.
>
> Thank you
> Bhamu
>
> On Mon, Mar 8, 2021 at 8:48 PM Rubel, Oleg  rub...@mcmaster.ca>> wrote:
> Dear Bhamu,
>
> it seems you have k-point index=38, band index=653. To be on a safe side,
> I would look for band ranges (":BANXXX") in case.scf (last iteration). The
> occupancies are written down in the same table. If you have questions about
> interpretation of :BANXXX, it will be better if you list this section for
> your SCF file.
>
> Thanks
> Oleg
>
> 
> From: Wien  wien-boun...@zeus.theochem.tuwien.ac.at>> on behalf of Dr. K. C. Bhamu <
> kcbham...@gmail.com<mailto:kcbham...@gmail.com>>
> Sent: Sunday, March 7, 2021 08:09
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Oleg
> Sorry to interrupt you.
> Earlier I was looking for the wrong file.
> My case.klist has 40 k-points and thus #KP also varies upto 40.
> From my eigenvalue file, my VBM lies on band index=38 (XX)
> row number   KP(YY)  ENE
> 6531.08800-0.04699
> So according to your hint, I should look for #KP 653 and then index number

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Dear Prof. Oleg
Sorry for the late reply. As we have the opposite time zone so I am
replying according to your office time.

My previous information was from pbe.spaghetti_ene.

Here is the relevant part from case.scf.

 Bandranges (emin - emax) and occupancy:
:BAN00066:  660.2189000.284902  1.
:BAN00067:  670.2817550.322256  1.
:BAN00068:  680.2817550.322256  1.
:BAN00069:  690.2879140.335582  1.
:BAN00070:  700.2879140.335582  1.
:BAN00071:  710.2941570.351734  1.
:BAN00072:  720.2941570.351734  1.
:BAN00073:  730.3010710.368987  1.
:BAN00074:  740.3010710.368987  1.
:BAN00075:  750.3400590.383706  1.

*:BAN00076:  760.3400590.383706  1.  VBM:BAN00077:  77
 0.4019980.551266  0.  CBM*
:BAN00078:  780.4019980.551266  0.
:BAN00079:  790.4728340.603663  0.
:BAN00080:  800.4728340.603663  0.
:BAN00081:  810.5567370.634231  0.
Energy to separate low and high energystates:   -0.57035

Just above this part, I see
:KPT   :  NUMBER OF K-POINTS: 40
   0.0   0.0 angle (M,z), angle (M,x) deg

SPIN-ORBIT EIGENVALUES:
 K=   0.14286   0.14286   0.14286 *1  (In case of "Si" it is 0 0 0
so you took KP =1?)*
  MATRIX SIZE=  552   WEIGHT= 8.00

Does it mean that I should look for #KP 1? and then of course, bandinxed
75,76 for VBM and CBM, respectively.
But in case of Si, you took #KP =1 for VBM and #KP=15 for CBM.
So now the band index is clear to me.

My next query is, how can I know #KP for VBM and CBM?

Sorry for the long conversation.

Thank you
Bhamu

On Mon, Mar 8, 2021 at 8:48 PM Rubel, Oleg  wrote:

> Dear Bhamu,
>
> it seems you have k-point index=38, band index=653. To be on a safe side,
> I would look for band ranges (":BANXXX") in case.scf (last iteration). The
> occupancies are written down in the same table. If you have questions about
> interpretation of :BANXXX, it will be better if you list this section for
> your SCF file.
>
> Thanks
> Oleg
>
> ____________
> From: Wien  on behalf of Dr. K.
> C. Bhamu 
> Sent: Sunday, March 7, 2021 08:09
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Oleg
> Sorry to interrupt you.
> Earlier I was looking for the wrong file.
> My case.klist has 40 k-points and thus #KP also varies upto 40.
> From my eigenvalue file, my VBM lies on band index=38 (XX)
> row number   KP(YY)  ENE
> 6531.08800-0.04699
> So according to your hint, I should look for #KP 653 and then index number
> 38.
> But I have #KP upto 40.
> You also mentioned occupancy, but I could not understand it.
>
> Could you please correct me?
>
> Thank you in advance.
> Regards
> Bhamu
>
>
>
>
>
>
> On Thu, Mar 4, 2021 at 10:51 PM Rubel, Oleg  rub...@mcmaster.ca>> wrote:
> Oh, sorry about the misunderstanding. In your previous correspondence it
> sounded as you had a confusion about which klist file is used.
>
> > In my case the CBM/CMB is at N-point which is located at 622 row number
> in case.klist_band. But I have only 20 K-points in my case.klist and thus
> the total KP in mstar output file is also 20.
>
> To get band edges, I would check an eigenvalues file to identify band
> number XX, k point number YY, occupancy. Then look for a line "# KP: YY"
> and band XX below that in the output of mstar.
>
> I hope it answers the question
> Oleg
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at<mailto: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

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Dear Prof. Oleg
Sorry to interrupt you.
Earlier I was looking for the wrong file.
My case.klist has 40 k-points and thus #KP also varies upto 40.
>From my eigenvalue file, my VBM lies on band index=38 (XX)
row number   KP(YY)  ENE
6531.08800-0.04699
So according to your hint, I should look for #KP 653 and then index number
38.
But I have #KP upto 40.
You also mentioned occupancy, but I could not understand it.

Could you please correct me?

Thank you in advance.
Regards
Bhamu






On Thu, Mar 4, 2021 at 10:51 PM Rubel, Oleg  wrote:

> Oh, sorry about the misunderstanding. In your previous correspondence it
> sounded as you had a confusion about which klist file is used.
>
> > In my case the CBM/CMB is at N-point which is located at 622 row number
> in case.klist_band. But I have only 20 K-points in my case.klist and thus
> the total KP in mstar output file is also 20.
>
> To get band edges, I would check an eigenvalues file to identify band
> number XX, k point number YY, occupancy. Then look for a line "# KP: YY"
> and band XX below that in the output of mstar.
>
> I hope it answers the question
> Oleg
> ___
> 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

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Dear Prof Oleg
I understand the procedure with case.klist or case.klist_band. my question
was not for the procedure.
My question is how to get m* from my attached files mstar output file? I
couldn't identify the KP index that has the m* for request VBM and cbm.
Please have a look on my supplied files.


Thank you very much
Bhamu

On Fri, Mar 5, 2021, 00:49 Rubel, Oleg  wrote:

> Dear Bhamu,
>
> mstar gets k points from case.mommat2[up/dn] file. It is create by OPTIC.
> The OPTIC, in turn, gets k points from vector files. Thus you need to have
> right k points in the vector files.
>
> The procedure described in
> https://github.com/rubel75/mstar/wiki/Tutorial-Si-with-SOC-(WIEN2k) has a
> part
>
> # WFs and eigenvalues with increased band range
> x lapw1
> x lapwso
>
> This will use case.klist (not case.klist_band) to generate vector files at
> LAPW1 step. Then it propagates to LAPWSO and OPTIC.
> If you want k points from case.klist_band, we need to generate vector
> files with (-band) option in LAPW1
>
> # WFs and eigenvalues with increased band range
> x lapw1 -band
> x lapwso
>
> There are not other changes in the workflow. Then k points from
> case.klist_band propagate into LAPWSO, OPTIC, and mstar eventually.
>
> Best regards
> Oleg
> ___
> 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

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Dear Prof. Oleg,

I could not understand how to find the mstar for CBM and VBM.
I came across [1], where you are talking about case.klist_band. I
understand that the position of "G" Point is at 13 in that case so we need
to consider KP-13. Then the entry under KP-13 covers the band index. We can
get the band index from the case.bands.agr file.
Please correct me if I am wrong.

In my case the CBM/CMB is at N-point which is located at 622 row number in
case.klist_band. But I have only 20 K-points in my case.klist and thus the
total KP in mstar output file is also 20.
In my case.bands.agr the VBM  band index is 75. So what I understand is I
should find the 75th band index in mstar output file under KP-X (but here X
is unknown for me as case.klist file has only 20 k-points).
I am keeping my all necessary files here [2].

NOTE: I did not use case.klist_band file for the calculation and I am
keeping case.klist_band and case.bands.agr files [2] from my previously
finished calculation for band structure.

[1].
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg20713.html

[2]. https://we.tl/t-FsnY88gTgx

Thank you
Bhamu


On Thu, Mar 4, 2021 at 3:01 AM Rubel, Oleg  wrote:

> You are right, it is not a universal line. It implies that the system is
> not magnetic (N at the end). Also, it avoids relativistic local orbitals
> (RLOs), which is default in init_so_lapw. I cannot point to a reference,
> but it seems that optic is not compatible with RLOs? (Maybe someone can
> comment.)
>
> Thank you
> Oleg
> ___
> 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

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Thank you Prof. Oleg for the clarification.
You are right, optic is not compatible with RLOs. It is well explained by
Gavin in the past for one of my query.

Thank you very much
Bhamu

On Thu, Mar 4, 2021, 06:31 Rubel, Oleg  wrote:

> You are right, it is not a universal line. It implies that the system is
> not magnetic (N at the end). Also, it avoids relativistic local orbitals
> (RLOs), which is default in init_so_lapw. I cannot point to a reference,
> but it seems that optic is not compatible with RLOs? (Maybe someone can
> comment.)
>
> Thank you
> Oleg
> ___
> 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

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

I have a quick question:
You mention about Si
echo -e "0 0 1\n\n\n\nN\n" | init_so_lapw

Is it true for all the cases that we should modify it according to the
system?
I have modified this line for my system.

Thank you
Bhamu



On Thu, Mar 4, 2021 at 1:58 AM Rubel, Oleg  wrote:

> Dear Bhamu,
>
> the error you mention in the latest email is (probably) caused by the way
> optic deals with SOC. The section "8.19.1 Execution" of the UG mentions "In
> cases of non-spinpolarized spin-orbit calculations WITHOUT inversion
> symmetry one must do some tricks and “mimic” a spinpolarized calculation:".
> Si does have an inversion symmetry but, to be on a safe side, I would do
> the trick.
>
> ~~ serial calculation ~~
>
> Steps are described in
> https://github.com/rubel75/mstar/wiki/Tutorial-Si-with-SOC-(WIEN2k) under
> "# fake spin-polarized calculation for optic" section immediately before
> calling optic.
>
> ...
> # fake spin-polarized calculation for optic
> rm ${case}.vspup
> ln -s ${case}.vsp ${case}.vspup
> rm ${case}.vspdn
> ln -s ${case}.vsp ${case}.vspdn
> ln -s ${case}.vectorso ${case}.vectorsoup
> ...
>
> It relies on the ${case} variable. Maybe it was not set up?
>
> case=${PWD##*/}
>
> Please check the variable and all symbolic links.
>
> ~~ parallel calculation ~~
>
> Now when you run optic in parallel (-p) after
>
> run_lapw ... -so -p
>
> the same "ln ..." has to be done to all case.vectorso_XX files. To deal
> with this, I have a bash script:
>
> # fake spin-polarized calculation for optic
> echo "making symbolic link: ${case}.vspup -> ${case}.vsp"
> rm ${case}.vspup
> ln -s ${case}.vsp ${case}.vspup
> echo "making symbolic link: ${case}.vspdn -> ${case}.vsp"
> rm ${case}.vspdn
> ln -s ${case}.vsp ${case}.vspdn
> i="1" # init counter for parallel files
> filevec=${case}.vectorso_${i} # name of vector file
> while [ -f "$filevec" ] # while the vector file exists
> do
>   echo "$filevec exist"
>   echo "making symbolic link: ${case}.vectorsoup_${i} -> $filevec"
>   ln -s $filevec ${case}.vectorsoup_${i}
>   i=$[$i+1] # increment the counter
>   filevec=${case}.vectorso_${i} # next vector file
> done
>
> You need to verify that alter running the script you have
> pbe.vectorsoup_XX files in place.
>
>
> I hope it will help
> Oleg
>
> 
> From: Wien  on behalf of Dr. K.
> C. Bhamu 
> Sent: Wednesday, March 3, 2021 14:04
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Peter
> I have tried with the new opticpara_lapw but still I am getting the same
> error:
>
> x_lapw optic -so -up -p
>
> [1] 13614
> OPTIC - ERROR
> [1]  + Done  ( cd $PWD; $t $exe
> ${def}_${loop}.def; rm -f .lock_$lockfile[$p] ) >> .timeop_$loop
> [1] 13619
> OPTIC - ERROR
> [1]  + Done  ( cd $PWD; $t $exe
> ${def}_${loop}.def; rm -f .lock_$lockfile[$p] ) >> .timeop_$loop
> [1] 13624
> OPTIC - ERROR
> [1]  + Done  ( cd $PWD; $t $exe
> ${def}_${loop}.def; rm -f .lock_$lockfile[$p] ) >> .timeop_$loop
> **  OPTIC crashed!
> 0.151u 0.199s 0:04.15 8.1% 0+0k 6008+2104io 25pf+0w
> error: command   /home/kcbhamu/soft/w2k192/opticcpara -up -c -so
> upoptic.def   failed
>  cat *error
>
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_10
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_11
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_12
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_13
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_14
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_15
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_16
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_1
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_2
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Dear Prof. Oleg
Thank you very much.
It worked for me. I was running that serial script for a parallel
calculation.
Thank you for developing a perfect toop for the Wien2k community.

I will get back to you if I have any questions.

Regards
Bhamu

On Thu, Mar 4, 2021 at 1:58 AM Rubel, Oleg  wrote:

> Dear Bhamu,
>
> the error you mention in the latest email is (probably) caused by the way
> optic deals with SOC. The section "8.19.1 Execution" of the UG mentions "In
> cases of non-spinpolarized spin-orbit calculations WITHOUT inversion
> symmetry one must do some tricks and “mimic” a spinpolarized calculation:".
> Si does have an inversion symmetry but, to be on a safe side, I would do
> the trick.
>
> ~~ serial calculation ~~
>
> Steps are described in
> https://github.com/rubel75/mstar/wiki/Tutorial-Si-with-SOC-(WIEN2k) under
> "# fake spin-polarized calculation for optic" section immediately before
> calling optic.
>
> ...
> # fake spin-polarized calculation for optic
> rm ${case}.vspup
> ln -s ${case}.vsp ${case}.vspup
> rm ${case}.vspdn
> ln -s ${case}.vsp ${case}.vspdn
> ln -s ${case}.vectorso ${case}.vectorsoup
> ...
>
> It relies on the ${case} variable. Maybe it was not set up?
>
> case=${PWD##*/}
>
> Please check the variable and all symbolic links.
>
> ~~ parallel calculation ~~
>
> Now when you run optic in parallel (-p) after
>
> run_lapw ... -so -p
>
> the same "ln ..." has to be done to all case.vectorso_XX files. To deal
> with this, I have a bash script:
>
> # fake spin-polarized calculation for optic
> echo "making symbolic link: ${case}.vspup -> ${case}.vsp"
> rm ${case}.vspup
> ln -s ${case}.vsp ${case}.vspup
> echo "making symbolic link: ${case}.vspdn -> ${case}.vsp"
> rm ${case}.vspdn
> ln -s ${case}.vsp ${case}.vspdn
> i="1" # init counter for parallel files
> filevec=${case}.vectorso_${i} # name of vector file
> while [ -f "$filevec" ] # while the vector file exists
> do
>   echo "$filevec exist"
>   echo "making symbolic link: ${case}.vectorsoup_${i} -> $filevec"
>   ln -s $filevec ${case}.vectorsoup_${i}
>   i=$[$i+1] # increment the counter
>   filevec=${case}.vectorso_${i} # next vector file
> done
>
> You need to verify that alter running the script you have
> pbe.vectorsoup_XX files in place.
>
>
> I hope it will help
> Oleg
>
> 
> From: Wien  on behalf of Dr. K.
> C. Bhamu 
> Sent: Wednesday, March 3, 2021 14:04
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] opticcpara crashed for mstar
>
> Dear Prof. Peter
> I have tried with the new opticpara_lapw but still I am getting the same
> error:
>
> x_lapw optic -so -up -p
>
> [1] 13614
> OPTIC - ERROR
> [1]  + Done  ( cd $PWD; $t $exe
> ${def}_${loop}.def; rm -f .lock_$lockfile[$p] ) >> .timeop_$loop
> [1] 13619
> OPTIC - ERROR
> [1]  + Done  ( cd $PWD; $t $exe
> ${def}_${loop}.def; rm -f .lock_$lockfile[$p] ) >> .timeop_$loop
> [1] 13624
> OPTIC - ERROR
> [1]  + Done  ( cd $PWD; $t $exe
> ${def}_${loop}.def; rm -f .lock_$lockfile[$p] ) >> .timeop_$loop
> **  OPTIC crashed!
> 0.151u 0.199s 0:04.15 8.1% 0+0k 6008+2104io 25pf+0w
> error: command   /home/kcbhamu/soft/w2k192/opticcpara -up -c -so
> upoptic.def   failed
>  cat *error
>
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_10
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_11
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_12
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_13
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_14
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_15
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_16
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_1
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit: 10
>  'OPTIC' -  filename: ./pbe.vectorsoup_2
>  'OPTIC' -  status: OLD  form: UNFORMATTED
>  'OPTIC' -  can't open unit:

Re: [Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Dear Prof. Peter
I have tried with the new opticpara_lapw but still I am getting the same
error:


*x_lapw optic -so -up -p*

[1] 13614
OPTIC - ERROR
[1]  + Done  ( cd $PWD; $t $exe ${def}_${loop}.def;
rm -f .lock_$lockfile[$p] ) >> .timeop_$loop
[1] 13619
OPTIC - ERROR
[1]  + Done  ( cd $PWD; $t $exe ${def}_${loop}.def;
rm -f .lock_$lockfile[$p] ) >> .timeop_$loop
[1] 13624
OPTIC - ERROR
[1]  + Done  ( cd $PWD; $t $exe ${def}_${loop}.def;
rm -f .lock_$lockfile[$p] ) >> .timeop_$loop
**  OPTIC crashed!
0.151u 0.199s 0:04.15 8.1% 0+0k 6008+2104io 25pf+0w
error: command   /home/kcbhamu/soft/w2k192/opticcpara -up -c -so
upoptic.def   failed
* cat *error*

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_10

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_11

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_12

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_13

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_14

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_15

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_16

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_1

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_2

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_3

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_4

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_5

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_6

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_7

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_8

 'OPTIC' -  status: OLD  form: UNFORMATTED

 'OPTIC' -  can't open unit: 10

 'OPTIC' -  filename: ./pbe.vectorsoup_9

 'OPTIC' -  status: OLD  form: UNFORMATTED

**  Error in Parallel OPTIC
**  Error in Parallel OPTIC

On Wed, Mar 3, 2021 at 11:53 PM Peter Blaha 
wrote:

> Are you running in k-point parallel mode ??
>
> Clearly, method B is missing a   -p
>
> In addition, I think the opticpara_lapw script of wien2k_19 does not
> work properly with the required case.mommat2 files.
>
> Try the attached new version.
>
> Regards
>
> Am 03.03.2021 um 18:58 schrieb Dr. K. C. Bhamu:
> > Dear Prof. Oleg
> >
> > I am trying to run mstar code to calculate effective mass for a
> > tetragonal system with SOC.
> > I am using Wien2k_19.2 compiled with mkl+ifort on a cluster.
> >
> > To calculate the mstar, I am using a script given for Si(SOC).
> >
> > All steps went fine but optic code has crashed.
> > Below is the error report:
> >
> > A. Output when I run optic using a job file:
> > **  OPTIC crashed!
> > 0.141u 0.434s 0:05.06 11.2% 0+0k 3560+1384io 4pf+0w
> > error: command   /home/kcbhamu/soft/w2k192/opticcpara -up -c -so
> > upoptic.def   failed
> >   Detected input arguments = 2
> >   Input mommat file = pbe.mommat2up
> >   Degeneracy tolerance dEtol = 1e-5 [Ha]
> >   Confirming text-to-number conversion dEtol =  1.0E-05 [Ha]
> >   The input file pbe.mommat2up does not exist. Exiting
> >
> > B. Output when I run opticon terminal:
> > [kcbhamu@elpidos pbe]$ x optic -so -up
> >   emin,emax,nbvalmax  -5.007.00
> > 
> > forrtl: severe (24): end-of-file during read, unit 10, file
> > /home/kcbhamu/work/mstar/hossan/automa/pbe/./pbe.vectorsoup
> > Image  PCRoutineLine
> Source
> > opticc 0046CD5B  Unknown   Unknown
> Unknown
> > opticc 0048A259  Unknown   Unknown
> Unknown
> > opticc 0042F60C  mom_mat_  200
> > sph-UP_tmp.f
> > opticc 0041F94B  MAIN__469
> opmain.f
>

[Wien] opticcpara crashed for mstar

[Dr. K. C. Bhamu]

Dear Prof. Oleg

I am trying to run mstar code to calculate effective mass for a tetragonal
system with SOC.
I am using Wien2k_19.2 compiled with mkl+ifort on a cluster.

To calculate the mstar, I am using a script given for Si(SOC).

All steps went fine but optic code has crashed.
Below is the error report:

A. Output when I run optic using a job file:
**  OPTIC crashed!
0.141u 0.434s 0:05.06 11.2% 0+0k 3560+1384io 4pf+0w
error: command   /home/kcbhamu/soft/w2k192/opticcpara -up -c -so
upoptic.def   failed
 Detected input arguments = 2
 Input mommat file = pbe.mommat2up
 Degeneracy tolerance dEtol = 1e-5 [Ha]
 Confirming text-to-number conversion dEtol =  1.0E-05 [Ha]
 The input file pbe.mommat2up does not exist. Exiting

B. Output when I run opticon terminal:
[kcbhamu@elpidos pbe]$ x optic -so -up
 emin,emax,nbvalmax  -5.007.00
 
forrtl: severe (24): end-of-file during read, unit 10, file
/home/kcbhamu/work/mstar/hossan/automa/pbe/./pbe.vectorsoup
Image  PCRoutineLineSource
opticc 0046CD5B  Unknown   Unknown  Unknown
opticc 0048A259  Unknown   Unknown  Unknown
opticc 0042F60C  mom_mat_  200
sph-UP_tmp.f
opticc 0041F94B  MAIN__469  opmain.f
opticc 004047A2  Unknown   Unknown  Unknown
libc-2.17.so   2AF1E6804555
__libc_start_main Unknown  Unknown
opticc 004046A9  Unknown   Unknown  Unknown
0.000u 0.002s 0:00.00 0.0% 0+0k 408+64io 2pf+0w
error: command   /home/kcbhamu/soft/w2k192/opticc upoptic.def   failed


Here is my case.inop file
9 1   number of k-points, first k-point
-5.0 7.0  Emin, Emax for matrix elements, NBvalMAX
2 number of choices (columns in *outmat): 2: hex or tetrag. case
1 Re xx
3 Re zz
ON   ON/OFF   writes MME to unit 4

Choices:
1..Re 
2..Re 
3..Re 
4..Re 
5..Re 
6..Re 
7..Im 
8..Im 
9..Im 

Could you please advise me how I can get rid of this error?


Please let me know if I need to provide any additional information in
support of my query.


Regards
Bhamu
___
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

Re: [Wien] Need extensive help for a job file for slurm job scheduler cluster

[Dr. K. C. Bhamu]

Thank you Dr. Tran, Gavin and Prof. Marks
It worked now after installing the bc on the client node.

Thank you very much.

Regards
Bhamu

On Sun, Nov 15, 2020 at 2:45 PM Laurence Marks 
wrote:

> If your sys admin does not want to install bc, you can install it yourself
> into ~/bin if this is nfs mounted. Or some other nfs mounted directory that
> you add to your PATH or is already included. Do a Google search on "linux
> how to install bc".
>
> Wien2k requires a working bc, and standard linux commands on all nodes.
> There is no way around this short of a massive rewrite (which nobody will
> do for you).
>
> _
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu
>
> On Sun, Nov 15, 2020, 02:19 Tran, Fabien  wrote:
>
>> The probably simplest solution is to ask the system administrator to
>> install bc on all nodes:
>> ​​
>> https://urldefense.com/v3/__https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17679.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!A8k2iWg8Er5xRYR-yIFE18w7dC40LekNfBwq17MhDvT_aN0YCI47gIpy1J4evqZPKah9Bg$
>>
>>
>> From: Wien  on behalf of Dr. K.
>> C. Bhamu 
>> Sent: Sunday, November 15, 2020 8:07 AM
>> To: A Mailing list for WIEN2k users
>> Subject: Re: [Wien] Need extensive help for a job file for slurm job
>> scheduler cluster
>>
>>
>>
>> Additional information (maybe this is the main cause of the lapw1 crash):
>> bc is only working on the head node. node11 or other clint nodes are not
>> having bc installed.
>> If the bc is only the issue then is it possible to modify the job file
>> such that it uses bc on the head node only.
>>
>>
>> Thank you
>> Bhamu
>>
>>
>> On Sun, Nov 15, 2020 at 12:25 PM Dr. K. C. Bhamu 
>> wrote:
>>
>>
>>
>> Dear Gavin and Prof. Marks
>> Thank you for your inputs.
>> qsub MyJobFIle.job creates the .machines file.
>>
>>
>> With the below given  job file, I could create the proper .machine files
>> (equal to number of cores in the node and .machines file) but  lapw1
>> always crashes
>>
>>
>> case.dayfile is
>>
>> Calculating pbe in /home/kcbhamu/work/test/pbe
>> on node11 with PID 9241
>> using WIEN2k_19.1 (Release 25/6/2019) in /home/kcbhamu/soft/w2k192
>>
>>
>> start (Sun Nov 15 15:42:05 KST 2020) with lapw0 (40/99 to go)
>>
>> cycle 1 (Sun Nov 15 15:42:05 KST 2020) (40/99 to go)
>>
>> >   lapw0   -p (15:42:05) starting parallel lapw0 at Sun Nov 15 15:42:05
>> KST 2020
>>  .machine0 : processors
>> running lapw0 in single mode
>> 7.281u 0.272s 0:07.64 98.8% 0+0k 1000+1216io 0pf+0w
>> >   lapw1  -p (15:42:13) starting parallel lapw1 at Sun Nov 15
>> 15:42:13 KST 2020
>> ->  starting parallel LAPW1 jobs at Sun Nov 15 15:42:13 KST 2020
>> running LAPW1 in parallel mode (using .machines)
>> 16 number_of_parallel_jobs
>> 0.200u 0.369s 0:00.59 94.9% 0+0k 208+456io 0pf+0w
>> error: command   /home/kcbhamu/soft/w2k192/lapw1para lapw1.def   failed
>>
>> >   stop error
>>
>>
>>
>> the job.eout file indicates below error:
>>
>>
>> But I am getting below error
>>
>>
>> bc: Command not found.
>>  LAPW0 END
>> bc: Command not found.
>> number_per_job: Subscript out of range.
>> grep: *scf1*: No such file or directory
>> grep: lapw2*.error: No such file or directory
>>
>>
>>
>> .machines file is give below
>>
>>
>>
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> 1:node11
>> granularity:1
>> extrafine:1
>>
>>
>>
>>
>>
>> parallel_options file
>> setenv TASKSET "no"
>> if ( ! $?USE_REMOTE ) setenv USE_REMOTE 0
>> if ( ! $?MPI_REMOTE ) setenv MPI_REMOTE 0
>> setenv WIEN_GRANULARITY 1
>> setenv DELAY 0.1
>> setenv SLEEPY 1
>> setenv WIEN_MPIRUN "mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_"
>> setenv CORES_PER_NODE 16
>>
>>
>>
>> job file
>>
>>
>> #!/bin/sh
>> #SBATCH -J test
>> #SBATCH -p 52core# THis is the name of the partition.
>> #SBATCH -N 1
>> #SBATCH -n 16
>> #SBATCH -o %x.o%j
>> #SBATCH -e %x.e%

Re: [Wien] Need extensive help for a job file for slurm job scheduler cluster

[Dr. K. C. Bhamu]

Additional information (maybe this is the main cause of the lapw1 crash):
bc is only working on the head node. node11 or other clint nodes are not
having bc installed.
If the bc is only the issue then is it possible to modify the job file such
that it uses bc on the head node only.

Thank you
Bhamu

On Sun, Nov 15, 2020 at 12:25 PM Dr. K. C. Bhamu 
wrote:

> Dear Gavin and Prof. Marks
> Thank you for your inputs.
> qsub MyJobFIle.job creates the .machines file.
>
> With the below given  job file, I could create the proper .machine files
> (equal to number of cores in the node and .machines file) but  lapw1
> always crashes
>
> *case.dayfile is*
>
> Calculating pbe in /home/kcbhamu/work/test/pbe
> on node11 with PID 9241
> using WIEN2k_19.1 (Release 25/6/2019) in /home/kcbhamu/soft/w2k192
>
>
> start (Sun Nov 15 15:42:05 KST 2020) with lapw0 (40/99 to go)
>
> cycle 1 (Sun Nov 15 15:42:05 KST 2020) (40/99 to go)
>
> >   lapw0   -p (15:42:05) starting parallel lapw0 at Sun Nov 15 15:42:05
> KST 2020
>  .machine0 : processors
> running lapw0 in single mode
> 7.281u 0.272s 0:07.64 98.8% 0+0k 1000+1216io 0pf+0w
> >   lapw1  -p (15:42:13) starting parallel lapw1 at Sun Nov 15
> 15:42:13 KST 2020
> ->  starting parallel LAPW1 jobs at Sun Nov 15 15:42:13 KST 2020
> running LAPW1 in parallel mode (using .machines)
> 16 number_of_parallel_jobs
> 0.200u 0.369s 0:00.59 94.9% 0+0k 208+456io 0pf+0w
> error: command   /home/kcbhamu/soft/w2k192/lapw1para lapw1.def   failed
>
> >   stop error
>
> *the job.eout file indicates below error:*
>
> But I am getting below error
>
> bc: Command not found.
>  LAPW0 END
> bc: Command not found.
> number_per_job: Subscript out of range.
> grep: *scf1*: No such file or directory
> grep: lapw2*.error: No such file or directory
>
>
> *.machines file is give below*
>
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> 1:node11
> granularity:1
> extrafine:1
>
>
> *parallel_options file*
> setenv TASKSET "no"
> if ( ! $?USE_REMOTE ) setenv USE_REMOTE 0
> if ( ! $?MPI_REMOTE ) setenv MPI_REMOTE 0
> setenv WIEN_GRANULARITY 1
> setenv DELAY 0.1
> setenv SLEEPY 1
> setenv WIEN_MPIRUN "mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_"
> setenv CORES_PER_NODE 16
>
> *job file*
>
> #!/bin/sh
> #SBATCH -J test
> #SBATCH -p 52core# THis is the name of the partition.
> #SBATCH -N 1
> #SBATCH -n 16
> #SBATCH -o %x.o%j
> #SBATCH -e %x.e%j
> #export I_MPI_PMI_LIBRARY=/usr/lib64/libpmi.so
>
> export OMP_NUM_THREADS=16 # I have check with 1,2 4, 8 also.
>
> # Use , as list separator
> IFS=','
> # Convert string to array
> hcpus=($SLURM_JOB_CPUS_PER_NODE)
> unset IFS
>
> declare -a conv
>
> # Expand compressed slurm array
> for cpu in ${hcpus[@]}; do
>  if [[ $cpu =~ (.*)\((.*)x\) ]]; then
> # found compressed value
> value=${BASH_REMATCH[1]}
> factor=${BASH_REMATCH[2]}
> for j in $(seq 1 $factor); do
>conv=( ${conv[*]} $value )
> done
>  else
> conv=( ${conv[*]} $cpu )
>  fi
> done
>
> # Build .machines file
> rm -f .machines
>
> nhost=0
>
> echo ${conv[@]};
>
> IFS=','
> for node in $SLURM_NODELIST
> do
> declare -i cpuspernode=${conv[$nhost]};
> for ((i=0; i<${cpuspernode}; i++))
> do
> echo 1:$node >> .machines
> done
> let nhost+=1
> done
>
> echo 'granularity:1' >>.machines
> echo 'extrafine:1' >>.machines
>
>
> run_lapw -p
>
>
> Thank you very much
>
> Regards
> Bhamu
>
>
>
> On Fri, Nov 13, 2020 at 7:04 PM Gavin Abo  wrote:
>
>> If you have a look at [1], it can be seen that different cluster systems
>> have different commands for job submission.
>>
>> I did not see it clearly shown in your post how the job was submitted,
>> for example did you maybe use something similar to that at [2]:
>>
>> $ sbatch MyJobScript.sh
>>
>> *What command creates your .machines file?*
>>
>> In your MyJobScript.sh below, I'm not seeing any lines that create a
>> .machines file.
>> MyJobScript.sh
>>
>> 
>> #!/bin/sh
>> #SBATCH -J test #job name
>> #SBATCH -p 44core #partition name
>> #SBATCH -N 1 #node
>> #SBATCH -n 18 #core
>> #SBATCH -o %x.o%j
>> #SBATCH -e %x.e%j
>> export I_MPI_PMI_LIBRARY=/usr/lib64/libpmi.so #

Re: [Wien] Need extensive help for a job file for slurm job scheduler cluster

[Dr. K. C. Bhamu]

om/wien@zeus.theochem.tuwien.ac.at/msg07097.html
> [7] https://www.nsc.liu.se/software/installed/tetralith/wien2k/
>
> On 11/13/2020 3:37 AM, Laurence Marks wrote:
>
> N.B., example mid-term questions:
> 1. What SBATCH command will give you 3 nodes?
> 2. What command creates your .machines file?
> 3. What are your fastest and slowest nodes?
> 4. Which nodes have the best communications.
>
> N.B., please don't post your answers -- just understand!
>
> _
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu
>
> On Fri, Nov 13, 2020, 04:21 Laurence Marks 
> wrote:
>
>> Much of what you are requesting is problem/cluster specific, so there is
>> no magic answer -- it will vary. Suggestions:
>> 1) Read the UG sections on .machines and parallel operation.
>> 2) Read the man page for your cluster job command (srun)
>> 3) Reread the UG sections.
>> 4) Read the example scripts, and understand (lookup) all the commands so
>> you know what they are doing.
>>
>> It is really not that complicated. If you cannot master this by yourself,
>> I will wonder whether you are in the right profession.
>>
>> _
>> Professor Laurence Marks
>> "Research is to see what everybody else has seen, and to think what
>> nobody else has thought", Albert Szent-Gyorgi
>> www.numis.northwestern.edu
>>
>> On Fri, Nov 13, 2020, 03:24 Dr. K. C. Bhamu  wrote:
>>
>>> Dear All
>>>
>>> I need your extensive help.
>>> I have tried to provide full details that can help you understand my
>>> requirement. In case I have missed something, please let me know.
>>>
>>> I am looking for a job file for our cluster. The available jobs files on
>>> FAQs are not working. They give me
>>> .machine0  .machines  .machines_current   files only
>>> wherein .machines has # and the other two are empty.
>>>
>>> The script that is working fine for Quantum Espresso for 44core
>>> partition is below
>>> #!/bin/sh
>>> #SBATCH -J test #job name
>>> #SBATCH -p 44core #partition name
>>> #SBATCH -N 1 #node
>>> #SBATCH -n 18 #core
>>> #SBATCH -o %x.o%j
>>> #SBATCH -e %x.e%j
>>> export I_MPI_PMI_LIBRARY=/usr/lib64/libpmi.so #Do not change here!!
>>> srun ~/soft/qe66/bin/pw.x  < case.in
>>> <https://urldefense.com/v3/__http://case.in__;!!Dq0X2DkFhyF93HkjWTBQKhk!GAoAiAGPo-P9rf1ZIm9YcQa-sF1GVFoIXYQ5SUQSFmUQH3oCvMobKrJ6gbDtT98andJs2Q$>
>>> > case.out
>>>
>>> I have compiled Wien2k_19.2 on the Centos queuing system which has the
>>> head node of Centos kernel Linux 3.10.0-1127.19.1.el7.x86_64.
>>>
>>> I used compilers_and_libraries_2020.2.254 , fftw-3.3.8 , libxc-4.34 for
>>> the installation.
>>>
>>> The details of the nodes that I can use are as follows (I can login into
>>> these nodes with my user password):
>>> NODELIST   NODES PARTITION   STATE CPUSS:C:T MEMORY TMP_DISK
>>> WEIGHT AVAIL_FE REASON
>>> elpidos1masteridle 4   4:1:1  157870
>>>  1   (null) none
>>> node01 172core   allocated 72 72:1:1 5156830
>>>  1   (null) none
>>> node02 172core   allocated 72 72:1:1 2576510
>>>  1   (null) none
>>> node03 172core   allocated 72 72:1:1 2576510
>>>  1   (null) none
>>> node09 144core   mixed 44 44:1:1 1286500
>>>  1   (null) none
>>> node10 144core   mixed 44 44:1:1 1286490
>>>  1   (null) none
>>> node11 1   52core*   allocated 52 52:1:1 1919320
>>>  1   (null) none
>>> node12 1   52core*   allocated 52 52:1:1 1919320
>>>  1   (null) none
>>>
>>> The other nodes have a mixture of the kernel as below.
>>>
>>>OS=Linux 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC
>>> 2020
>>>OS=Linux 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 UTC
>>> 2020
>>>OS=Linux 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016
>>>OS=Linux 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC
>>> 2019
>>>
>>> Your extensive help will improve my research productivity.
>>>
>>> Thank you very much.
>>> Regards
>>> Bhamu
>>>
>> ___
> 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] Need extensive help for a job file for slurm job scheduler cluster

[Dr. K. C. Bhamu]

Dear All

I need your extensive help.
I have tried to provide full details that can help you understand my
requirement. In case I have missed something, please let me know.

I am looking for a job file for our cluster. The available jobs files on
FAQs are not working. They give me
.machine0  .machines  .machines_current   files only
wherein .machines has # and the other two are empty.

The script that is working fine for Quantum Espresso for 44core partition
is below
#!/bin/sh
#SBATCH -J test #job name
#SBATCH -p 44core #partition name
#SBATCH -N 1 #node
#SBATCH -n 18 #core
#SBATCH -o %x.o%j
#SBATCH -e %x.e%j
export I_MPI_PMI_LIBRARY=/usr/lib64/libpmi.so #Do not change here!!
srun ~/soft/qe66/bin/pw.x  < case.in > case.out

I have compiled Wien2k_19.2 on the Centos queuing system which has the head
node of Centos kernel Linux 3.10.0-1127.19.1.el7.x86_64.

I used compilers_and_libraries_2020.2.254 , fftw-3.3.8 , libxc-4.34 for the
installation.

The details of the nodes that I can use are as follows (I can login into
these nodes with my user password):
NODELIST   NODES PARTITION   STATE CPUSS:C:T MEMORY TMP_DISK WEIGHT
AVAIL_FE REASON
elpidos1masteridle 4   4:1:1  157870  1
  (null) none
node01 172core   allocated 72 72:1:1 5156830  1
  (null) none
node02 172core   allocated 72 72:1:1 2576510  1
  (null) none
node03 172core   allocated 72 72:1:1 2576510  1
  (null) none
node09 144core   mixed 44 44:1:1 1286500  1
  (null) none
node10 144core   mixed 44 44:1:1 1286490  1
  (null) none
node11 1   52core*   allocated 52 52:1:1 1919320  1
  (null) none
node12 1   52core*   allocated 52 52:1:1 1919320  1
  (null) none

The other nodes have a mixture of the kernel as below.

   OS=Linux 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020
   OS=Linux 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 UTC 2020
   OS=Linux 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016
   OS=Linux 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC 2019

Your extensive help will improve my research productivity.

Thank you very much.
Regards
Bhamu

*Full details of the nodes are here:*

NodeName=elpidos Arch=x86_64 CoresPerSocket=1
   CPUAlloc=0 CPUTot=4 CPULoad=0.06
   AvailableFeatures=(null)
   ActiveFeatures=(null)
   Gres=(null)
   NodeAddr=10.0.0.250 NodeHostName=elpidos Version=20.02.3
   OS=Linux 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 UTC 2020
   RealMemory=15787 AllocMem=0 FreeMem=5597 Sockets=4 Boards=1
   State=IDLE ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A
   Partitions=master
   BootTime=2020-10-13T14:25:13 SlurmdStartTime=2020-10-13T14:25:26
   CfgTRES=cpu=4,mem=15787M,billing=4
   AllocTRES=
   CapWatts=n/a
   CurrentWatts=0 AveWatts=0
   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s


NodeName=node01 Arch=x86_64 CoresPerSocket=1
   CPUAlloc=72 CPUTot=72 CPULoad=72.00
   AvailableFeatures=(null)
   ActiveFeatures=(null)
   Gres=(null)
   NodeAddr=10.0.0.1 NodeHostName=node01 Version=20.02.3
   OS=Linux 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 UTC 2020
   RealMemory=515683 AllocMem=0 FreeMem=363362 Sockets=72 Boards=1
   State=ALLOCATED ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A
MCS_label=N/A
   Partitions=72core
   BootTime=2020-10-13T20:44:04 SlurmdStartTime=2020-10-14T05:44:23
   CfgTRES=cpu=72,mem=515683M,billing=72
   AllocTRES=cpu=72
   CapWatts=n/a
   CurrentWatts=0 AveWatts=0
   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s


NodeName=node02 Arch=x86_64 CoresPerSocket=1
   CPUAlloc=72 CPUTot=72 CPULoad=71.92
   AvailableFeatures=(null)
   ActiveFeatures=(null)
   Gres=(null)
   NodeAddr=10.0.0.2 NodeHostName=node02 Version=20.02.3
   OS=Linux 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 UTC 2020
   RealMemory=257651 AllocMem=0 FreeMem=142057 Sockets=72 Boards=1
   State=ALLOCATED ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A
MCS_label=N/A
   Partitions=72core
   BootTime=2020-10-13T20:44:04 SlurmdStartTime=2020-10-14T05:44:17
   CfgTRES=cpu=72,mem=257651M,billing=72
   AllocTRES=cpu=72
   CapWatts=n/a
   CurrentWatts=0 AveWatts=0
   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s


NodeName=node03 Arch=x86_64 CoresPerSocket=1
   CPUAlloc=72 CPUTot=72 CPULoad=71.96
   AvailableFeatures=(null)
   ActiveFeatures=(null)
   Gres=(null)
   NodeAddr=10.0.0.3 NodeHostName=node03 Version=20.02.3
   OS=Linux 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 UTC 2020
   RealMemory=257651 AllocMem=0 FreeMem=168118 Sockets=72 Boards=1
   State=ALLOCATED ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A
MCS_label=N/A
   Partitions=72core
   BootTime=2020-10-13T20:44:33 SlurmdStartTime=2020-10-14T05:43:35
   CfgTRES=cpu=72,mem=257651M,billing=72
   

Re: [Wien] few Wien2k compilation issues

[Dr. K. C. Bhamu]

Thank you Prof. Marks
I forgot to use the way you suggested.
I was using export for icc and ifort.
Now I could install FFTW-3.3.8.

Thank you very much.

Regards
Bhamu

On Sun, Nov 1, 2020 at 12:36 AM Laurence Marks 
wrote:

> The errors you see are not relevant.
>
> FFTW installation is really not for this list. It appears that you have an
> inadequate/corrupt OS, probably you did not install all the gcc files. That
> said, below is the script that I use to compile with ifort/icc (I do not
> recommend using gcc); you will need to edit the mpi library for your system
> and perhaps change the -ax flag and also the installation location:
>
> CC=icc
> MPICC=mpiicc
> FFLAGS="-O2 -axCORE-AVX512 -prec_div -r8 -pc80 -fpconstant -traceback
> -no-complex-limited-range -no-fast-transcendentals -fminshared \
> -L/opt/intel/compilers_and_libraries_2019.0.117/linux/mpi/intel64/lib
> -prec-sqrt -pad -mieee-fp -no-ftz  -fimf-precision=high \
> "
> CFLAGS="-O2 -axCORE-AVX512 -pc80 -traceback  -no-complex-limited-range
> -prec-sqrt -no-fast-transcendentals -fminshared -mieee-fp \
> -fimf-precision=high -no-ftz -prec-sqrt
> -L/opt/intel/compilers_and_libraries_2019.0.117/linux/mpi/intel64/lib"
> F77=ifort
>
> export MPICC FFLAGS CFLAGS CC F77
> ./configure --prefix=/opt/fftw-3.3.8 --enable-mpi --enable-threads
>
> On Sat, Oct 31, 2020 at 10:28 AM Dr. K. C. Bhamu 
> wrote:
>
>> Dear Wien2k Users
>>
>> I’m sorry to bother you in the weekend.
>>
>> I faced some issues while installing Wien2k_19.2 on Ubuntu-20.04 with the
>> mkl cluster version 2019.
>>
>> *Issue-1:*
>>
>> Without FFTW3 I could compile it but see below warning
>>
>>- *ifort: warning #10315: specifying -lm before files may supersede
>>the Intel(R) math library and affect performance*
>>
>> *One solution was already provided by Gavin for my previous post for
>> Wien2k_18 version.*
>>
>>
>> *https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17807.html*
>> <https://urldefense.com/v3/__https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17807.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!ADnT3eMa6f6mLpkUHqYGLJofpVwR4_nHBglkWE_zmvZX2kbf43AQicDAN1WVRhyU9eqf0A$>
>>
>> *I am wondering if this warning can be traced in the coming  updated
>> versions.*
>>
>>-
>> *cp: -r not specified; omitting directory 'SRC_BerryPI/BerryPI' *
>>
>> *Issue-2:*
>>
>>
>>- I am wondering if there is a way to compile Wien2k using the MKL
>>version of FFTW.
>>
>> I have defined the FFTW3 path of mkl but I met an error with a message
>> "ld: cannot find -lfftw3'
>>
>> *Issue-3:*
>>
>> Then I tried to install FFTW-3.3.8.
>>
>> But I could not manage to install FFTW-3.3.8. The error message is
>> mentioned below:
>>
>>
>> *FFTW-3.3.8 error while executing ./configure*
>>
>> checking sys/time.h usability... no
>> checking sys/time.h presence... yes
>> configure: WARNING: sys/time.h: present but cannot be compiled
>> configure: WARNING: sys/time.h: check for missing prerequisite
>> headers?
>> configure: WARNING: sys/time.h: see the Autoconf documentation
>> configure: WARNING: sys/time.h: section "Present But Cannot Be
>> Compiled"
>> configure: WARNING: sys/time.h: proceeding with the compiler's result
>> configure: WARNING: ##  ##
>> configure: WARNING: ## Report this to f...@fftw.org ##
>> configure: WARNING: ##  ##
>> checking for sys/time.h... no
>> checking altivec.h usability... no
>> checking altivec.h presence... no
>> checking for altivec.h... no
>> checking for an ANSI C-conforming const... yes
>> checking for inline... inline
>> checking for size_t... no
>> checking for uint32_t... no
>> checking for uint64_t... no
>> checking whether time.h and sys/time.h may both be included... no
>> checking for long double... no
>> checking for hrtime_t... no
>> checking size of int... 0
>> checking size of unsigned int... 0
>> checking size of long... 0
>> checking size of unsigned long... 0
>> checking size of long long... 0
>> checking size of unsigned long long... 0
>> checking size of size_t... 0
>> checking size of ptrdiff_t... 0
>> checking for ptrdiff_t... no
>> checking for uintptr_t... no
>> checking size of void *... 0
>> checking size of float... 0
>> checking size of double... 0
>> checking size of fft

[Wien] few Wien2k compilation issues

[Dr. K. C. Bhamu]

Dear Wien2k Users

I’m sorry to bother you in the weekend.

I faced some issues while installing Wien2k_19.2 on Ubuntu-20.04 with the
mkl cluster version 2019.

*Issue-1:*

Without FFTW3 I could compile it but see below warning

   - *ifort: warning #10315: specifying -lm before files may supersede the
   Intel(R) math library and affect performance*

*One solution was already provided by Gavin for my previous post for
Wien2k_18 version.*

*https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17807.html*


*I am wondering if this warning can be traced in the coming  updated
versions.*

   -
*cp: -r not specified; omitting directory 'SRC_BerryPI/BerryPI' *

*Issue-2:*


   - I am wondering if there is a way to compile Wien2k using the MKL
   version of FFTW.

I have defined the FFTW3 path of mkl but I met an error with a message "ld:
cannot find -lfftw3'

*Issue-3:*

Then I tried to install FFTW-3.3.8.

But I could not manage to install FFTW-3.3.8. The error message is
mentioned below:


*FFTW-3.3.8 error while executing ./configure*

checking sys/time.h usability... no
checking sys/time.h presence... yes
configure: WARNING: sys/time.h: present but cannot be compiled
configure: WARNING: sys/time.h: check for missing prerequisite headers?
configure: WARNING: sys/time.h: see the Autoconf documentation
configure: WARNING: sys/time.h: section "Present But Cannot Be Compiled"
configure: WARNING: sys/time.h: proceeding with the compiler's result
configure: WARNING: ##  ##
configure: WARNING: ## Report this to f...@fftw.org ##
configure: WARNING: ##  ##
checking for sys/time.h... no
checking altivec.h usability... no
checking altivec.h presence... no
checking for altivec.h... no
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... no
checking for uint32_t... no
checking for uint64_t... no
checking whether time.h and sys/time.h may both be included... no
checking for long double... no
checking for hrtime_t... no
checking size of int... 0
checking size of unsigned int... 0
checking size of long... 0
checking size of unsigned long... 0
checking size of long long... 0
checking size of unsigned long long... 0
checking size of size_t... 0
checking size of ptrdiff_t... 0
checking for ptrdiff_t... no
checking for uintptr_t... no
checking size of void *... 0
checking size of float... 0
checking size of double... 0
checking size of fftw_r2r_kind... 0
configure: error: sizeof(fftw_r2r_kind) test failed


Looking forward to hearing from you.

Thank you very much

Regards
bhamu
___
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

Re: [Wien] Structure optimization of Beta -Sn

[Dr. K. C. Bhamu]

hii Shamik,

open the cif file in VESTA and then export it again as a cif file. This new
cif file should work.
Regards
Bhamu


On Thu, Jun 4, 2020 at 12:43 PM Xavier Rocquefelte <
xavier.rocquefe...@univ-rennes1.fr> wrote:

> Dear Fabien
>
> This is strange... Perhaps a conversion problem. Yes I have used the
> following cif file and cif2struct works for me!
>
> Regards
>
> Xavier
>
>
>
> Le 04/06/2020 à 09:10, Tran, Fabien a écrit :
>
> Dear Xavier,
>
> I read your email from yesterday, but I thought that his struct file was
> correct, because I got the same struct file from this cif file:
>
> http://rruff.geo.arizona.edu/AMS/download.php?id=13353.cif=cif
>
> But you are right; if I visualize it, I can see that it is not beta-Sn.
> Besides, I can not convert cif to struct other cif files like the one that
> you sent. With cif2struct, I get "unknown space group name: I41/amds" and
> no struct file is generated.
>
> Did cif2struct work for you?
>
>
>
> --
> *From:* Wien 
>  on behalf of Xavier Rocquefelte
>  
> *Sent:* Wednesday, June 3, 2020 11:54 PM
> *To:* wien@zeus.theochem.tuwien.ac.at
> *Subject:* Re: [Wien] Structure optimization of Beta -Sn
>
>
> Dear Fabien,
>
> I explained to Shamik that the structure he was using was not correct.
>
> I also sent cif and struct file.
>
> See below a proper case.struct file.
>
> Shamik could you please send email only to the wienlist to avoid multiple
> answers from the list and many people trying to help you without having all
> the details?
>
>
> blebleble
> B   LATTICE,NONEQUIV.ATOMS:  1 141 I41/amd
> MODE OF CALC=RELA unit=bohr
>  11.019938 11.019938  6.011975 90.00 90.00 90.00
> ATOM   1: X=0.5000 Y=0.2500 Z=0.1250
>   MULT= 2  ISPLIT=-2
>1: X=0. Y=0.2500 Z=0.3750
> Sn1NPT=  781  R0=.1 RMT= 2.5 Z:  50.
> LOCAL ROT MATRIX:1.000 0.000 0.000
>  0.000 1.000 0.000
>  0.000 0.000 1.000
>   16  NUMBER OF SYMMETRY OPERATIONS
>  1 0 0 0.
>  0 1 0 0.
>  0 0 1 0.
>1
> -1 0 0 0.5000
>  0-1 0 0.
>  0 0 1 0.5000
>2
>  0-1 0 0.2500
>  1 0 0 0.7500
>  0 0 1 0.2500
>3
>  0 1 0 0.2500
> -1 0 0 0.2500
>  0 0 1 0.7500
>4
> -1 0 0 0.5000
>  0 1 0 0.
>  0 0-1 0.5000
>5
>  1 0 0 0.
>  0-1 0 0.
>  0 0-1 0.
>6
>  0 1 0 0.2500
>  1 0 0 0.7500
>  0 0-1 0.2500
>7
>  0-1 0 0.2500
> -1 0 0 0.2500
>  0 0-1 0.7500
>8
> -1 0 0 0.
>  0-1 0 0.
>  0 0-1 0.
>9
>  1 0 0 0.5000
>  0 1 0 0.
>  0 0-1 0.5000
>   10
>  0 1 0 0.7500
> -1 0 0 0.2500
>  0 0-1 0.7500
>   11
>  0-1 0 0.7500
>  1 0 0 0.7500
>  0 0-1 0.2500
>   12
>  1 0 0 0.5000
>  0-1 0 0.
>  0 0 1 0.5000
>   13
> -1 0 0 0.
>  0 1 0 0.
>  0 0 1 0.
>   14
>  0-1 0 0.7500
> -1 0 0 0.2500
>  0 0 1 0.7500
>   15
>  0 1 0 0.7500
>  1 0 0 0.7500
>  0 0 1 0.2500
>   16
>
>
>
>
>
> Le 03/06/2020 à 21:38, Tran, Fabien a écrit :
>
> Using a RKmax above 7 should not lead to completely wrong results.
> One important point is how the lattice constants a and c were varied. In a
> meaningful way?
>
>
> --
> *From:* Wien 
>  on behalf of shamik chakrabarti
>  
> *Sent:* Wednesday, June 3, 2020 8:40 PM
> *To:* A Mailing list for WIEN2k users
> *Subject:* Re: [Wien] Structure optimization of Beta -Sn
>
> Dear Dr. Tran,
>
>   I have used both plain GGA & nlvdw independently & in
> both cases the results are same. I have used Rmr*Kmax=9 for nlvdw & 7 for
> GGA. Do you think moving to larger Rmt*Kmax may solve the problem? I am
> currently going through the literature you have sent..
>
> with regards,
>
> On Wed, 3 Jun 2020 at 23:53, Tran, Fabien 
> wrote:
>
>> At first sight you struct file seems ok, but this is difficult to help
>> you without more details. For instance: Which functional have you used? Are
>> you keeping the c/a ratio fixed? Have you looked into the literature:
>>
>> https://aip.scitation.org/doi/abs/10.1063/1.4948434
>>
>>
>> --
>> *From:* Wien  on behalf of
>> shamik chakrabarti 
>> *Sent:* Wednesday, June 3, 2020 8:06 PM
>> *To:* A Mailing list for WIEN2k users
>> *Subject:* [Wien] Structure optimization of Beta -Sn
>>
>> Dear wien2k users,
>>
>>  I am trying to optimize the structure of
>> Beta - Sn. However, even after 20% increment of the volume there is no sign
>> of energy minima. I am attaching the struct file herewith this mail
>> for your consideration.
>>
>> Looking forward to hearing from you.
>>
>> with regards,
>>
>> --
>> Dr. Shamik Chakrabarti
>> Research Fellow
>> Department 

Re: [Wien] temperature dependent DFT (band, ...) calculations

[Dr. K. C. Bhamu]

Dear Prof. Peter,
Thank you very much for taking my query into consideration.
Your reply gives me some understanding and now I should read the paper you
mentioned and some other related appropriate literature.

Thank you very much.

Regards
Bhamu



On Sat, Apr 18, 2020 at 9:12 PM Peter Blaha 
wrote:

> If you are lucky, yes, but in general, the answer is NO !!!
>
> The lattice parameter is only a "mean value", and is a "prerequisite"
> for a finit temp calculation.
>
> But think about: what means "Termperature"  ?
>
> It vibrations, which are excited more or less with T. The atoms move
> around heavily and this can be even anisotropic.
> And one measures basically an average of a certain quantity while the
> atoms are vibrating around.
>
> Calculating phonons gives you entropy and free energies;
> Doing properties with temperature dependent average displacements gives
> you properties at finite T.
>
> One example: Physical Review B, 98 (2018), S. 235205.
>
>
> Am 18.04.2020 um 15:33 schrieb Dr. K. C. Bhamu:
> > Dear Experts,
> >
> > Could you please confirm that if I have temperature dependent lattice
> > parameters, from DFT calculation, then whatever properties like band,
> > phonon, elastic, ... , I compute will be considered as temperature
> > dependent ?
> > Yes, ionic positions should be relaxed what I know.
> > My own answer would be yes for this query but I need a confirmation.
> >
> > It would be a help from computational resources point of view. I do not
> > want to test the calculation and see the the difference as system is
> > more computational time demanding.
> >
> > Thank you very much.
> >
> > Regards
> > Bhamu
> >
> >
> >
> > ___
> > 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
> >
>
> --
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
> Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
> WWW:
>
> http://www.imc.tuwien.ac.at/tc_blaha-
>
> ___
> 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

Re: [Wien] temperature dependent DFT (band, ...) calculations

[Dr. K. C. Bhamu]

Dear Prof. L. Marks,
I do not think that this query is not related to this list.
Yes, it can be asked somewhere else but as Wien2K is my primary DFT tool so
I thought to ask here.
In many research papers we see that the authors report lattice parameters
at 0K and 300K.
If I take lattice parameters that is mentioned for 300K (from experimental
paper) and do a DFT calculation using Wien2K then should we consider our
all DFT calculations at 300K?
Ideally DFT does all the calculations at 0K but I am a bit confused in
such a situation where we have lattice parameters at some higher
temperature.
I think my query  appropriate this this list and hoping a
appropriate response to someone from the list.


Thank you very much.

Regards
Bhamu



On Sat, Apr 18, 2020 at 7:48 PM Laurence Marks 
wrote:

> I really think such questions are inappropriate for this list. If you have
> general physics questions such as this, you should ask on some appropriate
> list.
>
> This list is an appropriate place for real problems with using Wien2k.
>
> _
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu
>
> On Sat, Apr 18, 2020, 08:33 Dr. K. C. Bhamu  wrote:
>
>> Dear Experts,
>>
>> Could you please confirm that if I have temperature dependent lattice
>> parameters, from DFT calculation, then whatever properties like band,
>> phonon, elastic, ... , I compute will be considered as temperature
>> dependent ?
>> Yes, ionic positions should be relaxed what I know.
>> My own answer would be yes for this query but I need a confirmation.
>>
>> It would be a help from computational resources point of view. I do not
>> want to test the calculation and see the the difference as system is more
>> computational time demanding.
>>
>> Thank you very much.
>>
>> Regards
>> Bhamu
>>
>>
>> ___
>> Wien mailing list
>> Wien@zeus.theochem.tuwien.ac.at
>>
>> https://urldefense.com/v3/__http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien__;!!Dq0X2DkFhyF93HkjWTBQKhk!GRUj1pN4IwCnApRvu6jaYERxdhm3FHToVAls2nKQZOdCzklR_qLnsSwk3QRssfgfG3SCxg$
>> SEARCH the MAILING-LIST at:
>> https://urldefense.com/v3/__http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!GRUj1pN4IwCnApRvu6jaYERxdhm3FHToVAls2nKQZOdCzklR_qLnsSwk3QRssfhViYqsww$
>>
> ___
> 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] temperature dependent DFT (band, ...) calculations

[Dr. K. C. Bhamu]

Dear Experts,

Could you please confirm that if I have temperature dependent lattice
parameters, from DFT calculation, then whatever properties like band,
phonon, elastic, ... , I compute will be considered as temperature
dependent ?
Yes, ionic positions should be relaxed what I know.
My own answer would be yes for this query but I need a confirmation.

It would be a help from computational resources point of view. I do not
want to test the calculation and see the the difference as system is more
computational time demanding.

Thank you very much.

Regards
Bhamu
___
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

Re: [Wien] Elastic_1.0 issue in a particular distorted structure

[Dr. K. C. Bhamu]

Dear  Experts,

Greetings!!!

Could someone please help me to cure the issue?

Regards
Bhamu


On Wed, Feb 19, 2020 at 5:45 PM Dr. K. C. Bhamu  wrote:

> Dear Experts,
> Greetings!!!
>
> [Wien2k_19.1 with intel 2015 parallel version]
> [I will share original structure file/directory on your personal email].
>
> Before writing here I have asked developer of the code and remained
> unanswered.
> #
> I have tried Elastic_1.0 from" from Unsupported software goodies for few
> compounds and worked fine. But for a particular distorted case (in ABX4
> type structure)
>
> P4 10 P2/m
>  RELA
>  13.076905 12.925727  7.294343 90.00 90.00 90.369523
>
>   I am not able to fix the error.
>
> During initialisation the system information disappears and I get below
> corrupted structure file:
> Dst11_04
> P   LATTICE,NONEQUIV.ATOMS:  4
> MODE OF CALC=RELA unit=
>  13.076905 12.925727  7.294343 89.988541 90.74 90.369523
>4  NUMBER OF SYMMETRY OPERATIONS
> -1 0 0 0.
>  0-1 0 0.
>  0 0-1 0.
>1
> -1 0 0 0.
>  0-1 0 0.
>  0 0 1 0.
>2
>  1 0 0 0.
>  0 1 0 0.
>  0 0-1 0.
>3
>  1 0 0 0.
>  0 1 0 0.
>  0 0 1 0.
>4
>
> I will supply full directory/details to  only those who want to help me
> out.
>
> Regards
> Bhamu
>
>
>
___
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] Elastic_1.0 issue in a particular distorted structure

[Dr. K. C. Bhamu]

Dear Experts,
Greetings!!!

[Wien2k_19.1 with intel 2015 parallel version]
[I will share original structure file/directory on your personal email].

Before writing here I have asked developer of the code and remained
unanswered.
#
I have tried Elastic_1.0 from" from Unsupported software goodies for few
compounds and worked fine. But for a particular distorted case (in ABX4
type structure)

P4 10 P2/m
 RELA
 13.076905 12.925727  7.294343 90.00 90.00 90.369523

  I am not able to fix the error.

During initialisation the system information disappears and I get below
corrupted structure file:
Dst11_04
P   LATTICE,NONEQUIV.ATOMS:  4
MODE OF CALC=RELA unit=
 13.076905 12.925727  7.294343 89.988541 90.74 90.369523
   4  NUMBER OF SYMMETRY OPERATIONS
-1 0 0 0.
 0-1 0 0.
 0 0-1 0.
   1
-1 0 0 0.
 0-1 0 0.
 0 0 1 0.
   2
 1 0 0 0.
 0 1 0 0.
 0 0-1 0.
   3
 1 0 0 0.
 0 1 0 0.
 0 0 1 0.
   4

I will supply full directory/details to  only those who want to help me out.

Regards
Bhamu
___
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

Re: [Wien] Problem in Bandstructure plot

[Dr. K. C. Bhamu]

Hii,
Did you shift the the bands with Fermi?

Use case.insp and put FERMI in this file at  and run lapw2 and
spaghetti again.

Regards
Bhamu



On Sat, Nov 23, 2019, 10:46 Peeyush kumar kamlesh <
peeyush.physik@gmail.com> wrote:

> Dear Users,
> Greetings!
> Generally when we plot bandstructure in WIEN2k, it shows fermi level (Ef =
> 0) just above the valance band. But when i am plotting it for my compound
> then fermi level is crossing the valance band. Can you please explain the
> problem and suggest a solution?
>
> Regards
> Peeyush Kumar Kamlesh
> ___
> 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] new mBJ parameters (PHYSICAL REVIEW B99, 035139 (2019))

[Dr. K. C. Bhamu]

Dear Dr. Tran,

I found a RRB paper [1] where the authors have re-parameterized the c
parameter.

cfit=2.2507−0.03376L (L=0 for 3D systems).

As we need A,B,e and c to do a mBJ calculation.
Could you please estimate and tell us (or add one more mBJ option in
Wien2K) the values of above parameters from this paper?
[1]. https://journals.aps.org/prb/pdf/10.1103/PhysRevB.99.035139

regards
Bhamu
___
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

Re: [Wien] error in analysing data from elastic_1.1m package

[Dr. K. C. Bhamu]

Dear Gavin,
Thank you very much for pointing useful suggestion.
Actually I have activated conda environment which was creating problem.

Now it worked on local PC.

Thank you very much.
Regards
Bhamu


On Fri, Nov 8, 2019 at 8:52 AM Gavin Abo  wrote:

> The error below with ElaStic [1] might be coming from running
> ElaStic_Analyze with Python 3.x.  You might need to run it with Python 2.x,
> or modify Python script to work with Python 3.x [2,3].
> [1] http://exciting-code.org/elastic
> [2] https://python-future.org/compatible_idioms.html
> [3]
> https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python
>
> On 11/7/2019 7:34 AM, Dr. K. C. Bhamu wrote:
>
> Dear Wien2k users,
>
> Greetings!!
>
> I could successfully run all scf calculations with Elast_1.1m package
> interfaced with latest Wien2k_19.1.
> I am able to get the elastic constants on my cluster.
> But Xterm is not set for xmgrace so I could not visualize the plots on
> cluster.
>
> When I tried to analysis the results on my local PC (with Ubutu_18.04.1
> and Wien2k_18.2 compiled with ifort), I encounter an error "raw_input not
> found" while same files worked on cluster.
>
> The detailed error is below:
>
> kcbhamu@kcbhamu-HP:~/Documents/work/w2k/case$ *./ElaStic_Analyze*
> Traceback (most recent call last):
>   File ".//ElaStic_Analyze_Energy", line 205, in 
> print >>f, strain,'   ', energy
> TypeError: unsupported operand type(s) for >>:
> 'builtin_function_or_method' and '_io.TextIOWrapper'. Did you mean
> "print(, file=)"?
> Traceback (most recent call last):
>   File "./ElaStic_Analyze", line 52, in 
> var = raw_input('>>>> press any key to continue  ')
> NameError: name 'raw_input' is not defined
>
> but with /ElaStic_Analyze_Energy I am getting different error.
>
> kcbhamu@kcbhamu-HP:~/Documents/work/w2k/case$* ./ElaStic_Analyze_Energy *
> Traceback (most recent call last):
>   File "./ElaStic_Analyze_Energy", line 205, in 
> print >>f, strain,'   ', energy
> TypeError: unsupported operand type(s) for >>:
> 'builtin_function_or_method' and '_io.TextIOWrapper'. Did you mean
> "print(, file=)"?
>
> *My INFO_ElaStic file reads:*
> Order of elastic constants  = 2
> Method of calculation   = Energy
> DFT code name   = WIEN2k
> Space-group number  = 129
> Volume of equilibrium unit cell = 564.617991633 [a.u^3]
> Maximum Lagrangian strain   = 0.07
> Number of distorted structures  = 7
>
> Could someone please help me how to overcome this error?
>
> Please let me know if any additional information is required for the same.
>
> Regards
> Bhamu
>
> ___
> 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] error in analysing data from elastic_1.1m package

[Dr. K. C. Bhamu]

Dear Wien2k users,

Greetings!!

I could successfully run all scf calculations with Elast_1.1m package
interfaced with latest Wien2k_19.1.
I am able to get the elastic constants on my cluster.
But Xterm is not set for xmgrace so I could not visualize the plots on
cluster.

When I tried to analysis the results on my local PC (with Ubutu_18.04.1 and
Wien2k_18.2 compiled with ifort), I encounter an error "raw_input not
found" while same files worked on cluster.

The detailed error is below:

kcbhamu@kcbhamu-HP:~/Documents/work/w2k/case$ *./ElaStic_Analyze*
Traceback (most recent call last):
  File ".//ElaStic_Analyze_Energy", line 205, in 
print >>f, strain,'   ', energy
TypeError: unsupported operand type(s) for >>: 'builtin_function_or_method'
and '_io.TextIOWrapper'. Did you mean "print(,
file=)"?
Traceback (most recent call last):
  File "./ElaStic_Analyze", line 52, in 
var = raw_input(' press any key to continue  ')
NameError: name 'raw_input' is not defined

but with /ElaStic_Analyze_Energy I am getting different error.

kcbhamu@kcbhamu-HP:~/Documents/work/w2k/case$* ./ElaStic_Analyze_Energy *
Traceback (most recent call last):
  File "./ElaStic_Analyze_Energy", line 205, in 
print >>f, strain,'   ', energy
TypeError: unsupported operand type(s) for >>: 'builtin_function_or_method'
and '_io.TextIOWrapper'. Did you mean "print(,
file=)"?

*My INFO_ElaStic file reads:*
Order of elastic constants  = 2
Method of calculation   = Energy
DFT code name   = WIEN2k
Space-group number  = 129
Volume of equilibrium unit cell = 564.617991633 [a.u^3]
Maximum Lagrangian strain   = 0.07
Number of distorted structures  = 7

Could someone please help me how to overcome this error?

Please let me know if any additional information is required for the same.

Regards
Bhamu
___
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

Re: [Wien] wien2k installation: XSEDE

[Dr. K. C. Bhamu]

Dear Bushra,

I hope you are using the same cluster you are using before (NERSC:
cori/edison).
>From your job file it seems that you want to submit job on edison (28
cores).
Please make sure that edison is still working. My available information
says that edison has retired now. Please confirm from the system admin.
I would suggest you to submit job on cori. A job file is there on web-page
of NERSC.

Anyway, please send the details as Prof. Peter has requested so that he can
help you.


Regards
Bhamu





On Mon, Nov 4, 2019 at 1:14 PM Peter Blaha 
wrote:

> What means:  " does not work" ??
>
> We need details.
>
> On 11/3/19 10:48 PM, BUSHRA SABIR wrote:
> > Hi experts,
> > I am working on super computer with WIEN2K/19.1 and using the following
> > job file, but this job file is not working for parallel run of LAPW1.
> > Need help to improve this job file.
> > #!/bin/bash
> > #SBATCH -N 1
> > #SBATCH -p RM
> > #SBATCH --ntasks-per-node 28
> > #SBATCH -t 2:0:00
> > # echo commands to stdout
> > # set -x
> > module load mpi
> > module load intel
> > export SCRATCH="./"
> >
> > #rm .machines
> > #write .machines file
> > echo '#' .machines
> > # example for an MPI parallel lapw0
> > #echo 'lapw0:'`hostname`'  :'$nproc >> .machines
> > # k-point and mpi parallel lapw1/2
> >
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> > echo '1:'`hostname`':1' >> .machines
> >
> > echo 'granularity:1' >>.machines
> > echo 'extrafine:1' >>.machines
> > export SCRATCH=./
> > runsp_lapw -p -ec 0.01 -cc 0.0001 -i 40 -fc 1.0
> >
> >
> >   Bushra
> >
> >
> > 
> >
> > ___
> > 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
> >
>
> --
>
>P.Blaha
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
> Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
> WWW:   http://www.imc.tuwien.ac.at/TC_Blaha
> --
> ___
> 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

Re: [Wien] some one using elast package can help me [INVALID INPUT PARAMETER]

[Dr. K. C. Bhamu]

hmmm,

Thanks Prof. Marks for suggesting to try a manual approach and I found one
case_scf* was missing.

I managed many calculations with a script so in the problematic case,
tetra__-4.0* calculations terminated incorrectly.
Now, I managed the calculations.

Thank you very much.

Regards
Bhamu



On Thu, Sep 26, 2019 at 6:39 PM Dr. K. C. Bhamu  wrote:

> Thank you Prof. Gerhard and Marks,
> I am checking the calculations manually and preparing *ene and *lat files.
> I see some files are missing.
> Will update here for final conclusions, what mistake I did.
> Regards
> Bhamu
>
>
>
> On Thu, Sep 26, 2019 at 6:32 PM Fecher, Gerhard 
> wrote:
>
>> Dear Bahmu,
>> there are no changes in SRC_elast since 2013 (most are from 2002 !) that
>> is, it should not matter which version one uses (supposed they are compiled
>> correctly)
>>
>> ***MESSAGE FROM ROUTINE DPOLFT IN LIBRARY SLATEC.
>> shows that a problem in anaelast appears when trying to fit the data for
>> tetra (maybe later for rhomb, too)
>>
>> this means your tetra.lat and/or tera.ene files have a problem (and/or
>> rhomb.ene and/or rhomb.lat)
>> they should be created by the ana_elast_lapw script (not by the anaelast
>> program !)
>> the existence of eos.xxx files only is not enough !
>>
>> Do all necessary files exist and are all names and directories correct ?
>>
>> Ciao
>> Gerhard
>>
>> DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
>> "I think the problem, to be quite honest with you,
>> is that you have never actually known what the question is."
>>
>> 
>> Dr. Gerhard H. Fecher
>> Institut of Inorganic and Analytical Chemistry
>> Johannes Gutenberg - University
>> 55099 Mainz
>> and
>> Max Planck Institute for Chemical Physics of Solids
>> 01187 Dresden
>> 
>> Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Dr.
>> K. C. Bhamu [kcbham...@gmail.com]
>> Gesendet: Donnerstag, 26. September 2019 14:39
>> An: A Mailing list for WIEN2k users
>> Betreff: Re: [Wien] some one using elast package can help me [INVALID
>> INPUT PARAMETER]
>>
>> Yes, I  also doubt about energy but I could not find any energy related
>> issue.
>> Also, switching over Wien2k_18.2 is not an issue as other cases are
>> working fine.
>> Please find the data directory here
>> https://we.tl/t-2d5o1Tp9e2
>>
>> Regards
>> Bhamu
>>
>>
>> On Thu, Sep 26, 2019 at 5:45 PM Laurence Marks > <mailto:laurence.ma...@gmail.com>> wrote:
>> Probably you have some incorrect energies or something else is wrong in
>> one or more of your calculations. It might be that there is a format
>> problem; if you used 19.1 to calculate use the 19.1 elastic package. And/or
>> switch to only using 18.2. I suggest that you plot the values by hand,
>> which may also indicate the problem.
>>
>> Without the actual values you used I doubt that anyone can help you much
>> more than this. They would need to replicate the problem in order to solve
>> it.
>>
>> _
>> Professor Laurence Marks
>> "Research is to see what everybody else has seen, and to think what
>> nobody else has thought", Albert Szent-Gyorgi
>> www.numis.northwestern.edu<http://www.numis.northwestern.edu>
>>
>> On Thu, Sep 26, 2019, 06:59 Dr. K. C. Bhamu > kcbham...@gmail.com>> wrote:
>> Dear Wien2k users,
>>
>> I am facing this issue, INVALID INPUT PARAMETER,  first time and I could
>> not figure it out how to solve this problem.
>> I run a elastic calculation with very recent version of Wien2k and then
>> tried to fit the data with Wien2k_18.2.
>> For one case I do not see any issue but for another case (225 SG for both
>> the case), ana_elast_lapw is not generating rhomb.strain rhomb.fit,
>> tetra.strain, and tetra.fit in the */results/output data.
>> my rhmob/tetra/eos.ene and hmob/tetra/eos.lat files in */results/output
>> seems okay to me.
>> The */results/*struct files are correctly read from its home dir (one
>> step own dir).
>> I compared the case with another case which has been compiled with no
>> error/warning and I see no data file is missing.
>>
>>
>> The message on screen I am getting is
>>
>>
>> eos_
>> tetra_
>> rhomb_
>>  ***
>>  ***
>>   We are calculating elastic tensor for
>>  F Cubic phase:
>&g

Re: [Wien] some one using elast package can help me [INVALID INPUT PARAMETER]

[Dr. K. C. Bhamu]

Thank you Prof. Gerhard and Marks,
I am checking the calculations manually and preparing *ene and *lat files.
I see some files are missing.
Will update here for final conclusions, what mistake I did.
Regards
Bhamu



On Thu, Sep 26, 2019 at 6:32 PM Fecher, Gerhard  wrote:

> Dear Bahmu,
> there are no changes in SRC_elast since 2013 (most are from 2002 !) that
> is, it should not matter which version one uses (supposed they are compiled
> correctly)
>
> ***MESSAGE FROM ROUTINE DPOLFT IN LIBRARY SLATEC.
> shows that a problem in anaelast appears when trying to fit the data for
> tetra (maybe later for rhomb, too)
>
> this means your tetra.lat and/or tera.ene files have a problem (and/or
> rhomb.ene and/or rhomb.lat)
> they should be created by the ana_elast_lapw script (not by the anaelast
> program !)
> the existence of eos.xxx files only is not enough !
>
> Do all necessary files exist and are all names and directories correct ?
>
> Ciao
> Gerhard
>
> DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
> "I think the problem, to be quite honest with you,
> is that you have never actually known what the question is."
>
> 
> Dr. Gerhard H. Fecher
> Institut of Inorganic and Analytical Chemistry
> Johannes Gutenberg - University
> 55099 Mainz
> and
> Max Planck Institute for Chemical Physics of Solids
> 01187 Dresden
> ____________
> Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Dr. K.
> C. Bhamu [kcbham...@gmail.com]
> Gesendet: Donnerstag, 26. September 2019 14:39
> An: A Mailing list for WIEN2k users
> Betreff: Re: [Wien] some one using elast package can help me [INVALID
> INPUT PARAMETER]
>
> Yes, I  also doubt about energy but I could not find any energy related
> issue.
> Also, switching over Wien2k_18.2 is not an issue as other cases are
> working fine.
> Please find the data directory here
> https://we.tl/t-2d5o1Tp9e2
>
> Regards
> Bhamu
>
>
> On Thu, Sep 26, 2019 at 5:45 PM Laurence Marks  <mailto:laurence.ma...@gmail.com>> wrote:
> Probably you have some incorrect energies or something else is wrong in
> one or more of your calculations. It might be that there is a format
> problem; if you used 19.1 to calculate use the 19.1 elastic package. And/or
> switch to only using 18.2. I suggest that you plot the values by hand,
> which may also indicate the problem.
>
> Without the actual values you used I doubt that anyone can help you much
> more than this. They would need to replicate the problem in order to solve
> it.
>
> _
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu<http://www.numis.northwestern.edu>
>
> On Thu, Sep 26, 2019, 06:59 Dr. K. C. Bhamu  kcbham...@gmail.com>> wrote:
> Dear Wien2k users,
>
> I am facing this issue, INVALID INPUT PARAMETER,  first time and I could
> not figure it out how to solve this problem.
> I run a elastic calculation with very recent version of Wien2k and then
> tried to fit the data with Wien2k_18.2.
> For one case I do not see any issue but for another case (225 SG for both
> the case), ana_elast_lapw is not generating rhomb.strain rhomb.fit,
> tetra.strain, and tetra.fit in the */results/output data.
> my rhmob/tetra/eos.ene and hmob/tetra/eos.lat files in */results/output
> seems okay to me.
> The */results/*struct files are correctly read from its home dir (one step
> own dir).
> I compared the case with another case which has been compiled with no
> error/warning and I see no data file is missing.
>
>
> The message on screen I am getting is
>
>
> eos_
> tetra_
> rhomb_
>  ***
>  ***
>   We are calculating elastic tensor for
>  F Cubic phase:
>blebleble
>   At volume:
>   1066.03 bohr^3 per formula
>  ***
>  ***
>
>
>  *
> Birch Murnaghan fit done
>
> At volume=   1066.03 bohr^3
> Pressure is: 0.12 a.u. or   0.178 GPa
> Bulk modulus is: 0.009284 a.u or   136.579 GPa=(C11+2C12)/3
>  *
>
> Hit return to continue
>
>  ***MESSAGE FROM ROUTINE DPOLFT IN LIBRARY SLATEC.
>  ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>  *  INVALID INPUT PARAMETER.
>  *  ERROR NUMBER = 2
>  *
>  ***END OF MESSAGE
>
>  ***JOB ABORT DUE TO UNRECOVERED ERROR.
> 0  ERROR MESSAGE SUMMARY
>  LIBRARYSUBROUTINE 

Re: [Wien] some one using elast package can help me [INVALID INPUT PARAMETER]

[Dr. K. C. Bhamu]

Yes, I  also doubt about energy but I could not find any energy related
issue.
Also, switching over Wien2k_18.2 is not an issue as other cases are working
fine.
Please find the data directory here
https://we.tl/t-2d5o1Tp9e2

Regards
Bhamu


On Thu, Sep 26, 2019 at 5:45 PM Laurence Marks 
wrote:

> Probably you have some incorrect energies or something else is wrong in
> one or more of your calculations. It might be that there is a format
> problem; if you used 19.1 to calculate use the 19.1 elastic package. And/or
> switch to only using 18.2. I suggest that you plot the values by hand,
> which may also indicate the problem.
>
> Without the actual values you used I doubt that anyone can help you much
> more than this. They would need to replicate the problem in order to solve
> it.
>
> _
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu
>
> On Thu, Sep 26, 2019, 06:59 Dr. K. C. Bhamu  wrote:
>
>> Dear Wien2k users,
>>
>> I am facing this issue, INVALID INPUT PARAMETER,  first time and I could
>> not figure it out how to solve this problem.
>> I run a elastic calculation with very recent version of Wien2k and then
>> tried to fit the data with Wien2k_18.2.
>> For one case I do not see any issue but for another case (225 SG for both
>> the case), ana_elast_lapw is not generating rhomb.strain rhomb.fit,
>> tetra.strain, and tetra.fit in the */results/output data.
>> my rhmob/tetra/eos.ene and hmob/tetra/eos.lat files in */results/output
>> seems okay to me.
>> The */results/*struct files are correctly read from its home dir (one
>> step own dir).
>> I compared the case with another case which has been compiled with no
>> error/warning and I see no data file is missing.
>>
>>
>> The message on screen I am getting is
>>
>>
>> eos_
>> tetra_
>> rhomb_
>>  ***
>>  ***
>>   We are calculating elastic tensor for
>>  F Cubic phase:
>>blebleble
>>
>>   At volume:
>>   1066.03 bohr^3 per formula
>>  ***
>>  ***
>>
>>
>>  *
>> Birch Murnaghan fit done
>>
>> At volume=   1066.03 bohr^3
>> Pressure is: 0.12 a.u. or   0.178 GPa
>> Bulk modulus is: 0.009284 a.u or   136.579 GPa=(C11+2C12)/3
>>  *
>>
>> Hit return to continue
>>
>>  ***MESSAGE FROM ROUTINE DPOLFT IN LIBRARY SLATEC.
>>  ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>  *  INVALID INPUT PARAMETER.
>>  *  ERROR NUMBER = 2
>>  *
>>  ***END OF MESSAGE
>>
>>  ***JOB ABORT DUE TO UNRECOVERED ERROR.
>> 0  ERROR MESSAGE SUMMARY
>>  LIBRARYSUBROUTINE MESSAGE START NERR LEVEL COUNT
>>  SLATEC DPOLFT INVALID INPUT PARAME 2 1 1
>>
>>
>> **
>>  Plotting results 
>> **
>>
>> press RETURN to continue
>>
>> Do you want a hardcopy? (y/N)
>> press RETURN to continue
>> "tempor", line 4: warning: Cannot find or open file "tetra.strain"
>> "tempor", line 4: warning: Cannot find or open file "tetra.fit"
>> "tempor", line 4: No data in plot
>>
>> Do you want a hardcopy? (y/N)
>> press RETURN to continue
>> "tempor", line 4: warning: Cannot find or open file "rhomb.strain"
>> "tempor", line 4: warning: Cannot find or open file "rhomb.fit"
>> "tempor", line 4: No data in plot
>>
>> Do you want a hardcopy? (y/N)
>> mv: No match.
>>
>>
>> Any help will be appreciated.
>>
>> Regards
>> Bhamu
>> ___
>> Wien mailing list
>> Wien@zeus.theochem.tuwien.ac.at
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=lijmPdgURKLG8Jg1yGYgJRKN7TbUVllHL7wEWICSZmw=gjgKXw7in4dU-_DyiwF-R7H3gKY4B9D-KSSWbKLD91Q=
>> SEARCH the MAILING-LIST at:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=lijmPdgURKLG8Jg1yGYgJRKN7TbUVllHL7wEWICSZmw=Vb3tfWjMcKdmWWVWWIWDcyaWASQGOLlpnMatgIrn_GU=
>>
> ___
> 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] some one using elast package can help me [INVALID INPUT PARAMETER]

[Dr. K. C. Bhamu]

Dear Wien2k users,

I am facing this issue, INVALID INPUT PARAMETER,  first time and I could
not figure it out how to solve this problem.
I run a elastic calculation with very recent version of Wien2k and then
tried to fit the data with Wien2k_18.2.
For one case I do not see any issue but for another case (225 SG for both
the case), ana_elast_lapw is not generating rhomb.strain rhomb.fit,
tetra.strain, and tetra.fit in the */results/output data.
my rhmob/tetra/eos.ene and hmob/tetra/eos.lat files in */results/output
seems okay to me.
The */results/*struct files are correctly read from its home dir (one step
own dir).
I compared the case with another case which has been compiled with no
error/warning and I see no data file is missing.


The message on screen I am getting is


eos_
tetra_
rhomb_
 ***
 ***
  We are calculating elastic tensor for
 F Cubic phase:
   blebleble

  At volume:
  1066.03 bohr^3 per formula
 ***
 ***


 *
Birch Murnaghan fit done

At volume=   1066.03 bohr^3
Pressure is: 0.12 a.u. or   0.178 GPa
Bulk modulus is: 0.009284 a.u or   136.579 GPa=(C11+2C12)/3
 *

Hit return to continue

 ***MESSAGE FROM ROUTINE DPOLFT IN LIBRARY SLATEC.
 ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
 *  INVALID INPUT PARAMETER.
 *  ERROR NUMBER = 2
 *
 ***END OF MESSAGE

 ***JOB ABORT DUE TO UNRECOVERED ERROR.
0  ERROR MESSAGE SUMMARY
 LIBRARYSUBROUTINE MESSAGE START NERR LEVEL COUNT
 SLATEC DPOLFT INVALID INPUT PARAME 2 1 1


**
 Plotting results 
**

press RETURN to continue

Do you want a hardcopy? (y/N)
press RETURN to continue
"tempor", line 4: warning: Cannot find or open file "tetra.strain"
"tempor", line 4: warning: Cannot find or open file "tetra.fit"
"tempor", line 4: No data in plot

Do you want a hardcopy? (y/N)
press RETURN to continue
"tempor", line 4: warning: Cannot find or open file "rhomb.strain"
"tempor", line 4: warning: Cannot find or open file "rhomb.fit"
"tempor", line 4: No data in plot

Do you want a hardcopy? (y/N)
mv: No match.


Any help will be appreciated.

Regards
Bhamu
___
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

Re: [Wien] VK-COUL not well converged: Increase GMAX or decrease NCON

[Dr. K. C. Bhamu]

Dear Tran,
Thanks for explaining the meaning of warnings.
Yes,  warning disappears by  increasing Gmax to 14.

What is mean by NCON?
In which file it is written and is there any batch command to increase it?

Regards
Bhamu

On Sun, Aug 25, 2019 at 4:17 PM  wrote:

> This is a warning from lapw0, which indicates that the Fourier expansion
> of the Coulomb potential may not be well converged. Increase GMAX in
> case.in2 to 16 to see if this warning disappears.
>
>
> On Sunday 2019-08-25 12:10, Dr. K. C. Bhamu wrote:
>
> >Date: Sun, 25 Aug 2019 12:10:49
> >From: Dr. K. C. Bhamu 
> >Reply-To: A Mailing list for WIEN2k users <
> wien@zeus.theochem.tuwien.ac.at>
> >To: A Mailing list for WIEN2k users 
> >Subject: [Wien] VK-COUL not well converged: Increase GMAX or decrease NCON
> >
> >Dear Experts,
> >We are running a GGA-PBE calculation on a cubic double perovskite on
> Wien2k_19.1 with intel compilers with
> >
> > 8 10   6   ELPA pxq hm (R-MT*K-MAX,MAX L IN
> WF,V-NMT,lib,gridshape,hm/lm)
> >GMAX=12
> >We are getting VK-COUL error.
> >
> >Exact warning is this:  VK-COUL not well converged: Increase GMAX or
> decrease NCON
> >There is no information on mailing list and UG on this warning.
> >Could someone please explore the meaning of these warnings?
> >
> >PS: Running scf with dense k-mesh on a scf that was finished with
> Wien2k_18.2.
> >
> >regards
> >Bhamu
> >
> >
> >___
> 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] VK-COUL not well converged: Increase GMAX or decrease NCON

[Dr. K. C. Bhamu]

Dear Experts,
We are running a GGA-PBE calculation on a cubic double perovskite on
Wien2k_19.1 with intel compilers with

 8 10   6   ELPA pxq hm (R-MT*K-MAX,MAX L IN
WF,V-NMT,lib,gridshape,hm/lm)
GMAX=12
We are getting VK-COUL error.

Exact warning is this:  VK-COUL not well converged: Increase GMAX or
decrease NCON
There is no information on mailing list and UG on this warning.
Could someone please explore the meaning of these warnings?

PS: Running scf with dense k-mesh on a scf that was finished with
Wien2k_18.2.

regards
Bhamu
___
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

Re: [Wien] Fwd: YS-PBE0 with -so

[Dr. K. C. Bhamu]

Thanks Gavin for the update.
Yes the new version is WIEN2k_19.1 (Release 25/6/2019).
I have applied your patch. Will update the status of the calculations here.

Regards
Bhamu


On Sun, Aug 11, 2019 at 5:45 PM Gavin Abo  wrote:

> WIEN2k 19.1 has the fixes for the first two bugs [1,2].  It should not
> have the fix for the third bug [3].
>
> If you would like to use my hfpara_lapw.patch for resolving the third bug
> [3], make sure you are using the current package dated 25/6/2019 from the
> download area of the WIEN2k website (as there was an older 19.1 version
> when it was first released) then apply the patch:
>
> username@computername:~$ cd $WIENROOT
> username@computername:~/WIEN2k$ cat WIEN2k_VERSION
> WIEN2k_19.1 (Release 25/6/2019)
> username@computername:~/WIEN2k$ wget
> https://raw.githubusercontent.com/gsabo/WIEN2k-Patches/master/19.1/hfpara_lapw.patch
> ...
> username@computername:~/WIEN2k$ patch -b hfpara_lapw hfpara_lapw.patch
> patching file hfpara_lapw
> On 8/11/2019 2:00 AM, Dr. K. C. Bhamu wrote:
>
> Dear Tran,
> I have loaded the Wien2k_19.1 version and I see all the bugs have been
> fixed.
> Will update here if I still encounter any issue.
>
> Bhamu
>
> On Sun, Aug 11, 2019 at 12:40 AM  wrote:
>
>> Hi,
>>
>> When the HF/hybrid calculation starts, a vector file (if present)
>> generated from a previous calculation will be used. If it was
>> generated with another k-mesh, then the HF/hybrid calculation will
>> crash. In such a case, the solution is to delete this vector file with
>> clean_lapw before run_lapw -hf ...
>>
>> Besides, you used 3x3x2 for both the normal k-mesh and the
>> reduced one. This is useless (see UG).
>>
>> Recently, several bugs related to HF+SO with redklist/newklist were fixed:
>>  [1]
>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18301.html
>>  [2]
>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18306.html
>>  [3]
>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18833.html
>>
>> FT
>>
> ___
> 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

Re: [Wien] Fwd: YS-PBE0 with -so

[Dr. K. C. Bhamu]

Dear Tran,
I have loaded the Wien2k_19.1 version and I see all the bugs have been
fixed.
Will update here if I still encounter any issue.

Bhamu

On Sun, Aug 11, 2019 at 12:40 AM  wrote:

> Hi,
>
> When the HF/hybrid calculation starts, a vector file (if present)
> generated from a previous calculation will be used. If it was
> generated with another k-mesh, then the HF/hybrid calculation will
> crash. In such a case, the solution is to delete this vector file with
> clean_lapw before run_lapw -hf ...
>
> Besides, you used 3x3x2 for both the normal k-mesh and the
> reduced one. This is useless (see UG).
>
> Recently, several bugs related to HF+SO with redklist/newklist were fixed:
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18301.html
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18306.html
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18833.html
>
> FT
>
> On Friday 2019-08-09 08:20, Dr. K. C. Bhamu wrote:
>
> >Date: Fri, 9 Aug 2019 08:20:33
> >From: Dr. K. C. Bhamu 
> >Reply-To: A Mailing list for WIEN2k users <
> wien@zeus.theochem.tuwien.ac.at>
> >To: A Mailing list for WIEN2k users 
> >Subject: Re: [Wien] Fwd: YS-PBE0 with -so
> >
> >Dear Tran,
> >(Wien2k_18.1 with mkl and fftw3.4 on a cluster).
> >
> >I am getting error with hf(+so) scf.
> >
>
> >What I followed is:
> >
> >1. PBE+SO
> >2. save_lapw -d 
> >3. init_hf_lapw and used reduced and nonshifted mesh 3 3 2 over the
> original 7 7 5 mesh (detailed inputs are appended below).
> >Here I did not increase the default Gmax which is 6 while in my original
> calculation it is 8. Should I increase it?
> >4. run_lapw -redklist -hf -p -so
> >
> >I am getting Parallel HF error
> >cat *error:
> >error in hf
> >error in hf
> >error in hf
> >error in hf
> >error in hf
> >error in hf
> >**  Error in Parallel HF
> >**  testerror: Error in Parallel HF
> >
> >Inputs for init_hf_lapw
> >
> >Do you want to use a REDUCED k-mesh for HF (saving cpu-time) (Y/n) ?
> >y
> >This script runs 'x kgen' twice and generates equivalent meshes in the
> IBZ and FBZ.
> >How many k-points in the full BZ?
> >If you type 0 you can give 3 integers for nx,ny,nz
> >0
> >How many in x?
> >3
> >How many in y?
> >3
> >How many in z?
> >2
> >  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
> > length of reciprocal lattice vectors:   0.549   0.549   0.387   0.000
> 0.000   0.000
> >  Specify 3 mesh-divisions (n1,n2,n3):
> >  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
> >   6  k-points generated, ndiv=   3   3
> 2
> >KGEN ENDS
> >0.007u 0.030s 0:00.04 75.0% 0+0k 0+240io 0pf+0w
> >   1  symmetry operations without inversion
> >  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
> > length of reciprocal lattice vectors:   0.549   0.549   0.387   0.000
> 0.000   0.000
> >  Specify 3 mesh-divisions (n1,n2,n3):
> >  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
> >  18  k-points generated, ndiv=   3   3
> 2
> >KGEN ENDS
> >0.006u 0.026s 0:00.03 66.6% 0+0k 0+56io 0pf+0w
> >Give nx,ny,nz for the reduced mesh
> >nx=?
> >3
> >ny=?
> >3
> >nz=?
> >2
> >  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
> > length of reciprocal lattice vectors:   0.549   0.549   0.387   0.000
> 0.000   0.000
> >  Specify 3 mesh-divisions (n1,n2,n3):
> >  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
> >   6  k-points generated, ndiv=   3   3
> 2
> >KGEN ENDS
> >0.004u 0.029s 0:00.03 66.6% 0+0k 0+40io 0pf+0w
> >   1  symmetry operations without inversion
> >  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
> > length of reciprocal lattice vectors:   0.549   0.549   0.387   0.000
> 0.000   0.000
> >  Specify 3 mesh-divisions (n1,n2,n3):
> >  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
> >  18  k-points generated, ndiv=   3   3
> 2
> >KGEN ENDS
> >0.005u 0.024s 0:00.03 66.6% 0+0k 0+56io 0pf+0w
> >Now you can use run(sp)_lapw -hf -redklist ...
> >pbe.in0_grr and pbe.inhf and hf-kmesh prepared
> >Now do the hybrid calculation:   run_lapw -hf -redklist ...
> >
> >regards
> >Bhamu
> >
> >
> >On Thu, Aug 8, 2019, 13:40  wrote:
&g

Re: [Wien] Fwd: YS-PBE0 with -so

[Dr. K. C. Bhamu]

Dear Tran,
(Wien2k_18.1 with mkl and fftw3.4 on a cluster).

I am getting error with hf(+so) scf.

What I followed is:

1. PBE+SO
2. save_lapw -d 
3. init_hf_lapw and used reduced and nonshifted mesh 3 3 2 over the
original 7 7 5 mesh (detailed inputs are appended below).
Here I did not increase the default Gmax which is 6 while in my original
calculation it is 8. Should I increase it?
4. run_lapw -redklist -hf -p -so

I am getting Parallel HF error
cat *error:
error in hf
error in hf
error in hf
error in hf
error in hf
error in hf
**  Error in Parallel HF
**  testerror: Error in Parallel HF

Inputs for init_hf_lapw

Do you want to use a REDUCED k-mesh for HF (saving cpu-time) (Y/n) ?
y
This script runs 'x kgen' twice and generates equivalent meshes in the IBZ
and FBZ.
How many k-points in the full BZ?
If you type 0 you can give 3 integers for nx,ny,nz
0
How many in x?
3
How many in y?
3
How many in z?
2
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.549   0.549   0.387   0.000
0.000   0.000
  Specify 3 mesh-divisions (n1,n2,n3):
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
   6  k-points generated, ndiv=   3   3   2
KGEN ENDS
0.007u 0.030s 0:00.04 75.0% 0+0k 0+240io 0pf+0w
   1  symmetry operations without inversion
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.549   0.549   0.387   0.000
0.000   0.000
  Specify 3 mesh-divisions (n1,n2,n3):
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
  18  k-points generated, ndiv=   3   3   2
KGEN ENDS
0.006u 0.026s 0:00.03 66.6% 0+0k 0+56io 0pf+0w
Give nx,ny,nz for the reduced mesh
nx=?
3
ny=?
3
nz=?
2
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.549   0.549   0.387   0.000
0.000   0.000
  Specify 3 mesh-divisions (n1,n2,n3):
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
   6  k-points generated, ndiv=   3   3   2
KGEN ENDS
0.004u 0.029s 0:00.03 66.6% 0+0k 0+40io 0pf+0w
   1  symmetry operations without inversion
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.549   0.549   0.387   0.000
0.000   0.000
  Specify 3 mesh-divisions (n1,n2,n3):
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
  18  k-points generated, ndiv=   3   3   2
KGEN ENDS
0.005u 0.024s 0:00.03 66.6% 0+0k 0+56io 0pf+0w
Now you can use run(sp)_lapw -hf -redklist ...
pbe.in0_grr and pbe.inhf and hf-kmesh prepared
Now do the hybrid calculation:   run_lapw -hf -redklist ...

regards
Bhamu


On Thu, Aug 8, 2019, 13:40  wrote:

> Hi,
>
> A few comments:
>
> Using the "-redklist" option is for sure a very efficient
> way to reduce the computational cost.
>
> For post-SCF properties (optics, DOS, thermoelectric) which require
> more k-points than for the normal SCF calculation, the option "-newklist"
> is also extremely useful: after the normal SCF calculation
> (and save_lapw), do just one iteration ("-newklist -i 1") with more
> k-points, and then calculate the property.
>
> "-redklist" and "-newklist" can be used simultaneously.
>
> "-redklist" can be used for the normal SCF and/or for the
> one-iteration step with more k-points.
>
> As usual, the number of k-points is a parameter that needs to
> be tested.
>
> Your steps for DOS, band structure and optics look ok.
>
> F. Tran
>
> On Tuesday 2019-08-06 20:27, Dr. K. C. Bhamu wrote:
>
> >Date: Tue, 6 Aug 2019 20:27:10
> >From: Dr. K. C. Bhamu 
> >Reply-To: A Mailing list for WIEN2k users <
> wien@zeus.theochem.tuwien.ac.at>
> >To: A Mailing list for WIEN2k users 
> >Subject: [Wien] Fwd: YS-PBE0 with -so
> >
> >Dear Tran
> >I am performing YS-PBE0 on a scf (with -so) calculation with pbe-gga with
> Wien2k_18.1.
> >I have few  queries.
> >A.
> >1. My original scf(-so) has done with 7 7 5 shifted mesh. To reduce the
> computational cost I am using 3 3 2 mesh for YS-PBE0 (see appendix below
> how I did it).
> >Can we do this and if so then should we call it redklist?
> >
> >2.
> >Again with a limited HPC facilities, how safer would be for the doss,
> band, optic calculations if we go with the 3 3 2 mesh?
> >Also I want to use the same scf calculations for thermoelectric
> calculations without additional scf.
> >
> >3. Could you please correct me if I am doing any mistake in the below
> steps?
> >
> >I am curious to know in particular: in normal dft+so calculations we do a
> 

[Wien] Fwd: YS-PBE0 with -so

[Dr. K. C. Bhamu]

Dear Tran
I am performing YS-PBE0 on a scf (with -so) calculation with pbe-gga with
Wien2k_18.1.
I have few  queries.
A.
1. My original scf(-so) has done with 7 7 5 shifted mesh. To reduce the
computational cost I am using 3 3 2 mesh for YS-PBE0 (see appendix below
how I did it).
Can we do this and if so then should we call it redklist?

2.
Again with a limited HPC facilities, how safer would be for the doss, band,
optic calculations if we go with the 3 3 2 mesh?
Also I want to use the same scf calculations for thermoelectric
calculations without additional scf.

3. Could you please correct me if I am doing any mistake in the below steps?

I am curious to know in particular: in normal dft+so calculations we do a
additional step as "lapwso" in between lapw1 and lapw2 -so.
Is it okay here if we avoid both the steps i.e. lapw1 -so and lapwso for
YS-PBE0+SO?

Steps:
x_lapw lapw2 -qtl -hf -so -p
x_lapw tetra -hf -so

run_bandplothf_lapw -p -qtl -redklist
x_lapw spaghetti -hf -p -so

x_lapw optic -hf -p -so
x_lapw joint -hf -p -so
x_lapw kram -p -so

Appendix:

$run_kgenhf_lapw

If you type 0 you can give 3 integers for nx,ny,nz
0
How many in x?
3
How many in y?
3
How many in z?
2
Do you want to shift? (0=no, 1=shift)
0
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.549   0.549   0.387   0.000
0.000   0.000
  Specify 3 mesh-divisions (n1,n2,n3):
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
   6  k-points generated, ndiv=   3   3   2
KGEN ENDS
0.007u 0.038s 0:00.05 60.0% 0+0k 0+240io 0pf+0w
   1  symmetry operations without inversion
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.549   0.549   0.387   0.000
0.000   0.000
  Specify 3 mesh-divisions (n1,n2,n3):
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
  18  k-points generated, ndiv=   3   3   2
KGEN ENDS
0.001u 0.036s 0:00.04 75.0% 0+0k 0+56io 0pf+0w


regards
Bhamu
___
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

Re: [Wien] Problem in band structure plot using hf potential.

[Dr. K. C. Bhamu]

You can find detailed steps below
Re: [Wien] problem with YS-PBE0


t...@theochem.tuwien.ac.at
Mon, Aug 20, 2018, 1:24 PM


Hi,

The calculation of DOS, band structure and optical properties with
hybrid functionals is more complicated than with GGA, in particular
if this is for a k-mesh that is different from the one used during
the SCF calculation. If there is a change of k-mesh, one
iteration needs to be done. With hybrid functionals, "x lapw1" is
not enough to generate new vector file. Instead, one iteration has to
be done.

DOS without change of k-mesh (page 55 of UG):
1) x lapw2 -qtl -hf
2) x tetra -hf

DOS with new k-mesh:
1) follow the steps in "Starting a calculation from another k-mesh" (page
54 of UG) to create new k-mesh
2) run_lapw -hf -i 1 -newklist
3) x lapw2 -qtl -hf
4) x tetra -hf

Band structure (page 55 of UG):
1) create case.klist_band as usual
2) run_bandplothf_lapw

Optic without change of k-mesh:
1) x optic -hf
2) x joint -hf
3) x kram

Optic with new k-mesh:
1) follow the steps in "Starting a calculation from another k-mesh" (page
54 of UG) to create new k-mesh
2) run_lapw -hf -i 1 -newklist
3) x optic -hf
4) x joint -hf
5) x kram

FT

On Friday 2018-08-17 14:35, Dr. K. C. Bhamu wrote:

>Date: Fri, 17 Aug 2018 14:35:13
>From: Dr. K. C. Bhamu 
>Reply-To: A Mailing list for WIEN2k users 
>To: A Mailing list for WIEN2k users 
>Subject: [Wien] problem with YS-PBE0
>
>Dear Wienk Users,
>
>I attempted to do a band structure calculation of a perovskite structure
with YS-PBE0 (standard alpa parameter)
>with Wien2k-18.1.
>Up to scf and doss, I do not see any problem.
>
>But I am not getting optical properties and below is what I am getting in
band.agr file:
>
>
>My log file is:
>
>Thu Aug 16 17:15:58 IST 2018> (x_lapw) lapw1 -p
>Thu Aug 16 17:16:24 IST 2018> (x_lapw) lapw2 -qtl -p -hf
>Thu Aug 16 17:16:29 IST 2018> (x_lapw) tetra -p -hf
>Thu Aug 16 17:16:40 IST 2018> (x_lapw) lapw1 -p
>Thu Aug 16 17:17:08 IST 2018> (x_lapw) lapw2 -fermi -p -hf
>Thu Aug 16 17:17:11 IST 2018> (x_lapw) optic -p -hf
>Thu Aug 16 17:17:20 IST 2018> (x_lapw) joint -p -hf
>Thu Aug 16 17:17:31 IST 2018> (x_lapw) kram -p
>Thu Aug 16 17:17:46 IST 2018> (x_lapw) lapw1 -band -p
>Thu Aug 16 17:29:48 IST 2018> (x_lapw) lapw2 -band -qtl -p -hf
>Thu Aug 16 17:29:52 IST 2018> (x_lapw) spaghetti -p -hf
>
>I did not increase the k-points for bands and optical properties and
continued with 3x3x3 mesh (total 4 points).
>
>@ xaxis  tick major   0, 0.0
> @ xaxis  ticklabel0 ," 1  "
>@ xaxis  tick major   1, 0.15766
> @ xaxis  ticklabel1 ," 2  "
>@ xaxis  tick major   2, 0.31533
> @ xaxis  ticklabel2 ," 3  "
>@ xaxis  tick major   3, 0.47299
> @ xaxis  ticklabel3 ," 4  "
>@ with g0
>@ world 0,-21.0, 0.47299,12.0
> @ autoticks
> @ yaxis  label "Energy(eV)"
> @ with line
> @ line on
> @ line loctype world
>@ line  0.0, 0.0, 0.47299, 0.0
> @ line linestyle 3
> @ line def
> @ with string
> @ string on
> @ string loctype world
>@ string  0.49299, -0.1
> @ string char size 1.50
> @ string def "E\sF"
> @ title "CSI_ysfc"
> #k   ene character
> @ autoscale onread none
> @ target g0.s1
> @ type xysize
>
> # bandindex:   1
>   0.0 -69.93183   0.07000
>   0.15766 -69.93147   0.07000
>   0.31533 -69.93165   0.07000
>   0.47299 -69.93150   0.07000
>&
> @ autoscale onread none
> @ target g0.s2
> @ type xysize
>
> # bandindex:   2
>   0.0 -69.93183   0.07000
>   0.15766 -69.93147   0.07000
>   0.31533 -69.93151   0.07000
>   0.47299 -69.93149   0.07000
>
>regards
>Bhamu
>
>_


On Fri, Aug 2, 2019 at 11:13 PM AJAY SINGH VERMA 
wrote:

> Dear Prof. Blaha
>
>
> I am working on half heusler compounds using HF potential. When I plot
> DOS curve, then there is no peak seen at conduction band side. But same
> time i plot  DOS plot using GGA-PBE complete curve seen at both sides. I
> followed all the steps given in manual for HF Potential -
> Command for YS-PBE0 potential
> 1. Initialize the structure-
> init_lapw -p
> 2. Run scf cycle by command
> run_lapw -p
> 3. Save files by "save_lapw -d case_pbe"
> 4. run command
> init_hf_lapw -p
> 5. A window appears on screen (case.inhe) xx in fourth line by number of
> partially or  occupied band in our case it is 11
> then save the file .
> 6. Another file case.in1c appears on screen just cross it without any
> change.
> 6. Run command
> run_lapw -redklist -hf -p
> 7. After

[Wien] Issue with BZ wave vector points for the SG 129

[Dr. K. C. Bhamu]

Dear Wien2k Users,
I am studying a material having SG 129 (P4/nmm). The author of the paper
reported the BZ path in the band structure along Gamma-F-Q-Z-Gamma.
The space group of this material is 129 (P4/nmm) and the available
literature  suggests the BZ  path along: G-X-M-G-Z-R-A-G-X-R-M-A as can be
seen at MP for any material with SG 129.

I could not able to manage to get the path you: Gamma-F-Q-Z-Gamma.

Could someone please suggest me how to set the above path for the band
structure?
Looking forward to hearing from you asap.

regards
Bhamu
___
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

Re: [Wien] problem during thermal calculations

[Dr. K. C. Bhamu]

Dear Dr. Rai,

Please check that the name directory and files in it are same.
Regards
Bhamu


On Fri, Jun 28, 2019 at 5:24 PM GM RAI  wrote:

> Dear Wien2k mailing list,
>
> I am trying to calculate thermal properties of magnetic materials using
> BoltzTrap,
>
> I found the message, Stop error in opening file, during the command
> x_trans BoltzTrap,
>
> Please any one guide to remove this error
>
> --
> Murtaza
>
> ___
> 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

Re: [Wien] ERROR forrtl: severe (24) end of file

[Dr. K. C. Bhamu]

Your -ecut 6.4 should be -ecut -6.4.
You missed the "-".

regards
Bhamu

On Fri, Jun 7, 2019 at 2:16 PM Ashwani Kumar  wrote:

> Hi,
> initialization works fine in sequential step by step but shows
> forrtl:severe (24) end of file when command :init_lapw -b -vxc 13 -ecut 6.4
> -numk 8000. is executed. What could be the reason for this error. files are
> attached for the convenience.
>
> thanks and best regards,
> A. Kumar
> ___
> 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

Re: [Wien] Few questions about initialization

[Dr. K. C. Bhamu]

Hii Dr. Tran,

I am making some automatic scripts. So for the next calculations I want to
grep -ecut (energy required to separate out core and valence states).
I have a work around (print -ecut in some file and then read from that file
for further calculations).

Regards
Bhamu

On Tue, Jun 4, 2019, 1:36 AM  wrote:

> Hi,
>
> It's not possible to use gmax in batch mode with WIEN2k version 18.
> It will be possible with version 19.
>
> Which ecut?
>
> FT
>
> On Monday 2019-06-03 20:23, Dr. K. C. Bhamu wrote:
>
> >Date: Mon, 3 Jun 2019 20:23:31
> >From: Dr. K. C. Bhamu 
> >Reply-To: A Mailing list for WIEN2k users <
> wien@zeus.theochem.tuwien.ac.at>
> >To: A Mailing list for WIEN2k users 
> >Subject: [Wien] Few questions about initialization
> >
> >Dear Wien2k Experts,
> >I have some queries about initialization
> >
> >1. how to use gmax in batch mode ?
> >2. How to grep ecut ?
> >
> >3. This may be not for Wien2k related issue but  any experienced use may
> help or it may be related with Wien2k.
> >
> >When my the  PC is working for last few days and I want to do
> initialization then I face segmentation fault error (see below) and if I
> restart the PC,
> >everything goes well. Is there any workaround so that I do not need to
> restart the PC all the time?
> >
> > next is kgen
> >Segmentation fault
> > n stop error n
> >
> > So this is particular when kgen starts it means "x kgen" does not work.
> >x(_lapw) kgen gives
> >
> >Segmentation fault
> >0.0u 0.0s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
> >error: command   /home/kcbhamu/WIEN2k_18.2/kgen kgen.def   failed
> >I do not see that this is related to "x" as I faced the issue where my
> "x" was from some other Linux code.
> >
> >
> >Regards
> >Bhamu
> >
> >___
> 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] Few questions about initialization

[Dr. K. C. Bhamu]

Dear Wien2k Experts,
I have some queries about initialization

1. how to use gmax in batch mode ?
2. How to grep ecut ?

3. This may be not for Wien2k related issue but  any experienced use may
help or it may be related with Wien2k.

When my the  PC is working for last few days and I want to do
initialization then I face segmentation fault error (see below) and if I
restart the PC, everything goes well. Is there any workaround so that I do
not need to restart the PC all the time?

 next is kgen
Segmentation fault
 n stop error n

 So this is particular when kgen starts it means "x kgen" does not work.
x(_lapw) kgen gives

Segmentation fault
0.0u 0.0s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
error: command   /home/kcbhamu/WIEN2k_18.2/kgen kgen.def   failed
I do not see that this is related to "x" as I faced the issue where my "x"
was from some other Linux code.


Regards
Bhamu
___
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

Re: [Wien] System configuration

[Dr. K. C. Bhamu]

Hii,

If you are doing k-point parallel calculation (having number of k-points in
IBZ more then 12) then use below script on terminal where you want to run
the calculation or use in your job script with -p option in run(sp)_lapw
(-so).

if anyone knows how to repeat a nth line m times in a file then this script
can be changed.

Below script simply coping machine file from temple directory and updating
it as per your need.
So you do not need copy it, open it in your favorite editor and do it
manually.

cp $WIENROOT/SRC_templates/.machines . ; grep localhost .machines | perl
-ne 'print $_ x 6' > LOCALHOST.dat ; tail -n 2 .machines > grang.dat ; sed
'22,25d' .machines > MACHINE.dat ; cat MACHINE.dat localhost.dat grang.dat
> .machines ; rm LOCALHOST.dat MACHINE.dat grang.dat

regards
Bhamu


On Wed, May 22, 2019 at 10:52 PM Indranil mal 
wrote:

> respected sir/ Users,
> I am using a PC with intel i7 8th gen (with 12 cores)
> 32GB RAM and 2TB HDD with UBUNTU 18.04 LTS. I have installed
> OpenBLAS-0.2.20 and using GNU FORTRAN and c compiler. I am trying to run a
> system with 100 atoms only two cores are using the rest of them are idle
> and the calculation taking a too long time. I have not installed mpi
> ScaLAPACK or elpa. Please help me what should I do to utilize all of the
> cores of my cpu.
>
>
>
> Thanking you
>
> Indranil
> ___
> 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

Re: [Wien] PBESol is not generating atomic configuration for Li

[Dr. K. C. Bhamu]

Thanks Dr. Tran

Regards
Bhamu

On Sat, May 18, 2019, 2:11 PM  wrote:

> Hi,
>
> I can reproduce this problem for LiH, which strangely occurs
> only with PBESOl. We will look into this problem. Meanwhile,
> do init_lapw with PBE and then replace XC_PBE by XC_PBESOL
> in case.in0 before run_lapw.
>
> F. Tran
>
> On Saturday 2019-05-18 10:12, Dr. K. C. Bhamu wrote:
>
> >Date: Sat, 18 May 2019 10:12:58
> >From: Dr. K. C. Bhamu 
> >Reply-To: A Mailing list for WIEN2k users <
> wien@zeus.theochem.tuwien.ac.at>
> >To: A Mailing list for WIEN2k users 
> >Subject: [Wien] PBESol is not generating atomic configuration for Li
> >
> >Dear Wien2k users,
> >
> >I am initializing a case containing Li and H.
> >The initialization and scf goes well for GGA/LDA/PBE but for PBESol I am
> not getting any atomic configuration and it is empty on terminal.
> >The error is
> >Atomic configuration for atom: Li2   Z=   3.00
> > >>> nothing is written here!! while in case of other
> approaches atomic configuration is written for 1s and 2s states
> >
> >ERROR !!! nstop,iter,tets,test 362 4 9.99974752427E-007
> >You have to change your atomic configuration in pbe.inst
> > atom 1 has a large sphere , consider setting HDLOs and/or larger LVNS
> > atom 2 has a large sphere , consider setting HDLOs and/or larger LVNS
> >>   inputfiles prepared(13:39:37)
> > inputfiles prepared
> > next is kgen
> >  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
> > length of reciprocal lattice vectors:   0.827   0.827   0.827  10.000
> 10.000  10.000
> >  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
> >  35  k-points generated, ndiv=  10  10
> 10
> >KGEN ENDS
> > next is dstart
> >>   dstart  -p(13:39:37) running dstart in single mode
> >forrtl: severe (24): end-of-file during read, unit 81, file
> /home/kcbhamu/pbe/pbe.rsp
> >Image  PCRoutineLine
> Source
> >dstart 004232C7  Unknown   Unknown
> Unknown
> >dstart 00444603  Unknown   Unknown
> Unknown
> >dstart 0040B1EB  init_ 158  init.F
> >dstart 004096CB  MAIN__ 19
> dstart.F
> >dstart 00402FDE  Unknown   Unknown
> Unknown
> >libc.so.6  1510F641CB97  Unknown   Unknown
> Unknown
> >dstart 00402EEA  Unknown   Unknown
> Unknown
> >0.0u 0.0s 0:00.06 16.6% 0+0k 96+24io 0pf+0w
> >error: command   /home/kcbhamu/soft/WIEN2k_18.2/dstartpara dstart.def
> failed
> > n stop error n
> >
> >
> >Any hint or help will be appreciated.
> >
> >
> >regards
> >Bhamu
> >
> >
> >___
> 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] PBESol is not generating atomic configuration for Li

[Dr. K. C. Bhamu]

Dear Wien2k users,

I am initializing a case containing Li and H.
The initialization and scf goes well for GGA/LDA/PBE but for PBESol I am
not getting any atomic configuration and it is empty on terminal.
The error is
Atomic configuration for atom: Li2   Z=   3.00
 >>> nothing is written here!! while in case of other
approaches atomic configuration is written for 1s and 2s states

ERROR !!! nstop,iter,tets,test 362 4 9.99974752427E-007
You have to change your atomic configuration in pbe.inst
 atom 1 has a large sphere , consider setting HDLOs and/or larger LVNS
 atom 2 has a large sphere , consider setting HDLOs and/or larger LVNS
>   inputfiles prepared(13:39:37)
 inputfiles prepared
 next is kgen
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.827   0.827   0.827  10.000
10.000  10.000
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
  35  k-points generated, ndiv=  10  10  10
KGEN ENDS
 next is dstart
>   dstart  -p(13:39:37) running dstart in single mode
forrtl: severe (24): end-of-file during read, unit 81, file
/home/kcbhamu/pbe/pbe.rsp
Image  PCRoutineLine
Source
dstart 004232C7  Unknown   Unknown  Unknown
dstart 00444603  Unknown   Unknown  Unknown
dstart 0040B1EB  init_ 158  init.F
dstart 004096CB  MAIN__ 19  dstart.F
dstart 00402FDE  Unknown   Unknown  Unknown
libc.so.6  1510F641CB97  Unknown   Unknown  Unknown
dstart 00402EEA  Unknown   Unknown  Unknown
0.0u 0.0s 0:00.06 16.6% 0+0k 96+24io 0pf+0w
error: command   /home/kcbhamu/soft/WIEN2k_18.2/dstartpara dstart.def
failed
 n stop error n


Any hint or help will be appreciated.


regards
Bhamu
___
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

Re: [Wien] In the calculation of elastic properties why ​​​​​rhombohedral lattice parameter needs same k-mesh as used in pristine case

[Dr. K. C. Bhamu]

Dear Luis,
init_lpaw did not rotate the cell.

Anyway, I could break the loop and it took the uniform mesh that I used in
the pristine case.
But I still want to know the reason.


regards
Bhamu


On Fri, May 17, 2019 at 5:17 PM Luis Ogando  wrote:

> Dear Bhamu,
>
> Please, check if init_lpaw did not rotate your cell. Perhapes
> 18.184512 is now at y axis, b parameter.
>All the best,
>  Luis
>
> Em sex, 17 de mai de 2019 às 07:49, Dr. K. C. Bhamu 
> escreveu:
>
>> Dear Wien2k users,
>>
>> I am running a cubic (F) system having a=b=c=10.446600Bohr. The default
>> k-mesh size is 14 14 14 (3000kpt in FBZ).
>> I applied tetragonal and rhombohedral strain on optimized lattice
>> parameters (on above a,b,c) and the resultant strained a/b/c are
>> 10.429247/10.429247/10.481393 Bohr for tetragonal strain and 7.386862/
>> 7.386862/18.184512 Bohr for rhombohedral strain.
>>
>> My script advise me to use 20 20 8 kmesh size for the rhombohedral case
>> and "14 14 14" (as there is only slight change in a/b/c) for tetragonal
>> case.
>>
>> But for the rhombohedral case I am not able to use 20 20 8 mesh size and
>> the kgen program suggest me to use equal mesh in x and z direction (see
>> below in blue).
>>
>> Could you someone please advice me why I can not use the mesh size  20 20
>> 8 for the rhombohedral case?
>>
>> I may be convinced about my doubt because I am having  equal "length of
>> reciprocal lattice vectors:   1.041   1.041   1.041".  Am I right? If
>> so, then also I need to know why a lattice parameter which is almost double
>> in one direct wrt original cubic latice need the same k-points as used in
>> case of cubic case. The answer may be somewhere in symmetry operations but
>> I could not completely understand it.
>>
>>
>>
>>6  symmetry operations without inversion
>>  inversion added (non-spinpolarized non-so calculation)
>>   NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
>> 0
>>  length of reciprocal lattice vectors:   1.041   1.041   1.041   0.000
>> 0.000   0.000
>>   Specify 3 mesh-divisions (n1,n2,n3):
>> 20 20 8
>>  Lattice symmetry requires equal mesh in x and z direction
>>   Specify 3 mesh-divisions (n1,n2,n3):
>>
>>
>> regards
>> Bhamu
>>
>>
>> ___
>> 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

[Wien] In the calculation of elastic properties why ​​​​​rhombohedral lattice parameter needs same k-mesh as used in pristine case

[Dr. K. C. Bhamu]

Dear Wien2k users,

I am running a cubic (F) system having a=b=c=10.446600Bohr. The default
k-mesh size is 14 14 14 (3000kpt in FBZ).
I applied tetragonal and rhombohedral strain on optimized lattice
parameters (on above a,b,c) and the resultant strained a/b/c are 10.429247/
10.429247/10.481393 Bohr for tetragonal strain and 7.386862/7.386862/
18.184512 Bohr for rhombohedral strain.

My script advise me to use 20 20 8 kmesh size for the rhombohedral case and
"14 14 14" (as there is only slight change in a/b/c) for tetragonal case.

But for the rhombohedral case I am not able to use 20 20 8 mesh size and
the kgen program suggest me to use equal mesh in x and z direction (see
below in blue).

Could you someone please advice me why I can not use the mesh size  20 20 8
for the rhombohedral case?

I may be convinced about my doubt because I am having  equal "length of
reciprocal lattice vectors:   1.041   1.041   1.041".  Am I right? If so,
then also I need to know why a lattice parameter which is almost double in
one direct wrt original cubic latice need the same k-points as used in case
of cubic case. The answer may be somewhere in symmetry operations but I
could not completely understand it.



   6  symmetry operations without inversion
 inversion added (non-spinpolarized non-so calculation)
  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
0
 length of reciprocal lattice vectors:   1.041   1.041   1.041   0.000
0.000   0.000
  Specify 3 mesh-divisions (n1,n2,n3):
20 20 8
 Lattice symmetry requires equal mesh in x and z direction
  Specify 3 mesh-divisions (n1,n2,n3):


regards
Bhamu
___
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

Re: [Wien] Question about mbj

[Dr. K. C. Bhamu]

Thanks Prof. Peter,
Yes, I should increase the suggested parameters and I always do that.
This is just for a test case so I kept default parameters.
regards
Bhamu


On Wed, May 8, 2019 at 6:56 PM Peter Blaha 
wrote:

> Your request is anyway not meaningful.
>
> Increase RKMAX, GMAX and the IFFT factors in case.in1/2/0.
> Increase Lvns (in1) to 6.
>
> This will change the gap much more 
>
> On 5/8/19 9:55 AM, Dr. K. C. Bhamu wrote:
> > Dear Dr. Tran,
> >
> > I tested two different approaches for mBJ+SO  mentioned at [1]
> > In the present case the ground state energy differed by an amount
> > 0.00062938Ry and the band gap by a number 0.001eV which is as per the
> > difference in the :ENE.
> >
> > I know this difference is negligible and can be ignored but could you
> > please make any comment on it, why this difference occurred?
> >
> > I did the calculation in Wien2k_18.2, i5 machine with
> > composer_xe_2015.0.090 ifort and CC compiler.
> > The system is binary and no RLO.
> > pbe then mbj with -SO
> > TOTAL ENERGY IN Ry =   -43189.10920210
> > GAP =  0.006765 Ry = 0.092 eV
> >
> > pbe followed by  mbj and then followed by scf with -SO
> > TOTAL ENERGY IN Ry =   -43189.10857272
> > GAP = 0.006866 Ry = 0.093 eV
> >
> > *mBJ parameters:*
> >   -1.200E-002
> > 1.023000
> >0.500
> >
> > *case.inso*
> > WFFIL
> > 4  0  0 llmax,ipr,kpot
> > -10  1.9Emin, Emax
> >  0 0 1   h,k,l (direction of magnetization)
> >   0   number of atoms with RLO
> > 1 2  number of atoms without SO, atomnumbers
> >
> > *scf information*
> > rkmax=7, PBE, mesh size 10 10 10 (shifted, however no change with
> > shifted or non-shifted k-mesh).
> > -ec 0.0001 -cc 0.001
> >
> > [1]
> >
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18427.html
> >
> > regards
> > Bhamu
> >
> > ___
> > 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
> >
>
> --
>
>P.Blaha
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
> Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
> WWW:   http://www.imc.tuwien.ac.at/TC_Blaha
> --
> ___
> 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

Re: [Wien] Question about mbj

[Dr. K. C. Bhamu]

Yes,  I agree with you about the convergence criteria.
But, with the same files, same init and scf parameters and with same machine
how to convergence may differ in both cases? is it possible?

regards
Bhamu







On Wed, May 8, 2019 at 1:46 PM  wrote:

> Hi,
>
> If all input files of the two calculations are exactly the same,
> then the differences should be due to the scf convergence which
> is better in one of the two cases.
>
> FT
>
> On Wednesday 2019-05-08 09:55, Dr. K. C. Bhamu wrote:
>
> >Date: Wed, 8 May 2019 09:55:09
> >From: Dr. K. C. Bhamu 
> >Reply-To: A Mailing list for WIEN2k users <
> wien@zeus.theochem.tuwien.ac.at>
> >To: A Mailing list for WIEN2k users 
> >Subject: [Wien] Question about mbj
> >
> >Dear Dr. Tran,
> >
> >I tested two different approaches for mBJ+SO  mentioned at [1]
> >In the present case the ground state energy differed by an amount
> >0.00062938Ry and the band gap by a number 0.001eV which is as per the
> >difference in the :ENE.
> >
> >I know this difference is negligible and can be ignored but could you
> please
> >make any comment on it, why this difference occurred?
> >
> >I did the calculation in Wien2k_18.2, i5 machine with
> composer_xe_2015.0.090
> >ifort and CC compiler.
> >The system is binary and no RLO.
> >pbe then mbj with -SO
> >TOTAL ENERGY IN Ry =   -43189.10920210
> >GAP =  0.006765 Ry = 0.092 eV
> >
> >pbe followed by  mbj and then followed by scf with -SO
> >TOTAL ENERGY IN Ry =   -43189.10857272
> >GAP = 0.006866 Ry = 0.093 eV
> >
> >mBJ parameters:
> > -1.200E-002
> >   1.023000
> >  0.500
> >
> >case.inso
> >WFFIL
> >4  0  0 llmax,ipr,kpot
> >-10  1.9Emin, Emax
> >0 0 1   h,k,l (direction of magnetization)
> > 0   number of atoms with RLO
> >1 2  number of atoms without SO, atomnumbers
> >
> >scf information
> >rkmax=7, PBE, mesh size 10 10 10 (shifted, however no change with shifted
> or
> >non-shifted k-mesh).
> >-ec 0.0001 -cc 0.001
> >
> >[1]
> >
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18427.html
> >
> >regards
> >Bhamu
> >
> >___
> 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] Question about mbj

[Dr. K. C. Bhamu]

Dear Dr. Tran,

I tested two different approaches for mBJ+SO  mentioned at [1]
In the present case the ground state energy differed by an amount
0.00062938Ry and the band gap by a number 0.001eV which is as per the
difference in the :ENE.

I know this difference is negligible and can be ignored but could you
please make any comment on it, why this difference occurred?

I did the calculation in Wien2k_18.2, i5 machine with
composer_xe_2015.0.090 ifort and CC compiler.
The system is binary and no RLO.
pbe then mbj with -SO
TOTAL ENERGY IN Ry =   -43189.10920210
GAP =  0.006765 Ry = 0.092 eV

pbe followed by  mbj and then followed by scf with -SO
TOTAL ENERGY IN Ry =   -43189.10857272
GAP = 0.006866 Ry = 0.093 eV

*mBJ parameters:*
 -1.200E-002
   1.023000
  0.500

*case.inso*
WFFIL
4  0  0 llmax,ipr,kpot
-10  1.9Emin, Emax
0 0 1   h,k,l (direction of magnetization)
 0   number of atoms with RLO
1 2  number of atoms without SO, atomnumbers

*scf information*
rkmax=7, PBE, mesh size 10 10 10 (shifted, however no change with shifted
or non-shifted k-mesh).
-ec 0.0001 -cc 0.001

[1]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18427.html

regards
Bhamu
___
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

Re: [Wien] Speed-up of the nonlocal vdW functionals

[Dr. K. C. Bhamu]

Dear Dr. Tran,
Thanks for the email.
Please send me the new version of nlvdw.
Regards
Bhamu

On Tue, Nov 6, 2018, 3:44 PM  Dear WIEN2k users,
>
> Recent changes in the implementation of the nonlocal vdW
> functionals (SRC_nlvdw) have brought considerable speed-up.
> If you want to get the new module SRC_nlvdw, then ask me
> by email (the files are too big to be sent to the mailing list).
>
> F. Tran
> ___
> 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

Re: [Wien] error in parallel lapw2

[Dr. K. C. Bhamu]

Dear Gavin,
(updated)
I am writing on behalf of Ms. Bushra, as she is not able to reply for now,
with some test on the same cluster with wien2k version 17.1 and 18.2.

The actual error what she/me see is "/usr/common/nsg/bin/mpirun: Permission
denied" which may be solved by cluster admin only.

For Wien2k_17.1 the mpirun was defined as "mpirun -n _NP_ -machinefile
_HOSTS_ _EXEC_"

As in one of the thread Prof. Peter suggested to use "ifort + slurm".

Yes, I just installed Wien2k_18.2 at NERSC with ifort+slurm system
environment.

and the mpirun command is now "srun -K -N_nodes_ -n_NP_ -r_offset_
_PINNING_ _EXEC_"

But still I face same error.

The error is same and it does't matter if we have mpirun or srun [1]. Only
srun and mpirun word changes in the error.


In the past I faces same error and cluster admin only could solve so let us
first write to cluster admin and will update here the final outcome.

If you have any advice that can help to get rid of this issue please let us
know.

[1]
srun: error: No hardware architecture specified (-C)!
srun: error: Unable to allocate resources: Unspecified error
srun: fatal: --relative option invalid for job allocation request
srun: error: No hardware architecture specified (-C)!
srun: error: Unable to allocate resources: Unspecified error
LAO.scf1up_1: No such file or directory.
grep: No match.
srun: fatal: --relative option invalid for job allocation request
srun: error: No hardware architecture specified (-C)!
srun: error: Unable to allocate resources: Unspecified error
LAO.scf1dn_1: No such file or directory.
grep: No match.
LAPW2 - Error. Check file lapw2.error
cp: cannot stat '.in.tmp': No such file or directory
grep: No match.
grep: No match.
grep: No match.

>   stop error



On Sat, Oct 20, 2018 at 8:01 PM Gavin Abo  wrote:

> 1. It looks like you are using WIEN2k 17.1.  Some serious bugs were found
> in that version [ http://susi.theochem.tuwien.ac.at/reg_user/updates/ ].
> Consider installing and using WIEN2k 18.2 which has the fixes to it.  Also,
> WIEN2k 18.2 can be patched according to previous mailing list posts [
> https://github.com/gsabo/WIEN2k-Patches/tree/master/18.2 ].
>
> 2. Regarding your "file LAO.vspup is missing, i think it automatically
> generated during parallel lapw2", the case.vspup file should have been
> generated by lapw0.  See Table 4.3 on page 36 of the WIEN2k 18.2 usersguide
> [ http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf ]
> where it has program LAPW0 generates necessary case.vsp(up/dn).
>
> 3. I suggest you investigate why the LAO.vspup "can't open unit: 18" error
> happens with lapw2 but not with lapw1.  For example, did LAO.vspup exist
> with a non-zero file size after lapw0 completed, did it exist with a
> non-zero file size for lapw1, and did it get deleted or become zero in file
> size or loose node connection(s) just before lapw2?
>
> Is your .machines setup to run k-point parallel, mpi parallel, or a mix of
> both?  It looks like the job script that creates the .machines on the fly
> was not provided that shows that.
>
> If mpi parallel, using WIEN2k 18.2:
>
> 1. Run: ./siteconfig
> 2. Select Compiling Options, Selection: O
> 3. Select Parallel options, Selection: PO
> 4. What is MPIRUN set to?
>
> You also might check your mpirun command and talk with your cluster
> administrator to see if a supported mpi run command is being used for the
> system [
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17628.html
> ].
>
> Have you checked the standard output/error file?  This file name can vary
> from one system to another.  So you have to check your scheduling/queue
> system documentation to see what the default file(s) is called or use an
> option to name it yourself [ for example,
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18080.html
> ].  If there is a mpi run error, it usually shows up in that file.
>
> You also might have to check the hidden dot files [
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17317.html
> ] and output files (like case.output0, case.output1, etc.).
>
>
> On 10/20/2018 1:58 AM, BUSHRA SABIR wrote:
>
> Dear Peter Blaha and wien2k users
>
> I am facing one problem in parallel execution of job script. I am working
> on LaXO3 materials. initialization is ok but when i submitted job file on
> cluster for parallel execution with command line runsp_lapw -cc 0.001 -ec
> 0.0001 -i 40 -p .
>
> following error apears.cat *.error
>
> 'LAPW2' - can't open unit:
> 18
>  'LAPW2' -filename:
> LAO.vspup
>  'LAPW2' -  status: old  form:
> formatted
> **  testerror: Error in Parallel LAPW2
>
> file LAO.vspup is missing, i think it automatically generated during
> parallel lapw2
>
> i checked testpara1_lapw
> #
> # TESTPARA1 #
> #
>
> Sat Oct 20 00:22:39 PDT 2018
>
>

[Wien] eigenstates issue for -SO calculations

[Dr. K. C. Bhamu]

Dear Wien2k Experts and users,

I want to see effect of -SO on a d state of Cs in a structure (there are
different structure too where I have other heavy elements) with Wien2k_18.2.

To be at safe side one can optimize the EMAX value to include sufficient
number of "eigenstates".

When I go from 5 to 5.5, 6.0 or 6.5 Ryd then in some case I do not see any
warning for 5 and 5.5 Ryd while in some case I see that warning for 5.5Ryd.
I did not observe any warning at EMAX 5Ryd for my cases.

The warning is about QTL-B error.


But I do not see this warning for my other optimization parameters of any
scf/band calculations.

For this particular case I EMAX 5.0 Ryd is converging without any warning
while EMAX5.5 is giving QTL-B warnings. However the scf converges.

So my concern is: The range of EMAX at which I am getting warning is the
maximum limit or I should try to adjust structural parameters to eliminate
this error?

P.S.:If I do so then I need to re-do all the calculations. Also, if it is
necessary to adjust the structural parameters to eliminate this warning
from EMAX calculations then before doing all the calculation one should
check EMAX convergence so that rest calculation can be done without any
warnings.

The difference between scf  is 2meV for EMAX 5 and EMAX 5.5 Ryd while no
warning at EMAX 5 and warning appears at EMAX 5.5.

Any advice will be helpful.

Thanks and regards

Bhamu
___
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

Re: [Wien] nlvdw crash with wirn2k_18.2

[Dr. K. C. Bhamu]

Hii Tran,

Sorry for the late reply.

Yes, I see the problem is in parallel calculation only.

.machine file for nlvdw is empty while other machine files looks okay.

Kind
Bhamu





On Sat, Sep 29, 2018 at 6:10 PM  wrote:

> I don't know what could be the problem. Does it occur only in parallel
> or only with min_lapw?
>
>
> On Thursday 2018-09-27 22:56, Dr. K. C. Bhamu wrote:
>
> >Date: Thu, 27 Sep 2018 22:56:41
> >From: Dr. K. C. Bhamu 
> >Reply-To: A Mailing list for WIEN2k users <
> wien@zeus.theochem.tuwien.ac.at>
> >To: A Mailing list for WIEN2k users 
> >Subject: [Wien] nlvdw crash with wirn2k_18.2
> >
> >Dear Dr. Tran,
> >
> >This is for nlvdw (optB88_vdw)  with Wien2k_18.2.
> >
> >I encountered the similar error that some one has already reported [1].
> >error messages [2].
> >
> >I see lnsmax is already update to 5 in latest Wien2k version. I also
> tried to increase it upto 6 but it does not solve the problem.
> >
> >I am having mkl version 2013 with fftw3.
> >
> >cell optimization with
> >min_lapw -j "run_lapw -ec 0.1  -cc 0.0001 -p -fc 1 -i 100 -nlvdw"
> >---case.in0-
> >TOT  EX_OPTB88 EC_LDA VX_OPTB88 VC_LDA
> (XC_PBE,XC_PBESOL,XC_WC,XC_MBJ,XC_REVTPSSS)
> >NR2V  IFFT  (R2V)
> >   90   90   902.00  1min IFFT-parameters, enhancement factor,
> iprint
> >
> >
> >[1].
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17712.html
> >[2].
> >a.
> >running nlvdw in single mode
> >**  nlvdw crashed!
> >24.875u 0.054s 0:26.00 95.8%0+0k 0+72io 192pf+0w
> >error: command   /home/kcbhamu/Wien2k_18/nlvdwpara nlvdw.def   failed
> >
> >>   stop error
> >
> >b.
> >cat *error
> >**  Error in Parallel nlvdw
> >**  nlvdw STOPPED at Fri Sep 28 02:04:49 IST 2018
> >**  check ERROR FILES!
> >
> >c.
> >DSTART ENDS
> >DSTART ENDS
> >DSTART ENDS
> >cat: No match.
> >grep: *scf1*: No such file or directory
> >grep: lapw2*.error: No such file or directory
> >
> >Please let me know what addition information I can provide.
> >
> >Kind regards
> >
> >Bhamu
> >
> >
> >___
> 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

Re: [Wien] BerryPI

[Dr. K. C. Bhamu]

Dear Gavin,

Yes, alias berrypi calls berrypi
alias berrypi='/usr/bin/python2.7
/home/kcbhamu/Wien2k_18/SRC_BerryPI/BerryPI/berrypi'
also, berrypi -h worked.

thanks and regards
Bhamu

On Mon, Oct 1, 2018 at 5:42 PM Gavin Abo  wrote:

> "which berrypi" returning nothing I believe is fine since it uses an alias
> instead.
>
> Maybe check if the berrypi alias is setup with the terminal command:
>
> alias berrypi
>
> Maybe check that you can call berrypi, for example its help with the
> terminal command:
>
> berrypi -h
>
> In WIEN2k 18.2, I think it is userconfig that sets up BERRYPI_PATH and
> BERRYPI_PYTHON for you instead .bashrc instead of DEFAULT_BIN_PATH and
> DEFAULT_PYTHON_PATH, respectively.  So edit those, if the berrypi paths
> need adjusted.
> On 10/1/2018 4:57 AM, Dr. K. C. Bhamu wrote:
>
> Dear Prof. Oleg,
>
> I just installed the Wien2k_18.2.
>
> I saw one of your reply [1] where you call BerriPI with "which":
>
> when I do the same, I am not getting anything.
>
> My python variables in 'usr/bin' are:  python python2
> python2.7  python3python3.6  python3.6m python3m
>
>
> and
> config.py  is:
>
> DEFAULT_BIN_PATH="/home/kcbhamu/Wien2k_18.2/SRC_BerryPI/BerryPI"
> #Fix for python path to make sure it grabs the latest version
> #DEFAULT_PYTHON_PATH = "/usr/bin/python2.7"
> DEFAULT_PYTHON_PATH = "/usr/bin/python2.7"
>
> [1]
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16327.html
>
>
> regards
> Bhamu
>
> ___
> 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] BerryPI

[Dr. K. C. Bhamu]

Dear Prof. Oleg,

I just installed the Wien2k_18.2.

I saw one of your reply [1] where you call BerriPI with "which":

when I do the same, I am not getting anything.

My python variables in 'usr/bin' are:  python python2
python2.7  python3python3.6  python3.6m python3m


and
config.py  is:

DEFAULT_BIN_PATH="/home/kcbhamu/Wien2k_18.2/SRC_BerryPI/BerryPI"
#Fix for python path to make sure it grabs the latest version
#DEFAULT_PYTHON_PATH = "/usr/bin/python2.7"
DEFAULT_PYTHON_PATH = "/usr/bin/python2.7"

[1]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16327.html


regards
Bhamu
___
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

Re: [Wien] nlvdw crash with wirn2k_18.2

[Dr. K. C. Bhamu]

On Fri, Sep 28, 2018 at 2:26 AM Dr. K. C. Bhamu  wrote:

> Dear Dr. Tran,
>
> This is for nlvdw (optB88_vdw)  with Wien2k_18.2.
>
> I encountered the similar error that some one has already reported [1].
> error messages [2].
>
> I see lnsmax is already update to 5 in latest Wien2k version. I also tried
> to increase it upto 6 but it does not solve the problem.
>
> I am having mkl version 2013 with fftw3.
>
> cell optimization with
> min_lapw -j "run_lapw -ec 0.1  -cc 0.0001 -p -fc 1 -i 100 -nlvdw"
> ---case.in0-
> TOT  EX_OPTB88 EC_LDA VX_OPTB88 VC_LDA
> (XC_PBE,XC_PBESOL,XC_WC,XC_MBJ,XC_REVTPSSS)
> NR2V  IFFT  (R2V)
>90   90   902.00  1min IFFT-parameters, enhancement factor,
> iprint
>
>
> [1].
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17712.html
> [2].
> a.
> running nlvdw in single mode
> **  nlvdw crashed!
> 24.875u 0.054s 0:26.00 95.8%0+0k 0+72io 192pf+0w
> error: command   /home/kcbhamu/Wien2k_18/nlvdwpara nlvdw.def   failed
>
> >   stop error
>
> b.
> cat *error
> **  Error in Parallel nlvdw
> **  nlvdw STOPPED at Fri Sep 28 02:04:49 IST 2018
> **  check ERROR FILES!
>
> c.
> DSTART ENDS
> DSTART ENDS
> DSTART ENDS
> cat: No match.
> grep: *scf1*: No such file or directory
> grep: lapw2*.error: No such file or directory
>
> Please let me know what addition information I can provide.
>
> Kind regards
>
> Bhamu
>
>
___
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] nlvdw crash with wirn2k_18.2

[Dr. K. C. Bhamu]

Dear Dr. Tran,

This is for nlvdw (optB88_vdw)  with Wien2k_18.2.

I encountered the similar error that some one has already reported [1].
error messages [2].

I see lnsmax is already update to 5 in latest Wien2k version. I also tried
to increase it upto 6 but it does not solve the problem.

I am having mkl version 2013 with fftw3.

cell optimization with
min_lapw -j "run_lapw -ec 0.1  -cc 0.0001 -p -fc 1 -i 100 -nlvdw"
---case.in0-
TOT  EX_OPTB88 EC_LDA VX_OPTB88 VC_LDA
(XC_PBE,XC_PBESOL,XC_WC,XC_MBJ,XC_REVTPSSS)
NR2V  IFFT  (R2V)
   90   90   902.00  1min IFFT-parameters, enhancement factor,
iprint


[1].
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg17712.html
[2].
a.
running nlvdw in single mode
**  nlvdw crashed!
24.875u 0.054s 0:26.00 95.8%0+0k 0+72io 192pf+0w
error: command   /home/kcbhamu/Wien2k_18/nlvdwpara nlvdw.def   failed

>   stop error

b.
cat *error
**  Error in Parallel nlvdw
**  nlvdw STOPPED at Fri Sep 28 02:04:49 IST 2018
**  check ERROR FILES!

c.
DSTART ENDS
DSTART ENDS
DSTART ENDS
cat: No match.
grep: *scf1*: No such file or directory
grep: lapw2*.error: No such file or directory

Please let me know what addition information I can provide.

Kind regards

Bhamu
___
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

Re: [Wien] Minor bug in version 9.4 mixer

[Dr. K. C. Bhamu]

Thanks, Prof. Marks,

I apologize for my mistake but it was at line number 22 so as a non-coding
background Wien2k user I could not get it.
Thanks for the updated file.




Regards
Bhamu



On Sun, Aug 19, 2018 at 12:03 PM, Laurence Marks 
wrote:

> No it needs to be Jac*o*bian not Jacbian. Use the attached.
>
> N.B., the bug only effects the line "write(21,100)Jacobian(1:NJacs) "
> which could give a NaN and crash with some compilation options (not the
> Wien2k defaults).
>
> On Sun, Aug 19, 2018 at 1:23 AM, Dr. K. C. Bhamu 
> wrote:
>
>> Okay,
>> The available part of the code is;
>>
>> !
>> Jacbian=0
>> !
>> rel1=0.5D0
>> rel2=1.D0-rel1
>> if(.not.HaveDiags)then
>> rel2=1.D0
>> rel1=0.D0
>> if(verbose)write(21,101)'Diagonal Reset'
>> !   else
>> !   if(verbose)write(21,101)'Diagonal Used'
>> endif
>>
>>
>> *Maybe we need to make a change as below:*
>>
>> !
>>
>> *!   *
>> *Jacbian=0*
>> rel1=0.5D0
>> rel2=1.D0-rel1
>> if(.not.HaveDiags)then
>> rel2=1.D0
>> rel1=0.D0
>> if(verbose)write(21,101)'Diagonal Reset'
>> !   else
>> !   if(verbose)write(21,101)'Diagonal Used'
>> endif
>>
>>
>>
>>
>> On Sun, Aug 19, 2018 at 11:01 AM, Laurence Marks <
>> l-ma...@northwestern.edu> wrote:
>>
>>> No, add the line Jacobian=0 before it. Do not delete the line rel1=0.5,
>>> that will lead to chaos.
>>>
>>> On Sun, Aug 19, 2018 at 12:10 AM, Dr. K. C. Bhamu 
>>> wrote:
>>>
>>>> In wien2k_18.1 Line number 24 is " rel1=0.5D0"
>>>> You advised changing " rel1=0.5D0" to "Jacobian=0". Right?
>>>>
>>>>
>>>>
>>>>
>>>> Happy Sunday!!
>>>>
>>>>
>>>> regards
>>>> Bhamu
>>>>
>>>>
>>>>
>>>> On Mon, Aug 13, 2018 at 8:34 PM, Laurence Marks <
>>>> l-ma...@northwestern.edu> wrote:
>>>>
>>>>> Line 24 of ScaleDiag.F, please change to
>>>>> Jacobian=0
>>>>>
>>>>> (It was a typo, the version shipped has "Jacbian")
>>>>>
>>>>> --
>>>>> Professor Laurence Marks
>>>>> "Research is to see what everybody else has seen, and to think what
>>>>> nobody else has thought", Albert Szent-Gyorgi
>>>>> www.numis.northwestern.edu ; Corrosion in 4D:
>>>>> MURI4D.numis.northwestern.edu
>>>>> Partner of the CFW 100% program for gender equity,
>>>>> www.cfw.org/100-percent
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cfw.org_100-2Dpercent=DwMFaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=-jw092glayN_2rJ9kRs7veIeo6my1fqlDSi5MBwT32g=s4OhJffT2utdth4fcqLZNKyvXIXlc6hVoksT9p5FK10=>
>>>>> Co-Editor, Acta Cryst A
>>>>>
>>>>> ___
>>>>> Wien mailing list
>>>>> Wien@zeus.theochem.tuwien.ac.at
>>>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwMFaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=-jw092glayN_2rJ9kRs7veIeo6my1fqlDSi5MBwT32g=qS3ac9ctTaeh0fq7WiF4lTJyvbDe0vtIv16awTKZqks=>
>>>>> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/wi
>>>>> e...@zeus.theochem.tuwien.ac.at/index.html
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwMFaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=-jw092glayN_2rJ9kRs7veIeo6my1fqlDSi5MBwT32g=XusUSFKC_QDf-vbOGbiLx3n30srUth30vcrdjSPZDNg=>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Professor Laurence Marks
>>> "Research is to see what everybody else has seen, and to think what
>>> nobody else has thought", Albert Szent-Gyorgi
>>> www.numis.northwestern.edu ; Corrosion in 4D:
>>> MURI4D.numis.northwestern.edu
>>> Partner of the CFW 100% 

Re: [Wien] Minor bug in version 9.4 mixer

[Dr. K. C. Bhamu]

Okay,
The available part of the code is;

!
Jacbian=0
!
rel1=0.5D0
rel2=1.D0-rel1
if(.not.HaveDiags)then
rel2=1.D0
rel1=0.D0
if(verbose)write(21,101)'Diagonal Reset'
!   else
!   if(verbose)write(21,101)'Diagonal Used'
endif


*Maybe we need to make a change as below:*

!

*!   *
*Jacbian=0*
rel1=0.5D0
rel2=1.D0-rel1
if(.not.HaveDiags)then
rel2=1.D0
rel1=0.D0
if(verbose)write(21,101)'Diagonal Reset'
!   else
!   if(verbose)write(21,101)'Diagonal Used'
endif




On Sun, Aug 19, 2018 at 11:01 AM, Laurence Marks 
wrote:

> No, add the line Jacobian=0 before it. Do not delete the line rel1=0.5,
> that will lead to chaos.
>
> On Sun, Aug 19, 2018 at 12:10 AM, Dr. K. C. Bhamu 
> wrote:
>
>> In wien2k_18.1 Line number 24 is " rel1=0.5D0"
>> You advised changing " rel1=0.5D0" to "Jacobian=0". Right?
>>
>>
>>
>>
>> Happy Sunday!!
>>
>>
>> regards
>> Bhamu
>>
>>
>>
>> On Mon, Aug 13, 2018 at 8:34 PM, Laurence Marks > > wrote:
>>
>>> Line 24 of ScaleDiag.F, please change to
>>> Jacobian=0
>>>
>>> (It was a typo, the version shipped has "Jacbian")
>>>
>>> --
>>> Professor Laurence Marks
>>> "Research is to see what everybody else has seen, and to think what
>>> nobody else has thought", Albert Szent-Gyorgi
>>> www.numis.northwestern.edu ; Corrosion in 4D:
>>> MURI4D.numis.northwestern.edu
>>> Partner of the CFW 100% program for gender equity,
>>> www.cfw.org/100-percent
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cfw.org_100-2Dpercent=DwMFaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=-jw092glayN_2rJ9kRs7veIeo6my1fqlDSi5MBwT32g=s4OhJffT2utdth4fcqLZNKyvXIXlc6hVoksT9p5FK10=>
>>> Co-Editor, Acta Cryst A
>>>
>>> ___
>>> Wien mailing list
>>> Wien@zeus.theochem.tuwien.ac.at
>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwMFaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=-jw092glayN_2rJ9kRs7veIeo6my1fqlDSi5MBwT32g=qS3ac9ctTaeh0fq7WiF4lTJyvbDe0vtIv16awTKZqks=>
>>> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/wi
>>> e...@zeus.theochem.tuwien.ac.at/index.html
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwMFaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=-jw092glayN_2rJ9kRs7veIeo6my1fqlDSi5MBwT32g=XusUSFKC_QDf-vbOGbiLx3n30srUth30vcrdjSPZDNg=>
>>>
>>>
>>
>
>
> --
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu ; Corrosion in 4D:
> MURI4D.numis.northwestern.edu
> Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
> Co-Editor, Acta Cryst A
>
> ___
> 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

Re: [Wien] Minor bug in version 9.4 mixer

[Dr. K. C. Bhamu]

In wien2k_18.1 Line number 24 is " rel1=0.5D0"
You advised changing " rel1=0.5D0" to "Jacobian=0". Right?




Happy Sunday!!


regards
Bhamu



On Mon, Aug 13, 2018 at 8:34 PM, Laurence Marks 
wrote:

> Line 24 of ScaleDiag.F, please change to
> Jacobian=0
>
> (It was a typo, the version shipped has "Jacbian")
>
> --
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu ; Corrosion in 4D:
> MURI4D.numis.northwestern.edu
> Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
> Co-Editor, Acta Cryst A
>
> ___
> 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

Re: [Wien] how to use optB88-vdW with wien2k-18.1 (fwd)

[Dr. K. C. Bhamu]

Dear Tran,


I am not getting "case.r2v_nlvdw" file in case dir even I have a correct
case.in0 and case.innlvdw


My log file and other information:


case.in0--
TOT  EX_OPTB88 EC_LDA VX_OPTB88 VC_LDA
(XC_PBE,XC_PBESOL,XC_WC,XC_MBJ,XC_REVTPSSS)
NR2V  IFFT  (R2V)
   90   90   902.00  1min IFFT-parameters, enhancement factor,
iprint


initialized with

init_lapw -b -vxc 5 -rkmax 7  -numk 1000




>   (min_lapw) options: -j run_lapw -ec 0.0001  -cc 0.001 -p -fc 2 -i 100
-innlvdw
Sat Aug 18 02:55:32 IST 2018> (x) dstart -super
>   (min_lapw) recover inm-file & call job run_lapw -ec 0.0001  -cc 0.001
-p -fc 2 -i 100 -innlvdw
>   (run_lapw) options: -ec 0.1 -cc 0.0001 -p -fc 0.05 -i 100 -innlvdw
Sat Aug 18 02:55:35 IST 2018> (x) lapw0 -p
Sat Aug 18 02:56:02 IST 2018> (x) lapw1 -p
Sat Aug 18 02:56:31 IST 2018> (x) lapw2 -p
Sat Aug 18 02:56:46 IST 2018> (x) sumpara -d
Sat Aug 18 02:56:47 IST 2018> (x) lcore
Sat Aug 18 02:56:48 IST 2018> (x) mixer
Sat Aug 18 02:56:50 IST 2018> (x) lapw0 -p




Could you please have look and advice me if I am doing any mistake or we
may not get case.r2v_nlvdw file?

regards
Bhamu



On Fri, Aug 17, 2018 at 1:51 PM, Peter Blaha 
wrote:

> Yes, you can change it, but then you are using NOT what is called in
> literature optB88-vdW, but the "Bhamu-B88 functional".
>
> If you want to use what is called "optB88", you need to follow the
> instructions in the UG.
>
> Am 17.08.2018 um 10:04 schrieb Dr. K. C. Bhamu:
>
>> aah,
>>
>> I got it, yes we can!!
>>
>>
>> thanks
>>
>>
>>
>>
>> On Fri, Aug 17, 2018 at 1:29 PM, Dr. K. C. Bhamu > <mailto:kcbham...@gmail.com>> wrote:
>>
>> Hii Tran,
>>
>> Sorry to interrupt you again,
>>
>> I see in UG that I need to modify case.in0 with EX_OPTB88 *EC_LDA
>> *VX_OPTB88 *VC_LDA*
>>
>> I am dealing all other cases with PBE so should I change LDA to PBE
>> or optB88_vdw is run only with LDA so that I should not change
>> anything as in above EX/EC/VX/VC?
>> Page number 116-118 of UG does not say much clear about PBE.
>>
>>
>>
>> regards
>> K.C. Bhamu
>>
>> On Fri, Aug 17, 2018 at 12:49 AM, > <mailto:t...@theochem.tuwien.ac.at>> wrote:
>>
>> Hi,
>>
>> The file case.r2v_nlvdw will be generated and used during the
>> calculation. You don't need to care about it.
>>
>> The steps for DOS, band structure and optics are exactly the same
>> as with usual LDA or GGA.
>>
>> The extra computational time due to NLVDW does not depend on
>> RKMAX or k-mesh. It depends on the size of the unit cell and on
>> the value of plane-wave expansion cutoff GMAX in case.innlvdw.
>>
>> If you don't need to optimize position of atoms in the
>> unit cell (i.e., no "-min"), then replace "T" by "F" in the
>> last line of case.innlvdw. This will reduce significantly
>> the NLVDW computational time.
>>
>> F. Tran
>>
>> Dear Wien2k users
>>
>> I have a few questions for optB88-vdW with Wien2k_18.1.
>>
>>
>> I need to use optB88-vdW for a perovskite structure.
>>
>> What I found from the mailing list and UG;
>>
>> 1. Need two files case.in0 and case.innlvdw to use this
>> function and can optimize the structure with this NL
>> functional.
>> 2. One should add "–nlvdw" run(sp)_lapw script.
>>
>>
>> Now I have below queries:
>>
>> 1. It is mentioned to use "case.r2v_nlvdw" file [1], but in
>> UG nothing is said about this file. If we need to use
>> case.r2v_nlvdw then how to recall it?
>>
>> 2. Do we need to treat the step in the same way as we do for
>> doss, optical and band structure or we need to modify them? If
>> we need to modify these steps then what are the necessary
>> changes (x -h  show nothing about -nlvdw for calculating
>> these
>> properties)?
>>
>> 3. How expensive is in comparison to PBE? If I use 12x12x12
>> mesh for PBE then how much I can reduce the mesh size
>> (running on
>>

[Wien] problem with YS-PBE0

[Dr. K. C. Bhamu]

Dear Wienk Users,

I attempted to do a band structure calculation of a perovskite structure
with YS-PBE0 (standard alpa parameter) with Wien2k-18.1.
Up to scf and doss, I do not see any problem.

But I am not getting optical properties and below is what I am getting in
band.agr file:


My log file is:

Thu Aug 16 17:15:58 IST 2018> (x_lapw) lapw1 -p
Thu Aug 16 17:16:24 IST 2018> (x_lapw) lapw2 -qtl -p -hf
Thu Aug 16 17:16:29 IST 2018> (x_lapw) tetra -p -hf
Thu Aug 16 17:16:40 IST 2018> (x_lapw) lapw1 -p
Thu Aug 16 17:17:08 IST 2018> (x_lapw) lapw2 -fermi -p -hf
Thu Aug 16 17:17:11 IST 2018> (x_lapw) optic -p -hf
Thu Aug 16 17:17:20 IST 2018> (x_lapw) joint -p -hf
Thu Aug 16 17:17:31 IST 2018> (x_lapw) kram -p
Thu Aug 16 17:17:46 IST 2018> (x_lapw) lapw1 -band -p
Thu Aug 16 17:29:48 IST 2018> (x_lapw) lapw2 -band -qtl -p -hf
Thu Aug 16 17:29:52 IST 2018> (x_lapw) spaghetti -p -hf

I did not increase the k-points for bands and optical properties and
continued with 3x3x3 mesh (total 4 points).

@ xaxis  tick major   0, 0.0
 @ xaxis  ticklabel0 ," 1  "
@ xaxis  tick major   1, 0.15766
 @ xaxis  ticklabel1 ," 2  "
@ xaxis  tick major   2, 0.31533
 @ xaxis  ticklabel2 ," 3  "
@ xaxis  tick major   3, 0.47299
 @ xaxis  ticklabel3 ," 4  "
@ with g0
@ world 0,-21.0, 0.47299,12.0
 @ autoticks
 @ yaxis  label "Energy(eV)"
 @ with line
 @ line on
 @ line loctype world
@ line  0.0, 0.0, 0.47299, 0.0
 @ line linestyle 3
 @ line def
 @ with string
 @ string on
 @ string loctype world
@ string  0.49299, -0.1
 @ string char size 1.50
 @ string def "E\sF"
 @ title "CSI_ysfc"
 #k   ene character
 @ autoscale onread none
 @ target g0.s1
 @ type xysize

 # bandindex:   1
   0.0 -69.93183   0.07000
   0.15766 -69.93147   0.07000
   0.31533 -69.93165   0.07000
   0.47299 -69.93150   0.07000
&
 @ autoscale onread none
 @ target g0.s2
 @ type xysize

 # bandindex:   2
   0.0 -69.93183   0.07000
   0.15766 -69.93147   0.07000
   0.31533 -69.93151   0.07000
   0.47299 -69.93149   0.07000

regards
Bhamu
___
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

Re: [Wien] how to use optB88-vdW with wien2k-18.1 (fwd)

[Dr. K. C. Bhamu]

Thanks Prof. Peter,

I got the point now.

Regards
K.C. Bhamu




On Fri, Aug 17, 2018 at 1:51 PM, Peter Blaha 
wrote:

> Yes, you can change it, but then you are using NOT what is called in
> literature optB88-vdW, but the "Bhamu-B88 functional".
>
> If you want to use what is called "optB88", you need to follow the
> instructions in the UG.
>
> Am 17.08.2018 um 10:04 schrieb Dr. K. C. Bhamu:
>
>> aah,
>>
>> I got it, yes we can!!
>>
>>
>> thanks
>>
>>
>>
>>
>> On Fri, Aug 17, 2018 at 1:29 PM, Dr. K. C. Bhamu > <mailto:kcbham...@gmail.com>> wrote:
>>
>> Hii Tran,
>>
>> Sorry to interrupt you again,
>>
>> I see in UG that I need to modify case.in0 with EX_OPTB88 *EC_LDA
>> *VX_OPTB88 *VC_LDA*
>>
>> I am dealing all other cases with PBE so should I change LDA to PBE
>> or optB88_vdw is run only with LDA so that I should not change
>> anything as in above EX/EC/VX/VC?
>> Page number 116-118 of UG does not say much clear about PBE.
>>
>>
>>
>> regards
>> K.C. Bhamu
>>
>> On Fri, Aug 17, 2018 at 12:49 AM, > <mailto:t...@theochem.tuwien.ac.at>> wrote:
>>
>> Hi,
>>
>> The file case.r2v_nlvdw will be generated and used during the
>> calculation. You don't need to care about it.
>>
>> The steps for DOS, band structure and optics are exactly the same
>> as with usual LDA or GGA.
>>
>> The extra computational time due to NLVDW does not depend on
>> RKMAX or k-mesh. It depends on the size of the unit cell and on
>> the value of plane-wave expansion cutoff GMAX in case.innlvdw.
>>
>> If you don't need to optimize position of atoms in the
>> unit cell (i.e., no "-min"), then replace "T" by "F" in the
>> last line of case.innlvdw. This will reduce significantly
>> the NLVDW computational time.
>>
>> F. Tran
>>
>> Dear Wien2k users
>>
>> I have a few questions for optB88-vdW with Wien2k_18.1.
>>
>>
>> I need to use optB88-vdW for a perovskite structure.
>>
>> What I found from the mailing list and UG;
>>
>> 1. Need two files case.in0 and case.innlvdw to use this
>> function and can optimize the structure with this NL
>> functional.
>> 2. One should add "–nlvdw" run(sp)_lapw script.
>>
>>
>> Now I have below queries:
>>
>> 1. It is mentioned to use "case.r2v_nlvdw" file [1], but in
>> UG nothing is said about this file. If we need to use
>> case.r2v_nlvdw then how to recall it?
>>
>> 2. Do we need to treat the step in the same way as we do for
>> doss, optical and band structure or we need to modify them? If
>> we need to modify these steps then what are the necessary
>> changes (x -h  show nothing about -nlvdw for calculating
>> these
>> properties)?
>>
>> 3. How expensive is in comparison to PBE? If I use 12x12x12
>> mesh for PBE then how much I can reduce the mesh size
>> (running on
>> 16 processor CPU)?
>>
>>
>> [1]
>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at
>> /msg16549.html
>> <https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.a
>> t/msg16549.html>
>>
>>
>>
>> Thanks and regards
>>
>> K.C. Bhamu
>>
>>
>> ___
>> Wien mailing list
>> Wien@zeus.theochem.tuwien.ac.at
>> <mailto:Wien@zeus.theochem.tuwien.ac.at>
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>> <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
>> <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/wie

Re: [Wien] how to use optB88-vdW with wien2k-18.1 (fwd)

[Dr. K. C. Bhamu]

aah,

I got it, yes we can!!


thanks




On Fri, Aug 17, 2018 at 1:29 PM, Dr. K. C. Bhamu 
wrote:

> Hii Tran,
>
> Sorry to interrupt you again,
>
> I see in UG that I need to modify case.in0 with EX_OPTB88 *EC_LDA *VX_OPTB88
> *VC_LDA*
>
> I am dealing all other cases with PBE so should I change LDA to PBE or
> optB88_vdw is run only with LDA so that I should not change anything as in
> above EX/EC/VX/VC?
> Page number 116-118 of UG does not say much clear about PBE.
>
>
>
> regards
> K.C. Bhamu
>
> On Fri, Aug 17, 2018 at 12:49 AM,  wrote:
>
>> Hi,
>>
>> The file case.r2v_nlvdw will be generated and used during the
>> calculation. You don't need to care about it.
>>
>> The steps for DOS, band structure and optics are exactly the same
>> as with usual LDA or GGA.
>>
>> The extra computational time due to NLVDW does not depend on
>> RKMAX or k-mesh. It depends on the size of the unit cell and on
>> the value of plane-wave expansion cutoff GMAX in case.innlvdw.
>>
>> If you don't need to optimize position of atoms in the
>> unit cell (i.e., no "-min"), then replace "T" by "F" in the
>> last line of case.innlvdw. This will reduce significantly
>> the NLVDW computational time.
>>
>> F. Tran
>>
>> Dear Wien2k users
>>>
>>> I have a few questions for optB88-vdW with Wien2k_18.1.
>>>
>>>
>>> I need to use optB88-vdW for a perovskite structure.
>>>
>>> What I found from the mailing list and UG;
>>>
>>> 1. Need two files case.in0 and case.innlvdw to use this function and can
>>> optimize the structure with this NL functional.
>>> 2. One should add "–nlvdw" run(sp)_lapw script.
>>>
>>>
>>> Now I have below queries:
>>>
>>> 1. It is mentioned to use "case.r2v_nlvdw" file [1], but in UG nothing
>>> is said about this file. If we need to use
>>> case.r2v_nlvdw then how to recall it?
>>>
>>> 2. Do we need to treat the step in the same way as we do for doss,
>>> optical and band structure or we need to modify them? If
>>> we need to modify these steps then what are the necessary changes (x -h
>>>  show nothing about -nlvdw for calculating these
>>> properties)?
>>>
>>> 3. How expensive is in comparison to PBE? If I use 12x12x12 mesh for PBE
>>> then how much I can reduce the mesh size (running on
>>> 16 processor CPU)?
>>>
>>>
>>> [1] https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at
>>> /msg16549.html
>>>
>>>
>>>
>>> Thanks and regards
>>>
>>> K.C. Bhamu
>>
>>
>> ___
>> 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/wi
>> e...@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

Re: [Wien] how to use optB88-vdW with wien2k-18.1 (fwd)

[Dr. K. C. Bhamu]

Hii Tran,

Sorry to interrupt you again,

I see in UG that I need to modify case.in0 with EX_OPTB88 *EC_LDA *VX_OPTB88
*VC_LDA*

I am dealing all other cases with PBE so should I change LDA to PBE or
optB88_vdw is run only with LDA so that I should not change anything as in
above EX/EC/VX/VC?
Page number 116-118 of UG does not say much clear about PBE.



regards
K.C. Bhamu

On Fri, Aug 17, 2018 at 12:49 AM,  wrote:

> Hi,
>
> The file case.r2v_nlvdw will be generated and used during the
> calculation. You don't need to care about it.
>
> The steps for DOS, band structure and optics are exactly the same
> as with usual LDA or GGA.
>
> The extra computational time due to NLVDW does not depend on
> RKMAX or k-mesh. It depends on the size of the unit cell and on
> the value of plane-wave expansion cutoff GMAX in case.innlvdw.
>
> If you don't need to optimize position of atoms in the
> unit cell (i.e., no "-min"), then replace "T" by "F" in the
> last line of case.innlvdw. This will reduce significantly
> the NLVDW computational time.
>
> F. Tran
>
> Dear Wien2k users
>>
>> I have a few questions for optB88-vdW with Wien2k_18.1.
>>
>>
>> I need to use optB88-vdW for a perovskite structure.
>>
>> What I found from the mailing list and UG;
>>
>> 1. Need two files case.in0 and case.innlvdw to use this function and can
>> optimize the structure with this NL functional.
>> 2. One should add "–nlvdw" run(sp)_lapw script.
>>
>>
>> Now I have below queries:
>>
>> 1. It is mentioned to use "case.r2v_nlvdw" file [1], but in UG nothing is
>> said about this file. If we need to use
>> case.r2v_nlvdw then how to recall it?
>>
>> 2. Do we need to treat the step in the same way as we do for doss,
>> optical and band structure or we need to modify them? If
>> we need to modify these steps then what are the necessary changes (x -h
>>  show nothing about -nlvdw for calculating these
>> properties)?
>>
>> 3. How expensive is in comparison to PBE? If I use 12x12x12 mesh for PBE
>> then how much I can reduce the mesh size (running on
>> 16 processor CPU)?
>>
>>
>> [1] https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at
>> /msg16549.html
>>
>>
>>
>> Thanks and regards
>>
>> K.C. Bhamu
>
>
> ___
> 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] how to use optB88-vdW with wien2k-18.1

[Dr. K. C. Bhamu]

Dear Wien2k users

I have a few questions for optB88-vdW with Wien2k_18.1.


I need to use optB88-vdW for a perovskite structure.

What I found from the mailing list and UG;

1. Need two files case.in0 and case.innlvdw to use this function and can
optimize the structure with this NL functional.
2. One should add "–nlvdw" run(sp)_lapw script.


Now I have below queries:

1. It is mentioned to use "case.r2v_nlvdw" file [1], but in UG nothing is
said about this file. If we need to use case.r2v_nlvdw then how to recall
it?

2. Do we need to treat the step in the same way as we do for doss, optical
and band structure or we need to modify them? If we need to modify these
steps then what are the necessary changes (x -h  show nothing about
-nlvdw for calculating these properties)?

3. How expensive is in comparison to PBE? If I use 12x12x12 mesh for PBE
then how much I can reduce the mesh size (running on 16 processor CPU)?


[1]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16549.html



Thanks and regards

K.C. Bhamu
___
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

Re: [Wien] volume and atomic position relaxation

[Dr. K. C. Bhamu]

Dear Dr. Tran,

Maybe you are talking about this criterion in reference to energy/atom.

is it?


regards
Bhamu


On Thu, Aug 9, 2018 at 3:28 PM,  wrote:

> Hi,
>
> It depends on the size of your system. For a small unit cell, 1 eV could
> be large, but maybe not for one with many atoms. The larger is the
> number of atoms with relaxed atomic position, the larger is the change
> in the total energy.
>
> FT
>
> On Thursday 2018-08-09 09:25, Aaron Jung wrote:
>
> Date: Thu, 9 Aug 2018 09:25:17
>> From: Aaron Jung 
>> Reply-To: A Mailing list for WIEN2k users > at>
>> To: wien@zeus.theochem.tuwien.ac.at
>> Subject: [Wien] volume and atomic position relaxation
>>
>> Dear all,
>>
>> Hello.
>> I am checking for an equilibrium structure.
>> First, I got the volume relaxed data from an experimental structure using
>> non-spin polarized GGA method.; -5, -4. -3. -2. -1. 0, 1, 2, 3, 4, 5, 6, 7,
>> 8%.
>> The energy is shown as the red one in the attached figure.
>>
>>
>> And then,
>> I tried to calculate the atomic position relaxation with above each
>> structures using the same approach.
>> The relaxed energy is the pink one in the figure.
>>
>>
>> The energy difference between two relaxations is about 1eV.
>> It is very huge.
>>
>> Q. Is the attached data reasonable results in Wien2k program?
>>
>>
>> cf)
>> I used the same input files for every calculation; k-points=100,
>> RmtKmax=7, Rmt of each atoms, and so on.
>>
>>
>> Thank you for your interest.
>> Myung-Chul.
>>
>> =
>>
>> Myung-Chul Jung
>>
>>
>> Ph. D student
>>
>> Department of Applied Physics
>>
>> Korea University, Sejong campus
>>
>> 2511 Sejong-ro, Sejong
>>
>> 30019, Republic of Korea
>>
>> =
>>
>>
>>
> ___
> 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] Structural relaxation in hybrid calculations

[Dr. K. C. Bhamu]

Dear Dr. Tran,

I see a workaround for structural relaxation for YS-PBE0.

PBE optimization with "min_lapw " or "run_lapw . -min' will give
relaxed structure at different volumes.

Make another dir and initialize the case and copy all relaxed structure to
pwd and do optimization with YS-PBE0 without relaxation and run optimize.job

Could you please verify this workaround?

Regards
Bhamu




On Sat, Aug 4, 2018 at 8:30 PM,  wrote:

> No
>
> On Saturday 2018-08-04 16:22, Dr. K. C. Bhamu wrote:
>
> Date: Sat, 4 Aug 2018 16:22:20
>> From: Dr. K. C. Bhamu 
>> Reply-To: A Mailing list for WIEN2k users > at>
>> To: A Mailing list for WIEN2k users 
>> Subject: Re: [Wien] regarding mixing parameter in hybrid calculations
>>
>> Thanks Dr. Tran,
>>
>>
>>
>> My mistake, the standard value is 0.25!!
>>
>> Yes, I saw the link you provided (response was on my own queries).
>>
>>
>> What is advised there is:
>>
>>
>> "What you get from the optic calculation (the case.epsilon) file is only
>> the electronic part  (and not even the whole electronic part) of the
>> dielectric
>> constant."
>>
>> To get the ionic part of the static dielectric  constant you would need
>> to do the BERRYPI calculations to get Born effective charges tensors."
>>
>>
>>
>> Do you have any previous experience on how much the properties may vary
>> if we avoid the "ionic part of the dielectric constant'?
>>
>>
>>
>> Thanks and regards
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Aug 4, 2018 at 7:13 PM,  wrote:
>>  Hi,
>>
>>  First, the standard value is 0.25 and not 0.025.
>>
>>  For the dielectric constant, there was alreday some explanations
>> here:
>>  https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.a
>> t/msg14936.html
>>  https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.a
>> t/msg14875.html
>>
>>  alpha_opt at V=V_exp means that the dielectric function (and
>> alpha_opt)
>>  is calculated only at V_exp and then used for all other volumes.
>>  See also this:
>>  https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.a
>> t/msg15531.html
>>
>>  No, it is not mandatory to do PBE calculation before YS-PBE0.
>> Starting
>>  YS-PBE0 from PBE electron density (case.clmsum) may just help to
>> reduce
>>  the number of SCF iterations with YS-PBE0.
>>
>>  Of course it is possible to optimize lattice parameters with YS-PBE0.
>>  You just need to add the "-hf" option in the optimize.job file.
>>  What is not possible with YS-PBE0 is to optimize the position of
>>  atoms in the unit cell (because the forces are not implemented for
>>  YS-PBE0).
>>
>>  FT
>>
>>
>>  On Saturday 2018-08-04 14:46, Dr. K. C. Bhamu wrote:
>>
>>Date: Sat, 4 Aug 2018 14:46:02
>>From: Dr. K. C. Bhamu 
>>Reply-To: A Mailing list for WIEN2k users <
>> wien@zeus.theochem.tuwien.ac.at>
>>To: A Mailing list for WIEN2k users <
>> Wien@zeus.theochem.tuwien.ac.at>
>>Subject: [Wien] regarding mixing parameter in hybrid
>> calculations
>>
>>Dear Dr. Tran,
>>
>>In the recent past, I did some calculations using YS-PBE0 for
>> MgO and results were well reproduced (wien2k Exercise).
>>
>>I just read your paper (J. Phys.: Condens. Matter 25 (2013))
>> and get to know that we can control the mixing parameter using various
>>ways.
>>
>>1) Standard value (0.025)
>>2) By fitting  (alpa_opt)
>>3) alpa_opt (V=V_exp)
>>
>>I have queries for option 2 and 3 alpa:
>>
>>2) If I am not wrong (after having a detailed search), the
>> value of dielectric constant used to get alpa_opt is the value of dielectric
>>constant from
>>Rel(epsilon) at energy 0.013610 eV, right?
>>
>>3) How to get alpa_opt at V-V_exp?
>>
>>
>>
>>
>>
>>My next query is:
>>
>>It is reported in the Wien2k exercise that to do YS-PBE0
>> calculations we need to do a simple PBE scf.  So if we really need to
>> perform
>>PBE calculations before
>>going to YS-PBE0, I am wondering how to use YS-PBE0 to
>> optimiz