Good to see. As you know, "hup: Command not found" can be ignored:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-April/014484.html
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2010-September/013598.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11131.html
On
Thank you Sir for your instantaneous support. Now it is working smoothly
only with hup: Command not found.
On Sun, Sep 29, 2019 at 6:32 PM Gavin Abo wrote:
> Checking with "which lapw1c" on each node (vlsi1, vlsi2, vlsi3, and vlsi4)
> is a good idea. However, since WIENROOT is (blank) [1],
An additional comment, /home/username/WIEN2k (or ~/WIEN2k) is where I
have WIEN2k installed. Whereas, you have installed WIEN2k at
/servernode1 [1]. In the examples of my previous posts (e.g. [2]) you
might find some typographical errors were I forget to replace my
/home/username/WIEN2k with
You are using a very old WIEN2k version.
At that time x lapw5 would ALWAYS produce "clmval".
So the ONLY way to produce the total density was to edit lapw5.def and
case.in5 to set the correct values and then run lapw5 lapw5.def
The latest WIEN2k has several switches
Dear All,
When I calculated charge densities of cubic TiC using lapw5 in WIEN2k 13.1, I
found the valence charge density is bigger than the total charge density.
During the calculation, I constructed the case.in5 file first and then did ‘x
lapw5’. I used ‘VAL’ in case.in5 for valence charge
So there is progress as now the environment seems to be accepted in the
remote shell.
lapw1para (called by x_lapw, which is called by run_lapw -p) creates the
splitted klists-files (case.klist_1,...) and def files lapw1_1.def,...
It uses the $cwd variable and executes basically:
ssh vlsi1
6 matches
Mail list logo
