ModelApplier node: Missing input: Model, but model should be there

Question

Hello again,
Thanks for the quick response to my previous question about intermediate results.  I've now added a ModelWriter node to save the model after processing.

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.

What I'm trying to do is:

1. Read in training data (from a SQL Server database)
2. Convert one numerical attribute (age) to a nominal one
3. Create a multilayer perceptron neural net model
4. Read in some testing data (from SQL Server)
5. Convert age to nominal
6. Apply the model to the training data
7. Look at the performance

My operator tree looks like:

DatabaseExampleSource
AttributeSubsetProcessing
---- Numeric 2 Polynominal
W-MultiLayerPerceptron
DatabaseExampleSource(2)
AttributeSubsetPreProcessing(2)
----Numeric 2 Polynominal
ModelApplier
RegressionPerformance

The problem is that the I'm getting an error on the ModelApplier node saying "Missing input: model"  However, I added a breakpoint before the ModelApplier ndoe, and the model appears to exist, but the data table coming out of the AttributeSubetPreProcessing(2) seems to "mask" it somehow.

Confusingly, I can run the process to completion, and the model will in fact get applied, so the error doesn't seem to be causing a failure, it just generates an error message.

I tried adding an IOSelector node before the ModelApplier, with io_object=Model, thinking that the model might need to be the first object in the input queue.  That just moved the same error message from the ModelApplier to the IOSelector.

If I take the age attribute out of my model, which eliminates the need for the AttributeSubsetProcessing node, then everything works fine, without error.  So it seems that something about what that node is doing is causing the error message.

My hunch is that it has to do with how RM manages the input and output queues between nodes, but I don't quite understand why, and I didn't find a good explanation in the documentation.  Any explanation or pointers would be greatly apprecated.

Thanks,
Keith

keith · Answer

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.

Right, it occurred to me some time after I posted my previous message that I was really picturing a stack, not a queue.  Thanks again for your help.

Keith

TobiasMalbrecht · Answer

Hi Keith,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?

Yes, that is exactly the way it works.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?

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.

Regards,
Tobias

keith · Answer

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. (...)

Whew, I guess I did understand it after all!  :-)  Thanks for the explanation.  I wasn't confident in my understanding because of the error message.

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?

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?
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.

Perfect.  Thank you for your helpfulness and patience.

Keith