Skip to content
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

End to end flow instance is not created if subprogram access connections are involved #1941

Closed
reteprelief opened this issue Aug 8, 2019 · 9 comments

Comments

@reteprelief
Copy link
Contributor

@reteprelief reteprelief commented Aug 8, 2019

See the end to end flow and the remote subprogram call from t2 to t1.
Examples.txt

@lwrage
Copy link
Contributor

@lwrage lwrage commented Aug 8, 2019

Maybe caused by #676. E2e flow instantiation assumes there are only unidirectional connections in the instance model.

@lwrage
Copy link
Contributor

@lwrage lwrage commented Aug 9, 2019

Likely duplicate of #643.

@lwrage lwrage changed the title End to end flow instance is not created if subprogam access connections are involved End to end flow instance is not created if subprogram access connections are involved Aug 25, 2019
@lwrage lwrage assigned lwrage and AaronGreenhouse and unassigned lwrage Aug 25, 2019
@lwrage lwrage added this to the 2.6.0 milestone Aug 26, 2019
@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Oct 18, 2019

Tried instantiating Example19.impl. The end to end flow is created, and seems to be correct. However, actually 2 end to end flows are created, and one of them seems spurious.

Screen Shot 2019-10-18 at 12.36.19 PM.png

I'm investigating the second end to end flow (Speed_E_E_2) now. Not sure what it is created, or if it even has anything to do with the original problem of subprogram access connections.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Oct 18, 2019

The second end to end flow comes about because when looking for the connection instances that come out of flow Flow_Sub that match the connections list [ac2], we end up with two connection instances. This occurs as follows:

  1. In processFlowStep(ComponentInstance, EndToEndFlowInstance, Element, FlowImplementation, FlowIterator) the method collectionConnectionInstances() is called. The connections field contains one Connection, "ac2", which is the connection that immediately follows MyT1.Flow_Sub in flow path Flow2.
  2. Method collectionConnectionInstances() tests all the available connection instances using testConnection().
  3. The instance model has a semantic connection "MyT1.CompAvg -> MyT2.ext_sub" corresponding the connections ac1 and ac2.
  4. This connection matches in testConnection() because
  • The first part of the method is designed to match any connection instance where that has connections as a sublist of the connection references. [ac2] is a sublist of [ac1, ac2].
  • The directions of the flow and connection match
  • The final part of the method is designed to check that the end points of the connection instance and flow match, but only if the endpoint is a feature. As the end point of "MyT1.CompAvg -> MyT2.ext_sub" is a subprogram subcomponent, these check does nothing.

So I'm a bit confused why testConnections() operates the way it does.

  • Why does it check for a sublist? I would think you would want to check if the lists are identical.
  • Why are only feature endpoints checked? Is this an oversight, or there a reason for this?

It still seems to me that we do not want this second end to end flow. The matching of this second connection instance doesn't make a lot of sense.

@lwrage
Copy link
Contributor

@lwrage lwrage commented Oct 21, 2019

The connection instantiation is messed up. The ext_sub - shared_sub connection instances shouldn't be there and there should be an additional connection instance ext_sub -> CompAvg.

If I remove the subprogram the connections and flows are instantiated as expected.

@lwrage
Copy link
Contributor

@lwrage lwrage commented Oct 21, 2019

We need a better test case for this issue with calls and connections via call parameters.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Oct 22, 2019

Created a new issue for the connections problem and made this issue depend on it (Issue #2032)

@lwrage lwrage removed this from the 2.6.0 milestone Oct 24, 2019
@lwrage lwrage added this to the 2.6.1 milestone Oct 24, 2019
@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Nov 12, 2019

This seems to be fixed by #2032. The bad "ext_sub - shared_sub" connection is gone, and the missing "ext_sub -> CompAvg" connection is now present. There is one end to end flow instance created.

@lwrage lwrage removed this from the 2.6.1 milestone Dec 5, 2019
@lwrage lwrage added this to the 2.7.0 milestone Dec 5, 2019
@lwrage
Copy link
Contributor

@lwrage lwrage commented Jan 3, 2020

Fixed together with #2032

@lwrage lwrage closed this as completed Jan 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants