Feature Request: Residue Depth MSMS application integration

[ncoish]

BioPython supports using the MSMS tool to find residue depth from the solvent accessible surface. It would be great if Biotite could support this as well, possibly through an extension to the Application submodule.

I would be happy to help contribute to this, or if you have another suggestion for accomplishing the same goal I'm all ears!

The equivalent submodule in BioPython:
https://biopython.org/docs/1.75/api/Bio.PDB.ResidueDepth.html

[padix-key]

An Application class for the MSMS software sounds like a good idea to me! Since MSMS does not implement the residue depth directly (does it?), I think the depth should be implemented either in a separate function or as an example for the gallery. I am open to discussion, which of the options would fit better here. If implemented as function that would give the depth of each atom in an AtomArray, I think the more fitting term would be 'burying depth' as used for example here, because a single atom is no residue.

I would be happy if you could implement this functionality. If you need some support, feel free to ask.

I found a manual for MSMS with more in-depth explanation of the CLI parameters that the software itself: https://ccsb.scripps.edu/msms/documentation/

[ncoish]

I have an MVP version of the MSMS application working now, and I will open a PR soon, but I do have a couple of things I would appreciate your opinion on:

1. Looking through the other Application modules, it seems that you don't really expose the full set of CLI parameters to the caller, instead making decisions on their behalf. Is that a pattern you want to continue in all applications, or do you see value in adding extra parameters to __init__ to allow more granular CLI configuration?
2. Biopython uses a rather elaborate lookup method to determine atomic radii. This will be necessary for Biotite as well in order to construct the .xyz file necessary for MSMS to run. Should we just copy the BioPython lookup (and license) with minor modifications, or do you have another suggestion for atomic radii lookup?

[padix-key]

Hi, this sounds great. Regarding your questions:

1. The idea of the supported parameters in the Application classes has been to maximize the comfort for the user. This means that some parameters are always set, that are required to build the seamless interface. For example the output format must be compatible with the information you would like to return and with the parsers supported in Biotite. Furthermore, the most common parameters are directly set in the constructor and more rare options are set via the member methods in the CREATED state (se for example BlastWebApp), but there is really no hard boundary, what is 'common' or 'rare'. I would leave this up to you. Since some programs offer a myriad of options, that would be tedious to implement in a LocalApp, often not all options are implemented. If the user requires such an option nevertheless, they can use the add_additional_options() method. In the end it is up to you, how many parameters you deem worthy for implementation in the LocalApp for MSMS.
2. I would suggest to solve this problem in the same manner as in structure.sasa(). Here the parameter vdw_radii exists, that picks the radii from either vdw_radius_protor() (structures with no hydrogen), vdw_radius_single() (all atom structures) in biotite.structure.info, based on user decision. As alternative radii can be given by the user as array, if they need a custom solution. In the solution in Biopython you posted, there is unfortunately no citation, so I have no idea, whether their radii are more or less physical than then ones implemented in Biotite. If you like to implement another published method for radii calculation, I would propose you put this as separate function into biotite.structure.info.radii. This way the method is also usable for sasa() and any other purpose the user might have.