smp inner_loop mode is not documented

[jhenin]

[HanatoK]

We have discussed this issue in #780. The problem is that once we document it, we cannot change the name inner_loop anymore. However, according to @giacomofiorin's comment, the name inner_loop might mislead users, so I thought we might have to change inner_loop to a more meaningful name.

[jhenin]

Ah yes, thank you for reminding me. A good future-proof name would take into account the most likely extensions of this. In #780 you mentioned "optimal alignment, RMSD, COM calculations and metadynamics". I could add, possibly, future kernel-based versions of ABF.

Based on this, I don't see a better name than inner_loop.

Do you still believe that the feature should not be publicized in its current state?

[HanatoK]

Ah yes, thank you for reminding me. A good future-proof name would take into account the most likely extensions of this. In #780 you mentioned "optimal alignment, RMSD, COM calculations and metadynamics". I could add, possibly, future kernel-based versions of ABF.

Based on this, I don't see a better name than inner_loop.

Do you still believe that the feature should not be publicized in its current state?

Yes. The other reason is that only OPES really uses it for the time being. Nevertheless, we can keep the issue open.

[giacomofiorin]

Hi both, my concern is that the name inner_loop is a bit too general. Those use case where you have nested loops (e.g. coordination numbers of fittingGroup) are also those where performance loss is most visible.

As @HanatoK pointed out, this feature is not only not documented, but also not implemented yet. I agree with keeping the issue open, perhaps renaming it and adding a checklist of individual objects as they get parallelized.