Conversation
|
I love the animation |
| for comp in components_map[variable]: | ||
| vu.ApplyFixity(comp, True, model_part.Nodes) | ||
|
|
||
| def _ApplyRotationAndMeshDisplacementPython(self, theta): |
There was a problem hiding this comment.
These operation in C++ (can be implemented in some utilities) may gain some important performance.
loumalouomega
left a comment
There was a problem hiding this comment.
My only comment is that some operations may be interesting to implement in some utilities and expose to python to avoid performance penalty
|
@loumalouomega Those functions were in C++ at the beginning (slightly faster). But @RiccardoRossi convinced me to make everything in Python. See -> 102d1fb |
¯_(ツ)_/¯ |
|
Can't we use the standard f(x,y,z,t) functions I/O we have for all the processes to define the angular velocity here? Besides being more similar to the rest of processes, it would allow to define any ramp up function. |
Commit body Replace legacy target_angular_velocity_radians + acceleration_time input with a single angular_velocity_radians (constant or f(x,y,z,t) string). Add standard interval support to align with Kratos process conventions. Change rotation update to incremental step integration (delta_theta) over the overlap: [t-Δt, t] ∩ [interval_begin, interval_end] Apply incremental rotation on current coordinates and recompute MESH_DISPLACEMENT from initial coordinates. Keep rotational VELOCITY assignment active only when process interval is active. Manage fixity activation/deactivation consistently when entering/leaving interval. Enable equivalent behavior between: one process with piecewise angular velocity function, and two process instances split by interval. Update/add tests for: constant numeric vs constant string input equivalence, no-op outside interval, split-interval vs single piecewise-function equivalence. Migration note Update project parameters from: target_angular_velocity_radians, acceleration_time To: angular_velocity_radians (+ optional interval).
|
@rubenzorrilla done. RotatingFrameProcess now uses standard function input for angular velocity (angular_velocity_radians as constant or f(x,y,z,t)), with interval support. I removed target_angular_velocity_radians and acceleration_time to avoid duplicated APIs. Ramp-up can be defined directly in the function (e.g. -25.0*t if t<1.0 else -25.0). I also added regression tests for function input and interval behavior. |
|
@RiccardoRossi @rubenzorrilla any news here? |
Overview
This PR introduces a
RotatingFrameProcessin the MeshMovingApplication to apply rigid-body rotational kinematics to model parts in ALE-type simulations, e.g., Sliding Mesh.The process performs two operations:
MESH_DISPLACEMENTVELOCITYto another model part (rotating object/skin)Overview
This PR introduces a
RotatingFrameProcessin the MeshMovingApplication to apply rigid-body rotational kinematics to model parts in ALE-type simulations.The process performs two operations:
MESH_DISPLACEMENTVELOCITYto another model partThe rigid-body velocity is computed as
where
The mesh rotation is applied as
with the corresponding mesh displacement
Angular acceleration
If an
acceleration_timeis specified, the angular velocity is ramped linearly until the target value is reached.Let$\omega_t$ be the target angular velocity and $T_a$ the acceleration time.
The angular acceleration is
For$t \le T_a$ :
For$t \text{greater than} T_a$ :
This allows smoothly ramping the rotational motion before reaching the final constant angular velocity.
Process Settings
The process requires two model parts:
rotating_frame_model_part_nameModel part whose nodes are rotated and assigned
MESH_DISPLACEMENT.rotating_object_model_part_nameModel part where the rigid-body rotational
VELOCITYis imposed.Example:
{ "rotating_frame_model_part_name": "FluidModelPart.ALE", "rotating_object_model_part_name": "FluidModelPart.Slave", "center_of_rotation": [0.0, 0.0, 0.0], "axis_of_rotation": [0.0, 0.0, 1.0], "target_angular_velocity_radians": 5.0, "acceleration_time": 0.5 }