make topoaa.molX and mol_ parameter expandable

[joaomcteixeira]

• Your code is well documented. Functions and classes have proper docstrings as explained in contributing guidelines. You wrote explanatory comments for those tricky parts.
• 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
• You have stick to Python. Talk with us before if you really need to add other programming languages to HADDOCK3
• code follows our coding style
• You avoided structuring the code into classes as much as possible, using small functions instead. But, you can use classes if there's a purpose.
• PR does not add any install dependencies unless permission was granted by the HADDOCK team
• PR does not break licensing
• You get extra bonus if you write tests for already existing code

---

Define mol parameters as expandable parameters. These include the molX in topoaa and mol_fix_origin and mol_shape in some other modules.

For topoaa the prot_segid is defined by the alphabet progression unless the user has defined a value.

todo:

• implement forced progression for params except mol_

[codecov-commenter]

Codecov Report

Merging #350 (ebd9191) into main (528d7b6) will increase coverage by 1.19%.
The diff coverage is 93.91%.

@@            Coverage Diff             @@
##             main     #350      +/-   ##
==========================================
+ Coverage   59.49%   60.69%   +1.19%     
==========================================
  Files          65       65              
  Lines        4022     4152     +130     
==========================================
+ Hits         2393     2520     +127     
- Misses       1629     1632       +3     

Impacted Files	Coverage Δ
src/haddock/libs/libutil.py	64.10% <ø> (ø)
src/haddock/gear/prepare_run.py	48.71% <80.85%> (+9.34%)	⬆️
src/haddock/core/defaults.py	85.71% <100.00%> (+1.09%)	⬆️
src/haddock/gear/expandable_parameters.py	100.00% <100.00%> (ø)
tests/test_gear_expandable_parameters.py	100.00% <100.00%> (ø)
tests/test_gear_prepare_run.py	100.00% <100.00%> (ø)
tests/test_module_topoaa.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 528d7b6...ebd9191. Read the comment docs.

[joaomcteixeira]

Define mol parameters as expandable parameters.

These include the molX in topoaa and mol_fix_origin and mol_shape in some other modules.

For topoaa the prot_segid is defined by the alphabet progression unless the user has defined a value.

capri.tsv values are the same as in main for all the test.cfg cases.

[amjjbonvin]

How does it work? Will it create by default all values (e.g. mol_fix_origin and mol_shape), set those to the default values and write them to the CNS inp files? And of course take any value the user might define in the config file?

Also how will that connect to the i-vresse workflow builder/editor?

Also note that there are other molecule-related parameters that could be handled that way, e.g. nseg_1 nfle_1 nrair_1 and all associated parameters.

[joaomcteixeira]

How does it work? Will it create by default all values (e.g. mol_fix_origin and mol_shape), set those to the default values and write them to the CNS inp files? And of course take any value the user might define in the config file?

Yes, but only for the number of molecules input. For example, if the user provides two molecules and defines mol_fix_origin_2 = True. Then, a mol_fix_origin_1 = False will be written also to the CNS inp. But, mol_fix_origin_3 won't be written because only two molecules are in the input.

Also, if the user gives only two molecules and writes mol_shape_4 by mistake, HADDOCK3 will raise an error when reading the config file.

Also how will that connect to the i-vresse workflow builder/editor?

We need to investigate that. i-vresse could read from the python functions identifying which parameters are expandable, and create the appropriate menus for those.

Also note that there are other molecule-related parameters that could be handled that way, e.g. nseg_1 nfle_1 nrair_1 and all associated parameters.

Yes, but those are different. Those are associated with the rair_sta_1_1 parameters, for example. nseg_1 (and others) are a different kind of parameters that we can decide to populate automatically from the number of groups defined in the rair_sta_1_1 type of parameters. The rair_sta_1_1 type of parameter are expandable, as we have seen before.

[rvhonorato]

Approved but I don't understand anything about this part, trusting you @joaomcteixeira :)

[joaomcteixeira]

I am making a presentation for tomorrow. I think it's best to explain to all

[amjjbonvin]

Ok - all clear

Yes, but those are different. Those are associated with the rair_sta_1_1 parameters, for example. nseg_1 (and others) are a different kind of parameters that we can decide to populate automatically from the number of groups defined in the rair_sta_1_1 type of parameters. The rair_sta_1_1 type of parameter are expandable, as we have seen before.

These are molecule specific as the first index relates to the molecule and the second to the segment.

[joaomcteixeira]

These are molecule specific as the first index relates to the molecule and the second to the segment.

Yes. One thing I can do is to block to the maximum number of molecules also.

[joaomcteixeira]

Okay, I will add that in another issue, because this one was about cleaning the implementation and adding the mol

[amjjbonvin]

Looking good - one last comment:

Shouldn't the yaml file for the topoaa module be update so that the documentation (short and long) explains that this block and parameters can be duplicated for additional molecules?

[joaomcteixeira]

Added the documentation.
FYI, in the python shell, I treat these special cases of nested dictionaries with having or not the default key. That is, actual parameters have the default key, and if default is not present, the entry is treated as a subdictionary, as is the case of mol1. Need not to worry about this, was just to let it here stated. 👍
If you agree it can be merged.