I am hoping to use KNIME for some "experimental design" in medicinal chemist. In general this requires consideration of number of virtual molecules with a workflow to accept, reject or rank them based on drug-likeness (eg Lipinski's rules); user filters on properties or functionality groups; ability to satisfy one or more design goal or hypothesis for biological activity (ie single or multiple goal optimisation).
If one was writing such an application for a standard molecular modelling product, one would use scripts with for or while loops with breakouts for maximum number of iterations, time outs, achieving the target number of molecules to make etc. To some extent the preferred choice of code structure is arbitrary. KNIME offers the potential of using tools from multiple vendors and providing less of a 'black box' solution.
The looper seems to provide an inadequaate control structure for this task because:
1. The loop iteration counter is not available to the nodes.
2. An output row is required even if the contents are of no interest because the corresponding molecule is hopeless. (This has grave memory implications). I can also envisage circumstances when one would want to output a table for the best solution rather than a row per iteration.
3. There is no means of prematurely stopping the looping for instance when sufficient quality molecules have been found.
4. Any property or functional group filters have to be configured and passed to the loop using some concept of global scope variables (eg environment variables) created by some special node outside the looper.
5. For combinatorial chemistry the pictures becomes more complex because it would be desirable to use the minimum number of reagents to generate the best distribution of molecules which should show activity.
Based on a previous thread I understand that 2.x will have some improved looper capabilities and global scope variables. Is there any details available of the planned changes to the Looper?
Have any other developers looked at experimental design loops?
Has any-one attempted to rewrite Looper? Or is that a KNIME in-house developer challenge?
1. The loop iteration counter is not available to the nodes.
Will change in 2.0. There you can pass so-called scope-variables along the flow, that the nodes can use (in the dialog and/or directly in the code).
THINK wrote:
2. An output row is required even if the contents are of no interest because the corresponding molecule is hopeless. (This has grave memory implications). I can also envisage circumstances when one would want to output a table for the best solution rather than a row per iteration.
The current loop just collects all the rows from the iterations. An iteration may also produce an empty table at its last node, that is no problem. Though doing some selection for the "best of x" rows is currently not possible without writing a special meta node. That will also change in 2.0, when it is far more easy to write your own loop nodes.
THINK wrote:
3. There is no means of prematurely stopping the looping for instance when sufficient quality molecules have been found.
Doing this requires writing your own loop-end node in 2.0 which can the decide if another iteration should start or not depending in the passed along scope variables or the data collected so far.
THINK wrote:
4. Any property or functional group filters have to be configured and passed to the loop using some concept of global scope variables (eg environment variables) created by some special node outside the looper.
This will also come with 2.0. Any node may put something onto a so-called scope stack and any node may read these variables (as long as it knows the name and correct type).
THINK wrote:
Based on a previous thread I understand that 2.x will have some improved looper capabilities and global scope variables. Is there any details available of the planned changes to the Looper?
I don't think that the looper itself will change its behaviour. But as stated above it will become much easier to write your own looping nodes. We have already migrated the loop and cross validation node to the new concept, and have also already implemented a feature selection node. All with much less code and hassle than with KNIME 1.x
THINK wrote:
Or is that a KNIME in-house developer challenge?
With 1.x it unfortunately is...
This was much referring to the mysterious 2.0 release, but be assured, it will come 8)