You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When applying the rigid rotational transform being worked on in #3756 I hit an infinite loop in the order_transforms function. This happened in a case when I defined priors on the cartesian spin components, which are both input to and output by the transform, and this was the only transform being applied. As a result this line resolves as False and we get stuck.
I would be interested in hearing suggestions about how to overcome this. Is this a bug that could recur in other cases that we should fix? (There look to be other transforms that have parameters common between their inputs and outputs, e.g.). Or would it be preferable to change our new transform to avoid this?
The text was updated successfully, but these errors were encountered:
Interesting... I forgot we had transforms that can have shared input and output parameters (we really haven't used the other spin transforms; they were written as a part of a master's student's project, then never really put to use). The ordering function should be able to handle that. I think the easiest solution is to modify order_transforms to pull out new outputs rather than all outputs. In other words, change line 2268 to:
outputs = set().union(*[set(t.outputs)-set(t.inputs) for t in transforms])
When applying the rigid rotational transform being worked on in #3756 I hit an infinite loop in the
order_transforms
function. This happened in a case when I defined priors on the cartesian spin components, which are both input to and output by the transform, and this was the only transform being applied. As a result this line resolves as False and we get stuck.I would be interested in hearing suggestions about how to overcome this. Is this a bug that could recur in other cases that we should fix? (There look to be other transforms that have parameters common between their inputs and outputs, e.g.). Or would it be preferable to change our new transform to avoid this?
The text was updated successfully, but these errors were encountered: