[Smtk-developers] New Feature for Attribute Definitions - inheritable association rules

Haocheng Liu haocheng.liu at kitware.com
Wed Oct 25 14:22:31 EDT 2017


Hi Bob,

On Wed, Oct 25, 2017 at 10:26 AM, Bob Obara <bob.obara at kitware.com> wrote:

> Hi All,
>
> I’ve added the ability for an attribute definition to inherit the
> association rule from its base definition.  This should streamline the
> creation of templates.
>
> For example you can create a definition called “Surface Boundary
> Condition” and assign an association rule to indicate that it can be
> associated with faces.  By default and definition based on “Surface
> Boundary Condition” will inherit this association rule and therefore be
> associated with model faces.
> You can still override the inherited rule (note that in this
> implementation it will replace the entire rule).
>
> To support this functionality there were some changes made to the
> attribute::Definition API:
>
> associationRule() - returns the association rule that the definition uses
> - note that this can be a rule inherited from its Base Definition.  As a
> result this method now returns a shared pointer to a const model entity
> item definition
> localAssociationRule() - returns the local association rule overriding the
> rule the definition would inherit from its base definition (Note that this
> can be nullptr)
> createLocalAssociationRule() - creates a local association rule for the
> definition (by default its associated with nothing)
> clearLocalAssociationRule() - removes the local association rule- the
> definition will now use the one inherited by its base definition
> setAssociationRule(...) -> setLocalAssociationRule(…) - sets the
> definition’s local association rule that overrides the one inherited by its
> base definition
> associationMask() -> returns the association mask that the definition uses
> - note that this can be the mask inherited from its Base Definition.
> setAssociationMask->setLocalAssociationMask - sets the mask of the local
> association rule (and creates one if necessary)
>
> What needs to be done in the future is to determine what constraints (if
> any) are imposed on the local association rule by the association rule
> inherited by the base definition?  Does the rule need to be a subset or a
> superset of the inherited rule.
>
> For Example assume a base definition foo can be applied to edges and faces
> A definition bar is derived from foo and is going to have a local
> association rule
>
> Which of the following are allowed?
>
> 1. bar can be associated with just faces (its rule is a subset of foo’s
> rule)
> 2. bar can be associated with edges, faces, and volumes (its rule is a
> superset)
> 3. bar can be associated with volumes (its rule is independent)
>
> The question boils down to if bar can be treated as a foo then should it
> be associated to at least all  things foo? - then the we do superset
> or is it a specialization of foo - in that case its a subset
>
> I think case 3 (independent) is probably not allowed?
>
Just my 2 cents opinion, I think both case 2 and case 3 should not be
allowed. Since bar is derived from foo, it should not go beyond foo.

If case 2 happens, then the user should rethink about the definition of
foo. Either he or her should expand foo to incude volumes or transform it
into case 3 in which
bar just happens to share the same Boundary condition with foo but they are
independent of each other.

>
> Note that the functionality is currently being tested and should be
> committed soon.
>
>
> Comments?
>
> Bob
>
>
> Robert M. O'Bara, MEng.
> Assistant Director of Scientific Computing
>
> Kitware Inc.
> 28 Corporate Drive
> Suite 101
> Clifton Park, NY 12065
>
> Phone: (518) 881- 4931 <(518)%20881-4931>
>
>
>
>
>
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>
>


-- 
Best regards
Haocheng

Haocheng LIU
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4421 <(518)%20881-4421>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20171025/88bcceef/attachment.html>


More information about the Smtk-developers mailing list