First one needs a detailed information which files are really generated
in order to see where it stucks.
ls -alsrt list the files with full information (empty or non-empty
files, date+time of last write).
Then you should do a ps -ef and see what is running in connection with
optic (maybe add |grep optic)
If it does not start the parallel optic calculations, you may edit
opticpara and replace -f by -fx in the first line of this script.
It will give you a very lengthy, hard to read output, but basically this
should help to find the exact position/reason where it got stuck.
PS: I guess you have tried this to reproduce in a fresh directory ?
Am 22.04.2016 um 05:08 schrieb Gavin Abo:
If you haven't already done so, I would suggest looking at the content
in the files .timeop_1, .timeop_2, ... , and .timeop_X (e.g., while in
the case directory: cat .timeop_*), because an error message might be
logged in these files for a parallel optic calculation.
On 4/21/2016 3:44 PM, Maciej Polak wrote:
Dear WIEN2k Community,
I want to calculate the joint density of states but I ran into some
problems with parallel execution of x optic. I use only K-point
parallelization and run the newest 14.2 version of WIEN2k.
When I do sequential calculations, it all works fine. But for bigger
cases, and many K-points it is impossible to finish on one CPU. After
I add the -p flag to the relevant procedures, the last output I see
is: running OPTIC in parallel mode. From then, nothing happens. The
optic_X.def files are generated, and an optic.error file containing
"Error in Parallel OPTIC", nothing else. The code just stands still
after that, no activity on CPUs.
A simple minimalistic example to reproduce the error:
init_lapw -bw -vxc 5 -rkmax 7 -numk 1000 -red 2
run_lapw -p
x kgen <<< 10000
x lapw1 -p
x lapw2 -fermi -p
x optic -p
The same set of calculations, without the -p flag, would work just
fine. However, when I generate a bigger k-mesh and have a large number
of atoms it is absolutely impossible to perform the calculations on a
single core.
Regular k-point calculations (geometry optimization, bandstructures,
etc.) work perfectly.
I attached my *.struct and *.inop, but they are not the problem in
this case, since they work with sequential version as intended. This
is just a super simple FCC Si calculation just for testing.
I would really appreciate any help. I tried to read through the
mailing list, but couldn't find a similar problem.
Best regards,
Maciej Polak
Wroclaw University of Science and Technology
_______________________________________________
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.at WIEN2k: http://www.wien2k.at
WWW: http://www.imc.tuwien.ac.at/staff/tc_group_e.php
--------------------------------------------------------------------------
_______________________________________________
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
