Change the axis of rotation during a transient run in CFX 11
Looking for a way to change the axis of rotation during a transient run in CFX 11. The problem is a high speed disk of fluid spinning and undergoing gyroscopic precession at the same time.
Have you tried moving the rotation vector in a run?
What are you trying to model with this simulation?
Ring of fluid, water or oil spinning Z Axis at 10,000 rpm and also being rotated on the Y axis at 20 rpm.
I have not stated the problem very well on the first post, I need to simultaneously rotate on two axis at the same time. Seems in CFX 11 you can only define one axis of rotation so I thought maybe by defining high speed Z axis then with an expression rotate the Z axis around the Y axis .... well that's not going to work because moving the axis of rotation is not going to move the domain.
There were no option for entering an expression as part of defining the axis of rotation as well no options for an expression while defining a coordinate frame. So I tried using the command edit to force an expression then got the following message.
"Parameter 'Rotation Axis To' in object '/FLOW/DOMAIN:Default Domain/DOMAIN MODELS/DOMAIN MOTION/AXIS DEFINITION' appears to have been assigned an expression value 'TX'. This parameter may take only purely numeric values."
When my expression included "atstep" solver refused to run with following message.
Error processing expression 'global frame vector associated with Rotation Axis To'.
The expression is invalid because:
atstep is not available for use in this term
Error processing expression(s):
Rotation Axis To = TX
Rotation Axis To = TY
Rotation Axis To = TZ
I am now looking into the possibility of mesh motion on a per node basis. The mesh motion using regions seems limited to XYZ displacement but no options for rotating by movement. No problem moving a mesh region in a circle using XYZ but that is not rotation, no problem moving mesh in a rotation frame but still limited to one axis of rotation. My thought for a workaround would be to move each node in a circle you would then have a rotating domain.
The other possibility is instead of moving or rotating the domain around the Y axis I am trying to simply add acceleration. I have no problem writing expressions that would properly produce the acceleration values but they are not flat nor constant.
I have not found a way to MOVE the rotation vector DURING A RUN in CFX 11. I have no problems setting the rotation vector to about any direction desired prior to a solver run but found no way to make it a changing direction during the run.
Angular Acceleration issue
Angular Acceleration issue, the original post here I over wrote because I made the post way to long and was getting zero replies on it. Here is a short version.
See image this is a transient run, water, Rotating domain Z axis. It is a closed domain expect for one vent for pressure reference point set to 0 psi rotating. All walls are set to free slip. The rotation rate is controlled by an expression and is varied sinusoidal at 20 Hz making a 90 degree / quarter turn 20 times in a seconds! This runs peak to peak rpm from +1000 through 0 to -1000 rpm and back again. This should be like a water hammer effect except in this case the water and pipe are moving together then being decelerated suddenly.
I can see the velocity in stillframe vary through the run as it should, I get pressure rise and fall do to centrifugal force as I should get. But I get almost no pressure rise and fall that would result from angular acceleration / deceleration. I also get extremely low moment/torque readings from the solver monitor charts. I tried the check box alternative rotation model and got the same results. Varying the time per step has very little effect. I usually have at least 50 time steps per one 20 Hz cycle. I have tried compressible fluids with about the same results.
If I make the domain stationary, set up openings to flow the fluid around the ring in an oscillatory fashion I then get the pressure pulses and moments I would expect but this is just a simple case the real geometry I need to run is far too complicated to for this type of oscillatory flow workaround.
I am pretty sure changing the rotation axis is not supported, so all the coriolis and other terms resulting from this are not included - hence you cannot change the rotation axis.
I am also not sure that changing the rotational speed on a rotating domain has all those terms (ie angular acceleration) implemented as well. I could be wrong here, but I suspect this is the case.
If my comments are correct then some ideas would be:
* Model the whole motion as a moving mesh. This should be easy to implement, but is likely to be quite a slow simulation.
* Model the rotation using your own body forces using CEL functions to model centripetal, angular and coriolis forces. Not sure if this is possible for your case but it would be the best option if it is as then you will not need moving mesh and that speeds things up immensely.
Your statement "moving mesh. This should be easy to implement" gave me a smile. I have overcome the learning curve on moving mesh and find it quite useful with in limitations. The limitations seem to be a restriction to moving regions only and no way to move in a cylindrical coordinate system. I have written expressions that can move a region in a circular path but all nodes in any one region have to do the same XYZ motion but no way to rotate the region about an axis. Example I can have a rotating domain with a single defined fixed axis then divide the domain into a number of reigns (pie slices) and move those reigns in XYZ space but no way to rotate them about the Y axis. If I could find a way to move single nodes instead of regions that may help.
BEST FIX I am currently on is adding MOMENTUM SOURCING. I have only spent a few hours on that so far. When you say body forces I suspect we are talking the same type of solution for the problem. I would prefer a way to add an acceleration force directly but momentums not too far off from the same thing. Currently I have a day or so coming up to speed on validating my proper application of this new found area. My high for the day was running a few test, creating user functions and expressions that at least seemed like creating angular motion on a stationary domain. I am hoping to avoid the Fortran hurtle, it's like a foreign language to me plus windows platform compiling issues. Well it is late here, thanks for the reply Glenn.
Moving mesh - then you need a rotation transform (http://en.wikipedia.org/wiki/Rotation_%28mathematics%29). Simple (simplish anyway) :).
Momentum Source - should be no need for fortran. Just about any function you should need here can be done in CEL.
Hey Glenn thanks for the reply .... Your statement " then you need a rotation transform" .... Well heck I knew that and have done them many times but your statement clued me into the fact that mesh motion input fields would except an expression that included repositioning all XYZ points with total freedom, rotation included.
I had no idea of that plus my lack of understanding terms like "field variable" as used in CEL. Field Variable was a new term for me I happen to get from an error message I would have called it a data array variable (Pascal programming habit)
Been a long frustrating day BUT GREAT PROGRESS AT THE END! This will be a short update for now but I will soon do a complete and fairly lengthy strictly informative post. I am thinking it makes sense to start a new post for that titled something like.
MESH MOTION, ROTATION BY MESH MOTION, NUMBER ONE EASY FIX FOR negative ELEMENT volume!!
THE ONE REASON MESH MOTION FAILS FOR MOST
99.9% of the time "negative ELEMENT volume" is so easy to fix yet almost nothing on here that tells the correct easy fix. If you move a wall make sure that the adjacent stationary walls are NOT SET TO STATIONARY UNDER MESH MOTION they, BY DEFAUT ARE SET TO STATIONARY.
Under Boundary details tab for the Walls/Mesh THAT YOU ARE NOT MOVING if the wall is adjacent to the wall you are moving then you need to set mesh motion to UNSPECIFIED.
So I have my domain rotating via MESH MOTION and so far as I suspected all resulting centripetal, angular momentum and Coriolis forces are present as they should be sense they all simply result from inertia.
There are a number of potential problems people may get hung on, for now just a short list will have to do.
Use specified location input, for me so far using specified displacement has resulted in a shrinking domain. Calling on variables "Total Mesh Displacement X" or "Mesh Displacement X" yielded no help.
Boundary detail tab avoid FREE SLIP, use NO SLIP and also set wall velocity relative to mesh motion.
When you are specifying a new location setting Z to 0 is just plain wrong and will crash every time, see CEL below. My personal not seeing the forest because of the trees that took me 2 hours to catch. du?
Transient run set Time step to expression StepTime. Set all boundaries to moving mesh.
Location X Component = NewX
Location Y Component = NewY
Location Z Component = NewZ
Option = Specified Location
NewX = (cos(ZRAngle)*x) -(sin(ZRAngle)*y)
NewY = (sin(ZRAngle)*x)+(cos(ZRAngle)*y)
NewZ = z
StepTime = 1/(Zrpm/60)*1[s]/StepsPerZRev
StepsPerZRev = 1440
ZRAngle = ZRRate*pi/180
ZRRate = 360/StepsPerZRev
Zrpm = 3600
Got to go Friday night here, thanks all
You forgot the golden rule when developign moving mesh simulations:
* Set the results file to output every time step, include the mesh and only include one variable.
* Use expert parameters to turn solving of all fluid, turbulence, heat, volume fraction and anything else equations off, just model the mesh motion.
* Then run the simulation.
This will produce an output file of every time step and will run very fast as it is not actually doing any CFD at all, just mesh motion. You can then see how the mesh moves in each time step. When it crashes (which it always does for the first few goes) you look at the time steps before and see what is not working.
This method would have picked up easily all the errors you talked about. It is obvious when you have done it before :)
Timestep Interval set to 1, Edit a Run in Progress
Great advice, I was thinking how nice it would be to have had a debugger window for CEL expressions and all other variables of concern. Your suggestions sounds about as close as one can get to just that. Monitoring of an expression is always a good suggestion too.
So where do I pick up a copy of that golden rules book? CFD online, a great resource that has bailed me out many times is about as close as I have found.
I have an update for one of those Golden Rules you suggested.
Set Transient Results output to Timestep Interval = 1, this will get you every time step yet leave you the freedom to change the interval during the run.
For newbie's here one can changing / tweaking things during a run, look under Tools menu on the Solver Manger you will find "Edit a Run in Progress".
This is very useful for large and or very long transient runs. Check on the run in Post early by opening the latest TRN file to see if it is going as expected.
With Edit a Run in Progress one can change Rotation Rates, Boundary Mass Flows / Pressures, Duration of the run, the Time Step, the Transient Results Interval and many other settings.
WARNING you can easily trash / crash a run this way also.:eek: Think about the physics of your change before doing it!
Monitoring of an expression - definitely, if you have complex CEL then you need to do some debugging on that as well. If the CEL returns a single value then send that CEL variable to a monitor point so you can keep an eye on it as the simulation progresses. If the CEL returns a field variable send it to a additional variable (defined by an expression, where the expression is simply your CEL variable) so you can also monitor that in CFD-Post as the run progresses.
The question about moving mesh errors gets asked enough to write an FAQ on it. Do you want to write what we are talking about for debugging moving mesh simulations into an FAQ? There is already a FAQ on mesh stiffness but the discussion here is basic debugging which is more fundamental but but it is not obvious how to do it.
Rodrigues rotation formula
Do a FAQ write up? Sure I will do / help do that but it will be a few days, currently I am waste deep in Rotation Matrix Math with the
Rodrigues rotation formula
Currently I am working on the changing axis of rotation during the run. I have a MS Excel working version now going to CEL implementation in the next few days, I will post it here if it works. It might get close to the 256 characters per line CEL limit.
IF IT WORKS?? The problem that is arising. I need to rotate around the Y axis AND need to rotate around a moving axis I am defining with 3 points, The Y of the moving axis will remain 0. In CEL how can I determine or control which rotation happens first, it's not like typical programming where I can control the order of the variables updates. The position of the moving axis has two possibilities one being before the y rotation the other being after the Y rotation. Adding a new post with more images, ?? no way to add photos by editing a post?
Here is a snippet of the current CEL implemented it is limited to rotation about XY or Z axis but they can be done simultaneously in one solver step.
Variable name guide
NX New X
NY New Y
NZ New Z
YRA Y Rotate Angle
ZRA Z Rotate Angle
GOOD 2 FIXED AXIS ROTATION MOVE
NX = (cos(YRA)* ((cos(ZRA)*x) -(sin(ZRA)*y))) -(sin(YRA)*z)
NY = (sin(ZRA)*x)+(cos(ZRA)*y)
NZ = (sin(YRA)* ((cos(ZRA)*x) -(sin(ZRA)*y)))+(cos(YRA)*z)
ONE FIXED AXIS ROTATION MOVE
NX = (cos(ZRA)*x) -(sin(ZRA)*y)
NY = (sin(ZRA)*x)+(cos(ZRA)*y)
NewZ = z
Have a great Day
Adding addtional images
It is like gyroscope precession move
CEL Precedence of operators, Order of execution
Yes order of operations is my hang-up, I don't think precedence of operators can help me here but not sure. This post is a little long but should clearly help others with the wonders of why is my CEL not doing what it should.:(
View images before reading will help.
My case may be a good learning example. My desired motion is 15º rotation on the axel of the wheel every time step plus 5º rotation on the Y axis every time step. The Y rotation is easy the axis of rotation stays on the system Y.
Step1 Rotate 15º on Z axis first then Rotate 5º on Y Axis in that order.
solver iterations .....
Step2 Rotate -5º on Y axis first (This puts the wheel axial back in line with the Z Axis) then Rotate -15º on Z Axis. This puts me back to the original position. Then in the same step Rotate Z first +30º then Y +10º.
solver iterations .....
Then repeat step2 with an increasing final position every step.
Not a very efficient way to move, kind of ugly really but thought I might get it done with CEL and no need for a moving axis of rotation. Calculation time for the Mesh move is nothing compared to the fluid solution calculations either way done would be done.
My first attempt at getting this movement was to take the fixed 2 axis move code and nest the same duplicate 2 axis code inside. One set of code does the backward move, the other does the forward move. It almost seemed to work but drifted out of wack after a dozen moves or so.
Then for testing I went back to just the simpleish:rolleyes: single set of 2 axis code. Set up the CEL to simply move forward one step then back to home position the next step.
See images, a return to home position was not landing at home.:eek:
I see what I need the code to do but have no idea if it can be done in CEL alone.
Current code moves Z first then Y which is great going forward but pulls the wheel axel off the ZX plain moving back home because it does the moves in the same order as the forward move, Z first then Y.
Currently I will see if I can force an order of operations by creating a sequence of CEL stamens like
CEL 1 Statement - CFX Systems field Variable xyz to produce my defines Variables 1X 1Y 1Z
CEL 2 Statement - Use 1X 1Y 1Z to produce 2X 2Y 2Z and so on.
SEE 2XYZ depends on 1XYZ thus the hope is while running CFX maps these dependencies out to choose the order the stamens are executed in.
Well it is going to be a long day, going to get this to work, any help would be greatly appreciated.
Here is a short list of thing that would help.
1. A frozen copy of xyz variables from the beginning of the run that I could use to drive from.
Not sure but seems Total Mesh Displacement XYZ and Mesh Displacement XYZ hold strictly an accumulating magnitude value
which can have little to do with the original location. If a node takes a rotating curved path and Mesh Displacement accounts for the curve then subtracting that value from the current XYZ location will cause you to over shot on the straight line return path thus the domain will shrink expand distort, something bad.
2. A way to have 3/9 variables in CEL that can give me 3 know XYZ points on the domain as it is moved, I can then use them as reference point to determine the next move before I do the move. If I know the Node number can I get the XYZ of it. An example would be the Axis of rotation point for this move. I can keep track of where the axis should be and use my own calculated value but CFX works in real numbers (Kind of) and if this axis point for rotation lacks any precision it can throw some values way off.
NX = (cos(YRA)*((cos(ZRA)*x)-(sin(ZRA)*y)))-(sin(YRA)*z)
NY = (sin(ZRA)*x)+(cos(ZRA)*y)
NZ = (sin(YRA)*((cos(ZRA)*x)-(sin(ZRA)*y)))+(cos(YRA)*z)
NotSetTo = (SetTo-1)*-1
SetTo = step(atstep-1.3)
YRA = YRPos*pi/180
YRPos = (YRate*NotSetTo)+(YRate*SetTo*-1)
YRate = 12
ZRA = ZRPos*pi/180
ZRPos = (ZRate*NotSetTo)+(ZRate*SetTo*-1)
ZRate = 18
Green text is straight from the CFX Expression Language guide just for reference
All numbers are treated as real numbers.
The precedence of operators is as follows (from highest to lowest):
• The unary minus or negation operator ‘-’ as in ‘-x’.
• The power operator ‘^’ as in ‘x^y’.
• Multiplication and division as in ‘x*y/z’.
• Addition and subtraction as in ‘x+y-z’.
Note a difference from FORTRAN is that in FORTRAN, if A has the
value 1, then -A**2 is interpreted as -(A**2) and has the value -1. In
CEL -A^2 is interpreted as (-A)^2 and has the value 1. For clarity, you
can always use brackets to specify the order of operations.
|All times are GMT -4. The time now is 20:26.|