Work chains: Adopt consistent naming for namespaces

[mbercx]

Currently, there is some inconsistency in how we are naming the namespaces of the subprocesses of the work chains. For example:

• PwRelaxWorkChain uses base and base_scf for the PwBaseWorkChain namespaces of the geometry optimization and the final SCF.
• PwBandsWorkChain uses scf and bands for the PwBaseWorkChain namespaces of the SCF calculation and the band structure calculation.

We should consider if we can find a consistent naming scheme for the namespaces of the subprocesses. One question here is if the namespace should reflect the subprocess or the purpose of the calculation. We should probably also avoid namespace nestings like relax.relax (which is the reason why the PwRelaxWorkChain uses base for the PwBaseWorkChain of the geometry optimization). My suggestion is to try and use the final part of the entry point for the work chains, and add the purpose of the calculation in case of PwBaseWorkChains (especially if there are multiple, of course). So, we'd get the following namespaces:

• PwBaseWorkChain: base_<calculation_purpose>, e.g. base_scf, base_relax, ...
• PwRelaxWorkChain: relax (possibly add relax_type if there are multiple relax types in the work chain)
• PwBandsWorkChain: bands
• PdosWorkChain: pdos

But of course, other suggestions are more than welcome!

[greschd]

I think the purpose of the calculation should definitely be included. About the subprocess, I'm not sure.

Here's a hypothetical to consider: What happens if we decide to implement a workchain with specific behavior for scf - let's say this is a child class of PwBaseWorkChain, just with some added behavior. Now that would mean we'd have to rename the base_scf namespaces to stick to the scheme, even if it may be a compatible interface.
But then again, if the subprocess interface actually changes it could be helpful if the namespace name changes to explicitly alert the user to this change.

The base question this raises is whether we consider the subprocess type to be an implementation detail, or part of the public interface. In my opinion this abstraction will always be somewhat leaky, but it's more a matter of how much.