A program to recognize and reward our most engaged community members
keith wrote:I've run into another issue that I can't quite figure out. I think it's because I don't quite grasp how RM handles the stream of output objects that are passed from node to node during a process.
Tobias Malbrecht wrote:Well, generally it is pretty easy. Everything that is not consumed by an operator is passed on to the next one. This means, a model is passed on to the next operators by all operators which do not consume a model. (...)
The error (warning) you get, is therefore not intended. It seems that the process verification procedure which verifies if all required inputs of the operators match the outputs of the previous operators in line does not recognize the model and it seems indeed to be covered by the second example set. We will have a look into this issue and see if we can do anything about that. Until then, simply ignore the warning message. At least the process works at it should! Thanks for pointing out the problem.
keith wrote:Am I correct in thinking that the IOSelector node is intended for situations where you have multiple objects of the same type (e.g. two models, or two ExampleSets), and you want to bring one of them to the "front" of the queue, so it will be the next one of its type to be consumed?
keith wrote:Is it proper to think about the about the available inputs as a queue for each type, or is there a better way to visualize how RM handles them?
Tobias Malbrecht wrote:You can think about it as a queue. But since a operator puts a new output in front of the queue instead of queueing it at the end, it is more like a stack I think.