wannier90 icon indicating copy to clipboard operation
wannier90 copied to clipboard

Not all errors write the .werr file

Open greschd opened this issue 8 years ago • 4 comments

In trying to find an easy way to detect a failed Wannier90 run, I discovered that an error does not always mean a .werr is created. An example of this is when the number of overlaps in the .mmn file does is not correct.

Is this behaviour on purpose, or should the error file always be written when an error occurs? A workaround for detecting the failed runs is to just look for the Exiting....... string in the output.

greschd avatar Jul 27 '17 08:07 greschd

Hi Dominik

I don’t think this is intentional - we have tried in so far as possible to handle errors by calling io_error, which should write a message to the .werr file. Looking at overlap.F90, this is also what should happen when there is a problem reading the mmn file…

Best wishes,

Arash

— Arash Mostofi — www.mostofigroup.orghttp://www.mostofigroup.org Director, CDT in Theory and Simulation of Materials Imperial College London

On 27 Jul 2017, at 09:44, Dominik Gresch <[email protected]mailto:[email protected]> wrote:

In trying to find an easy way to detect a failed Wannier90 run, I discovered that an error does not always mean a .werr is created. An example of this is when the number of overlaps in the .mmn file does is not correct.

Is this behaviour on purpose, or should the error file always be written when an error occurs? A workaround for detecting the failed runs is to just look for the Exiting....... string in the output.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/wannier-developers/wannier90/issues/142, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFhKGpJDz2oMk8lrnmu_x4wB7R0bqVptks5sSE3hgaJpZM4Ok-G6.

mostofi avatar Jul 31 '17 16:07 mostofi

Ok, I'll try to investigate why the .werr file doesn't appear in the sample case I had. Can you please assign the issue to me?

greschd avatar Jul 31 '17 20:07 greschd

The problem is that io_error writes to the stdout unit in the non-MPI code (see here). In wannier_prog.F90, stdout is set to the .werr file during param_read, but later set to the .wout file (here).

So this means that if there are errors within reading the parameters list, the errors are written to .werr, but otherwise not.

I believe the correct way to solve this would be to add a stderr file unit which always points to the .werr file, and then use that. In the MPI code, we would have to rename the file units for each node (now called stderr).

@mostofi, what do you think about this?

greschd avatar Aug 02 '17 11:08 greschd

While this is important, we're moving it to v3.1 while we are feature-freezing the code for 3.0

giovannipizzi avatar Nov 27 '18 17:11 giovannipizzi

Testing on develop branch seems to have the error correctly written in the .werr file.

I tested the examples/example03 by removing randomly some lines in the silicon.mmn file, or changing the number of bands or kpoints in the same file. I also tried to change the number of bands in the silicon.win file. Every time, the silicon.werr is generated with the correct error reported.

@greschd could you test again with the last develop?

mikibonacci avatar Feb 16 '24 10:02 mikibonacci

Hi @mikibonacci,

Thanks for looking into this. Unfortunately, I don't have access to the original error case anymore. The tests you've made seem reasonable to me, so I think it's fine to just close this issue.

greschd avatar Feb 16 '24 11:02 greschd