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

Instatiator ignores in modes for end to end flows #2005

Closed
joeseibel opened this issue Oct 2, 2019 · 5 comments · Fixed by #2107
Closed

Instatiator ignores in modes for end to end flows #2005

joeseibel opened this issue Oct 2, 2019 · 5 comments · Fixed by #2107
Assignees
Milestone

Comments

@joeseibel
Copy link
Contributor

@joeseibel joeseibel commented Oct 2, 2019

When instatiating an end to end flow, the instatiator looks at the modes for all of the subcomponents and connections, but not the end to end flow itself. In the following example, the end to end flow only exists in mode m2, but the end to end flow instance exists in both SOMs when it should only exist in som_2:

package pkg1
public
  system top
    modes
      m1: initial mode;
      m2: mode;
  end top;

  system implementation top.i
    subcomponents
      sub1: system s1;
      sub2: system s2;
    connections
      conn1: feature sub1.out1 -> sub2.in2;
    flows
      etef1: end to end flow sub1.source1 -> conn1 -> sub2.sink2 in modes (m2);
  end top.i;

  system s1
    features
      out1: out feature;
    flows
      source1: flow source out1;
  end s1;

  system s2
    features
      in2: in feature;
    flows
      sink2: flow sink in2;
  end s2;
end pkg1;

If in modes (m2) is added to one of the subcomponents or the connection, then the end to end flow instance will only exist in som_2.

@lwrage lwrage added the core label Oct 16, 2019
@lwrage lwrage added this to the 2.6.1 milestone Nov 7, 2019
@lwrage lwrage removed this from the 2.6.1 milestone Nov 15, 2019
@lwrage lwrage assigned AaronGreenhouse and unassigned lwrage Dec 4, 2019
@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Dec 6, 2019

The in modes on the end to end flow declaration is ignored. The instantiation process infers the system operation modes that the end to end flow is capable of existing in. Probably we should add a step where we limit that set based on the in modes of the end to end flow.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Dec 10, 2019

So actually, the process is already trying to do the correct thing. It happens at the end of CreateEndToEndFlowsSwitch.fillInModes(). This is called by continueFlow(). The problem seems to be that is being called more than once as the chain of method calls through the flow unwind. The end of fillInModes() clears the modesList attribute of the end to end flow. This is the attribute that handles the modes declared on the end to end flow. So when fillInModes() is called again, it recomputes the modes for the end to end flow but ignores the modes from the end to end flow declaration itself.

I need to see how to keep the method from being called more than once.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Dec 10, 2019

I added a new Set field completedETEI to CreateEndToEndFlowsSwitch to keep track of the end to end flow instances that have already been completed.

	private final Set<EndToEndFlowInstance> completedETEI = new HashSet<>();

Updated continueFlow() to check and maintain this set:

	private void continueFlow(ComponentInstance ci, EndToEndFlowInstance etei, FlowIterator iter,
			NamedElement errorElement) {
		while (true) {
			if (ci == null) {
				error(errorElement, "Flow instance leaves system instance for flow " + etei.getInstanceObjectPath());
				connections.clear();
				return;
			}
			while (iter.hasNext()) {
				Element e = iter.next();
				processETESegment(ci, etei, e, iter, errorElement);
			}
			if (state.size() == 0) {
				if (!completedETEI.contains(etei)) {
					// a flow is done
					fillinModes(etei);
					myInfo.postConns.addAll(connections);
					connections.clear();
					completedETEI.add(etei);
				}
				break;
			}
			iter = state.pop();
			ci = ci.getContainingComponentInstance();
		}
	}

Seems to fix the problem.

I need to add JUnit tests now.

@lwrage lwrage added this to the 2.7.0 milestone Dec 10, 2019
@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Dec 11, 2019

I ran the existing unit tests and Serializer2Test failed. Upon investigation, I found a weird thing. Despite the processing do the wrong thing and calling fillInModes() multiple times, the SOMs for the end to end flow etef1 below are correct in the original version, but incorrect after my above fix.

package pkg1
public
  system top
    modes
      m1: initial mode;
      m2: mode;
      m3: mode;
      m4: mode;
  end top;

  system implementation top.i
    subcomponents
      sub10: system s1;
      sub20: system s2;
    connections
      conn10: feature sub10.out1 -> sub20.in2;
    flows
      etef10: end to end flow sub10.source2 -> conn10 -> sub20.sink2;
  end top.i;

  system s1
    features
      out1: out feature;
    flows
      source1: flow source out1 in modes (a1);
      source2: flow source out1 in modes (a2);
  	modes
  	  a1: initial mode;
  	  a2: mode;
  end s1;

  system s2
    features
      in2: in feature;
    flows
      sink1: flow sink in2 in modes (b1);
      sink2: flow sink in2 in modes (b2);
  	modes
  	  b1: initial mode;
  	  b2: mode;
  end s2;
end pkg1;

The immediate reasons for this are because the first time fillInModes runs the "modes list" of the flow is a "list of the empty list." This creates an empty list of SOMs. The second time it runs the modes list is just the empty list. This creates a different list of SOMs, which is the set of all SOMs that contain modes a2 and b2. (This is the correct result that we really should have the first time around.)

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Dec 11, 2019

fixed fillInModes() to skip over mode lists that are empty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants