-
Notifications
You must be signed in to change notification settings - Fork 131
Address #148 by adding ConfigurableFixedConstraint boundary condition class
#143
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
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
bhosale2
left a comment
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 <yashraj.iitb@gmail.com>
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 <53585636+armantekinalp@users.noreply.github.com>
Co-authored-by: Arman Tekinalp <53585636+armantekinalp@users.noreply.github.com>
- Legacy implementation is most likely faster / more efficient for the simple case of constraining all DoF
I updated the README in bdec395 |
armantekinalp
left a comment
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!
skim0119
left a comment
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 <skim0119@gmail.com>
…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 |
skim0119
left a comment
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
FreeBCclass. 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
ConfigurableFixedConstraintclass:translational_constraint_selectorandrotational_constraint_selector, the user can specify which Degrees of Freedom to allow / constrain at the specified nodes.ConfigurableFixedConstraintwill 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.FixedConstraintbe a child class ofConfigurableFixedConstraint.FixedConstraintwill 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 fullyFixedConstraintthe 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
ConfigurableFixedConstraintclassnb_constraint_rotational_valuesomega_collectioninto 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?