|
[Sponsors] |
November 9, 2020, 06:10 |
acoustic CFL number
|
#1 |
New Member
Jannis
Join Date: Jul 2020
Posts: 20
Rep Power: 6 |
Hello everyone,
I have a question regarding the acoustic CFL number. According to the CFX documentation (1.1.3.15) the acoustic CFL-number is calculated as follows: . c: local speed of sound If I use this formula to calculate the CFL number in a square tube with an equidistant mesh and a fixed time step, I get a result about three times smaller than the result written in the .OUT-file for the acoustic CFL number (RMS). Does anyone know what this could be caused by? Could it be because the formula is for the one-dimensional case and the simulation is three-dimensional? Best regards and stay healthy! |
|
November 9, 2020, 17:35 |
|
#2 |
Super Moderator
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 17,871
Rep Power: 144 |
You have not described what flow you are applying this to, so I cannot say what is going on.
The reference you quote has the CFL number calculated by a different method than you describe, it takes into account the different possible direction of the flow. So your calculation would need to do this as well, and then do an RMS average of your CFL number across the entire flow field to be equivalent to the CFX calculated number. Is this what you did?
__________________
Note: I do not answer CFD questions by PM. CFD questions should be posted on the forum. |
|
November 10, 2020, 08:44 |
|
#3 |
New Member
Jannis
Join Date: Jul 2020
Posts: 20
Rep Power: 6 |
Hello ghorrocks,
you are right, the whole formula for the acoustic CFL number is of course: For my simulation, however, it can be simplified as mentioned above, which I admit is not clear from the description so far. Therefore I attach an exemplary OUT-file and a picture of the calculation domain. Perhaps briefly summarised: - at the inlet the velocity along the pipe axis is given as 0.1 + 0.005 * sin(2*pi*frequency*time) [m/s]. - at the outlet, the pressure is specified as 2 [bar]. - at the inlet and outlet, the non-reflecting boundary condition is activated (beta feature) with a reflection factor of 0 - the wall (green part in the picture) is assumed to be frictionless - the flow is assumed to be laminar - the fluid is water - equidistant mesh () Regarding the use of RMS averaging in my calculations, I don't think it should have much influence on the result for the flow under consideration here. Because the speed of sound and the flow speed/direction in the calculation area should not differ much and the time step and grid spacing is constant. Therefore the CFL number should be almost constant in the calculation area. Best regards |
|
November 10, 2020, 08:59 |
|
#4 |
Senior Member
Join Date: Jun 2009
Posts: 1,880
Rep Power: 33 |
Valid points, and thank you for the detailed data.
How will the software figure out your distance dx = 0.001 [m] ? As pointed out previously, it is an RMS (which may not be the issue here) value on an unstructured mesh (general case). So I would expect an estimate of a length scale since there is no reliable way to produce a dx for all possible simulations in the field. Here a few questions: is the mesh isotropic? i.e. dx = dy = dz = 0.001[m] ? can you estimate the average volume of the control volumes throughout the mesh? ANSYS CFX already uses a characteristic length equal to the cubic root of the domain volume, correct? Can it be using the cubic root of the average control volume volume? How far off would that value be from your expected 0.001 [m]?
__________________
Note: I do not answer CFD questions by PM. CFD questions should be posted on the forum. |
|
November 11, 2020, 08:39 |
|
#5 | |||||
New Member
Jannis
Join Date: Jul 2020
Posts: 20
Rep Power: 6 |
Hi Opaque,
Quote:
I use ICEM CFD for mesh generation. To put it a bit simplified, you can specify how many nodes should be placed along the pipe axis and how they should be distributed along the pipe axis. By choosing an uniform distribution and the number of nodes you can define the grid spacing. ICEM also offers the possibility to check the grid quality, such as the largest grid spacing or the aspect ratio. I have checked all these values, so I am relatively sure that the mesh is equidistant (dx = dy = dz = 0.001 [m]). Quote:
Quote:
The tube has the dimensions: 0.512 x 0.016 x 0.016 [m] so there are 513 * 17 * 17 = 148257 nodes and thus also control volumes. The control volumes should have the following size: - in the corners: 0.0005^3 [m^3] (number: 8) - along the edges: 0.0005^2 * 0.001 [m^3] (number: 15 * 8 + 511 * 4 = 2164) - along the side surface: 0.0005 * 0.001^2 [m^3] (number: 4 * 511 * 15 + 2 * 15 * 15 = 31110) - inside: 0.001^3 [m^3] (number: 114975) on average: V = 8.84 * 10^-10 [m^3] Quote:
Quote:
Best regards |
||||||
November 11, 2020, 11:42 |
|
#6 |
Senior Member
Erik
Join Date: Feb 2011
Location: Earth (Land portion)
Posts: 1,188
Rep Power: 23 |
I'm guessing CFL calculated is exactly 3x what you are calculating (I get 1.001 for the 1D case.) RMS is 3.05, and not 3, since the side and corner cells raise the RMS value slightly. You max is exactly 6x higher than calculated for 1D.
So we know delta.t, and c, and delta.x is our only unknown. In an explicit code, delta.t does have to me smaller for a 2D and 3D case vs a 1D, so 3D CFL number should be higher than 1D. I don't have my books with me (working from home) or I would look up the equation. My guess is the program adds CFLx + CFLy + CFLz? Extend you mesh length in one direction and see if this equation still works, as it does now, or if it is of some other form. Actually, Wikipedia confirms this sum of 1D CFLs for 2D and 3D cases: https://en.wikipedia.org/wiki/Couran...Lewy_condition So 3D case with cube mesh should be 3x the CFL of the 1D case. CFL# is not really too important in CFX, as it is an implicit code. It can just be used as a general guide if helpful, but it has no hard limits which must be followed. |
|
November 12, 2020, 09:12 |
|
#7 |
New Member
Jannis
Join Date: Jul 2020
Posts: 20
Rep Power: 6 |
Hi evcelica,
I think you are right that the CFL number is the sum of the CFL numbers for the individual coordinate directions (CFL = CFLx + CFLy + CFLz). I have, as you suggested, varied the mesh and made no other changes to the simulation. Here are the results for the first iteration from the OUT file: dx = 0.001 [m], dy = 0.002 [m], dz = 0.001 [m]: CFL (RMS) = 2.54, CFL (MAX) = 5.00 dx = 0.001 [m], dy = 0.004 [m], dz = 0.002 [m]: CFL (RMS) = 1.8, CFL (MAX) = 3.5 Ideally the following CFL numbers would result from the summation of the CFL numbers for the individual coordinate directions: dx = 0.001 [m], dy = 0.002 [m], dz = 0.001 [m]: CFL = 2.50 dx = 0.001 [m], dy = 0.004 [m], dz = 0.002 [m]: CFL = 1.75 As you and Opaque have pointed out, the deviations can quite well be explained by the smaller control volumes at the boundaries of the calculation area. Smaller control volumes have a higher CFL number and thus increase the mean CFL number. The smallest control volumes are in the corners of the calculation area and have edge lengths only half as long as control volumes inside the calculation area. This results in a CFL number twice as large for the smallest control volumes. If you compare the maximum CFL number from the simulation with the calculated CFL number, it fits exactly. So I think we have solved the problem. Special thanks to all involved!!! Best regards and stay healthy! PS: @evcelica: Could you perhaps provide the titles of the books for further background reading? Would be really great! |
|
November 16, 2020, 12:25 |
|
#8 |
Senior Member
Erik
Join Date: Feb 2011
Location: Earth (Land portion)
Posts: 1,188
Rep Power: 23 |
The book I referenced was not that great of a book. It was just one I had to use for a numerical methods class, and I remember this explicit method maximum timestep equation being in the book. Next time I go into work, I'll look at it.
Thanks for taking the time do the tests to confirm how CFL is calculated in CFX. |
|
Tags |
acoustic courant number, cfl number |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
decomposePar no field transfert | Jeanp | OpenFOAM Pre-Processing | 3 | June 18, 2022 13:01 |
decomposePar problem: Cell 0contains face labels out of range | vaina74 | OpenFOAM Pre-Processing | 37 | July 20, 2020 06:38 |
[snappyHexMesh] Error snappyhexmesh - Multiple outside loops | avinashjagdale | OpenFOAM Meshing & Mesh Conversion | 53 | March 8, 2019 10:42 |
foam-extend_3.1 decompose and pyfoam warning | shipman | OpenFOAM | 3 | July 24, 2014 09:14 |
Cluster ID's not contiguous in compute-nodes domain. ??? | Shogan | FLUENT | 1 | May 28, 2014 16:03 |