- Nektar-users - imperial.ac.uk

Re: [Nektar-users] Parallel transposition not implemented yet for 3D-Homo-2D approach
by Asim Onder 17 Mar '16

17 Mar '16

Hi Spencer, Douglas, Thanks to your suggestions I managed to get the turbulent regime for the oscillatory channel flow. I have now completed the DNS study for one case, and built up a large database with checkpoint (*chk) files. I would like to calculate turbulent statistics using this database, especially for second order terms, e.g. Reynolds stresses and turbulent dissipation, and third order terms, e.g. turbulent diffusion terms. However, I am a little bit confused how I could achieve this. I would appreciate if you could give some hints about the following: 1. The only way I could think of to calculate turbulent statistics is to write a simple bash script to iterate over chk files, and apply various existing/extended FieldConvert operations on individual chk files. This would require some additional storage to store the intermediate steps, and therefore would be a bit cumbersome. Would it be any simpler way directly doing this directly in Nektar++? 2. I have one homogeneous direction, for which I used Fourier expansions. I would like to apply spatial averaging over this homogeneous direction. Does Nektar++ already contain such functionality? 3. I want to use 'wss' in Fieldconvert module to calculate wall shear stress. However, it returns segmentation fault. Any ideas why it could be? 4. I was wondering if there is any introductory document for basic programming in Nektar++. User guide does not contain information about programming. It would be nice to have some additional information to Doxygen documentation. Thank you very much in advance for your feedback. Cheers, Asim On 02/15/2016 11:59 PM, Serson, Douglas wrote: > Hi Asim, > > As Spencer mentioned, svv can help in stabilizing your solution. You can find information on how to set it up in the user guide (pages 92-93), but basically all you need to do is use: > <I PROPERTY="SpectralVanishingViscosity" VALUE="True"/> > You can also tune it by setting the parameters SVVCutoffRatio and SVVDiffCoeff, but I would suggest starting with the default parameters. > > Also, you can use the parameter IO_CFLSteps to output the CFL number. This way you can check if the time step you are using is appropriate. > > Cheers, > Douglas > > From: Sherwin, Spencer J > Sent: 14 February 2016 19:46 > To: ceeao > Cc: nektar-users; Serson, Douglas; Moxey, David > Subject: Re: [Nektar-users] Parallel transposition not implemented yet for 3D-Homo-2D approach > > Hi Asim, > > > Getting a flow through transition is very challenging since there is a strong localisation of shear and this can lead to aliasing issues which can then cause instabilities. > > > Both Douglas and Dave have experienced this with recent simulations so I am cc’ing them to make some suggestions. I would be inclined to be using spectralhpdealiasing and svv. Hopefully Douglas can send you an example of how to switch this on. > > > Cheers, > Spencer. > > > > On 11 Feb 2016, at 10:32, ceeao<ceeao(a)nus.edu.sg> wrote: > > > > Hi Spencer, Nektar-Users, > > I followed the suggestion and coarsened the grid a bit. This way it worked impressively fast, but the flow is stable and remains laminar, as I didn't add any perturbations. > > I need to kick the transition to have turbulence. If I add white noise, even very low magnitude, conjugate gradient solver blows up again. I also tried adding some sinusoidal perturbations to boundary conditions, and again had troubles with CG. I don't really get CG's extreme sensitivity to perturbations. > > Any suggestion is much appreciated. Thanks in advance. > > Cheers, > Asim > > On 02/08/2016 04:48 PM, Sherwin, Spencer J wrote: > HI Asim, > > > How many parallel cores are you running on. Sometime starting up these flows can be tricky especially if you are immediately jumping to a high Reynolds number. Have you tried first starting the flow at a Lower Reynolds number? > > > Also 100 x 200 is quite a few elements in the x-y plane. Remember the polynomial order adds in more points on top of the mesh discretisation. > > > I would perhaps recommend trying a smaller mesh to see how that goes first. Actually I note there is a file called TurbChFl_3D1H.xml in the > > > ~/Nektar/Solvers/IncNavierStokesSolver/Examples directory which might be worth looking at. I think this was a mesh used in Ale Bolis’ thesis which you can find under: > > > http://wwwf.imperial.ac.uk/ssherw/spectralhp/papers/PhDThesis/Bolis_Thesis.… > > > Cheers, > Spencer. > > > > On 1 Feb 2016, at 07:01, ceeao<ceeao(a)nus.edu.sg> wrote: > > > > Hi Spencer, > > Thank you for the quick reply and suggestion. I switched indeed to 3D homo 1D case and this time I have problems with the divergence of linear solvers. > > I refined the grid in the channel flow example to 100x200x64 in x-y-z directions, and left everything else the same. When I employ the default global system solver "IterativeStaticCond" with this setup, I get divergence: "Exceeded maximum number of iterations (5000)". I checked the initial fields and mesh in Paraview, everything seems to be normal. I also tried the "LowEnergyBlock" preconditioner, and apparently this one is valid only in sheer 3D cases. > > My knowledge in iterative solvers for hp-Fem is minimal. Therefore, I was wondering if you could suggest maybe a robust option that at least converge. My concern is getting some rough estimates for the speed of Nektar++ in my oscillating channel flow problem. If the speed will be promising, I will switch to Nektar++ from OpenFOAM, as OpenFOAM is low-order and not really suitable for DNS. > > Thanks again in advance. > > Cheers, > Asim > > > On 01/31/2016 11:53 PM, Sherwin, Spencer J wrote: > Hi Asim, > > > I think your conclusions is correct. We did some early implementation into the 2D Homogeneous expansion but have not pulled it all the way through since we did not have a full project on this topic. We have however kept the existing code running through our regression test. For now I would perhaps suggest you try the 3D homo 1D approach for your runs since you can use parallelisation in that code. > > > Cheers, > Spencer. > > > > > > > > On 29 Jan 2016, at 04:00, ceeao<ceeao(a)nus.edu.sg> wrote: > > > Dear all, > > I just installed the library, and need to simulate DNS of a channel flow > with oscillating pressure gradient. > As I have two homogeneous directions I applied standard Fourier > discretization in these directions. > > It seems like this case is not parallelized yet, and I got the error in > the subject. > > I was wondering if I'm overlooking something. If not, are there maybe > any plans in the future to include parallelization of 2D FFT's? > > Thank you in advance. > > Best, > Asim Onder > Research Fellow > National University of Singapore > > ________________________________ > > Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you. > > _______________________________________________ > Nektar-users mailing list > Nektar-users(a)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(a)imperial.ac.uk > +44 (0) 20 759 45052 > > > > Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you. > > > > > > > > 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(a)imperial.ac.uk > +44 (0) 20 759 45052 > > > > Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you. > > > > > > > > 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(a)imperial.ac.uk > +44 (0) 20 759 45052 > ________________________________ Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you.

