GLL points per element along each direction

[Jundi He]

Hi Neks,

I've recently run some test cases using the Nek5000, and I have some confusions about the solver:

1. In file "SIZE", lx1 is defined as the "GLL points per element along each direction", does it represent the mesh refinement? I have a simulation, it works well with lx1=2, but when we increase lx1 to 4 or 6, the simulation will diverge quickly. 

2. When we use lx1=8, each element is divided into 8 nodes in each direction, but such division is not uniform within each element: the division is finer at the edge of each element, does anyone know the reason for this? 

3. In [GENERAL] section of file xxx.par, we need to define the polynomialOrder, is this the order of the spatial discretisation in the solver? If I don't define this value, what is the default value? 

4. Are these two values, lx1 in file SIZE and polynomialOrder in file xxx.par relevant to each other? 

Regards!

Jundi

[Emmanuel Gillyns]

Hi,

The solution and data are represented in terms of N th-order tensor-product polynomials within each elements. The non-uniform spacial discretisation that you see within each element is the GLL (Gauss-Lobatto Legendre) grid, if you want to better understand the reason for this choice in nek5000, I suggest you read the following book :

"High-Order Methods for Incompressible Fluid Flow by M. O. Deville, P. F. Fischer, E.H.Mund"

Examples such as trubChannel use lx1=8, which is the order that usually provides the best behaviour (from low values to lx1=8 increases accuracy of the solution, but higher values gives deminishing return in terms of computational cost vs accuracy). Each case could be different of course, but a crash when increasing lx1 is not what I would expect to see. Can you give more info on the case you are trying to run ?

Sincerely,

Emmanuel

[Jundi He]

Hi Emmanuel,

Thanks for the explanation. I understand the sub-divided grids within each element represent the polynomial order. I am testing a simple flow case, it runs well when lx1=2, but when we increase lx1 to 8 (I believe this represents using the 7th order scheme), it diverges quickly. The flow is a simple jet flow, and this is its mesh:

There is an inlet, an outlet, and the rest faces are walls. The .re2, .par, .usr, SIZE files are attached. The hydraulic diameter of the inlet nozzle is 0.01m, and the inlet velocity is 200m/s. Could you simply have a look at the setup files and see if you can spot any problem that might cause the divergence? Many thanks for the time. 

Regards!

Jundi

 fi.par

 fi.re2

 fi.usr

 SIZE

--
You received this message because you are subscribed to a topic in the Google Groups "Nek5000" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nek5000/KjQEvutrQbg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nek5000+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nek5000/5fbf76fa-36c5-4ef8-9fa5-622cab960f0dn%40googlegroups.com.

--

Dr Jundi He

Research associate

Heat, Flow and Turbulence Research Group

Department of Mechanical Engineering

The University of Sheffield

E201, Mappin Building

Phone: +44(0)7521624203

Email: jund...@sheffield.ac.uk

[Emmanuel Gillyns]

Hi,

Your case files do not compile on my computer. How did you mesh it ?

Best,

Emmanuel

[Jundi He]

Hi Emmanuel,

I meshed it using Gmsh4, the .geo file is attached. Before running "makenek", I firstly ran "genmap", with a .ma2 file generated. They are attached, could you try again, thanks for your time. 

Regards!

Jundi

To view this discussion on the web visit https://groups.google.com/d/msgid/nek5000/4022605a-c237-4fee-961b-d8c4582b6873n%40googlegroups.com.

[Emmanuel Gillyns]

Hi,

After reducing the mesh resolution (in gmsh and in SIZE file), I was able to compile it (could be because I'm testing on my low power laptop). but I could not properly run it with such low resolution.

Also I don't have much experience with the "lowMachNS" solver, it is possible that it requires tighter tolerence in the "residualTol" for each quantity, but I could be wrong.

I hope someone else might help you better,

Emmanuel

[Jundi He]

Hi Emmanuel,

Thanks again for your time and your suggestion! I'll try to simplify the flow and run more test cases. 

Regards!

Jundi

[Haochen Li]

Jundi,

It might be caused by the reflection at the outlet boundary condition. You can try turb_outflow or dongOutflow. An example is available at  https://github.com/Nek5000/NekExamples/blob/master/turbJet/turbJet/turbJet.usr

Thanks,

Haochen

You received this message because you are subscribed to the Google Groups "Nek5000" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nek5000+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nek5000/d53cf82e-6283-4f90-8cc8-cacd16c7e044n%40googlegroups.com.

[Yuan, Haomin]

I will also suggest making your outlet longer. 

Get Outlook for iOS

---

From: nek...@googlegroups.com <nek...@googlegroups.com> on behalf of Haochen Li <haoch...@gmail.com>
Sent: Friday, July 9, 2021 12:54:22 PM
To: Jundi He <jund...@sheffield.ac.uk>
Cc: Nek5000 <nek...@googlegroups.com>
Subject: Re: [nek5000] Re: GLL points per element along each direction

 

To view this discussion on the web visit https://groups.google.com/d/msgid/nek5000/CAMR%2BYSNLnApTr_%3D%3DJKHzEDD9SPZiQfQc%3Db0ebk7190Kud%2BA-pA%40mail.gmail.com.

[Jundi He]

Hi,

Thanks for pointing this out and the useful suggestions, I'll try and test this. 

Regards!

Jundi