Advanced reference workchain needed?

[broeder-j]

To ensure consistent parameter and kpoints and so on we use the reference workchain key, where we parse an already run workchain to a new one to ensure consistency.

However, what consistency means may depend on the context of the higher workchain. Example: In the EOS case, we want to have the same parameter and the same kpoints.

But if we think about an 'Energy of formation workchain' there we might have to parse either the workchain of the crystal to all the workchains calculating the elemental references and there one does not want to enforce the same kpoints. Or one could parse all the elemental workchains (if they are run first) to the one running the crystal, i.e a list of reference workchains might be needed. So same sub workchain as in the EOS case, but different 'common' context.

Therefore, overall in the long term we might have to enhance or over think the reference workchain key for more general workchain cases.

(for the current efforts with just the EOSwc, the current situation is fine)

[giovannipizzi]

Fully agree, @bosonie and me were just discussing the same thing.

One way would be to have a get_builders (note the plural) where you pass multiple structures and it returns all builders, created in a compatible way (rather than running one and then having it as a reference). This would work better e.g. for formation energies. However, it might be complex to decide in a general way what the users want to do (e..g. if you get different cells, does the user want to do a formation energy or an EOS?).

Happy to discuss more (and agreed that for EOS it's fine as is)