jmichel80
commented
5 years ago Hi @nividic i agree we don't know whether different toolkits will ultimately support the desired functionality. We may end up with features that only work with specific toolkits, but I don't see why the API couldn't cope with that.
Regarding mapping rules flexibility this could be done via deriving virtual base classes so that people can contribute in code an algorithm. Since the goal of LOMAP is to produce a network description of a dataset the algorithm should operate on a collection of N molecules to be mapped. The advantage is that you do not have to make assumptions that a given algorithm can be broken down into a set of rules that are supported by the data structure you would design. For this to work the mapping algorithm should have access to different types of data representing a molecule in a dataset (2D/3D structures), and may also need to load parameters from a database. For instance a decision as to whether two molecules should be mapped directly could be made on the basis of 2D or 3D similarity, or actual efficiency of free energy estimation on related and previously processed molecules.
Also in practice the code should support cases where one has already computed a network for a set of N molecules, and wishes to add M new molecules to that network, rather than compute a fresh network for the N+M molecules.
This is useful because users may iteratively process batches of molecules (they don't know what they want to simulate until some results have been obtained), or because some users may have very large datasets that cannot be processed in a timely manner (because of the likely at least N^2 scaling of the operations needed to find a good network).
nividic
davidlmobley
Dear All, this is a partial starting plan to the Lomap code refactoring.
My idea is refactoring Lomap in building blocks. The refactoring will be large, and the current code will not be compatible with future versions. We can afford this kind of refactoring mainly because the current Lomap user base is not large and we do not have to rely on specific generated input/output Lomap formats that needs to be kept between versions. The refactoring should address the following main key points:
(1) support to multiple toolkits;
(2) support to NOT hardcoded rules to score molecules and to generate graphs;
(3) catch up with the latest package dependencies.
The first request will allow users to set their favorite chemoinformatic environment. Two possible toolkits have been selected so far: RDkit and OpenEye which are well spread in the community. The second and most important request will allow users to introduce new science in the construction of RBFE pre-calculation plans with the hope of increase RBFE efficiency. Finally, Lomap has not been maintained for long time and the package dependency updates have broken the current code in many points.
Multiple toolkit support
The first step is to support multiple toolkits. This can be accomplished in many ways and I advise to build a "common API" across the different toolkits. For example, in one of the first steps, Lomap requires the construction of a molecule database. This database could be populated by reading molecules from a given file format. Therefore, it must exist somewhere a reading function that accomplish this task. The reading function should be part of the “common API” however, when it is invoked the portion of code related to the selected toolkit will be executed. The common API is a sort of pillow between the users and the effective toolkit in use. The toolkit selection happens when the Lomap module is loaded. In case multiple toolkits are present one will be defined as “DEFAULT”. The user will be allowed to switch at running time between toolkits, but particular attention will be required to not invalidate previously built structures with a different toolkit (this functionality could create issues and I do not think that is an important user scenario). The toolkit selection will load the “common API” which will automatically point to the exposed toolkit functionalities (classes, functions etc.) The drawbacks to have a common API that I can spots are:
Support to NOT hardcoded rules to score molecules and to generate graphs
This is the most important key point and although a lot of thinking I’m still not sure what is the best thing to do. Here I was looking for API simplicity and flexibility. What I have come up so far is the following: the user can define or use rules from a repository. A rule is a function that execute a specific simple task. Rules will have a generic number of arguments and can return a generic number of outputs. Rules can operate on different objects. So far, the Lomap rules are operating on two molecules only returning a number. Rules can be combined together in an “algorithm” to accomplish a set of simple tasks. When the Lomap module is loaded the rules are loaded as well; users can add new rules at running time (here we can have also asymmetry between the toolkits loading different rules based on the default toolkit). Rules can manage set of molecules retuning numbers other molecules or graphs or combination of them. The user defines at running time “algorithms” that mixes the rules or use predefined “algorithms” from a repository. I think this is a quite general idea that should handle large class of problems that we would like to tackle.
Catch up with the latest package dependencies
Some important packages dependency updates have been done along the past years and we need to catch up with these updates. Networkx 2.2 has broken the code in the graph generation section but I think @ppxasjsm has fixed it updating also the graph plotting with new design features not based on the old pyqt code. We can incorporate all these changes but at the end of the large refactoring and in the meanwhile users should use the previous update @ppxasjsm 's version.
Please comments on the previous key points and when we will agree on them, we can start the development. I’m willing to work on the code (compatibly with my working schedule) and when the refactoring will be completed I would/have to work on the development of the OpenEye side the most.
Best