Sanity check: conservation of angular momentum problem (sprinkler rotation)

Please attach some images along with notations to describe your simulation model.  Please indicate if there are multiple volumes - some fixed, some moving, etc.  Also - what is MotionSolve handling in this?

Please attach some images along with notations to describe your simulation model.  Please indicate if there are multiple volumes - some fixed, some moving, etc.  Also - what is MotionSolve handling in this?

For now it is not clear for me how use the acusolve built-in rigid body motion (since the hypermesh 2021 interface is lagging, and I just don't want deal with the new hypermesh interface 2023 it very confusing to me). that's why I used co-simulation acusolve-motionsolve.

I attached a *.pptx to explain the problem.

thank you acupro for your help

For now it is not clear for me how use the acusolve built-in rigid body motion (since the hypermesh 2021 interface is lagging, and I just don't want deal with the new hypermesh interface 2023 it very confusing to me). that's why I used co-simulation acusolve-motionsolve.

I attached a *.pptx to explain the problem.

 

thank you acupro for your help

the computation now is @ 25% progress no error yet

but there is warnings

WARNING: inflow at outflow boundary: outlets (mass/time: in=-2.783691e-005, out=2.783685e-005)

the computation now is @ 25% progress no error yet

but there is warnings

WARNING: inflow at outflow boundary: outlets (mass/time: in=-2.783691e-005, out=2.783685e-005)

Your setup makes sense to me.  You're using MotionSolve to define bearing resistance, damping, etc. - and you want the entire model to move with the motion determined by MotionSolve.  You could probably get most of that with the Rigid Body Motion definition in AcuSolve also, but it may be easier to define them in MotionSolve as you've done.

I do suggest you split the outlets into separate sets - so Outlet1 and Outlet2 - rather than leaving them both in one set.

You'll probably need some trial and error to get the right time increment to keep things stable.  You may also want to ramp the fluid forces passed to MotionSolve over the first several steps - in order to reduce the effects of likely not very good convergence at the start.  Something like:

MULTIPLIER_FUNCTION( "Ramp" ) {
type = linear
curve_fit_variable = time_step
curve_fit_values = { 0.0, 0.0 ; 20.0, 1.0 ; }
}

Then add this to the EXTERNAL_CODE command:

multiplier_function = "Ramp"

(Right now, that parameter is set to none.)  This will then reach full passing for fluid forces by time step 20.

You may also want to increase max-stagger-iterations to 4 or 6, again to improve convergence per time step.

This simulation assumes the water tubes are entirely filled with water at all times.

You've requested nodal output every time step - so you could review the solution each time step, even while the job is running.

Yes - the old HyperMesh interface to AcuSolve has not been updated in some time, and likely will not be, in favor of the newer tools.  In case you haven't seen them - there are tutorials here - for both SimLab and HyperMesh CFD.

https://help.altair.com/hwcfdsolvers/acusolve/topics/chapter_heads/tutorials_r.htm

There probably isn't anything that covers your case exactly.

Your setup makes sense to me.  You're using MotionSolve to define bearing resistance, damping, etc. - and you want the entire model to move with the motion determined by MotionSolve.  You could probably get most of that with the Rigid Body Motion definition in AcuSolve also, but it may be easier to define them in MotionSolve as you've done.

I do suggest you split the outlets into separate sets - so Outlet1 and Outlet2 - rather than leaving them both in one set.

You'll probably need some trial and error to get the right time increment to keep things stable.  You may also want to ramp the fluid forces passed to MotionSolve over the first several steps - in order to reduce the effects of likely not very good convergence at the start.  Something like:

MULTIPLIER_FUNCTION( "Ramp" ) {
type = linear
curve_fit_variable = time_step
curve_fit_values = { 0.0, 0.0 ; 20.0, 1.0 ; }
}

Then add this to the EXTERNAL_CODE command:

multiplier_function = "Ramp"

(Right now, that parameter is set to none.)  This will then reach full passing for fluid forces by time step 20.

You may also want to increase max-stagger-iterations to 4 or 6, again to improve convergence per time step.

This simulation assumes the water tubes are entirely filled with water at all times.

You've requested nodal output every time step - so you could review the solution each time step, even while the job is running.

Yes - the old HyperMesh interface to AcuSolve has not been updated in some time, and likely will not be, in favor of the newer tools.  In case you haven't seen them - there are tutorials here - for both SimLab and HyperMesh CFD.

https://help.altair.com/hwcfdsolvers/acusolve/topics/chapter_heads/tutorials_r.htm

There probably isn't anything that covers your case exactly.

Hi acupro;

the set up from the last time is working as intended and I included you suggestions, I also applied pressure BC @ the inlet (applying flow rate seems to to cause the sprinkler move in the wrong direction I'm not yet sure why is that).

Any way now I want to include the fixed part of the system (where the bearing lift and drag will be insured by the fluid it self.

please check the attached file and let me know what you think, because now I have two volumes one is fixed and the other one is moving (due rigid body dynamics).

Thank for your support

Best Regards

Hi acupro;

the set up from the last time is working as intended and I included you suggestions, I also applied pressure BC @ the inlet (applying flow rate seems to to cause the sprinkler move in the wrong direction I'm not yet sure why is that).

Any way now I want to include the fixed part of the system (where the bearing lift and drag will be insured by the fluid it self.

please check the attached file and let me know what you think, because now I have two volumes one is fixed and the other one is moving (due rigid body dynamics).

 

Thank for your support

 

Best Regards

The auto-wall processing should take care of splitting the nodes between the fixed and moving volumes.  (Leave those surfaces as default wall - or however they are defined in the old interface.)  The mesh motion would be assigned to the moving volume as before.