May 2023 - Nektar-users - imperial.ac.uk

Modifying 2-D mesh in Gmsh
by Ma, Ting-Hsuan 10 May '23

10 May '23

******************* 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. ******************* Hi, I would recommend using the script method in Gmsh to add in the physical groups for 1d elements. A lot of time they are in incremental numbers, so it is easy to iterate through them. Below I'll provide the python code I wrote for my own use. I will emphasize here that you should double check the curves are set up in incremental numbers before applying the codes below. ##### Below this section is setting parameters for NekMesh ##### ## Note that this could be done in Gmsh, but it's faster to automate it ## Note that Curve loop will need to be defined after all physical groups like # inlet, outlet, top, and bottom boundary. If this is not done in order, # mesh verticies will exhibit a no-slip boundary condition onto the interior # flow. The order is paramount! loopRange = range(1,result.shape[0]) botRange = range(0,rows.shape[0]-1) outRange = range(rows.shape[0]-1, (rows.shape[0]+inlet.shape[0])) topRange = range((rows.shape[0]+inlet.shape[0]), (rows.shape[0]+inlet.shape[0]+top.shape[0])-1) inRange = range((rows.shape[0]+inlet.shape[0]+top.shape[0])-1, result.shape[0]) idx = loopRange[-1]+2 # define physical groups for rest of the assignment ## Bottom Boundary print("//+") print('Physical Curve("Bottom", %d) = {' % (int(idx)), end= '') for i in botRange: if i == botRange[-1]: print("%d" % (int(i)+1), end = '};\n') print("//+") else: print("%d," % (int(i)+1), end = '') ## Outlet print('Physical Curve("Outlet", %d) = {' % (int(idx+1)), end= '') for i in outRange: if i == outRange[-1]: print("%d" % (int(i)+1), end = '};\n') print("//+") else: print("%d," % (int(i)+1), end = '') ## Top Boundary print('Physical Curve("Top", %d) = {' % (int(idx+2)), end= '') for i in topRange: if i == topRange[-1]: print("%d" % (int(i)+1), end = '};\n') print("//+") else: print("%d," % (int(i)+1), end = '') ## Inlet print('Physical Curve("Inlet", %d) = {' % (int(idx+3)), end= '') for i in inRange: if i == inRange[-1]: print("%d" % (int(i)+1), end = '};\n') print("//+") else: print("%d," % (int(i)+1), end = '') # Physical Groups print("Curve Loop(1) = {", end="") for i in loopRange: print("%d," % (int(i)), end="") if i == loopRange[-1]: print("%d" % (int(i)+1), end="};\n") print("//+") print("Plane Surface(1) = {1};") print("//+") print('Physical Surface("Fluid", %d) = {1};' % (int(idx+4)) )

2 2

Re: [Nektar-users] Turbulent cylinder flow simulation errors
by Ehsan Asgari 09 May '23

09 May '23

