|
|
|
|
|
Description Motion of the mesh specified as a list of motion solvers. The motion solvers are executed in order and the resulting displacements accumulated into an overall displacement and the displaced point positions returned. i.e. it is assumed that the regions of motion are independent and no attempt at averaging or combining the motions in a more complex way is made. Various ideas at a more general motion combination approach have been considered but none are general enough; the averaging is likely to be dependent on the form and region of the various motions in the list. If you have multiple motions which interact you will need to decide how they should be combined and write a specific version of motionSolverList which does what you want. In the example you provided the two regions of motion do overlap and the simple summation of displacement is not appropriate. While your proposal is makes sense for the displacement solvers it is not correct for the more general velocity solvers and it is not clear how it would resolve the issue of interacting motions, could you demonstrate the advantage? |
|
|
The current motion accumulation only doesn't work fine for movements that overlap, I forgot to mention that. Providing a common reference (the initial mesh) for the displacement calculation, would create a more intuitive and predictable way (linear combination in every timestep) to implement movement combinations since, at the end, the motionSolverList combine the displacements generated by every solver, regardless of its nature. And, at the same time, the only modified solution would be for overlaping motion cases. I believe another option would be taking the mesh result of the previous solver in the list and using it as the "0" reference for the next solver, thus applying sequantialy the mesh motions, but I guess that is not how the motion solvers work. |
|
|
Could you demonstrate your proposal? I don't see how the change would help and it would only make sense for non-overlapping displacement solvers whereas the current implementation work for any non-overlapping motion solvers. |
|
|
Consider one point in the mesh with coordinates (0,0) for simplicity. Consider also two motion solver moving it independently (Solvers 1 and 2). Solver 1 moves the point 1 length unit in the x direction per time step, meanwhile, Solver 2 moves it 2 length units in the y direction per time step. The current motionSolverList.C member function code is: Foam::tmp<Foam::pointField> Foam::motionSolverList::curPoints() const { if (motionSolvers_.size()) { // Accumulated displacement pointField disp(motionSolvers_[0].curPoints() - mesh().points()); for (label i = 1; i < motionSolvers_.size(); i++) { disp += motionSolvers_[i].curPoints() - mesh().points(); } return mesh().points() + disp; } else { return mesh().points(); } } Note that whenever two or more motion solvers (regardless of its kind) are added to the dynamicMeshDict when using the dynamicFvMesh type dynamicMotionSolverFvMesh, function motionSolverList is called (this can be see in motionSolver.C). In figure Current_motionSolverList, the way the mesh is moved is depicted. Time step 1 refers to the movement between instants 0 and 1, Time step 2 refers to the movement between instants 1 and 2, and so on. Blue points are the outputs of Solver 1 and green points are the outputs of Solver 2 for every time step, which are expressed in code respectively, by "motionSolvers_[0].curPoints()" and "motionSolvers_[1].curPoints()". The Red point is point position during instant 0 (a.k.a. "initialMesh"). Black horizontal and vertical vectors are the difference between Solver 1 and 2 outputs, respectively, and the initial mesh (represented in code by "motionSolvers_[0].curPoints() - initialMesh" and "motionSolvers_[1].curPoints() - initialMesh"). Black points are the sequential motionSolverList outputs, described in "return mesh().points() + disp". Magenta and Ciano vectors are the differences between Solvers 1 and 2 outputs and the current mesh (which is the previous instant motion solver output), and are described as "motionSolvers_[0].curPoints() - mesh().points()" and "motionSolvers_[0].curPoints() - mesh().points()". The yellow vector is the difference in position between the current mesh and the initial mesh. Finally, the red vector is the combined displacement of the respective time instant, which means the sum of ciano and magenta vectors, and is expressed in code by "disp". It is worth noting that in Time Step 1, the ciano and magenta arrows overlap the black ones and the yellow one is a null vector. Besides, in Time Step 2, the red arrow is a null vector. In the proposed motionSolverList, the variable initialMesh, that assumes the coordinates of the mesh in the first intant, is created and the peace of code written above is replaced by the one below: Foam::tmp<Foam::pointField> Foam::motionSolverList::curPoints() const { if (motionSolvers_.size()) { // Accumulated displacement pointField disp(motionSolvers_[0].curPoints() - initialMesh); for (label i = 1; i < motionSolvers_.size(); i++) { disp += motionSolvers_[i].curPoints() - initialMesh; } return initialMesh + disp; } else { return mesh().points(); } } The mesh motion is now depicted as in figure Proposed_motionSovlerList. Arrows and points mean the same code expressions as previously described and the code output is now "initialMesh + disp". Note that the mesh movement is now a linear combination of previous movements. Another advantage of the porposed solver is that an added motion solver that doesn't move the mesh (zero displacement or zero velocity) is now a neutral element of the mesh motion, which doesn't happen in the current approach. Current_motionSolverList.png (59,823 bytes) Proposed_motionSolverList.png (56,283 bytes) |
|
|
Can you provide a test-case with non-overlapping motion which runs incorrectly with the current implementation? |
|
|
As far as I know, non-overlaping cases have no problems using the current implementation, my proposed fix is to improve handling of cases in which motions overlap. |
|
|
The current implementation is only for cases with non-overlapping motion, the change you propose would break it for cases in which velocity rather than displacement motion is used. It appears that you need a different motion solver for a different purpose and you will need to write one for it rather than change the existing solver which would break it for its designed purpose. |
|
|
In fact, that is exactly what I did. I needed to combine dynamic airfoil profile changing, rotation and translation. I created a similar new function and added the proposed correction (by introducing a solver with zero displacement that captured the initial mesh) and everything worked fine then. My goal with this post was to propose an improvement for handling the motion of overlaping mesh movements. |
|
|
I understand your aim but the problem is that it breaks the current design functionality which some users are relying on. |
|
|
The proposed change breaks existing functionality. |
- Anonymous
