-
Notifications
You must be signed in to change notification settings - Fork 111
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
Address #148 by adding ConfigurableFixedConstraint
boundary condition class
#143
Address #148 by adding ConfigurableFixedConstraint
boundary condition class
#143
Conversation
The |
Yes @mstoelzle that is correct. |
@armantekinalp Thanks for confirming this so quickly! @armantekinalp @bhosale2 @skim0119 Could you guys have a look at the |
@mstoelzle a couple of comments to start with from my side:
|
ConfigurableFixedConstraint
boundary condition classConfigurableFixedConstraint
boundary condition class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice addition @mstoelzle, can you also add tests for the class you add here in tests
?
…ode review Co-authored-by: Yashraj Bhosale <[email protected]>
Codecov Report
@@ Coverage Diff @@
## update-0.3.0 #143 +/- ##
================================================
+ Coverage 87.58% 87.62% +0.03%
================================================
Files 43 43
Lines 2780 2820 +40
Branches 361 368 +7
================================================
+ Hits 2435 2471 +36
- Misses 326 328 +2
- Partials 19 21 +2
Continue to review full report at Codecov.
|
- Application of end-forces to test fixed translational constraint and fixed x- and y- rotations - Application of torsional torque to test free yawing of BC
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, @mstoelzle one last thing–can you restore back the .lock
file from the update-0.3.0
branch? since no new dependencies were added (no change to .toml)
Thanks! Yes, sorry - I just reverted the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mstoelzle I asked some minor changes. One thing is could you please also update example ReadMe and add boundary condition examples.
Co-authored-by: Arman Tekinalp <[email protected]>
Co-authored-by: Arman Tekinalp <[email protected]>
- Legacy implementation is most likely faster / more efficient for the simple case of constraining all DoF
I updated the README in bdec395 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, nice work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add GeneralConstraint
in docs/api/constraints.rst
Co-authored-by: Seung Hyun Kim <[email protected]>
…ational_constraint_selector` - Declare `translational_constraint_selector` and `rotational_constraint_selector` as optional in docstring - Add `translational_constraint_selector` and `rotational_constraint_selector` as params to `__init__` instead of using `kwargs`
I added the |
Please add them on the table above as well. https://github.com/GazzolaLab/PyElastica/blob/master/docs/api/constraints.rst#description |
Sorry - didn't see that. Done in 4682601 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Good Work!
Motivation
Currently, there exists only the option to either have a) no boundary conditions or b) fully fixed boundary conditions. The only functionality in between is that for example translations are allowed, but rotations are constrained and vice-versa. However in practice, there are many situations where we would like to allow certain translations (for example along a plane) or rotations (for example allow yawing of the end of the rod), but constrain all other DoF. The user of the library would have to implement this functionality all themselves inheriting from the
FreeBC
class. In many cases, such an implementation is not straight-forward. Thus, the library should provide the user the option to configure the BC themselves in a simple fashion. Although it obviously will never cover all the edge-cases a specific project might require, it will give the user an idea / hint / guidance on how to implement a similar solution.Provided functionality
This PR add the following functionality through the
ConfigurableFixedConstraint
class:translational_constraint_selector
androtational_constraint_selector
, the user can specify which Degrees of Freedom to allow / constrain at the specified nodes.ConfigurableFixedConstraint
will now only re-set the positions, velocities, directors and omegas to the saved, fixed values for the constrained dimensions. The other DoF are allowed to freely move / rotate.FixedConstraint
be a child class ofConfigurableFixedConstraint
.FixedConstraint
will still constrain all dimension, e.g.translational_constraint_selector=np.array([True, True, True])
androtational_constraint_selector=np.array([True, True, True])
Examples for usage
Below examples motivate the usage of this new class.
I also added an example in
examples/BoundaryConditionCases/configurable_fixed_constraint.py
, which applies torsion to end tip of a rod. With a fullyFixedConstraint
the resulting orientation of the first node of the rod would look like this:Fully Fixed BC:
When we now use
rotational_constraint_selector=np.array([True, True, False])
(e.g. allow for yawing / rotation around the z-axis), the orientation of the first node of the rod looks like this:Free Yawing:
TODO's
ConfigurableFixedConstraint
classnb_constraint_rotational_values
omega_collection
into the inertial frame before applying zero-speed constraintsRequest for ideas / feedback
I would like to ask the maintainers specifically for feedback on the current prototype of
nb_constraint_rotational_values
. Obviously, this is currently not numba-compatible. But more importantly, I would like to ask for your thoughts if constraining the Euler angles is a suitable way to go and if you have other ideas to allow the rotation around certain axis and constrain the rotation around other axis?