-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug when resetting and executing transfer mechanism on different passes #3142
Comments
Adding some debug output:
distilled to just the executed parts:
The transfer mechanism is reset at the beginning of each trial. as requested by AtTrialStart |
The generated output matches the above:
The result of the first input is identical, as is the executed sequence. Executing only one input also produces matching results:
and
looks like there's something more happening between the trials |
Could it be an input port (on the my_lca mechanism) and/or an output port (on the my_input mechanism) issue, where even before execution the port gets populated with new/resetted values in Python mode but not in LLVMRun mode? |
Yes, I think it's an issue with output port values after reset. Python appears to update the output ports after Mechanism reset, which is not done in compiled mode. inserting some tracking to Python reset function confirms this:
The above is printing the mechanism and output port values before and after the call to reset. |
Thanks, Jan. How easy (and acceptable) a fix is this for compiled mode?
jdc
On Feb 4, 2025, at 12:51 PM, Jan Vesely ***@***.***> wrote:
Could it be an input port (on the my_lca mechanism) and/or an output port (on the my_input mechanism) issue, where even before execution the port gets populated with new/resetted values in Python mode but not in LLVMRun mode?
Yes, I think it's an issue with output port values after reset. Python appears to update the output ports after Mechanism reset, which is not done in compiled mode.
It looks like the first trial gets "lucky" and the output port values after reset would match those that are set during model construction so the compiled mode produces the correct result.
However, after the second reset the compiled mode does not update the output port values until <1/5/0> so the first 5 executions of the LCA would consume incorrect inputs.
inserting some tracking to Python reset function confirms this:
$ python 3142.py
Python Mode:
RESET INTEGRATOR START: TransferMechanism-0 AdaptiveIntegrator Function-1 [[0. 0.]] [array([0., 0.])]
RESET INTEGRATOR: TransferMechanism-0 AdaptiveIntegrator Function-1 [[0. 0.]] [array([0., 0.])]
RESET INTEGRATOR START: TransferMechanism-0 AdaptiveIntegrator Function-1 [[1. 0.]] [array([1., 0.])]
RESET INTEGRATOR: TransferMechanism-0 AdaptiveIntegrator Function-1 [[0. 0.]] [array([0., 0.])]
...
The above is printing the mechanism and output port values before and after the call to reset.
The first reset zeros both, but the new values match the old ones.
The second reset also zeros the values, but it overwrites the old values of [[1, 0]]. This is not happening in compiled version.
—
Reply to this email directly, view it on GitHub<#3142 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACSHKGHUFOWMOONZITVSJ4D2OD4YNAVCNFSM6AAAAABTM4COQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZUGY3DSMRWG4>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
There is a difference in Python mode and compiled mode, which I assume reflects a bug on the compiled side or at least an unimplemented feature that does not throw up a warning message:
When a transfer mechanism has reset_stateful_function_when=pnl.AtTrialStart() but is scheduled to only execute on a later pass, for example pass 5, then python mode will appropriately reset the mechanism at pass 0 and execute the mechanism at pass 5.
In compiled mode, however, the reset does not happen on pass 0 but instead on pass 5 when the mechanism executes. A reproducible example is posted below.
The text was updated successfully, but these errors were encountered: