nexus: forbid bundling sims that depend on each other

[jtkrogel]

Users attempting to bundle jobs/simulations together that depend on each other causes Nexus to hang. An example situation: attempting to bundle together SCF and DMC runs. Put a guard in place (error trap) to ensure that only simulations capable of simultaneous execution (i.e. in a single job) are bundled together.

[qmc-robot]

Can one of the maintainers verify this patch?

[qmc-robot]

Can one of the maintainers verify this patch?

[markdewing]

okay to test

[markdewing]

Do you have simple input file that creates this condition?

[jtkrogel]

I can make one, though using it as a test for pass/fail might not be simple. In the problem case, nexus polls indefinitely because no job can be started (A depends on B, but A and B are bundled for simultaneous execution). With the fix in place, a user oriented error message is displayed and execution ceases. Do you still want it?

In the future, we can adjust the nexus error processing system to throw an exception, or exit gracefully with the appropriate system code. I expect this type of behavior will be more useful for constructing tests.

[prckent]

Consistent with our earlier practices, I am going to merge this now. A test would indeed be helpful, but I think a higher priority should be put on adding tests of NEXUS QMC workflows to the ctest system. First, whether the system works for simple cases involving only QMCPACK. Second, if QE is enabled, whether whole wavefunction generation+QMC workflow series works. Queue submission vs "direct" runs is an extra complication to discuss. NEXUS could benefit from its own test system also.

[markdewing]

Creating an example that demonstrates a feature or error path is much lower bar than creating a reliable test case. I thought might be easier for @jtkrogel to create an example while the code is still fresh in his mind.

Additionally, this uses the job bundling feature, and it would be useful to have an example on how to use it.