Re: [Wien] Error coming from .timeso_X

2016-07-01 Thread Maciej Polak
Thank you for your answer and suggestions. I tried the same calculation with a ridiculous amount of memory (200GB, while non so calculations finish easily on 10 GB), and a recompiled lapwso. Nothing changed unfortunately... I'm lost now, and have no idea how to approach the problem,

Re: [Wien] Error coming from .timeso_X

2016-06-30 Thread Lyudmila Dobysheva
29.06.2016 22:07, Maciej Polak wrote: I'm curious though, how does it get there? I am not a specialist in commands of shell, but there are several commands writing their output to .timeso in lapwsopara, for example: (cd $PWD;$t $exe ${def}_${loop}.def;rm -f .lock_$lockfile[$p])

Re: [Wien] Error coming from .timeso_X

2016-06-29 Thread Maciej Polak
Dear Lyudmila, Thank you for the reply. I agree that this looks like LAPACK related stuff. I'm curious though, how does it get there? My case.inso and case.struct are fine I hope (case.struct is an effect of geometry optimization, and it looks fine in xcrysden and the forces are small). See

Re: [Wien] Error coming from .timeso_X

2016-06-29 Thread Lyudmila Dobysheva
29.06.2016 12:11, Maciej Polak wrote: I have trouble with running run_lapw with the "so" switch in parallel. I narrowed down the origin of this error to be located in .timeso_X files (.timeso_1). info in pzheevx16 5 2 1 {1,0}: On entry to PZUNMTR parameter number