(1) In this case, when entering the geometry, the hight of the cylinder, with original hight of 0.4 meters, is extended by adding 0.1 meters. In the web page text, it explains that the treatment like this can allow for a sharp and clean cut. How to unstand it? I feel puzzled about it. Is it related to the mesh generated later? Why 0.1 meters is added, not 0.2 or larger size? How to determine the added size?
(2) The suggested time step in the tutorial is 1e-3. However, the computation diverged when I ran the case with the same set ups as shown in the tutorial. It ran well when the time step was decreased to 1e-4. I am not sure why.
(3) I ran this case in the Wnidows operating system. The calculation converged well with single thread. However, it diverged when I used multithreaded computing. What caused this problem? How to deal with this problem, if I want to using multithreading to compute more effectively?
If you do not extend it, the intersection where the cylinder and the cap meet won’t be well resolved, see image on the left compared with the image on the right when the cylinder is extended.
I ran this case just now and I didn’t see any initial divergence. It is possible to get some non-convergence during the run, and the time step will automatically decrease. This is usually not a concern. The time step can also go back up if good convergence is achieved.
Not sure about the issue on Windows, it runs fine in SMP on Linux.
I ran the tutorial 3.5 with MFiX 21.3.2 on both Linux and Windows to look for problems with SMP on Windows. I obtained essentially the same results on both platforms when running with SMP support enabled/disabled.
Linux does seem to be a bit faster - I ran on two equivalent machines, Lenovo X280 Thinkpad, 16GB RAM, 4x i7-8650U CPU with 2 threads per core for a total of 8 available hyperthreads. Here’s my timing results:
Linux SMP threads=8
CPU 1420.0 s
Real 458.1 s
CPU/real 3.1
Linux SMP threads=1
CPU 755.7 s
Real 748.3 s
Linux serial (no SMP)
CPU 734.4 s
Real 727.1 s
Win10 SMP threads=8
CPU 1608.0 s
Real 519.7 s
CPU/real 3.1
Win10 SMP threads=1
CPU 805.1 s
Real 802.0 s
Win10 serial (no SMP)
CPU 745.5 s
Real 742.7 s
Several things are worth noting here: the speed difference between Linux and Windows is least noticeable when running with SMP disabled. SMP seems to have higher associated overhead on Windows.
With SMP enabled, on both platforms, even when we make 8 threads available, they are not completely used: the CPU/real time ratio is 3.1, meaning that we are keeping 3 cores busy. And the overhead of SMP is considerable, even with 8 cores we only observe approx 2x speedup comparing the real time for serial and threads=8 cases.
I did not observe any non-convergence, running out to tstop=1. I’m attaching the mfx file for your reference, perhaps you missed a step when setting this up?
Thank you. From your attached image, I have clearly known the importance of extending the hight of cylinder for better grids at the intersection. I run the case again, finding that the suggested time step do not cause initial divergence today, but it did not converged yesterday.
Thanks for your detail reply about computation efficiency with and without SMP.
I caculated with your test.mfx file. However, the initial divergence problem still appeared in my computer when I used the SMP on Windows. May be it is the bug of my computer. I will try to use the Linux MFIX version on Ubuntu later.
Now, I have a new confusion. It is about the cylinder resolution in geometry pane. In tuturial case 3.5, the suggested resolution is 30. I increased the resolution with an order of magnitude in order to obtain smoother cylindrical profile. The grid aspect ratio distributions when resolution=30 (upper) and 300 (under) are atteched here.
It can be found that resolution=30 seems to gain higher grid quality with less grids whose aspect ratio larger than two. But I am not sure whether resolution=30 may have influence on simulation accuracy? How to determine the resolution of cylinder? Is grid resolution related to this geometry resolution?
What does the non-convergence look like? DT < DT_MIN? Can you send a log from a failing SMP run on Windows? It’s odd that we are getting different results.
I don’t have the answer for your question about the cylinder resolution, but there is a comment in the tutorial
This is a fairly coarse grid for a TFM simulation. After completing this tutorial, try increasing the grid resolution to better resolve the bubbles.
I think the grid resolution is more important than the cylinder resolution. Perhaps someone else can comment further.
I used your test.mfx file and the error logs were “Error 1000: NaN detected in Residual:Pressure correction equation, phase (0)” and “Error from check_convergence.f:261 \ Error 1000: NaN detected in Residual:Pressure correction equation, phase (1)” when I ran this case on the Windows operating system with SMP.
I’ve found that the NaN is reproducible when I run with 4 threads but not with 8. I’m not sure what the problem is, but now that I can reproduce it I’ll investigate further.