1 0

ARCHER users: boost a bit broken
by David Moxey 15 Mar '16

15 Mar '16

Hi all, Just a quick note for anyone using ARCHER: the boost module appears to now be incompatible with the GNU compiler which I gather has been recently updated. If you'll use it, you'll see errors when compiling anything using the expression evaluator. The solution is to *not* load the boost module. This way, Nektar++ will download and compile boost 1.57, in which the bug does not appear. Hopefully, boost 1.60 will appear on ARCHER soon and we won't have this issue. Cheers, Dave

1 1

MeshConvert is now NekMesh
by David Moxey 14 Mar '16

14 Mar '16

Dear all, A quick note to let you know that as of the last commit to master (changeset cd796734), the MeshConvert executable is no more. In its place, you should instead use the NekMesh executable. The reason for this is that, thanks to the efforts of Michael Turner, MeshConvert has now evolved from a basic converter to something capable of generating 3D curvilinear meshes from CAD input. The decision was therefore made to change the name of MeshConvert to reflect this new functionality. The most important point is that your existing commands should continue to work exactly as before: just use the word NekMesh instead of MeshConvert. However, we would very much appreciate any feedback if you have issues with any of your existing meshes. There are two more important points for developers: * For any existing installations that are updated to the latest master, you will need to remove your builds directory to avoid issues with the MeshConvert placeholder. * For anyone using buildbot, *please merge master into your branch before running it*. Otherwise we will need to keep removing the builds directory on each of the slaves, which will inevitably increase build times. If you are interested in the mesh generation aspect of NekMesh, please get in touch with Michael (m.turner14(a)imperial.ac.uk) At this point, this is at an early beta-stage, so will require guidance until we can continue to make this aspect more automated. Cheers, Dave -- David Moxey (Research Associate) d.moxey(a)imperial.ac.uk | www.imperial.ac.uk/people/d.moxey Room 363, Department of Aeronautics, Imperial College London, London, SW7 2AZ, UK.