Thank you for your kind reply. I appreciate it. The problem is that I am using another package, GridPro, and when I load my 2-D mesh (a boundary layer flow) into Gmsh, the boundaries are not recognized. I have tried several ways to fix this but no success yet. Kind regards syavash On Tue, May 9, 2023, 19:21 Matt Duran <matt.duran60(a)gmail.com> wrote: > I have used mostly gmsh. Without seeing your exact details, make sure you > are defining your boundary conditions and the domain in gmsh first in the > geometry file. Then once you have specified the boundary conditions and the > domain you can export the mesh to use in Nektar++. I'm sending you a text > file where I have basically defined my boundary conditions and domain in a > gmsh file. > > The 'Physical Line(1)' is my inlet which consists of a few curves, > 'Physical Line(2)' is the outlet and so on. > Physical Surface(0) is the domain, you have to manually specify every > surface that makes up the domain. > > If you still have issues I can try to assist you. Or we could perhaps talk > on zoom if I think I can help with your issue. > > Matt > > > > > > > On Tue, May 9, 2023 at 11:26 AM Ehsan Asgari <eh.asgari(a)gmail.com> wrote: > >> No worries. I hope you will get satisfactory results. >> I had a question though, how did you generate your 2-D mesh? Did you use >> Gmsh or other commercial packages? Because I >> have difficulty converting my 2-D mesh to Nektar format. >> >> syavash >> >> On Tue, May 9, 2023, 18:47 Matt Duran <matt.duran60(a)gmail.com> wrote: >> >>> Hello Syavash, >>> >>> >>> That is very useful to know, 60% overprediction of drag certainly could >>> fit with some of the strange results I'm experiencing. I will attempt to >>> recreate some of the 3D results you have suggested to me from Jiang et al >>> then. >>> >>> I appreciate the help, >>> Matt >>> >>> On Tue, May 9, 2023 at 2:50 AM Ehsan Asgari <eh.asgari(a)gmail.com> wrote: >>> >>>> Hi Matt >>>> >>>> I noticed you are simulating the benchmark cylindrical flow at Re=3900. >>>> As you may see in literature, the flow and the wake at this Re are highly >>>> 3-D and 2-D representative will lead to overprediction of drag, as high as >>>> 60%. So, I would not expect to have a physical vortex shedding with this >>>> 2-D setup. >>>> >>>> Kind regards >>>> syavash >>>> >>>> >>>> >>>> On Tue, May 9, 2023, 04:09 Lahooti, Mohsen <m.lahooti(a)imperial.ac.uk> >>>> wrote: >>>> >>>>> Hi Matt, >>>>> >>>>> The vortices certainly look odd. But I wouldn't expect that much of >>>>> symmetry at this Re either. >>>>> >>>>> Nevertheless, I noticed in your condition file no expansions are set. >>>>> This means you are using the default expansion in the mesh file? I would >>>>> explicitly set the expansion in the condition file. >>>>> Also, I would suggest using high order out flow for the outlet boundary >>>>> >>>>> From your plots, the inlet and sides are also too close. Particularly >>>>> the side walls can affect your vortex structure >>>>> >>>>> After your 2D is sorted out, you also might want to try 3DH1D too >>>>> >>>>> We have a tutorial for flow over cylinder ( >>>>> https://www.nektar.info/notebooks//tutorials/basics-incns-solver/) >>>>> that might be helpful. It is quite through, and you might find it helpful >>>>> >>>>> Hope this helped >>>>> >>>>> Cheers >>>>> Mohsen >>>>> >>>>> Mohsen Lahooti >>>>> Lecturer in Fluid-Structure Interaction >>>>> Mechanical Engineering >>>>> >>>>> Newcastle University >>>>> School of Engineering >>>>> Stephenson Building >>>>> Newcastle upon Tyne >>>>> NE1 7RU >>>>> UK >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* nektar-users-bounces(a)imperial.ac.uk < >>>>> nektar-users-bounces(a)imperial.ac.uk> on behalf of Matt Duran < >>>>> matt.duran60(a)gmail.com> >>>>> *Sent:* Tuesday, May 9, 2023 1:24:44 AM >>>>> *To:* nektar-users <nektar-users(a)imperial.ac.uk> >>>>> *Subject:* [Nektar-users] Turbulent cylinder flow simulation errors >>>>> >>>>> >>>>> This email from matt.duran60(a)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. >>>>> >>>>> >>>>> >>>>> Hello Nektar++ users, >>>>> >>>>> I have been experiencing unusual results while simulating cylinder >>>>> flow with the incompressible Navier-Stokes Solver. When running the >>>>> simulation at higher Reynolds numbers such as Re = 3900, the flow does not >>>>> appear as would be expected. The early wake looks too unsymmetric, with >>>>> one of the first vortex growing to an unusually large size before >>>>> shedding. After running the simulation for a long period of time the >>>>> vortices still look quite unusual, lacking the symmetry that would be >>>>> expected in the vortex street. >>>>> >>>>> In trying to solve this issue I have checked the turbulent length >>>>> scale and ensured I have enough mesh resolution. I also have used a small >>>>> time scale of 0.0001. >>>>> >>>>> >>>>> >>>>> I was wondering whether anyone had advice on what I might be doing >>>>> wrong or how I may attempt to fix the issue. I have included some of the >>>>> results of the vorticity contours and the .xml conditions in hopes someone >>>>> recognizes why the simulation is not behaving as expected. >>>>> >>>>> >>>>> Thank you, >>>>> >>>>> Matt Duran >>>>> >>>>> PhD student >>>>> >>>>> University of Central Florida >>>>> >>>>> >>>>> _______________________________________________ >>>>> Nektar-users mailing list >>>>> Nektar-users(a)imperial.ac.uk >>>>> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users >>>>> >>>>

1 0

Modifying 2-D mesh in Gmsh
by Ehsan Asgari 09 May '23

09 May '23

******************* 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 All When I import a 3-D mesh in Gmsh, it can recognise 2-D surfaces and I label them as physical groups for Nektar to be used as boundary conditions. However, in case of a 2-D mesh, Gmsh cannot recognise 1-D line elements so I cannot label them to use as boundary conditions in Nektar. How can I get these 1-D elements recognised in Gmsh? Kind regards syavash

2 3

Turbulent cylinder flow simulation errors
by Matt Duran 09 May '23

09 May '23

******************* 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. ******************* Hello Nektar++ users, I have been experiencing unusual results while simulating cylinder flow with the incompressible Navier-Stokes Solver. When running the simulation at higher Reynolds numbers such as Re = 3900, the flow does not appear as would be expected. The early wake looks too unsymmetric, with one of the first vortex growing to an unusually large size before shedding. After running the simulation for a long period of time the vortices still look quite unusual, lacking the symmetry that would be expected in the vortex street. In trying to solve this issue I have checked the turbulent length scale and ensured I have enough mesh resolution. I also have used a small time scale of 0.0001. I was wondering whether anyone had advice on what I might be doing wrong or how I may attempt to fix the issue. I have included some of the results of the vorticity contours and the .xml conditions in hopes someone recognizes why the simulation is not behaving as expected. Thank you, Matt Duran PhD student University of Central Florida

3 3

Some issues on Nektar++ calculations
by duzz＠pku.edu.cn 06 May '23

06 May '23

******************* 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 Nektar++ users, I am writing to report a problem that I am currently experiencing with Nektar++ that I am using. I am a PhD student at Peking University and I am currently working on a computational project involving a quasi-3D separated flow over a flat plate. The initial condition is a pre-computed instantaneous flow field file (format .chk), where HomModesZ is 32. I am running the calculation with HomModesZ of 128 on a supercomputer with 16 nodes and a total of 896 cores. The npz is set to 64. After the calculation is completed, the instantaneous flow field files are generated with 896 fld files. However, two of the fld files are problematic. Specifically, the fld file with the number P0000171 is missing the <NEKTAR> tag at the beginning and the content is disordered. The fld file with the number P0000195 is an empty file. Both prevent me from converting the entire ".chk" folder to the .plt file format using the FieldConvert command. This issue has occurred multiple times in several computations, so it does not appear to be an isolated incident. The disk space usage during the computation did not reach full capacity, so I suspect there may be a bug in the calculation process. Additionally, in the similar calculations about 2 months ago, I didn’t find problems. It means that there’s probably nothing wrong with my case. Could you please provide any suggestions on how to resolve this issue? Thank you for your attention to this matter. Best regards, Du Zengzhi

3 2