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

Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300             FAX: +43-1-58801-165982
Email:    WIEN2k:
Wien mailing list

Reply via email to