1 0

FW: Requesting some help with the Adaptive SFD algorithm
by Sharma, Manish (sharmamh) 14 Mar '16

14 Mar '16

Hi Dave, Appended below is my original email with the input files attached. Thank you very much for helping with this. Manish -----Original Message----- From: Sharma, Manish (sharmamh) Sent: Friday, March 11, 2016 12:36 AM To: nektar-users-bounces(a)imperial.ac.uk Subject: Requesting some help with the Adaptive SFD algorithm Dear All, I am fairly new to nektar++, and have been trying to simulate the flow in a lid-driven cavity using the adaptive SFD method. However, after the first stability analysis run, I get the following output and error. Iteration: 1 (residual : 8.559e-27) Writing: "SquareCavityNonuniform110x110-AdaptiveSFD1.fld" L 2 error (variable u) : 1.60644e-14 L inf error (variable u) : 3.59318e-14 L 2 error (variable v) : 1.48736e-14 L inf error (variable v) : 3.72109e-14 L 2 error (variable p) : 1.01877e-14 L inf error (variable p) : 5.76926e-17 Fatal : Level 0 assertion violation Unrecognised value. I have checked my input files thoroughly, but am unable to understand what this error of "Unrecognised value" mean, or, how it has occurred. For your convenience/reference, the Geometry/Mesh, the nonlinear problem definition, and the homogeneous linear problem files are attached. Any suggestions/solutions to resolve this issue will be greatly appreciated. Thank you, Manish

1 0

Re: [Nektar-users] Requesting some help with the Adaptive SFD algorithm
by Sharma, Manish (sharmamh) 14 Mar '16

14 Mar '16

Just checking to see if the appended email went through the listserv. Thank you, Manish Sharma ________________________________________ From: Sharma, Manish (sharmamh) Sent: Friday, March 11, 2016 12:36 AM To: nektar-users-bounces(a)imperial.ac.uk Subject: Requesting some help with the Adaptive SFD algorithm Dear All, I am fairly new to nektar++, and have been trying to simulate the flow in a lid-driven cavity using the adaptive SFD method. However, after the first stability analysis run, I get the following output and error. Iteration: 1 (residual : 8.559e-27) Writing: "SquareCavityNonuniform110x110-AdaptiveSFD1.fld" L 2 error (variable u) : 1.60644e-14 L inf error (variable u) : 3.59318e-14 L 2 error (variable v) : 1.48736e-14 L inf error (variable v) : 3.72109e-14 L 2 error (variable p) : 1.01877e-14 L inf error (variable p) : 5.76926e-17 Fatal : Level 0 assertion violation Unrecognised value. I have checked my input files thoroughly, but am unable to understand what this error of "Unrecognised value" mean, or, how it has occurred. For your convenience/reference, the Geometry/Mesh, the nonlinear problem definition, and the homogeneous linear problem files are attached. Any suggestions/solutions to resolve this issue will be greatly appreciated. Thank you, Manish

2 2

Re: [Nektar-users] Implicit LES in Nektar++
by Rodrigo Moura 01 Mar '16

01 Mar '16

