grep :RKM case.scf
It will tell you, what the actual RKMax is, which was reduced automatically due
to the
NMATMAX value set during installation of WIEN2k (memory-limitation).
Am 17.03.2012 03:47, schrieb arqum hashmi:
Dear users
previously i asked about one system with 50 atoms in a unit
My guess: there is no error at all here. Depending on the OS and
compiler (and/or compiler settings?), the 'end' message can be
different. Probably the piece of code in SRC_lcore was compiled in a
different way (even with a different compiler?) then the rest of your
wien2k installation. Maybe
/
-- next part --
An HTML attachment was scrubbed...
URL:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120319/ae2cbfec/attachment.htm
should do also
another criteria like the options 3 and/or 4?
thanks
sufyan naji
-- next part --
An HTML attachment was scrubbed...
URL:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120319/daa46ce4/attachment.htm
/
-- next part --
An HTML attachment was scrubbed...
URL:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120319/be9a99a3/attachment.htm
Just as the total energy will decrease asymptotically (=forever) if you
increase RKMax, it will decrease asymptotically if you increase Emax.
How do you find the appropriate RKMax? == not by monitoring the total
energy as such, but either energy *differences* or your observable
property of
/
-- next part --
An HTML attachment was scrubbed...
URL:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120319/1aae7a9b/attachment.htm
/pipermail/wien/attachments/20120319/e3431fa8/attachment.gz
-- next part --
A non-text attachment was scrubbed...
Name: 2.tar.gz
Type: application/x-gzip
Size: 8068 bytes
Desc: not available
URL:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120319/e3431fa8
8 matches
Mail list logo