Computation of N_eff when the align stage (but not the couplings stage) is run

[berkalpay]

EVcouplings/evcouplings/utils/app.py

Lines 451 to 452 in 49748ad

	if "align" in config["stages"] and "couplings" not in config["stages"]:
	config["align"]["compute_num_effective_seqs"] = True

This may be unexpected behavior since the corresponding config file parameter is overridden. Additionally, computing N_eff in the align stage may significantly lengthen computation when the couplings stage is expected to be run at a later point.

[thomashopf]

Hi @berkalpay, I agree this may seem unexpected (and I am normally not happy with having explicit overrides in the code like that). At the same time, the reason why this was put in because it makes the common use case where you first explore the available amount of sequences without calculating couplings a lot more convenient. Before having the override, the unexpected behaviour was to not have N_eff available after running align only, which is a major inconvenience.

Do you have a use case where you just run the alignment, but do not care about the Meff?

[berkalpay]

Hi @thomashopf. Yes, my code runs the stages of EVcouplings separately; it is useful for my pipeline for the stages to be modular (e.g. for parallelization). So, in my use case the couplings stage is often run immediately after the align stage, and I would like to avoid calculating N_eff in the align stage - this can add many hours to what should be a quick step. Unfortunately, there seems to be no way to get around the override, so I have forked the repository in the meantime and removed the lines of code above.

[thomashopf]

@berkalpay I understand... this really bends the way the command-line application is meant to be used. The intended way to patch together the individual stages/components of the pipeline differently (I very much anticipated this scenario, e.g. different pipeline runners) would be to call some of the underlying Python functions directly depending on the level of abstraction needed.

But anyways, to accommodate your off-label use case, we could add an optional command-line flag that allows to turn off the override. I've flagged this as an enhancement for now.