Dear Kamil, For the incompressible solver you should definitely include the dealiasing flag, namely, <I PROPERTY="SpectralhpDealiasing" VALUE="True" /> inside section <SOLVERINFO> of your XML file. Please refer to Sec 2.4.1.2 of Spencer's book (Spectral/hp element methods for computational fluid dynamics) for an explanation about the dealiasing strategy used by the incompressible solver. Note however the following. The success of our implicit LES approach via high-order CG methods (both in terms of discretization robustness and solution quality) is closely connect to a sensible use of SVV (spectral vanishing viscosity). This requires good knowledge of turbulence physics and of LES-like approaches and takes some programming expertise in Nektar++ since currently we do not have full control of the SVV operator only through the XML file. What I mean is that, for the purpose of implicit LES, you might need to modify the SVV operator inside Nektar and this is a somewhat advanced topic not covered by the user guide, as the CG+SVV-based implicit LES is a modern approach and not yet fully mature. Please note the following study that discusses the behaviour of different SVV operators from a perspective of under-resolved turbulence computations: http://www.sciencedirect.com/science/article/pii/S0021999115008256 Cheers, Rodrigo . On Mon, Feb 29, 2016 at 11:22 AM, Kamil ÖZDEN <kamil.ozden.me(a)gmail.com> wrote: > Hi Rodrigo, > > Thanks for your interest at first. I want to use the incompressible one. > Do you know what settings should I do in the *.xml file to run an implicit > LES? > > Best Regards, > Kamil > > 29.02.2016 12:03 tarihinde Rodrigo Moura yazdı: > > Hi Kamil, >> >> Do you intend to use the incompressible solver or the compressible one? >> The incompressible is currently much more efficient in Nektar due to the >> possibility of using implicit time-stepping. >> >> Cheers, >> Rodrigo >> . >> > > > --- > Bu e-posta virüslere karşı Avast antivirüs yazılımı tarafından kontrol > edilmiştir. > https://www.avast.com/antivirus > >

1 0

Porous Region in nektar++
by 张宾 01 Mar '16

01 Mar '16

Dear all We are using nektar to calculate multiple outlets flow problem, and porous region is required in the simulation. In my opinion, when the porous region is applied in computational domain, inertial resistance coefficients and viscous resistance coefficients should be set for the porous region. Is there any instructions that tell us how to set these two coefficients in Condition section of XML session file, or are there other ways to use porous region in nektar++? Best regards, Bin

2 4

How to figure out each Face's Expansion Coefficients given ElementExpansion Coeffcients
by ashok jallepalli 01 Mar '16

01 Mar '16

Dear All, I am trying to do the following in my code. I am stuck with not being able to few steps. Can you please suggest if there are any api calls which I can use. Or areas of code which does the same. Take Multi-region element, Loop through each element in the multi region. Loop through each face of element of multi region. Get 2D element expansion of each face and its coefficients. End each face loop. End each element loop. Question(1) To get the 2D element expansion, I am able to use GetfaceExp() on Expansion3D. This only works for boundary elements when the field is Cont3DExp. When element is not in the boundary it gives a segmentation fault 11. - Is this supposed to work ? Question(2) I can overcome the above problem by initializing the field as DisCont3DExp, while loading from fld file. (This seems to work for now). - Is there a function to get each face's Expansion coefficients from element expansion coefficients ? - Or should I dynamically check if the element is Hex, Tet, prism and try to figure out from the mapping order? Thank you,

2 5

Nektar++ User Workshop 2016
by Sherwin, Spencer J 27 Feb '16

27 Feb '16

Hi, Following the success of our inaugural workshop last year we are planning to run it again this year on June 7th/8th. Please see a provisional outline under http://www.nektar.info/community/workshops/nektar-2016/ If you are interested in attending could we request that you register under the web page so we can get an idea of numbers. We would also be very interested in hearing about whether you would like to attend an introductory or advanced satellite session. Best regards, Spencer. 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(a)imperial.ac.uk +44 (0) 20 759 45052

1 0

Implicit LES in Nektar++
by Kamil ÖZDEN 27 Feb '16

27 Feb '16

Dear All, I want to run Implicit Large Eddy Simulations by using Nektar++. As far as I know from some studies in literature (i. e. http://arxiv.org/pdf/1507.06012.pdf) it is possible to do such simulations in Nektar++. However, I couldn't find any detail about it in the user guide. Is there any document (tutorial etc.) that shows how to run such simulations in Nektar++? Best Regards, Kamil --- Bu e-posta virüslere karşı Avast antivirüs yazılımı tarafından kontrol edilmiştir. https://www.avast.com/antivirus

2 2