sasascore module

[mgiulini]

You are about to submit a new Pull Request. Before continuing make sure you read the contributing guidelines and that you comply with the following criteria:

• You have sticked to Python. Please talk to us before adding other programming languages to HADDOCK3
• Your PR is about CNS
• Your code is well documented: proper docstrings and explanatory comments for those tricky parts
• You structured the code into small functions as much as possible. You can use classes if there is a (state) purpose
• Your code follows our coding style
• You wrote tests for the new code
• tox tests pass. Run tox command inside the repository folder
• -test.cfg examples execute without errors. Inside examples/ run python run_tests.py -b
• PR does not add any dependencies, unless permission granted by the HADDOCK team
• PR does not break licensing
• Your PR is about writing documentation for already existing code 🔥
• Your PR is about writing tests for already existing code

---

Closes #861 by creating a sasascore module, which allows to score PDB files against existing accessibility information.

As an example, if some glycosylation sites on chain A (say residues 40 and 50) are known to be preserved upon complex formation, a penalty can be added if they are buried in the resulting model. At the same time, if some residues are known to be buried in the complex, we can impose a penalty if they are accessible.

An example application of the module:

[sasascore]
resdic_accessible_A = [40,50]
residic_buried_B = [22,23,24]

This will create a sasascore.tsv file, analogous to the other scoring tsv files.

structure       original_name   md5     score
cluster_1_model_1.pdb   emref_1.pdb     None    2
cluster_1_model_2.pdb   emref_2.pdb     None    2
cluster_2_model_1.pdb   emref_4.pdb     None    5
cluster_3_model_1.pdb   emref_3.pdb     None    5
cluster_2_model_2.pdb   emref_5.pdb     None    5

Here the score is the number of times the input information has not be satisfied (the lower the better). A file named violations.tsv is also produced, with a detailed picture of the violations:

structure             bur_A acc_B
cluster_1_model_1.pdb 40 22
cluster_1_model_2.pdb 50 23 
cluster_2_model_1.pdb 40,50 22,23,24
cluster_3_model_1.pdb 40,50 22,23,24  
cluster_2_model_2.pdb 40,50 22,23,24

[amjjbonvin]

I would suggest to rename this module to sasascore

[VGPReys]

Code base: OK

still have to test it

[rvhonorato]

best to move this inside the sasascore module and call it here instead of the other way around since these CLIs are marked for deletion

[mgiulini]

I can move it to the restraints library, imo a better place than the module file

[rvhonorato]

This pattern here looks very similar to what you had before in the caprieval module and that we changed to produce less files. See the implementation I did there: https://github.com/haddocking/haddock3/blob/main/src/haddock/modules/analysis/caprieval/capri.py#L905

You can extract the values directly from the scheduler object, no need to have these intermediate files

[mgiulini]

but that holds only for the scheduler, doesn't it? and here the intermediate files are much less..OK though, will add this other call

[rvhonorato]

Something is producing several files, and they are being merge here, right? This thing that is producing the several files is the one that should go trough the scheduler and then here instead of merging the file you just retrieve the values

[mgiulini]

I am checking this over and over and I think this induces code duplication everywhere. now caprieval has both the rearrange_output function (when less_io = false) and this extract_data_from_capri_class (when less_io = true)..both doing the same thing in a completely different manner.
Everything would be much easier if fewer output files were generated by each module.

[rvhonorato]

It does yes, but it's already part of our technological debt because of how people decided this workflow execution would be done - unfortunately nothing we can do at this point except work around it 🤷🏽

but this pattern is in many places already, just add a comment in the code and add it to this list here: #970

[mgiulini]

there is something that can be done, which is simply having much fewer files produced by each analysis module. The code duplication this less_io pattern introduces is not worth the advantage imo. Probably something to be discussed in a code meeting. I won't add anything to that PR for the time being.

[rvhonorato]

I'm a bit confused here, why are you doing this per core and why not per model?

[mgiulini]

we don't want to launch hundreds/thousands of extremely short jobs, but rather concatenate them so that each core is dealing with a decent number of jobs

[rvhonorato]

This is already handled by the scheduler:

haddock3/src/haddock/libs/libparallel.py

Line 148 in 01eb9ae

job_list = split_tasks(sorted_task_list, self.num_processes)

so it's not responsability of a scoring module to sort tasks - that's what the library is for heh so here you can just loop over the models

[mgiulini]

@rvhonorato I have been thinking about this. I don't think this way of handling the tasks is a good idea (related also to the caprieval code linked above). If the running mode is not local and less_io is not active (the if clause in the caprieval output), this still amounts at creating a huge amount of files (for example 10k in the higher sampling scenarios), which can be avoided by simply parallelising internally on the number of cores (much lower in general). Additionally, for super-short tasks like this one, this probably makes things faster. what do you think?

[rvhonorato]

I just found out that pattern is found in many other places in the code, see here: #970

So please add this one to the list there and I can handle them in another PR

[rvhonorato]

typo here?