PwBaseWorkChain: Add report on disabling bands sanity check

[mbercx]

Fixes #628

When the PwCalculation finishes with exit code 0, the PwBaseWorkChain still executes a sanity check to make sure the highest energy band is not occupied, which is an indication that the calculation was run with insufficient bands in case the input structure is metallic. If the user is running an insulator, however, the check is still performed unless the occupations input of the SYSTEM namelist is specifically set to 'fixed'. Since this is also the default value of pw.x, it might be confusing to users that the number of bands is increased.

Here we add a message to the report logs to explain this to the user in case the SYSTEM.occupations input is not specified, along with a recommendation that the check can be disabled when the input is specifically set to 'fixed'.

[sphuber]

Just thinking of a potential downside of this: since for the high-throughput work, not explicitly setting the occupations is the default behavior, means that we will have a lot of these report messages. Essentially every PwCalculation iteration in every PwBaseWorkChain. This will give a non-negligible load on the database with these duplicated messages. Question is then if we should have this in the report or simply in the documentation of the workchain? @giovannipizzi

[mbercx]

This will give a non-negligible load on the database with these duplicated messages.

If this is true, then I'm a little worried about all the paramiko-related error messages due to the connectivity issues we're experiencing connecting with piz daint. Some of the more problematic PwCalculations have 34 ERROR messages in the log, which corresponds to 2317 lines. 😅

[sphuber]

If this is true, then I'm a little worried about all the paramiko-related error messages due to the connectivity issues we're experiencing connecting with piz daint. Some of the more problematic PwCalculations have 34 ERROR messages in the log, which corresponds to 2317 lines. sweat_smile

Fair point. At some point we will need to think of "archiving" nodes that can either clean the database content, like logs, or even store them in compressed more efficient form.

[giovannipizzi]

Aren't you using smearing rather than fixed in the first recoinnassance SCF? So the warning should not pop up.

And once you determine it's an insulator, I would suggest to set occupations to fixed otherwise we run with 2x CPU time as the first calculation will always "fail" and need to be rerun with more bands?

To further reduce the messages one could think not to print the message if # bands != # electrons (times spin degeneracy where appropriate, one needs to consider nspin == 1, 2, 4), i.e. after if the # bands has already been explicitly increased

[sphuber]

And once you determine it's an insulator, I would suggest to set occupations to fixed otherwise we run with 2x CPU time as the first calculation will always "fail" and need to be rerun with more bands?

That is not trivial though, because you will need to introduce a threshold above which a material is considered and insulator and then potentially some functionality to prevent this automatic change of treating the system. I am not convinced the base workchain should automatically do these changes.

[giovannipizzi]

What I'm saying is indeed that it's the outer caller, after a reconnaissance SCF, can decide to set fixed for insulators (with some threshold).
Therefore, for this type of runs, there will not be warning messages written by the base workchain (the issue discussed above).

[sphuber]

What I'm saying is indeed that it's the outer caller, after a reconnaissance SCF, can decide to set fixed for insulators (with some threshold).
Therefore, for this type of runs, there will not be warning messages written by the base workchain (the issue discussed above).

Ok perfect, I think we agree then. It is to the caller to suppress this warning by updating the parameters accordingly if they know what they're doing. Would this be ok to merge for you then @giovannipizzi ?

[giovannipizzi]

Sure! I approved