Hi @mccall.ryan , all,
I am trying to use your version of the HTM Engine (MultiStep Predictions added) but I am facing an error on the Anomaly service when I run the supervisor.
Do you know why this happens?
Best regards,
José Santos
Hi @mccall.ryan , all,
I am trying to use your version of the HTM Engine (MultiStep Predictions added) but I am facing an error on the Anomaly service when I run the supervisor.
Do you know why this happens?
Best regards,
José Santos
I moved this topic from #nupic:developers into #NuPIC (because the developers channel is for discussion about contributions to the NuPIC codebase).
Hi José,
Thanks for the report. Could you give some more context and description of
how to reproduce the error?
Also, did you run the database migration?
best,
Ryan
Ryan J. McCall
ryanjmccall.com
Hi, ryan,
When I run the migration script I encounter an error (I added the script for the new column):
I suppose that the error is related to the revisions.
Best regards,
José Santos
Hi Ryan,
I have made some tests and by removing the 002 revision from the versions folder I was able to migrate the dabase and adding the multiStep column to the database.
However, when I run the supervisor, the htmengine.anomaly service fails. The error is the same that I pasted here on the top.
Best regards,
José Santos
Hi José,
I found one problem. I originally made the new version file for the database migration with respect to the most recent revision found in the skeleton-htmengine-app repo. But there is divergence b/w the set of these version files and those in htmengine; namely, there is an extra file. I found that updating the version 003 like this fixes the problem:
down_revision = ‘872a895b8e8’
I’ll push that up.
As for the initial exception in anomaly service, please paste the full stack trace. It seems something has been cut off at the beginning.
Best,
Ryan
Hi Ryan,
I tested the new migration script and there is no problem with it.
I am sending the full log of the anomaly service:
Thank you for the help.
Best regards,
José Santos
Hi José,
I was able to reproduce your stack trace. The problem occurs if the [db-name].mswapper.results queue contains “old” messages (e.g., from running HTM engine from master) lacking the best predictions. then the model swapper interface objects to reconstructing the ModelInferenceResult
object from the received message raising an AssertionError because it detects that the number of attributes (defined in slots) (and increased by 1 in my PR) doesn’t match the number of attributes in the item’s state. If you don’t care too much about the in-progress results in the results queue, I’d recommend flushing out that queue to solve the problem.
Best,
Ryan
Hi Ryan,
Thank you for the help, now it’s working! The default value of the steps is “1” right? Can I change this through the HTTP API when I define the model parameters, such as the max and min?
Best regards,
José Santos