Extending ReferenceItem

Simulation Modeling Toolkit (SMTK)
1

The idea is to provide ReferenceItem functionality similarly to discrete ValueItem in terms of optional children.

Review of Discrete Value Items

  • The item Definition includes the following:
    • A list of Item Definitions that represents the children items of the Discrete Item
    • A mapping between the Item’s discrete values and subsets of the children items
  • The set of active children corresponds to the current value of the discrete item

Extending this Functionality to ReferenceItem

  • Assume that, similar to discrete ValueItem Definitions, a Reference Item definition would have a set of children Item Definitions.
  • Similar to discrete Value Item, the ReferenceItem would contain a map. But in this case its a mapping between PersistentObject queries and subsets of the children items.
  • The set of active children would correspond to which query in the map, the current item’s value matches.

So consider the following example:

Definitions:

  • GenericMaterial
  • LiquidMaterial : GenericMaterial
  • SolidMaterial : GenericMaterial
  • Void : GenericMaterial

Lets assume we have a Reference Item that can be assigned to GenericMaterial, but have the additional requirements:

  • if LiquidMaterial - Additional children are:
    • Initial Flow Rate
    • Initial Temperature
  • if SolidMaterial - Additional children are:
    • Initial Temperature
  • if Void - no additional children

API Changes

ReferenceItemDefinition (additions);

  • setContinuousMatching(bool); // Should all conditionals be checked
  • bool continuousMatching() const;
  • std::size_t numberOfChildrenItemDefinitions() const;
  • bool hasChildItemDefinition(const std::string& itemName) const;
  • bool hasChildItemDefinition(const std::string& valueName, const std::string& itemName);
  • bool addChildItemDefinition(smtk::attribute::ItemDefinitionPtr cdef);
  • bool addItemDefinition(smtk::attribute::ItemDefinitionPtr cdef);
  • template typename smtk::internal::shared_ptr_type::SharedPointerType addItemDefinition(const std::string& idName);
  • int addConditional(const std::string& resourceQuery, const std::string& componentQuery, const std::vectorstd::string& itemNames);
  • std::vectorstd::string conditionalItems(int index) const;
  • std::size_t numberOfConditionals() const;

ReferenceItem (additions)

  • std::size_t numberOfChildrenItems() const;
  • std::size_t numberOfActiveChildrenItems() const;
  • smtk::attribute::ItemPtr activeChildItem(int i) const;

XML Format

        <Component Name="material" EnforceCategories="true">
          <Accepts>
            <Resource Name="smtk::attribute::Resource" Filter="attribute[type='material']" />
          </Accepts>
          <ChildrenDefinitions>
            <Double Name="velocity" NumberOfRequiredValues="3"/>
            <Double Name="temp"/>
          </ChildrenDefinitions>
          <ConditionalInfo>
            <Query Filter="attribute[type='solid_material']">
              <Items>
                <Item> temp </Item>
              </Items>
            </Query >
            <Query Filter="attribute[type='liquid_material']">
              <Items>
                <Item> velocity </Item>
                <Item> temp </Item>
              </Items>
            </Query >
          </ConditionalInfo>
        </Component>

Related GitLab Info

2

@chart3388 @johnt @amuhsin FYI

3

There has been some internal discussion and consensus (I think) that the query elements need to be generalized to support resource or component queries, or both. To do this, here are a couple formatting options to consider.

1. Use current syntax in ComponentItem
e.g.

<Query Name="smtk::attribute::Resource" Filter="attribute[type='material']" />
// TBD syntax for combined resource & component query

2. Use more descriptive attribute names
e.g.

<Query Resource="smtk::attribute::Resource" Component="attribute[type='material']" />
<Query Filter="smtk::attribute::Resource//attribute[type='material']" />
  • Each query string has a different name (Resource, Component, Filter).
  • In the first example, either Resource or Component can also be omitted if not relevant:
<Query Resource="smtk::attribute::Resource" />
<Query Component=attribute[type='material']" />

2a.\ Minor variation

If the general term “Filter” is too non-descriptive, we could also change the element name from Query to Condition to free up “Query”, that is

<Condition Query="smtk::attribute::Resource//attribute[type='material']" />
<Condition Resource="smtk::attribute::Resource" Component="attribute[type='material']" />
<Condition Resource="smtk::attribute::Resource" />
<Condition Component=attribute[type='material']" />

If we were starting from scratch, this would be my preference, but it might cause some heartburn in terms of supporting this in addition to the current smtk query syntax.