From 6ec62d6224aaef1c6d4c472dd9d35283702d40c4 Mon Sep 17 00:00:00 2001 From: Ajay Seth Date: Mon, 7 Nov 2016 13:52:40 -0800 Subject: [PATCH 1/6] First draft of a design proposal to exclude a Component from the underlying System. The purpose it to to handle common a desired use case for completely ignoring the existence of a Component so once can accurately assess its impact on computation. --- .../excludeComponentFromSystem.md | 65 +++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md diff --git a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md new file mode 100644 index 0000000000..99e9104214 --- /dev/null +++ b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md @@ -0,0 +1,65 @@ +## Proposal: Exclude Components from the underlying Computational System +***OpenSim Development Proposal*** + +### Overview +This proposal describes how OpenSim Component's can be excluded from computations and thereby replace +the adhoc mechanisms in place that attempt to "disable" certain components, like Forces and Constraints. +The adhoc nature of the current mechanism puts the burden of "disabling" a Component on the Component +writer and results in inconsistent behaviours, including partially disabling by not applying the force of a Muscle, for example, to the the MultibodySystem, but still computing the force or other costly values such as its length. +The overall desired behaviour is that a Component that is disabled (excluded) is excluded from any +downstream computations and is effectively removed from the Model and resulting System. + +For background, see: +- [issue #845](https://github.com/opensim-org/opensim-core/issues/845) +- [issue #1111](https://github.com/opensim-org/opensim-core/issues/1111) +- [issue #1358](https://github.com/opensim-org/opensim-core/issues/1358) + +**Current Behaviour** + +Several Components, namely Forces, Constraints and Controllers, can be disabled with the expectation that disabled means they no longer effect the computations and dynamics of the System. This is not the case. While an OpenSim `Force::computeForce(s)` is not invoked if a Force is disabled, any and all of its `realize` methods remain and are apart of the realization of the System. That means that position and velocity calculations are available for invocation and the onus is on the Force writer to check that the Force is disabled to skip those evaluations. In many case, such as Muscle path length calculations and drawing of the path these are likely to have unexpected consequences on a Model (System) where the disable Component is expected to have no effect. + +### Requirements +- Exclusion means the Component is not present in computational System in any shape or form. It has absolutely no effect, direct or otherwise, on the System. +- Any Component can be excluded from the Model's System. +- Exclusion of a Component means the exclusion of all its subcomponents. +- Exclusion status is a property NOT a discrete state variable. +- The only way to change the exclusion status is to update the associated property (flag) and triggering `finalizeFromPropeties()` +- Exclusion status overrides existing disabling behaviour. In other words, if a Component is excluded, the status of an existing disabled flag is irrelevant, since the Component for all intents and purposes does not exist. If the Component is not excluded + +### Architecture +The design proposes adding the ability to exclude Components independent of whether or not they can be disabled. +These are the proposed changes: + +1. add an `excluded` flag as a property to `Component` with a default value of `false` +2. the inclusion of a Component property as a subcomponent becomes contingent on the flag being `false` and if true it is not included as a subcomponent and it can no longer receive delegated Component interface calls to `connect()`, `addToSystem()`, `realize*()`, etc... +3. Component::getComponentList is devoid of excluded components and does not merely "skip-over" excluded Components. + +### Interfaces +The added `excluded` property results in property related methods being added to the `Component` interface, such as: `get_excluded()`, `upd_excluded`, `getProperty_excluded()`, ... + +### Bindings and GUI +There are no special implications for Python and Java bindings. A Component that is excluded is still accessible via Property accessors so its exclusion status can be changed. It is imperative then that the GUI provide a list of ALL components (including excluded Components) and cannot rely on the ComponentList iterator to achieve this. + +### Backwards Compatibility +The ConsoleReporter and TableReporter classes are new to 4.0, so there are no backwards compatibility issues. + +### Lifecycle and Ownership / Memory Management +No new objects are being proposed. + +### Performance Considerations +No significant changes in performance are expected. + +### Required Tests +Additional test cases will be added to verify that: +1. an excluded Component is inaccessible from its parent (owning) Component and Model. +2. excluding Components never increases the number of computations to realize the Model from `Time` to `Report`. +3. re-including a Component(setting excluded to false) and finalizing from properties +4. verify that Tool performances with excluded Constraints, Forces and Controllers yields the same results as when they were disabled. + +### Potential hurdles or roadblocks +Exclusion and disabling will coexist (at least initially) and we should decide in which use cases does the user/test case intend to exclude the Component altogether in the analysis or whether the Component was intentionally and temporarily being disabled as part of a more complex analysis (e.g. InducedAccelerationAnalysis disables all Forces and them enables them one by one to compute its contribute to system acceleration) in which case to exclude would be incorrect usage). + + +### Pull Requests +A single PR should be necessary to implement the proposal, however a subsequent PR may be required +to improve error messages (e.g. excluding the pelvis from a gait model will fail when attempting to establish valid connections for hip joints, etc...) From 494b3ac548d61926cdc36b5d2eed8f3ff320125e Mon Sep 17 00:00:00 2001 From: Ajay Seth Date: Mon, 7 Nov 2016 15:09:22 -0800 Subject: [PATCH 2/6] Include more details describing the need for this feature. --- .../excludeComponentFromSystem.md | 47 ++++++++++--------- 1 file changed, 26 insertions(+), 21 deletions(-) diff --git a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md index 99e9104214..56a6a80dea 100644 --- a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md +++ b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md @@ -1,13 +1,15 @@ ## Proposal: Exclude Components from the underlying Computational System ***OpenSim Development Proposal*** +### The Need: + +Models are complicated and the Component paradigm is enabling the construction of ever more complex models and behaviours. Modeller have to troubleshoot and users must test models, which often requires isolating a problematic component. The easiest way to isolate a problematic Component's effect is to effectively remove it from the Model and see if the problem is alleviated. The current method is to *disable* the Component, which is applicable to a handful of Components (Constraints and Forces). Unfortunately, disabling does not equate to effectively removing the Component and the effect of disabling is inconsistent across the subset of Components. + +The purpose of this proposal is to enable the fundamental ability to effectively remove a Component so one can accurately assess its impact on computation (timing, CPU usage) and results. Currently, users have little confidence that disabling a Component (if it has that option) effectively removes its calculations and it is often recommended to remove Components by hand from XML files. + + ### Overview -This proposal describes how OpenSim Component's can be excluded from computations and thereby replace -the adhoc mechanisms in place that attempt to "disable" certain components, like Forces and Constraints. -The adhoc nature of the current mechanism puts the burden of "disabling" a Component on the Component -writer and results in inconsistent behaviours, including partially disabling by not applying the force of a Muscle, for example, to the the MultibodySystem, but still computing the force or other costly values such as its length. -The overall desired behaviour is that a Component that is disabled (excluded) is excluded from any -downstream computations and is effectively removed from the Model and resulting System. +This proposal describes a simple mechanism to exclude OpenSim Components from all computations. It can, in many cases, replace the adhoc mechanisms to "disable" components (offered by Forces and Constraints). The nature of the current scheme places the burden of "disabling" a Component on the Component writer and results in inconsistent behaviours, including partially disabling by not applying the force of a Muscle, for example, to the the MultibodySystem, and still computing the force or other costly values such as its length. A common objective of excluding a Component is to accurately assess what effect that Component is having on the System. The desired behaviour is that a Component is excluded from any downstream computations and is effectively removed from the Model and resulting System without the user having to resort to XML editing. For background, see: - [issue #845](https://github.com/opensim-org/opensim-core/issues/845) @@ -16,50 +18,53 @@ For background, see: **Current Behaviour** -Several Components, namely Forces, Constraints and Controllers, can be disabled with the expectation that disabled means they no longer effect the computations and dynamics of the System. This is not the case. While an OpenSim `Force::computeForce(s)` is not invoked if a Force is disabled, any and all of its `realize` methods remain and are apart of the realization of the System. That means that position and velocity calculations are available for invocation and the onus is on the Force writer to check that the Force is disabled to skip those evaluations. In many case, such as Muscle path length calculations and drawing of the path these are likely to have unexpected consequences on a Model (System) where the disable Component is expected to have no effect. +There is currently no ability to effectively exclude a Component from the underlying System short of editing the Model's XML file. Several Components, namely Forces, Constraints and Controllers, can be disabled with the expectation that disabled means they no longer effect the computations and dynamics of the System. This is also not necessarily the case. While an OpenSim `Force::computeForce(s)` is not invoked if a Force is *disabled*, any and all of its `realize` methods remain a part of the realization of the System. That means that position, velocity, ... (includes reporting) calculations are available for invocation. The onus is on the Force writer to check that the Force is disabled to skip those evaluations. In many cases, such as Muscle path length calculations and drawing of the path these are likely to have unexpected consequences on a Model (System) where the disable Component is expected to have no effect. ### Requirements -- Exclusion means the Component is not present in computational System in any shape or form. It has absolutely no effect, direct or otherwise, on the System. +- Users require a bullet-proof method of excluding components without editing XML to manually remove the Component. +- Exclusion must entail that the Component is not present in the computational System in any shape or form. It has absolutely no effect, direct or otherwise, on the System. - Any Component can be excluded from the Model's System. - Exclusion of a Component means the exclusion of all its subcomponents. - Exclusion status is a property NOT a discrete state variable. - The only way to change the exclusion status is to update the associated property (flag) and triggering `finalizeFromPropeties()` -- Exclusion status overrides existing disabling behaviour. In other words, if a Component is excluded, the status of an existing disabled flag is irrelevant, since the Component for all intents and purposes does not exist. If the Component is not excluded +- Exclusion status overrides any existing disabling behaviour. In other words, if a Component is excluded, the status of an existing disabled flag is irrelevant, since the Component for all intents and purposes does not exist. If the Component is not excluded, a disabled Constraint or Force will ONLY have its dynamic contribution ignored and will have no guarantees on other computations. ### Architecture -The design proposes adding the ability to exclude Components independent of whether or not they can be disabled. -These are the proposed changes: +The design proposes adding the ability to exclude Components independent of whether or not it can be disabled. +These are the main changes: -1. add an `excluded` flag as a property to `Component` with a default value of `false` +1. add an `excluded` flag (bool) as a property to `Component` with a default value of `false` 2. the inclusion of a Component property as a subcomponent becomes contingent on the flag being `false` and if true it is not included as a subcomponent and it can no longer receive delegated Component interface calls to `connect()`, `addToSystem()`, `realize*()`, etc... -3. Component::getComponentList is devoid of excluded components and does not merely "skip-over" excluded Components. +3. modify Component::getComponentList to ensure it is devoid of excluded components and their subcomponents. This is necessary so that users and Component aggregators (e.g. Controller, Model) do not accidentally access excluded Components. +4. add Component::get/updExcludedComponentList get access to excluded components. This is necessary so one can access and the re-include excluded Components. ### Interfaces -The added `excluded` property results in property related methods being added to the `Component` interface, such as: `get_excluded()`, `upd_excluded`, `getProperty_excluded()`, ... +No significant implications to the Component interface other than additional accessors to the `excluded` property and to access the list of excluded subcomponents. ### Bindings and GUI -There are no special implications for Python and Java bindings. A Component that is excluded is still accessible via Property accessors so its exclusion status can be changed. It is imperative then that the GUI provide a list of ALL components (including excluded Components) and cannot rely on the ComponentList iterator to achieve this. +Need to wrap `Component::get/updExcludedComponentList` to enable scripting access to excluded Components. + +A Component that is excluded is still accessible via Property accessors so its exclusion status can be changed. It will be imperative that the GUI can provide a list of ALL components (including excluded Components) so users can toggle the Components exclusion status. ### Backwards Compatibility The ConsoleReporter and TableReporter classes are new to 4.0, so there are no backwards compatibility issues. ### Lifecycle and Ownership / Memory Management -No new objects are being proposed. +No new classes are being proposed. ### Performance Considerations No significant changes in performance are expected. ### Required Tests Additional test cases will be added to verify that: -1. an excluded Component is inaccessible from its parent (owning) Component and Model. -2. excluding Components never increases the number of computations to realize the Model from `Time` to `Report`. -3. re-including a Component(setting excluded to false) and finalizing from properties -4. verify that Tool performances with excluded Constraints, Forces and Controllers yields the same results as when they were disabled. +1. an excluded Component is not accessible via its parent (owning) Component and Model getComponentList(). +2. excluding Components should provide identical performance (timing and results) as manually removing the Components from XML. +3. re-including a Component(setting excluded to false) and finalizing from properties restores the Component as part of the System. +4. Tool performances with excluded Constraints, Forces and Controllers yield the same results as when were disabled. ### Potential hurdles or roadblocks Exclusion and disabling will coexist (at least initially) and we should decide in which use cases does the user/test case intend to exclude the Component altogether in the analysis or whether the Component was intentionally and temporarily being disabled as part of a more complex analysis (e.g. InducedAccelerationAnalysis disables all Forces and them enables them one by one to compute its contribute to system acceleration) in which case to exclude would be incorrect usage). - ### Pull Requests A single PR should be necessary to implement the proposal, however a subsequent PR may be required to improve error messages (e.g. excluding the pelvis from a gait model will fail when attempting to establish valid connections for hip joints, etc...) From e0b6fd165958601d33131bd0f792519e4bbe048f Mon Sep 17 00:00:00 2001 From: Ajay Seth Date: Mon, 7 Nov 2016 15:10:17 -0800 Subject: [PATCH 3/6] Make it clear that this proposal is for a new feature. --- .../excludeComponentFromSystem/excludeComponentFromSystem.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md index 56a6a80dea..27ba7ef659 100644 --- a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md +++ b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md @@ -1,4 +1,4 @@ -## Proposal: Exclude Components from the underlying Computational System +## Proposal: Add a Feature to Exclude Components from the underlying Computational System ***OpenSim Development Proposal*** ### The Need: From eab76126fdc6b273da1406b489bd31a0dc3ada17 Mon Sep 17 00:00:00 2001 From: Ajay Seth Date: Mon, 7 Nov 2016 15:44:43 -0800 Subject: [PATCH 4/6] Simplify and clarify the proposal. --- .../excludeComponentFromSystem.md | 30 +++++++++---------- 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md index 27ba7ef659..d10b346a8f 100644 --- a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md +++ b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md @@ -2,14 +2,12 @@ ***OpenSim Development Proposal*** ### The Need: +Models are complicated and the Component paradigm will permit the composition of ever more complex models and behaviours. Modeller have to troubleshoot and users must test these models, which often requires isolating a problematic component. The easiest way to isolate a problematic Component's effect is to effectively remove it from the Model and see if the problem is alleviated. The current approach to this task is to *disable* the Component, which is applicable to a handful of Components (Constraints and Forces). Unfortunately, disabling does not equate to effectively removing the Component and the effect of disabling is inconsistent across Components. -Models are complicated and the Component paradigm is enabling the construction of ever more complex models and behaviours. Modeller have to troubleshoot and users must test models, which often requires isolating a problematic component. The easiest way to isolate a problematic Component's effect is to effectively remove it from the Model and see if the problem is alleviated. The current method is to *disable* the Component, which is applicable to a handful of Components (Constraints and Forces). Unfortunately, disabling does not equate to effectively removing the Component and the effect of disabling is inconsistent across the subset of Components. - -The purpose of this proposal is to enable the fundamental ability to effectively remove a Component so one can accurately assess its impact on computation (timing, CPU usage) and results. Currently, users have little confidence that disabling a Component (if it has that option) effectively removes its calculations and it is often recommended to remove Components by hand from XML files. - +The purpose of this proposal is to enable the fundamental ability to exclude a Component from all computations. It is necessary to accurately assess a Component's impact on computation (timing, CPU usage) and results. Currently, users have little confidence that disabling a Component (if it has that option) effectively removes its calculations. ### Overview -This proposal describes a simple mechanism to exclude OpenSim Components from all computations. It can, in many cases, replace the adhoc mechanisms to "disable" components (offered by Forces and Constraints). The nature of the current scheme places the burden of "disabling" a Component on the Component writer and results in inconsistent behaviours, including partially disabling by not applying the force of a Muscle, for example, to the the MultibodySystem, and still computing the force or other costly values such as its length. A common objective of excluding a Component is to accurately assess what effect that Component is having on the System. The desired behaviour is that a Component is excluded from any downstream computations and is effectively removed from the Model and resulting System without the user having to resort to XML editing. +This proposal describes a simple mechanism to exclude OpenSim Components from all computations. It can, in some cases, replace the adhoc mechanisms to "disable" components (offered by Forces and Constraints). The nature of the current adhoc scheme places the burden of "disabling" a Component on the Component writer and results in inconsistent behaviours. For example, a disabled Muscle will not apply forces to the MultibodySystem, but there is now preventing it from still computing the muscle tension or other costly values such as its length. The objective of excluding a Component is to accurately assess what effect that Component is having on the System. Without being able to guarantee that a disabled Force will not perform calculations users have to resort to removing Forces via XML editing. For background, see: - [issue #845](https://github.com/opensim-org/opensim-core/issues/845) @@ -17,16 +15,15 @@ For background, see: - [issue #1358](https://github.com/opensim-org/opensim-core/issues/1358) **Current Behaviour** - -There is currently no ability to effectively exclude a Component from the underlying System short of editing the Model's XML file. Several Components, namely Forces, Constraints and Controllers, can be disabled with the expectation that disabled means they no longer effect the computations and dynamics of the System. This is also not necessarily the case. While an OpenSim `Force::computeForce(s)` is not invoked if a Force is *disabled*, any and all of its `realize` methods remain a part of the realization of the System. That means that position, velocity, ... (includes reporting) calculations are available for invocation. The onus is on the Force writer to check that the Force is disabled to skip those evaluations. In many cases, such as Muscle path length calculations and drawing of the path these are likely to have unexpected consequences on a Model (System) where the disable Component is expected to have no effect. +There is currently no method of excluding a Component from the underlying System short of editing the Model's XML file. Several Components, namely Forces, Constraints and Controllers, can be disabled with the expectation that disabled will result in no computations of that Component in the System. This is not currently enforceable. While an OpenSim `Force::computeForce(s)` is not invoked if a Force is *disabled*, any and all of its `realize` methods remain a part of the realization of the System. That means that Position, Velocity, ... (includes reporting) realizations are available for invocation. The onus is on the Force writer to check that the Force is disabled to skip those evaluations. In many cases, such as Muscle path length calculations and drawing of the GeometryPath, these are likely to have unexpected consequences/computations on a Model (System) where one may expect the disabled Component to have no effect. ### Requirements -- Users require a bullet-proof method of excluding components without editing XML to manually remove the Component. -- Exclusion must entail that the Component is not present in the computational System in any shape or form. It has absolutely no effect, direct or otherwise, on the System. +- Users require a robust method of excluding components without editing XML to manually remove the Component. +- Exclusion must entail that the Component is not present in the computational System in any shape or form. It must have absolutely no effect, direct or otherwise, on the System. - Any Component can be excluded from the Model's System. - Exclusion of a Component means the exclusion of all its subcomponents. - Exclusion status is a property NOT a discrete state variable. -- The only way to change the exclusion status is to update the associated property (flag) and triggering `finalizeFromPropeties()` +- The only way to change the exclusion status is to update the associated property (flag) and invoke `finalizeFromProperties()` - Exclusion status overrides any existing disabling behaviour. In other words, if a Component is excluded, the status of an existing disabled flag is irrelevant, since the Component for all intents and purposes does not exist. If the Component is not excluded, a disabled Constraint or Force will ONLY have its dynamic contribution ignored and will have no guarantees on other computations. ### Architecture @@ -57,14 +54,15 @@ No significant changes in performance are expected. ### Required Tests Additional test cases will be added to verify that: -1. an excluded Component is not accessible via its parent (owning) Component and Model getComponentList(). +1. an excluded Component is not accessible via its parent (owning) Component (or Model) getComponentList(). 2. excluding Components should provide identical performance (timing and results) as manually removing the Components from XML. -3. re-including a Component(setting excluded to false) and finalizing from properties restores the Component as part of the System. -4. Tool performances with excluded Constraints, Forces and Controllers yield the same results as when were disabled. +3. re-including a Component(setting `excluded` to false) and finalizing from properties restores the Component as part of the System and reproduces pre-exclusion results +4. Tool performances with excluded Constraints, Forces and Controllers yield the same results as when these Components were disabled. ### Potential hurdles or roadblocks -Exclusion and disabling will coexist (at least initially) and we should decide in which use cases does the user/test case intend to exclude the Component altogether in the analysis or whether the Component was intentionally and temporarily being disabled as part of a more complex analysis (e.g. InducedAccelerationAnalysis disables all Forces and them enables them one by one to compute its contribute to system acceleration) in which case to exclude would be incorrect usage). +Exclusion and disabling will coexist (at least initially) and we should decide in which use cases does the user/test case intend to exclude the Component altogether or whether the Component was intentionally and temporarily being disabled as part of a more complex analysis. For examples, InducedAccelerationAnalysis disables all Forces and then enables them one by one to compute its contribute to system acceleration, in which case to exclude would be incorrect usage of the feature. ### Pull Requests -A single PR should be necessary to implement the proposal, however a subsequent PR may be required -to improve error messages (e.g. excluding the pelvis from a gait model will fail when attempting to establish valid connections for hip joints, etc...) +A single PR should be sufficient to implement this proposal, however a subsequent PR may be required +to improve error messages to inform users of expected failures. For example, if one excluded the pelvis from a gait model it will fail to load due to invalid connections for hip joints, etc... and those messages should be properly relayed/presented to the user. + From e3f38756294237e5b709e8b08cd01a2eb8245850 Mon Sep 17 00:00:00 2001 From: Ajay Seth Date: Mon, 7 Nov 2016 15:46:56 -0800 Subject: [PATCH 5/6] [ci skip] added a space --- .../excludeComponentFromSystem/excludeComponentFromSystem.md | 1 + 1 file changed, 1 insertion(+) diff --git a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md index d10b346a8f..b792736345 100644 --- a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md +++ b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md @@ -1,4 +1,5 @@ ## Proposal: Add a Feature to Exclude Components from the underlying Computational System + ***OpenSim Development Proposal*** ### The Need: From 72f0d91476158a6b412996ae9c08b7f370974c87 Mon Sep 17 00:00:00 2001 From: Ajay Seth Date: Mon, 7 Nov 2016 16:13:22 -0800 Subject: [PATCH 6/6] [ci skip] identify methods --- .../excludeComponentFromSystem/excludeComponentFromSystem.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md index b792736345..838fcb55af 100644 --- a/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md +++ b/DevelopmentProposals/excludeComponentFromSystem/excludeComponentFromSystem.md @@ -33,8 +33,8 @@ These are the main changes: 1. add an `excluded` flag (bool) as a property to `Component` with a default value of `false` 2. the inclusion of a Component property as a subcomponent becomes contingent on the flag being `false` and if true it is not included as a subcomponent and it can no longer receive delegated Component interface calls to `connect()`, `addToSystem()`, `realize*()`, etc... -3. modify Component::getComponentList to ensure it is devoid of excluded components and their subcomponents. This is necessary so that users and Component aggregators (e.g. Controller, Model) do not accidentally access excluded Components. -4. add Component::get/updExcludedComponentList get access to excluded components. This is necessary so one can access and the re-include excluded Components. +3. modify `Component::getComponentList()` to ensure it is devoid of excluded components and their subcomponents. This is necessary so that users and Component aggregators (e.g. Controller, Model) do not accidentally access excluded Components. +4. add `Component::get/updExcludedComponentList()` get access to excluded components. This is necessary to access and update its flag to re-include excluded Components. ### Interfaces No significant implications to the Component interface other than additional accessors to the `excluded` property and to access the list of excluded subcomponents.