CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Slow and unstable severe slug simulation using compressibleInterFoam

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   March 26, 2019, 05:36
Default Slow and unstable severe slug simulation using compressibleInterFoam
  #1
New Member
 
Rasmus Jørgensen
Join Date: Feb 2019
Location: Denmark
Posts: 7
Rep Power: 7
RasmusTJ is on a distinguished road
Hi Foamers!

We are two graduate students currently doing our first CFD project involving multi-phase flow. Our previous CFD experience is limited to incompressible single-phase flow using ANSYS Fluent, so it is also our first use of OpenFOAM. We have simulated different tutorials and simple cases during the last months and are becoming more confident with the OpenFOAM structure.

Our case is a pipeline with a fixed inlet mass flow rate of air and water and fixed pressure of 100 kPa at the outlet on a 630k cell mesh created using blockMesh. The zipped case is available from https://drive.google.com/open?id=1L7...nZnTtXXgN54waq. A single timestep is available in the processor folders for when the water has just reached the lowest point of the pipeline (which is actually 95 seconds of simulation).



We have stitched together the current case setup from different tutorials, mainly angledDuct (interFoam, RAS) and and bubbleColumn (compressibleInterFoam, laminar) as they have inlet and outlet boundaries such as our case and applies compressibleInterFoam and turbulence modelling, respectively. Also, we have applied changes to the 0 and system files based on tips and tricks from the internet.

However, we are struggling a bit with stability and speed. As the flow reaches the bottom of the pipeline vertical section, we have to decrease maximum Courant numbers to as low as 0.2 to continue solving. As we hope to simulate 100-200 seconds, an achievable deltaT of 0.3 msec is a bit less than we had hoped for. We have currently decomposed the case to run on 14 threads.

Our hardware and software specs:
- 2x Intel Xeon E5-2637 V4, 4-Core, 3.50 GHz Processor (8 cores and 16 threds in total)
- 256 GB DDR4-2400 RAM
- 300 GB SSD
- Ubuntu 18.04 LTS
- OpenFOAM v6

We suspect that our inferior knowledge might have caused us to apply inappropriate boundary coniditon, discretization schemes or solvers causing such poor performance.

We hope you can provide feedback on our case - any help is greatly appreciated!

With best regards,
Rasmus
RasmusTJ is offline   Reply With Quote

Old   March 31, 2019, 14:00
Default
  #2
Member
 
Geir Karlsen
Join Date: Nov 2013
Location: Norway
Posts: 59
Rep Power: 13
gkarlsen is on a distinguished road
Greetings!

The time step in your case is adjusted based on the Courant number. As you know, the Courant number is calculated based on the local velocity, the distance between mesh elements and the time step. So, if you want the time step to be higher there is basically three things you can do:

- Reduce the velocity
- Coarsen the mesh (primarily in areas with high velocity). Elongating cells in the flow direction could be one option.
- Increase the courant number

To increase the maxAlphaCo beyond 0.2 and still maintain stability. You could increase the number of alphaSubCycles (fvSolution). E.g. to 4 with a maxAlphaCo=0.8. This will however only help if the time step is held back by the interface Courant number and not overall Courant number.

Changing numerical options could reduce the solve time, but will not affect the time step.

For your 8 physical cores it typically does not improve the speed to decompose the domain into more than 8 parts. In fact, many find that they get better performance by turning off hyperthreading completely in the BIOS. I highly recommend the hardware sub forum for more information on this topic. It also includes a openfoam benchmark in a sticky thread. By running the benchmark you could ensure that your hardware is running at its expected performance, and also evaluate how it scales with number of sub-domains

Hopefully, someone might have suggestions for faster numerical schemes for you as well. Good luck
gkarlsen is offline   Reply With Quote

Old   April 1, 2019, 03:09
Default
  #3
New Member
 
Rasmus Jørgensen
Join Date: Feb 2019
Location: Denmark
Posts: 7
Rep Power: 7
RasmusTJ is on a distinguished road
Thanks for your reply, Geir! It is much appreciated.

We will try to modify our setup based on your feedback.

Regarding hyperthreading, we have already reduced the decomposition to 7 parts, and noticed a significant performance gain. We will try to investigate the possibility of disabling hyperthreading all together.

Best regards,
Rasmus
RasmusTJ is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[waves2Foam] Unstable simulation when using 'stokesFirstwCurrent' Ahmed Elhanafi OpenFOAM Community Contributions 1 October 19, 2017 13:45


All times are GMT -4. The time now is 10:12.