Desired feature/enhancement
While the PDB format is limited to a max of 99999 atoms, CNS can in principle handle more than that since it uses for number >99999 the hydrid_36 format (see https://cci.lbl.gov/cctbx_sources/iotbx/pdb/hybrid_36.py)
The current limitation in HADDOCK3 comes from the topoaa module that call pdb_tidy and pdb_tidy has a hard check for the 99999 limit.
Two options:
- modify topoaa to bypass the pdb_tidy call and handle PDB files that use the hydrid_36 format (generated by CNS)
- modify
pdb_tidy in the pdb-tools repo to add an option to handle hydrid_36 format
Motivation
Dealing with very large systems (e.g. ribosome) (some ongoing project)
Description
Option 2 is the simplest to implement and I already have a working version.
The hybrid_36 format can be supported by adding the -cns option as argument to pdb_tidy
This option could thus be used in the topoaa module.
It will mean updating pdb-tools and then defining a minimal version for it in the HADDOCK3 dependencies.
Desired feature/enhancement
While the PDB format is limited to a max of 99999 atoms, CNS can in principle handle more than that since it uses for number >99999 the hydrid_36 format (see https://cci.lbl.gov/cctbx_sources/iotbx/pdb/hybrid_36.py)
The current limitation in HADDOCK3 comes from the
topoaamodule that callpdb_tidyandpdb_tidyhas a hard check for the 99999 limit.Two options:
pdb_tidyin thepdb-toolsrepo to add an option to handle hydrid_36 formatMotivation
Dealing with very large systems (e.g. ribosome) (some ongoing project)
Description
Option 2 is the simplest to implement and I already have a working version.
The hybrid_36 format can be supported by adding the
-cnsoption as argument topdb_tidyThis option could thus be used in the
topoaamodule.It will mean updating
pdb-toolsand then defining a minimal version for it in the HADDOCK3 dependencies.