Handle n<param> parameter assignment logic internally?

[rvhonorato]

We've had this discussion IRL and I'm adding it here for future reference

Currently we have some parameters that represent the number of segments/residues for a given functionality;

• nfle1: Number of fully flexible segments
• nseg1: Number of semi-flexible segments
• nhisd: Number of HISD residue
• nhise: Number of HISE residue
• numc2sym: Number of C2 symmetry restraints
• numc3sym: Number of C3 symmetry restraints
• numc4sym: Number of C4 symmetry restraints
• numc5sym: Number of C5 symmetry restraints
• numc6sym: Number of C6 symmetry restraints
• nums3sym: Number of S3 symmetry restraints
• numncs: Number of non-crystallographic symmetry restraints

These are defined by the user, then the number of these parameters must match the number of segments defined.

If this logic is handled internally (without user intervention), we both remove a possible fault point and simplify the integration with the web interface.

Besides that, nsegN is polymorphic and can be a bit confusing for users:

if -1 = automatic
if 0 = rigid
if >1 == integer defining the number of segments

To alleviate that we can add a new parameter but still write nsegN since its needed for CNS

mol_semiflex_1: # choice (auto, rigid, manual), expert
  default: auto
  choices:
    - auto
    - rigid
    - manual
  group: 'flexbility'
  explevel: expert

Similarly nfleN:

if 0: none
if >1 == integer defining the number of segments

We can also alleviate that with adding a new parameter but still write nfleN since its needed for CNS that can even account for the full flexibility

mol_fullflex_1: 
  default: none
  choices:
    - none
    - manual
    - full
  group: 'flexibility'
  explevel: expert

Additionaly ranair is a boolean, but it should be a choice

ranair: 
  default: none
  choices:
    - none
    - manual
    - full
  group: 'ab initio mode'
  explevel: expert

and then nrair_N should be handled internally

[sverhoeven]

nrair_1 in rigidbody module is another number of segment parameter

[rvhonorato]

Did this get patched already @joaomcteixeira or is it still relevant?

[joaomcteixeira]

No. It is an open discussion, still. Currently, users need to provide nfle1 according to the number of segments defined in the configuration file. We can definitively handle this internally. Are there any significant reasons not to do it @amjjbonvin?

[rvhonorato]

I thought this should be implemented, changed it to discussion to better reflect the current state of things.

[joaomcteixeira]

@amjjbonvin, when you have time let us know your opinion here.

[amjjbonvin]

Looking at the discussion I think this all makes sense

[amjjbonvin]

As long as that parameter is written to the CNS input files it does not need to be defined by the user. But it is required for the CNS scripts to work properly