Different results when running on different number of threads
Hi Everyone,
I am running an acusolve job on an HPC cluster, and I found that the results are different for the same test-case run on different numbers of threads. And if I run the job on 6 threads, or 10 thread, it gives me this warning:
*** WARNING: inflow at outflow boundary: Outlet_3 (mass/time: in=-1.487182e-09, out=3.392650e-03)
whereas it does not give that warning if I run on 3, 4, 5, or 8 threads.
Some output log files are attached. Does anyone know what the problem might be?
The case itself is a simple internal flow problem through an expanding circular duct.
Thanks,
Josh
Best Answer
-
Josh Fontana said:
Ok, thanks for the info. I was told some variation can be expected in these sorts of codes, when running on multiple threads. Would you think this level of variation is OK?
The first table shows the maximum values of velocity, pressure, and eddy viscosity for each case. The second table shows the percent difference between the maximums for the 20 proc and 10 proc cases (2nd column), and between the 40 proc and 10 proc cases (3rd column) for each variable.
I'll admit, my mesh may not be the best-quality mesh. Could this much variation be due to a poor mesh?
The difference for the Z-Velocity value is the largest percentage. But if you look at the actual value, the largest difference is about 0.6E-4 m/s - very small, indeed. It's also likely the location of the reverse flow portions will not be stable, so could wander around a bit. You could extend the outlet a bit, and maybe add a contraction, to avoid the reverse flow. (I always try to avoid reverse flow if all possible.)
It could certainly still be related to mesh, too.
0
Altair EmployeeAnswers
-
This is basically telling you that this case with the current mesh has at least a slight tendency to have reverse flow at the outlet - due to the expansion. Due to the small differences in the math due to the different numbers of cores used, sometimes that manifests itself in the results, and sometimes it doesn't.
What happens if you make the mesh finer?
What happens if you set the convergence tolerance lower - to 1e-4 instead of 1e-3?
0 -
acupro_21778 said:
This is basically telling you that this case with the current mesh has at least a slight tendency to have reverse flow at the outlet - due to the expansion. Due to the small differences in the math due to the different numbers of cores used, sometimes that manifests itself in the results, and sometimes it doesn't.
What happens if you make the mesh finer?
What happens if you set the convergence tolerance lower - to 1e-4 instead of 1e-3?
Hi acupro,
Thanks for the reply. I tried a bunch of cases, some with tighter convergence tolerance and some with a new, more refined mesh. The cases with tighter tolerance all yielded the same result as the original 10-thread case, when run on 10 threads.
The cases with the finer mesh, once again, gave different results depending on the number of threads used. FYI this finer mesh is a completely new mesh generated for the same geometry, with smaller elements than the original mesh, but it is not strictly a refined version of the original mesh. (I wasn't sure how to refine an existing mesh in SimLab).
The log files for these cases are in the attached zip file.
Thanks,
Josh
0 -
Josh Fontana said:
Hi acupro,
Thanks for the reply. I tried a bunch of cases, some with tighter convergence tolerance and some with a new, more refined mesh. The cases with tighter tolerance all yielded the same result as the original 10-thread case, when run on 10 threads.
The cases with the finer mesh, once again, gave different results depending on the number of threads used. FYI this finer mesh is a completely new mesh generated for the same geometry, with smaller elements than the original mesh, but it is not strictly a refined version of the original mesh. (I wasn't sure how to refine an existing mesh in SimLab).
The log files for these cases are in the attached zip file.
Thanks,
Josh
On the refined model - yes, just more mesh from remeshing - it seems all the runs gave reverse flow by the end of the run, with the incoming flow at the exit about 3 orders of magnitude less than the exiting flow. Seems that's what the physics of the problem dictate - which is quite common for geometrically-expanding exits in order to maintain conservation.
0 -
acupro_21778 said:
On the refined model - yes, just more mesh from remeshing - it seems all the runs gave reverse flow by the end of the run, with the incoming flow at the exit about 3 orders of magnitude less than the exiting flow. Seems that's what the physics of the problem dictate - which is quite common for geometrically-expanding exits in order to maintain conservation.
Ok, thanks for the info. I was told some variation can be expected in these sorts of codes, when running on multiple threads. Would you think this level of variation is OK?
The first table shows the maximum values of velocity, pressure, and eddy viscosity for each case. The second table shows the percent difference between the maximums for the 20 proc and 10 proc cases (2nd column), and between the 40 proc and 10 proc cases (3rd column) for each variable.
I'll admit, my mesh may not be the best-quality mesh. Could this much variation be due to a poor mesh?
0 -
Josh Fontana said:
Ok, thanks for the info. I was told some variation can be expected in these sorts of codes, when running on multiple threads. Would you think this level of variation is OK?
The first table shows the maximum values of velocity, pressure, and eddy viscosity for each case. The second table shows the percent difference between the maximums for the 20 proc and 10 proc cases (2nd column), and between the 40 proc and 10 proc cases (3rd column) for each variable.
I'll admit, my mesh may not be the best-quality mesh. Could this much variation be due to a poor mesh?
The difference for the Z-Velocity value is the largest percentage. But if you look at the actual value, the largest difference is about 0.6E-4 m/s - very small, indeed. It's also likely the location of the reverse flow portions will not be stable, so could wander around a bit. You could extend the outlet a bit, and maybe add a contraction, to avoid the reverse flow. (I always try to avoid reverse flow if all possible.)
It could certainly still be related to mesh, too.
0 -
acupro_21778 said:
The difference for the Z-Velocity value is the largest percentage. But if you look at the actual value, the largest difference is about 0.6E-4 m/s - very small, indeed. It's also likely the location of the reverse flow portions will not be stable, so could wander around a bit. You could extend the outlet a bit, and maybe add a contraction, to avoid the reverse flow. (I always try to avoid reverse flow if all possible.)
It could certainly still be related to mesh, too.
Ok, thanks for your help!
0