Mesh rigid body motion

[Luca]

Hi everyone!

I am performing flutter analysis on bridge decks. In order to do that I need the mesh do deform allowing the deck to move in the fluid domain. In addition I would like the mesh to move rigidly close to the body in order to ensure quality close to the BL. I have performed this setting the mesh viscosity to very high values close to the deck but this method is extremely inefficient and increase the calculation time of a factor 4.
I would like to prescribe a rigid body motion for same zones and allow deformation for others. I have seen that this is possible using usalcl.f90 but in the examples it only refers to boundary faces.

Then, the questions are:

1) Is the ALE module going to work fine if I impose a time varying node displacement in usalcl.f90?
2) If this is not possible can I use usalcl.f90 to impose the rigid body velocity field to some faces? Is this going to be efficient? Can I assign prescribed velocity also to internal faces?

I'm using CS 2.2.0

Thanks a lot for the support!

Luca

[JamesMcNaughton]

Hi Luca,

I've only done very basic movement with the ALE so someone may come with a more informative answer for you but a few pointers to start you off..

1) You can displace nodes as you like using the example in usalcl as a starting point. (If you're not moving the nodes of a boundary face using this method you should use the other BCs igliss, ivimpo etc to properly describe what is happening to these faces or there will be an error). For example define all BCs as per the examples and then those nodes you want to move more exactly do using this loop over certain nodes. To loop over / move certain nodes you may loop over their internal faces by selection (as below).

2) If you're wanting to loop over internal faces and move these nodes you can use the GETFAC subroutine (just like GETFBR) but you can't give these a velocity, only move the nodes by looping over them as in the example (but use IPNFAC not IPNFBR).

Hope that was some help to you.

James

[Luca]

Thank you James!

I think that what you said will already help! My doubts anyway are actually these.

From what i know in the ALE formulation the mesh velocity is needed in order to describe the fluid motion. I can't undersand if moving the nodes as I wish (with time varying displacements and also in non boundary faces) will make the code automatically calculate the mesh velocity and apply the ALE formulation or if some error will occur.

The second point is that the all problem is that the mesh motion is computationally expensive becouse it is applied on the whole mesh. In reality 50% of the mesh is moving in a rigid way, 20% is actually deforming and 30% is not moving at all. In the computation I would like to avoid the fixed and the rigid body mesh velocities (ore displacements) to be treated as unknows.

Does anyone knows what routine actually calculates the mesh deformation?

Thanks,
Luca

[Luca]

I just made an experiment: I activated the ALE module and fixed all the boundaries so that actually nothing is moving. The calculation time still increase of a factor 4. I guess that things get more complicated to be solved for me.

Is there any workaround?

Thanks,
Luca

[JamesMcNaughton]

Hi Luca,

This is something I have observed also - although I haven't an exact value I notice that calculations are much slower using ALE.

I noticed the majority of this added time was coming in the gradient calculation (gradrc / gradmc) when the cell centre of gravity is recalculated. If ale is on (iale=1) then the ccog is recalculated each time gradient is called which is quite expensive. You could try changing this for your fixed mesh with ALE solution and see if there is much change. I don't imagine it is safe to overwrite this for an actual ALE case though..

Also I am using v2.0 and I know they have changed and improved ALE a lot so this might not be relevant any more!

[Luca]

Thanks James,

Thank you for your precious indications! I will try to install the last version as a first attempt then! I really would like not to change the code in such deep parts as it might be unsafe without exactly knowing what is going on.

Luca

[Luca]

I downloaded the version 2.3.0 and there is not improvement of speed.
The calculation time is not sensitive to the residuals required to the mesh velocities equations so I guess that, as you stated, the problem is in the gradient calculation.
It would be nice to have a tool to handle efficiently mesh rigid body motions. The gradients should be transformed using the rigid body motion instead of being recalculated I guess. Might be a proposal for the next releases !

[Yvan Fournier]

Hello,

To compare computational time, I would suggest checking the end of the "listing" file, as well as the "performance.log" file (for versions > 2.1). This will provide a summary of time spent in linear solvees as well as gradient calculations, as well as a few other tiings, which you can relate to the global tie to check where tie is spent.

I known with versions 2.3 and 3.0, some mesh quality criteria are recomputed at each time step in ALE mode, and we need to add an option to deactivate this to save some computational time, but checking and reporting where time is spent is the first step to help us focus on the best optimization opportunities.

Best regards,

Yvan

[Luca]

Dear Yvan,

sorry for the late answer but I forgot my password and I could not retrieve it. Here are the listing and performance files. I limited the listing file to 100 time steps deleting the subsequent ones.

Thanks,
Luca

[Yvan Fournier]

Hello,

In your case, about 30% of the computational coast is recomputing the wall distance, and another 30% is iterative velocity gradients. Gradients could be made slighty cheaper by rotating some geometric quantities, and also not recompute them for all variables, but only once per time step that were the cause for the cost. This requires minor modifications so as to make the gradient calculation aware of the current time step.

Also, there is not much we can do about wall distance, which needs to be updated for turbulence, except possibly assume deformation is slow and update it only once every few time steps.

Ill check with Martin, who has better knowledge of ALE thant I do, if there is no reason not to do either of this, and possibly sent you a patch to test those options.

Also, did you test non-iterative gradients ?.

Best regards,

Yvan