Common loads about brim HOT 3 CLOSED

Adding linear springs and dampers to all of the joints is a common thing to do.

from brim.

This post is mostly written chronological, to document my thought process a bit better. Apart from the edits, so when I start doing so, I'm actually rewriting some stuff. I also try to keep it a bit clean, so I sometimes also remove parts.

Okay let's first list some requirements, though the once on BRiM core are of course inherited.

Functional requirements:

• It must support multiple different load groups per model.
  • As an end-user I want to have simple torques like T_elbow(t) * A.y, spring dampers like k_elbow(t) * (q_ref_elbow(t) - q_elbow(t)) * A.y - c_elbow(t) * u_elbow(t) * A.y, and in the end also more advanced musculotendons, between which I can easily switch.
• It must have the option to use your own load group, which has not yet been implemented.
  • As an end-user I want to be able to also assign my own musculotendon load group without having to edit the source code.
• It could be an option to assign multiple load groups to a single model.
• A load group must be able to get multiple models.
  • As a modeler I want to create single load groups, which do not only need the arm but also the shoulder and the torso.
    • This can be fixed by assigning it to the Rider and have the option to assign multiple load groups.

Performance requirements:

• It must be as easy as possible to see what load groups have already been implemented.
  • As an end-user I want to easily see between which load groups I can choose.
• The boiler plate on implementing a new load group should be minimized.
  • As a modeler I want to write only really that essential code describing the loads, when implementing a new load group.

Constraints:

• It must be group before the define_objects or even the define_connections stage (by preference as it can then be integrated in the other parts)

Some remarks, which are not really requirements:

• Most of these load groups will be rather specific for a model, not for a single model and not a group of models.

Okay, I think that there should be something like the following workflow:

model.add_load_group(load_group)
    load_group.parent = self
        if load_group._parent is not None:
            raise ValueError(f"Load group is already used by {self.parent}")
        ...
model.define_objects()
    ...
    for load_group in self.load_groups:  # It should be called as last probably, which is problematic
        load_group.define_objects()
...
# the `get_systems` in `to_systems` should be updated by also adding [grp.system for grp in model.load_groups] and [grp.system for conn in model.connections for grp in conn.load_groups]

Let's check a bit out for the implementation of this load thing:

# BrimBase should make some things abstract methods and move the implementation to the subclasses:
#   required_models: tuple[ModelRequirement]  should be moved
#   the submodels properties should be moved
#   get_descriptions should get an extra one for checking the loads



class LoadGroupBase(BrimBase, metaclass=LoadsMeta):
     parent: ModelBase | ConnectionBase | tuple[ModelBase | ConnectionBase, ...]

from brim.

I'll be opening a PR hopefully soon. However I'm just noting a decision down for now. I do allow some code duplication between ConnectionBase and ModelBase as it is only once and making separate mixin classes or something seems a bit overkill, knowing it is only duplicated once.

from brim.