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
--
