******************* This email originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address. ******************* Dear users, I have been running simulations of 3D convection in a box with the incompressible Navier-Stokes solver. I find that there is always an anomaly at one of the points, where the pressure field is zero (it is obvious that this zero value is wrong - see attached image). It might be worth noting that in the image, there are 12 elements with 4 modes per direction each, so 12*4^3 (=768) degrees of freedom, and the anomalous point seems to be number 767 i.e. the final one, so perhaps the last pressure variable is not being updated. The session file used to generate the result shown in the image is attached (takes about 1min to run on my laptop). Also note it is correct that u, v, w, and T are zero at the sample point - just not p! I have found this issue on a variety of cuboidal and also tetrahedral meshes. The command to run I used is mpiexec -np 4 incnavierstokessolver nektar_3d_convection.xml Can anyone help resolve this? Many thanks, Dr Ed Threlfall, UKAEA.
Hi Ed, Having a quick look at your file it seems the problem might be something like a temperature driven flow in a box? Adding a temperature field like this might be the issue since I would have expected this case to run otherwise. Mohammad (cc’ed) has been working on a branch of the code where we have fixed a number of issues to do with adding a temperature field. @Mohammad: Could you try running Ed’s case and see if it works for you? If so I suggest Ed runs on your branch until we get that merged? Cheers, Spencer. Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/ On 10 Sep 2020, at 18:04, Edward Threlfall <ejthrelfall@gmail.com<mailto:ejthrelfall@gmail.com>> wrote: This email from ejthrelfall@gmail.com<mailto:ejthrelfall@gmail.com> originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list<https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address. Dear users, I have been running simulations of 3D convection in a box with the incompressible Navier-Stokes solver. I find that there is always an anomaly at one of the points, where the pressure field is zero (it is obvious that this zero value is wrong - see attached image). It might be worth noting that in the image, there are 12 elements with 4 modes per direction each, so 12*4^3 (=768) degrees of freedom, and the anomalous point seems to be number 767 i.e. the final one, so perhaps the last pressure variable is not being updated. The session file used to generate the result shown in the image is attached (takes about 1min to run on my laptop). Also note it is correct that u, v, w, and T are zero at the sample point - just not p! I have found this issue on a variety of cuboidal and also tetrahedral meshes. The command to run I used is mpiexec -np 4 incnavierstokessolver nektar_3d_convection.xml Can anyone help resolve this? Many thanks, Dr Ed Threlfall, UKAEA. <nektar_3d_convection_problem.png><nektar_3d_convection.xml>_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk<mailto:Nektar-users@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users [cid:2f4f14e6-b17f-4bec-bf8d-4ed6c4304a82@eurprd06.prod.outlook.com]
Dear Professor, You are correct, the example is supposed to be Rayleigh-Benard convection in a 3D box (a temperature-driven flow). Prof. Hossain provided me with a working 2D example and I tried to convert to 3D. I am now trying to get Nektar++ running in the Visual Studio IDE so I can attempt to find the issue. Many thanks, Ed. On Tue, Sep 15, 2020 at 10:16 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
Having a quick look at your file it seems the problem might be something like a temperature driven flow in a box? Adding a temperature field like this might be the issue since I would have expected this case to run otherwise.
Mohammad (cc’ed) has been working on a branch of the code where we have fixed a number of issues to do with adding a temperature field. @Mohammad: Could you try running Ed’s case and see if it works for you? If so I suggest Ed runs on your branch until we get that merged?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 10 Sep 2020, at 18:04, Edward Threlfall <ejthrelfall@gmail.com> wrote:
This email from ejthrelfall@gmail.com originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.
Dear users,
I have been running simulations of 3D convection in a box with the incompressible Navier-Stokes solver.
I find that there is always an anomaly at one of the points, where the pressure field is zero (it is obvious that this zero value is wrong - see attached image). It might be worth noting that in the image, there are 12 elements with 4 modes per direction each, so 12*4^3 (=768) degrees of freedom, and the anomalous point seems to be number 767 i.e. the final one, so perhaps the last pressure variable is not being updated. The session file used to generate the result shown in the image is attached (takes about 1min to run on my laptop). Also note it is correct that u, v, w, and T are zero at the sample point - just not p!
I have found this issue on a variety of cuboidal and also tetrahedral meshes.
The command to run I used is
mpiexec -np 4 incnavierstokessolver nektar_3d_convection.xml
Can anyone help resolve this?
Many thanks,
Dr Ed Threlfall, UKAEA. <nektar_3d_convection_problem.png><nektar_3d_convection.xml> _______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
Hi Ed, OK thanks for letting me know. Are you running his branch or the master branch? Cheers, Spencer. Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/ On 15 Sep 2020, at 10:33, Edward Threlfall <ejthrelfall@gmail.com<mailto:ejthrelfall@gmail.com>> wrote: Dear Professor, You are correct, the example is supposed to be Rayleigh-Benard convection in a 3D box (a temperature-driven flow). Prof. Hossain provided me with a working 2D example and I tried to convert to 3D. I am now trying to get Nektar++ running in the Visual Studio IDE so I can attempt to find the issue. Many thanks, Ed. On Tue, Sep 15, 2020 at 10:16 AM Sherwin, Spencer J <s.sherwin@imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk>> wrote: Hi Ed, Having a quick look at your file it seems the problem might be something like a temperature driven flow in a box? Adding a temperature field like this might be the issue since I would have expected this case to run otherwise. Mohammad (cc’ed) has been working on a branch of the code where we have fixed a number of issues to do with adding a temperature field. @Mohammad: Could you try running Ed’s case and see if it works for you? If so I suggest Ed runs on your branch until we get that merged? Cheers, Spencer. Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/ On 10 Sep 2020, at 18:04, Edward Threlfall <ejthrelfall@gmail.com<mailto:ejthrelfall@gmail.com>> wrote: This email from ejthrelfall@gmail.com<mailto:ejthrelfall@gmail.com> originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list<https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address. Dear users, I have been running simulations of 3D convection in a box with the incompressible Navier-Stokes solver. I find that there is always an anomaly at one of the points, where the pressure field is zero (it is obvious that this zero value is wrong - see attached image). It might be worth noting that in the image, there are 12 elements with 4 modes per direction each, so 12*4^3 (=768) degrees of freedom, and the anomalous point seems to be number 767 i.e. the final one, so perhaps the last pressure variable is not being updated. The session file used to generate the result shown in the image is attached (takes about 1min to run on my laptop). Also note it is correct that u, v, w, and T are zero at the sample point - just not p! I have found this issue on a variety of cuboidal and also tetrahedral meshes. The command to run I used is mpiexec -np 4 incnavierstokessolver nektar_3d_convection.xml Can anyone help resolve this? Many thanks, Dr Ed Threlfall, UKAEA. <nektar_3d_convection_problem.png><nektar_3d_convection.xml>_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk<mailto:Nektar-users@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users <nektar_3d_convection_problem.png>
Hi Edward, I tried to play with your xml file. I think there was issue with the resolution. I have attached the modified xml file, and the plot of pressure and velocity field. I hope this works. [image: Screenshot 2020-09-15 at 11.26.11.png] [image: Screenshot 2020-09-15 at 11.26.50.png] With regards Abhishek --------------------------------------------------------------------------------------- Abhishek Kumar Assistant Professor (Research) Centre for Fluid and Complex Systems Coventry University, Coventry CV15FB The United Kingdom --------------------------------------------------------------------------------------- On Tue, Sep 15, 2020 at 11:20 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
OK thanks for letting me know. Are you running his branch or the master branch?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 15 Sep 2020, at 10:33, Edward Threlfall <ejthrelfall@gmail.com> wrote:
Dear Professor,
You are correct, the example is supposed to be Rayleigh-Benard convection in a 3D box (a temperature-driven flow). Prof. Hossain provided me with a working 2D example and I tried to convert to 3D.
I am now trying to get Nektar++ running in the Visual Studio IDE so I can attempt to find the issue.
Many thanks,
Ed.
On Tue, Sep 15, 2020 at 10:16 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
Having a quick look at your file it seems the problem might be something like a temperature driven flow in a box? Adding a temperature field like this might be the issue since I would have expected this case to run otherwise.
Mohammad (cc’ed) has been working on a branch of the code where we have fixed a number of issues to do with adding a temperature field. @Mohammad: Could you try running Ed’s case and see if it works for you? If so I suggest Ed runs on your branch until we get that merged?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 10 Sep 2020, at 18:04, Edward Threlfall <ejthrelfall@gmail.com> wrote:
This email from ejthrelfall@gmail.com originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.
Dear users,
I have been running simulations of 3D convection in a box with the incompressible Navier-Stokes solver.
I find that there is always an anomaly at one of the points, where the pressure field is zero (it is obvious that this zero value is wrong - see attached image). It might be worth noting that in the image, there are 12 elements with 4 modes per direction each, so 12*4^3 (=768) degrees of freedom, and the anomalous point seems to be number 767 i.e. the final one, so perhaps the last pressure variable is not being updated. The session file used to generate the result shown in the image is attached (takes about 1min to run on my laptop). Also note it is correct that u, v, w, and T are zero at the sample point - just not p!
I have found this issue on a variety of cuboidal and also tetrahedral meshes.
The command to run I used is
mpiexec -np 4 incnavierstokessolver nektar_3d_convection.xml
Can anyone help resolve this?
Many thanks,
Dr Ed Threlfall, UKAEA. <nektar_3d_convection_problem.png><nektar_3d_convection.xml> _______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
<nektar_3d_convection_problem.png>
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
--
Dear Professors, Thanks to Prof. Kumar for the example. I think the issue is still present in this case - it becomes harder to see as the resolution is increased. I have also seen the same issue in a similar 2D convection problem. Looking inside the code, it seems the fixed value is set deliberately because the IncNavierStokesSolver decides that the (Neumann boundary condition) pressure system is singular; it therefore adds a Dirichlet condition at a single point, which corresponds to the fixed zero in my example. To quote a comment in AssemblyMapCG.cpp: // If the system is singular, the process with the maximum // number of BCs will set a Dirichlet vertex to make // system non-singular. Note: we find the process with // maximum boundary regions to ensure we do not try to set // a Dirichlet vertex on a partition with no intersection // with the boundary. The solver certainly crashes if I turn off the singular checking for the pressure. I guess it would be nice to know why this system is singular and whether there is a nicer way of dealing with it than having to fix the pressure at a point. Thanks, Ed. On Tue, Sep 15, 2020 at 11:33 AM Abhishek Kumar <abhishek.kir@gmail.com> wrote:
Hi Edward,
I tried to play with your xml file. I think there was issue with the resolution. I have attached the modified xml file, and the plot of pressure and velocity field. I hope this works.
[image: Screenshot 2020-09-15 at 11.26.11.png] [image: Screenshot 2020-09-15 at 11.26.50.png] With regards Abhishek
---------------------------------------------------------------------------------------
Abhishek Kumar
Assistant Professor (Research)
Centre for Fluid and Complex Systems
Coventry University, Coventry CV15FB
The United Kingdom
---------------------------------------------------------------------------------------
On Tue, Sep 15, 2020 at 11:20 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
OK thanks for letting me know. Are you running his branch or the master branch?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 15 Sep 2020, at 10:33, Edward Threlfall <ejthrelfall@gmail.com> wrote:
Dear Professor,
You are correct, the example is supposed to be Rayleigh-Benard convection in a 3D box (a temperature-driven flow). Prof. Hossain provided me with a working 2D example and I tried to convert to 3D.
I am now trying to get Nektar++ running in the Visual Studio IDE so I can attempt to find the issue.
Many thanks,
Ed.
On Tue, Sep 15, 2020 at 10:16 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
Having a quick look at your file it seems the problem might be something like a temperature driven flow in a box? Adding a temperature field like this might be the issue since I would have expected this case to run otherwise.
Mohammad (cc’ed) has been working on a branch of the code where we have fixed a number of issues to do with adding a temperature field. @Mohammad: Could you try running Ed’s case and see if it works for you? If so I suggest Ed runs on your branch until we get that merged?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 10 Sep 2020, at 18:04, Edward Threlfall <ejthrelfall@gmail.com> wrote:
This email from ejthrelfall@gmail.com originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.
Dear users,
I have been running simulations of 3D convection in a box with the incompressible Navier-Stokes solver.
I find that there is always an anomaly at one of the points, where the pressure field is zero (it is obvious that this zero value is wrong - see attached image). It might be worth noting that in the image, there are 12 elements with 4 modes per direction each, so 12*4^3 (=768) degrees of freedom, and the anomalous point seems to be number 767 i.e. the final one, so perhaps the last pressure variable is not being updated. The session file used to generate the result shown in the image is attached (takes about 1min to run on my laptop). Also note it is correct that u, v, w, and T are zero at the sample point - just not p!
I have found this issue on a variety of cuboidal and also tetrahedral meshes.
The command to run I used is
mpiexec -np 4 incnavierstokessolver nektar_3d_convection.xml
Can anyone help resolve this?
Many thanks,
Dr Ed Threlfall, UKAEA. <nektar_3d_convection_problem.png><nektar_3d_convection.xml> _______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
<nektar_3d_convection_problem.png>
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
--
Dear Edward, In your problem, you set Neumann boundary condition at all sides, which is naturally correct. But it has a consequence on the Poisson solver for pressure. A Poisson equation with all Neumann boundary condition loses "Uniqueness". Therefore a unique solution doesn't exist. Thus the operator can't be inverted, and we call system to be singular. One need to put an extra condition for its uniqueness such as (1) fixing a point in the domain to zero or (2) setting mean to zero. As far as I understand, Nektar++ uses the first option. Now, if you turn off the singularity option than code must crash, since you can't invert the operator. Note that in your case, the pressure is not unique, but $\grad p$ is. You can add any constant to pressure, it still will be a valid solution. With regards Abhishek On Thu, Sep 17, 2020 at 2:41 PM Edward Threlfall <ejthrelfall@gmail.com> wrote:
Dear Professors,
Thanks to Prof. Kumar for the example. I think the issue is still present in this case - it becomes harder to see as the resolution is increased. I have also seen the same issue in a similar 2D convection problem.
Looking inside the code, it seems the fixed value is set deliberately because the IncNavierStokesSolver decides that the (Neumann boundary condition) pressure system is singular; it therefore adds a Dirichlet condition at a single point, which corresponds to the fixed zero in my example. To quote a comment in AssemblyMapCG.cpp:
// If the system is singular, the process with the maximum // number of BCs will set a Dirichlet vertex to make // system non-singular. Note: we find the process with // maximum boundary regions to ensure we do not try to set // a Dirichlet vertex on a partition with no intersection // with the boundary.
The solver certainly crashes if I turn off the singular checking for the pressure.
I guess it would be nice to know why this system is singular and whether there is a nicer way of dealing with it than having to fix the pressure at a point.
Thanks,
Ed.
On Tue, Sep 15, 2020 at 11:33 AM Abhishek Kumar <abhishek.kir@gmail.com> wrote:
Hi Edward,
I tried to play with your xml file. I think there was issue with the resolution. I have attached the modified xml file, and the plot of pressure and velocity field. I hope this works.
[image: Screenshot 2020-09-15 at 11.26.11.png] [image: Screenshot 2020-09-15 at 11.26.50.png] With regards Abhishek
---------------------------------------------------------------------------------------
Abhishek Kumar
Assistant Professor (Research)
Centre for Fluid and Complex Systems
Coventry University, Coventry CV15FB
The United Kingdom
---------------------------------------------------------------------------------------
On Tue, Sep 15, 2020 at 11:20 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
OK thanks for letting me know. Are you running his branch or the master branch?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 15 Sep 2020, at 10:33, Edward Threlfall <ejthrelfall@gmail.com> wrote:
Dear Professor,
You are correct, the example is supposed to be Rayleigh-Benard convection in a 3D box (a temperature-driven flow). Prof. Hossain provided me with a working 2D example and I tried to convert to 3D.
I am now trying to get Nektar++ running in the Visual Studio IDE so I can attempt to find the issue.
Many thanks,
Ed.
On Tue, Sep 15, 2020 at 10:16 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
Having a quick look at your file it seems the problem might be something like a temperature driven flow in a box? Adding a temperature field like this might be the issue since I would have expected this case to run otherwise.
Mohammad (cc’ed) has been working on a branch of the code where we have fixed a number of issues to do with adding a temperature field. @Mohammad: Could you try running Ed’s case and see if it works for you? If so I suggest Ed runs on your branch until we get that merged?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 10 Sep 2020, at 18:04, Edward Threlfall <ejthrelfall@gmail.com> wrote:
This email from ejthrelfall@gmail.com originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.
Dear users,
I have been running simulations of 3D convection in a box with the incompressible Navier-Stokes solver.
I find that there is always an anomaly at one of the points, where the pressure field is zero (it is obvious that this zero value is wrong - see attached image). It might be worth noting that in the image, there are 12 elements with 4 modes per direction each, so 12*4^3 (=768) degrees of freedom, and the anomalous point seems to be number 767 i.e. the final one, so perhaps the last pressure variable is not being updated. The session file used to generate the result shown in the image is attached (takes about 1min to run on my laptop). Also note it is correct that u, v, w, and T are zero at the sample point - just not p!
I have found this issue on a variety of cuboidal and also tetrahedral meshes.
The command to run I used is
mpiexec -np 4 incnavierstokessolver nektar_3d_convection.xml
Can anyone help resolve this?
Many thanks,
Dr Ed Threlfall, UKAEA. <nektar_3d_convection_problem.png><nektar_3d_convection.xml> _______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
<nektar_3d_convection_problem.png>
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
--
--
Hi Edward, Abhishek, This is correct there is an arbitrary constant you can add to p in the case of all Neumann boundary conditions. Just through observation I have seen that setting the singular vertex in the interior of the flow is sometime more robust than setting it on the boundary. You can use the Parameter “SingularVertex” to set it to a different location. If the problem blows up the fixing of this vertex will still be zero and so visually can seem like it is the problem when the key issue is that the simulation has blown up and this could be for a completely different reason. Finally in theory it is possible to set the mean of the field to a constant or zero which is a mathematically more elegant solution. However this couples many of the degrees of freedom and when using a direct solver involves much more coupling than setting a single vertex to zero. Cheers, Spencer. Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/ On 18 Sep 2020, at 22:43, Abhishek Kumar <abhishek.kir@gmail.com<mailto:abhishek.kir@gmail.com>> wrote: Dear Edward, In your problem, you set Neumann boundary condition at all sides, which is naturally correct. But it has a consequence on the Poisson solver for pressure. A Poisson equation with all Neumann boundary condition loses "Uniqueness". Therefore a unique solution doesn't exist. Thus the operator can't be inverted, and we call system to be singular. One need to put an extra condition for its uniqueness such as (1) fixing a point in the domain to zero or (2) setting mean to zero. As far as I understand, Nektar++ uses the first option. Now, if you turn off the singularity option than code must crash, since you can't invert the operator. Note that in your case, the pressure is not unique, but $\grad p$ is. You can add any constant to pressure, it still will be a valid solution. With regards Abhishek On Thu, Sep 17, 2020 at 2:41 PM Edward Threlfall <ejthrelfall@gmail.com<mailto:ejthrelfall@gmail.com>> wrote: Dear Professors, Thanks to Prof. Kumar for the example. I think the issue is still present in this case - it becomes harder to see as the resolution is increased. I have also seen the same issue in a similar 2D convection problem. Looking inside the code, it seems the fixed value is set deliberately because the IncNavierStokesSolver decides that the (Neumann boundary condition) pressure system is singular; it therefore adds a Dirichlet condition at a single point, which corresponds to the fixed zero in my example. To quote a comment in AssemblyMapCG.cpp: // If the system is singular, the process with the maximum // number of BCs will set a Dirichlet vertex to make // system non-singular. Note: we find the process with // maximum boundary regions to ensure we do not try to set // a Dirichlet vertex on a partition with no intersection // with the boundary. The solver certainly crashes if I turn off the singular checking for the pressure. I guess it would be nice to know why this system is singular and whether there is a nicer way of dealing with it than having to fix the pressure at a point. Thanks, Ed. On Tue, Sep 15, 2020 at 11:33 AM Abhishek Kumar <abhishek.kir@gmail.com<mailto:abhishek.kir@gmail.com>> wrote: Hi Edward, I tried to play with your xml file. I think there was issue with the resolution. I have attached the modified xml file, and the plot of pressure and velocity field. I hope this works. <Screenshot 2020-09-15 at 11.26.11.png> <Screenshot 2020-09-15 at 11.26.50.png> With regards Abhishek --------------------------------------------------------------------------------------- Abhishek Kumar Assistant Professor (Research) Centre for Fluid and Complex Systems Coventry University, Coventry CV15FB The United Kingdom --------------------------------------------------------------------------------------- On Tue, Sep 15, 2020 at 11:20 AM Sherwin, Spencer J <s.sherwin@imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk>> wrote: Hi Ed, OK thanks for letting me know. Are you running his branch or the master branch? Cheers, Spencer. Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/ On 15 Sep 2020, at 10:33, Edward Threlfall <ejthrelfall@gmail.com<mailto:ejthrelfall@gmail.com>> wrote: Dear Professor, You are correct, the example is supposed to be Rayleigh-Benard convection in a 3D box (a temperature-driven flow). Prof. Hossain provided me with a working 2D example and I tried to convert to 3D. I am now trying to get Nektar++ running in the Visual Studio IDE so I can attempt to find the issue. Many thanks, Ed. On Tue, Sep 15, 2020 at 10:16 AM Sherwin, Spencer J <s.sherwin@imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk>> wrote: Hi Ed, Having a quick look at your file it seems the problem might be something like a temperature driven flow in a box? Adding a temperature field like this might be the issue since I would have expected this case to run otherwise. Mohammad (cc’ed) has been working on a branch of the code where we have fixed a number of issues to do with adding a temperature field. @Mohammad: Could you try running Ed’s case and see if it works for you? If so I suggest Ed runs on your branch until we get that merged? Cheers, Spencer. Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/ On 10 Sep 2020, at 18:04, Edward Threlfall <ejthrelfall@gmail.com<mailto:ejthrelfall@gmail.com>> wrote: This email from ejthrelfall@gmail.com<mailto:ejthrelfall@gmail.com> originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list<https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address. Dear users, I have been running simulations of 3D convection in a box with the incompressible Navier-Stokes solver. I find that there is always an anomaly at one of the points, where the pressure field is zero (it is obvious that this zero value is wrong - see attached image). It might be worth noting that in the image, there are 12 elements with 4 modes per direction each, so 12*4^3 (=768) degrees of freedom, and the anomalous point seems to be number 767 i.e. the final one, so perhaps the last pressure variable is not being updated. The session file used to generate the result shown in the image is attached (takes about 1min to run on my laptop). Also note it is correct that u, v, w, and T are zero at the sample point - just not p! I have found this issue on a variety of cuboidal and also tetrahedral meshes. The command to run I used is mpiexec -np 4 incnavierstokessolver nektar_3d_convection.xml Can anyone help resolve this? Many thanks, Dr Ed Threlfall, UKAEA. <nektar_3d_convection_problem.png><nektar_3d_convection.xml>_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk<mailto:Nektar-users@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users <nektar_3d_convection_problem.png> _______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk<mailto:Nektar-users@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users -- --
Hi Spencer, Thanks for your comments. It's good to know that there is a possibility to adjust the location of SingularVertex. With regards Abhishek On Tue, Sep 22, 2020 at 9:32 AM Sherwin, Spencer J <s.sherwin@imperial.ac.uk> wrote:
Hi Edward, Abhishek,
This is correct there is an arbitrary constant you can add to p in the case of all Neumann boundary conditions. Just through observation I have seen that setting the singular vertex in the interior of the flow is sometime more robust than setting it on the boundary. You can use the Parameter “SingularVertex” to set it to a different location.
If the problem blows up the fixing of this vertex will still be zero and so visually can seem like it is the problem when the key issue is that the simulation has blown up and this could be for a completely different reason.
Finally in theory it is possible to set the mean of the field to a constant or zero which is a mathematically more elegant solution. However this couples many of the degrees of freedom and when using a direct solver involves much more coupling than setting a single vertex to zero.
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 18 Sep 2020, at 22:43, Abhishek Kumar <abhishek.kir@gmail.com> wrote:
Dear Edward,
In your problem, you set Neumann boundary condition at all sides, which is naturally correct. But it has a consequence on the Poisson solver for pressure.
A Poisson equation with all Neumann boundary condition loses "Uniqueness". Therefore a unique solution doesn't exist. Thus the operator can't be inverted, and we call system to be singular. One need to put an extra condition for its uniqueness such as (1) fixing a point in the domain to zero or (2) setting mean to zero. As far as I understand, Nektar++ uses the first option.
Now, if you turn off the singularity option than code must crash, since you can't invert the operator.
Note that in your case, the pressure is not unique, but $\grad p$ is. You can add any constant to pressure, it still will be a valid solution.
With regards Abhishek
On Thu, Sep 17, 2020 at 2:41 PM Edward Threlfall <ejthrelfall@gmail.com> wrote:
Dear Professors,
Thanks to Prof. Kumar for the example. I think the issue is still present in this case - it becomes harder to see as the resolution is increased. I have also seen the same issue in a similar 2D convection problem.
Looking inside the code, it seems the fixed value is set deliberately because the IncNavierStokesSolver decides that the (Neumann boundary condition) pressure system is singular; it therefore adds a Dirichlet condition at a single point, which corresponds to the fixed zero in my example. To quote a comment in AssemblyMapCG.cpp:
// If the system is singular, the process with the maximum // number of BCs will set a Dirichlet vertex to make // system non-singular. Note: we find the process with // maximum boundary regions to ensure we do not try to set // a Dirichlet vertex on a partition with no intersection // with the boundary.
The solver certainly crashes if I turn off the singular checking for the pressure.
I guess it would be nice to know why this system is singular and whether there is a nicer way of dealing with it than having to fix the pressure at a point.
Thanks,
Ed.
On Tue, Sep 15, 2020 at 11:33 AM Abhishek Kumar <abhishek.kir@gmail.com> wrote:
Hi Edward,
I tried to play with your xml file. I think there was issue with the resolution. I have attached the modified xml file, and the plot of pressure and velocity field. I hope this works.
<Screenshot 2020-09-15 at 11.26.11.png> <Screenshot 2020-09-15 at 11.26.50.png> With regards Abhishek
--------------------------------------------------------------------------------------- Abhishek Kumar Assistant Professor (Research) Centre for Fluid and Complex Systems Coventry University, Coventry CV15FB The United Kingdom
---------------------------------------------------------------------------------------
On Tue, Sep 15, 2020 at 11:20 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
OK thanks for letting me know. Are you running his branch or the master branch?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 15 Sep 2020, at 10:33, Edward Threlfall <ejthrelfall@gmail.com> wrote:
Dear Professor,
You are correct, the example is supposed to be Rayleigh-Benard convection in a 3D box (a temperature-driven flow). Prof. Hossain provided me with a working 2D example and I tried to convert to 3D.
I am now trying to get Nektar++ running in the Visual Studio IDE so I can attempt to find the issue.
Many thanks,
Ed.
On Tue, Sep 15, 2020 at 10:16 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
Having a quick look at your file it seems the problem might be something like a temperature driven flow in a box? Adding a temperature field like this might be the issue since I would have expected this case to run otherwise.
Mohammad (cc’ed) has been working on a branch of the code where we have fixed a number of issues to do with adding a temperature field. @Mohammad: Could you try running Ed’s case and see if it works for you? If so I suggest Ed runs on your branch until we get that merged?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 10 Sep 2020, at 18:04, Edward Threlfall <ejthrelfall@gmail.com> wrote:
This email from ejthrelfall@gmail.com originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.
Dear users,
I have been running simulations of 3D convection in a box with the incompressible Navier-Stokes solver.
I find that there is always an anomaly at one of the points, where the pressure field is zero (it is obvious that this zero value is wrong - see attached image). It might be worth noting that in the image, there are 12 elements with 4 modes per direction each, so 12*4^3 (=768) degrees of freedom, and the anomalous point seems to be number 767 i.e. the final one, so perhaps the last pressure variable is not being updated. The session file used to generate the result shown in the image is attached (takes about 1min to run on my laptop). Also note it is correct that u, v, w, and T are zero at the sample point - just not p!
I have found this issue on a variety of cuboidal and also tetrahedral meshes.
The command to run I used is
mpiexec -np 4 incnavierstokessolver nektar_3d_convection.xml
Can anyone help resolve this?
Many thanks,
Dr Ed Threlfall, UKAEA. <nektar_3d_convection_problem.png><nektar_3d_convection.xml> _______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
<nektar_3d_convection_problem.png>
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
--
--
-- --------------------------------------------------------------------------------------- Abhishek Kumar Assistant Professor (Research) Centre for Fluid and Complex Systems Coventry University, Coventry CV15FB The United Kingdom Phone: +44 24 7765 9150 Mobile: +44 7464026494 ---------------------------------------------------------------------------------------
Dear Professors, Many thanks for the comments. It does seem a little unexpected that it is necessary to decouple one of the pressure degrees of freedom (i.e. the singular vertex) completely in order to run the calculation (speaking as something of a newcomer to fluids). One could imagine updating the value of p at this point by using neighbouring values, but I guess that might create issues with the parallel implementation. For the problem I am running, I guess also that I could set a Dirichlet p=0 condition on the T=0 surface and get the same physics (the velocity is constrained zero there by the no-slip condition, so p should be proportional to T). Thanks, Ed. On Thu, Sep 24, 2020 at 11:22 AM Abhishek Kumar <abhishek.kir@gmail.com> wrote:
Hi Spencer,
Thanks for your comments.
It's good to know that there is a possibility to adjust the location of SingularVertex.
With regards Abhishek
On Tue, Sep 22, 2020 at 9:32 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Edward, Abhishek,
This is correct there is an arbitrary constant you can add to p in the case of all Neumann boundary conditions. Just through observation I have seen that setting the singular vertex in the interior of the flow is sometime more robust than setting it on the boundary. You can use the Parameter “SingularVertex” to set it to a different location.
If the problem blows up the fixing of this vertex will still be zero and so visually can seem like it is the problem when the key issue is that the simulation has blown up and this could be for a completely different reason.
Finally in theory it is possible to set the mean of the field to a constant or zero which is a mathematically more elegant solution. However this couples many of the degrees of freedom and when using a direct solver involves much more coupling than setting a single vertex to zero.
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 18 Sep 2020, at 22:43, Abhishek Kumar <abhishek.kir@gmail.com> wrote:
Dear Edward,
In your problem, you set Neumann boundary condition at all sides, which is naturally correct. But it has a consequence on the Poisson solver for pressure.
A Poisson equation with all Neumann boundary condition loses "Uniqueness". Therefore a unique solution doesn't exist. Thus the operator can't be inverted, and we call system to be singular. One need to put an extra condition for its uniqueness such as (1) fixing a point in the domain to zero or (2) setting mean to zero. As far as I understand, Nektar++ uses the first option.
Now, if you turn off the singularity option than code must crash, since you can't invert the operator.
Note that in your case, the pressure is not unique, but $\grad p$ is. You can add any constant to pressure, it still will be a valid solution.
With regards Abhishek
On Thu, Sep 17, 2020 at 2:41 PM Edward Threlfall <ejthrelfall@gmail.com> wrote:
Dear Professors,
Thanks to Prof. Kumar for the example. I think the issue is still present in this case - it becomes harder to see as the resolution is increased. I have also seen the same issue in a similar 2D convection problem.
Looking inside the code, it seems the fixed value is set deliberately because the IncNavierStokesSolver decides that the (Neumann boundary condition) pressure system is singular; it therefore adds a Dirichlet condition at a single point, which corresponds to the fixed zero in my example. To quote a comment in AssemblyMapCG.cpp:
// If the system is singular, the process with the maximum // number of BCs will set a Dirichlet vertex to make // system non-singular. Note: we find the process with // maximum boundary regions to ensure we do not try to set // a Dirichlet vertex on a partition with no intersection // with the boundary.
The solver certainly crashes if I turn off the singular checking for the pressure.
I guess it would be nice to know why this system is singular and whether there is a nicer way of dealing with it than having to fix the pressure at a point.
Thanks,
Ed.
On Tue, Sep 15, 2020 at 11:33 AM Abhishek Kumar <abhishek.kir@gmail.com> wrote:
Hi Edward,
I tried to play with your xml file. I think there was issue with the resolution. I have attached the modified xml file, and the plot of pressure and velocity field. I hope this works.
<Screenshot 2020-09-15 at 11.26.11.png> <Screenshot 2020-09-15 at 11.26.50.png> With regards Abhishek
--------------------------------------------------------------------------------------- Abhishek Kumar Assistant Professor (Research) Centre for Fluid and Complex Systems Coventry University, Coventry CV15FB The United Kingdom
---------------------------------------------------------------------------------------
On Tue, Sep 15, 2020 at 11:20 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
OK thanks for letting me know. Are you running his branch or the master branch?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 15 Sep 2020, at 10:33, Edward Threlfall <ejthrelfall@gmail.com> wrote:
Dear Professor,
You are correct, the example is supposed to be Rayleigh-Benard convection in a 3D box (a temperature-driven flow). Prof. Hossain provided me with a working 2D example and I tried to convert to 3D.
I am now trying to get Nektar++ running in the Visual Studio IDE so I can attempt to find the issue.
Many thanks,
Ed.
On Tue, Sep 15, 2020 at 10:16 AM Sherwin, Spencer J < s.sherwin@imperial.ac.uk> wrote:
Hi Ed,
Having a quick look at your file it seems the problem might be something like a temperature driven flow in a box? Adding a temperature field like this might be the issue since I would have expected this case to run otherwise.
Mohammad (cc’ed) has been working on a branch of the code where we have fixed a number of issues to do with adding a temperature field. @Mohammad: Could you try running Ed’s case and see if it works for you? If so I suggest Ed runs on your branch until we get that merged?
Cheers, Spencer.
Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, South Kensington Campus, Imperial College London, SW7 2AZ, UK Phone: +44 (0)20 7594 5052 http://www.imperial.ac.uk/people/s.sherwin/
On 10 Sep 2020, at 18:04, Edward Threlfall <ejthrelfall@gmail.com> wrote:
This email from ejthrelfall@gmail.com originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.
Dear users,
I have been running simulations of 3D convection in a box with the incompressible Navier-Stokes solver.
I find that there is always an anomaly at one of the points, where the pressure field is zero (it is obvious that this zero value is wrong - see attached image). It might be worth noting that in the image, there are 12 elements with 4 modes per direction each, so 12*4^3 (=768) degrees of freedom, and the anomalous point seems to be number 767 i.e. the final one, so perhaps the last pressure variable is not being updated. The session file used to generate the result shown in the image is attached (takes about 1min to run on my laptop). Also note it is correct that u, v, w, and T are zero at the sample point - just not p!
I have found this issue on a variety of cuboidal and also tetrahedral meshes.
The command to run I used is
mpiexec -np 4 incnavierstokessolver nektar_3d_convection.xml
Can anyone help resolve this?
Many thanks,
Dr Ed Threlfall, UKAEA. <nektar_3d_convection_problem.png><nektar_3d_convection.xml> _______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
<nektar_3d_convection_problem.png>
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
--
--
--
---------------------------------------------------------------------------------------
Abhishek Kumar
Assistant Professor (Research)
Centre for Fluid and Complex Systems
Coventry University, Coventry CV15FB
The United Kingdom
Phone: +44 24 7765 9150
Mobile: +44 7464026494
---------------------------------------------------------------------------------------
participants (3)
-
Abhishek Kumar
-
Edward Threlfall
-
Sherwin, Spencer J