Cannot get the correct centerline velocity for laminar pipe flow
Dear All, We want to use Nektar++ to perform DNS of blood flow inside constricted vessels. Unfortunately the learning process turned out to be quite slow. We started with the following simple laminar pipe flow problem Diameter = 0.2 m Length = 8 m Kin. viscosity = 2 (10^-3) m2/s Inlet velocity = 1m/s Outlet pressure = 0 Pa Re = 100 Fully developed centerline velocity is known to be 2 m/s. With a fine enough mesh we expect to get this value exactly. But the best we got was 1.974 m/s. We generated the mesh using Gmsh and we suspect that the problem might be related to the curved edge definitions. In the process we observed quite bizarre behaviors, such as even worse centerline velocities as the polynomial order inside the elements is increased. That's why my student Kamil previously asked here couple of questions about this, but I guess some questions remained unanswered or maybe we couldn't interpret the answers properly. To make sure that we're doing everything else right, we generated a similar duct flow problem with straight surfaces. Fully developed centerline velocity is again known and we can easily get that value correct up to 3-4 digits. At this point we're not sure about what we're doing wrong in the pipe flow case. Is it really a curvature issue or something else? We'd really appreciate if you can shed some light. We can share the XML file if that might help to resolve the problem. Thanks in advance for the help and thanks for sharing this flow solver with us. Cuneyt Sert
Dear Cuneyt, We are doing our best to support all requests but obviously since this is a voluntary project we can only manage a limited number of responses. However I think the approach you have taken to set up a test case is reasonable. Certainly when using a channel flow where the solution is therefore a polynomial you should get an answer to machine precision. Indeed in the regression test examples in Nektar++/solvers/IncompressibleNSSolver/Tests there are a number of small test cases using different shape discretisations which check this and so i am confident the code should be running for this case. So if you have Nmodes >=3 the answer should be even more accurate than 3-4 digits. As you also suggest it is highly likely that the reason your pipe case is not giving the correct maximum velocity. Having a look it appears we do not have pipe regression test and this is probably something we should add. I have an old pipe example using tets and prisms but that also gives an error about 0.03 so that would seem to be consistent. The mesh Kamil sent is quite coarse around the boundaries and so I suspect the geometry resolution could yet be a problem. Can I also ask how long the run has been executed since it may also not have seltted down into a steady state? I note the file that Kamil sent today has 3000 steps where the inflow conditions are a blunt profile. The blunt profile is also likely to cause problems since you cannot satisfy a blunt condition of w=1 and the wall boundary condition of w=0. This probably means that at inflow the flow is blended over the outer element and may not be actually enforcing the correct amount of mass at the inflow of at least the amount you expect for your exact solution. Have you instead considered setting the exact boundary conditions and possibly initial conditions to see what answer that give? Cheers, Spencer.
Dear All,
We want to use Nektar++ to perform DNS of blood flow inside constricted vessels. Unfortunately the learning process turned out to be quite slow. We started with the following simple laminar pipe flow problem
Diameter = 0.2 m Length = 8 m Kin. viscosity = 2 (10^-3) m2/s Inlet velocity = 1m/s Outlet pressure = 0 Pa Re = 100
Fully developed centerline velocity is known to be 2 m/s. With a fine enough mesh we expect to get this value exactly. But the best we got was 1.974 m/s. We generated the mesh using Gmsh and we suspect that the problem might be related to the curved edge definitions. In the process we observed quite bizarre behaviors, such as even worse centerline velocities as the polynomial order inside the elements is increased. That's why my student Kamil previously asked here couple of questions about this, but I guess some questions remained unanswered or maybe we couldn't interpret the answers properly.
To make sure that we're doing everything else right, we generated a similar duct flow problem with straight surfaces. Fully developed centerline velocity is again known and we can easily get that value correct up to 3-4 digits.
At this point we're not sure about what we're doing wrong in the pipe flow case. Is it really a curvature issue or something else? We'd really appreciate if you can shed some light. We can share the XML file if that might help to resolve the problem.
Thanks in advance for the help and thanks for sharing this flow solver with us.
Cuneyt Sert
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
Spencer Sherwin McLaren Racing/Royal Academy of Engineering Research Chair, Professor of Computational Fluid Mechanics, Department of Aeronautics, Imperial College London South Kensington Campus London SW7 2AZ s.sherwin@imperial.ac.uk +44 (0) 20 759 45052
Dear Prof. Sherwin, First of all we really appreciate your work and support. We hope that the issues raised in this list can be used to enhance the code and its documentation so that the time you are spending will worth it. We tried several different meshes and discretization orders for the pipe flow case. We monitored the centerline velocity during the run and made sure that it is no longer changing in time. The imposibbility of specifying exact blunt inflow profile came to our mind, but we thought that the channel flow case should also have suffered from it, which did not. But we'll check that again. Your 0.03 error is better than our best, so we'll keep trying. Thank you. Cuneyt Sert -----Original Message----- From: Sherwin, Spencer J [mailto:s.sherwin@imperial.ac.uk] Sent: Sunday, October 12, 2014 11:03 PM To: Cuneyt Sert Cc: nektar-users Subject: Re: [Nektar-users] Cannot get the correct centerline velocity for laminar pipe flow Dear Cuneyt, We are doing our best to support all requests but obviously since this is a voluntary project we can only manage a limited number of responses. However I think the approach you have taken to set up a test case is reasonable. Certainly when using a channel flow where the solution is therefore a polynomial you should get an answer to machine precision. Indeed in the regression test examples in Nektar++/solvers/IncompressibleNSSolver/Tests there are a number of small test cases using different shape discretisations which check this and so i am confident the code should be running for this case. So if you have Nmodes >=3 the answer should be even more accurate than 3-4 digits. As you also suggest it is highly likely that the reason your pipe case is not giving the correct maximum velocity. Having a look it appears we do not have pipe regression test and this is probably something we should add. I have an old pipe example using tets and prisms but that also gives an error about 0.03 so that would seem to be consistent. The mesh Kamil sent is quite coarse around the boundaries and so I suspect the geometry resolution could yet be a problem. Can I also ask how long the run has been executed since it may also not have seltted down into a steady state? I note the file that Kamil sent today has 3000 steps where the inflow conditions are a blunt profile. The blunt profile is also likely to cause problems since you cannot satisfy a blunt condition of w=1 and the wall boundary condition of w=0. This probably means that at inflow the flow is blended over the outer element and may not be actually enforcing the correct amount of mass at the inflow of at least the amount you expect for your exact solution. Have you instead considered setting the exact boundary conditions and possibly initial conditions to see what answer that give? Cheers, Spencer.
Dear All,
We want to use Nektar++ to perform DNS of blood flow inside constricted vessels. Unfortunately the learning process turned out to be quite slow. We started with the following simple laminar pipe flow problem
Diameter = 0.2 m Length = 8 m Kin. viscosity = 2 (10^-3) m2/s Inlet velocity = 1m/s Outlet pressure = 0 Pa Re = 100
Fully developed centerline velocity is known to be 2 m/s. With a fine enough mesh we expect to get this value exactly. But the best we got was 1.974 m/s. We generated the mesh using Gmsh and we suspect that the problem might be related to the curved edge definitions. In the process we observed quite bizarre behaviors, such as even worse centerline velocities as the polynomial order inside the elements is increased. That's why my student Kamil previously asked here couple of questions about this, but I guess some questions remained unanswered or maybe we couldn't interpret the answers properly.
To make sure that we're doing everything else right, we generated a similar duct flow problem with straight surfaces. Fully developed centerline velocity is again known and we can easily get that value correct up to 3-4 digits.
At this point we're not sure about what we're doing wrong in the pipe flow case. Is it really a curvature issue or something else? We'd really appreciate if you can shed some light. We can share the XML file if that might help to resolve the problem.
Thanks in advance for the help and thanks for sharing this flow solver with us.
Cuneyt Sert
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
Spencer Sherwin McLaren Racing/Royal Academy of Engineering Research Chair, Professor of Computational Fluid Mechanics, Department of Aeronautics, Imperial College London South Kensington Campus London SW7 2AZ s.sherwin@imperial.ac.uk +44 (0) 20 759 45052
participants (2)
-
Cuneyt Sert
-
Sherwin, Spencer J