- Nektar-users - imperial.ac.uk

Correct Designation of Boundary Conditions
by Amitvikram Dutta 26 Apr '16

26 Apr '16

Hi all, I'm having some confusion in applying appropriate boundary conditions to proper named surfaces in my mesh. I'm using v4.2.0 with the original mesh being constructed in gmsh. I subsequently use the MeshConvert utility to generate the partial xml file for the simulation. In my .msh file I have my surfaces set as $PhysicalNames 5 2 1 "Unspecified" 1 2 "Airfoil" 1 3 "Inlet" 1 4 "Outlet" 1 5 "Tandb" $EndPhysicalNames I want to apply no-slip condition to the airfoil, a velocity inlet , a constant pressure outlet and no slip wall to TandB as well. My relevant section of the xml case file is given below. I'd like to know if I'm implementing the boundary conditions correctly. <BOUNDARYREGIONS> C[2] C[3] C[4] C[5] </BOUNDARYREGIONS> <BOUNDARYCONDITIONS> <REGION REF="0"> <D VAR="u" VALUE="0" /> <D VAR="v" VALUE="0" /> <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> </REGION> <REGION REF="1"> <D VAR="u" VALUE ="1" /> <D VAR="v" VALUE="0" /> <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> </REGION> <REGION REF="2"> <N VAR="u" VALUE="0" /> <N VAR="v" VALUE="0" /> <D VAR="p" VALUE="0" /> </REGION> <REGION REF="3"> <D VAR="u" VALUE="0" /> <D VAR="v" VALUE="0" /> <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> </REGION> </BOUNDARYCONDITIONS> <FUNCTION NAME="InitialConditions"> <E VAR= "u" VALUE="1" /> <E VAR="v" VALUE="0" /> <E VAR="p" VALUE="0" /> </FUNCTION> -- *Amitvikram Dutta* *MASc Candidate* *Graduate Research Assistant * *Okanagan CFD Laboratory* *University of British Columbia | Okanagan Campus*

2 2

Nektar++ on OS X and Xcode 7.3
by David Moxey 26 Apr '16

26 Apr '16

Hi all, Just want to draw OS X users' attention to a compilation bug with METIS on OS X. If you are using Xcode 7.3 (i.e. clang -v says: Apple LLVM version 7.3.0 (clang-703.0.29)), presently there's some kind of low-level bug when compiling METIS which will yield the following error, or one like it: [ 79%] Building C object programs/CMakeFiles/cmpfillin.dir/smbfactor.c.o Linking C executable cmpfillin ld: in ../libmetis/libmetis.a(error.c.o), section __DATA/__thread_bss extends beyond end of file, for architecture x86_64 Right now there is no known workaround for this, other than to use gcc or another compiler version. I therefore thoroughly recommend avoiding Xcode 7.3 for the time being, otherwise you will not be able to compile Nektar++. If you have already upgraded, you can try to downgrade to Xcode 7.2, which continues to work fine. For reference, there is a homebrew bug report here: https://github.com/Homebrew/homebrew-science/issues/3461 and a possible LLVM bug here: https://llvm.org/bugs/show_bug.cgi?id=27059 Cheers, Dave -- David Moxey (Research Fellow) 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 1

Basis type for the "MODIFIED"
by Hongfu Zhang 21 Apr '16

21 Apr '16

Hi all, Look at the words in XML "<E COMPOSITE="C[0]" NUMMODES="5" FIELDS="u" TYPE="MODIFIED" />" I would like to know what the default basis type for the "MODIFIED" ? Regards! Hongfu Zhang

2 1

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

15 Apr '16

Dear All, Just checking to see if you received my email query of March 14, 2016 (appended below for your convenience). Looking forward to hearing from you soon. Thank you very much! Manish Sharma -----Original Message----- From: Sharma, Manish (sharmamh) Sent: Monday, March 14, 2016 11:41 AM To: David Moxey <d.moxey(a)imperial.ac.uk> Cc: nektar-users(a)imperial.ac.uk Subject: FW: Requesting some help with the Adaptive SFD algorithm 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

4 5

Installation problem: Boost specification
by Victor Eijkhout 12 Apr '16

12 Apr '16

I can not find in the documentation how to specify the Boost library. 1. I’ve unzipped the tar.bz2 file in the ThirdParty directory, but nektar still tries to download the tar.bz2 file. 2. I have a boost 1.59 installed, and the bin directory is in the LD_LIBRARY_PATH but the installation is not finding or using it. Victor.

3 7

Re: [Nektar-users] Parallel transposition not implemented yet for 3D-Homo-2D approach
by Sherwin, Spencer J 12 Apr '16

12 Apr '16

Hi Asim, To follow-up on Douglas’ comment we are trying to get more organised to sort out a developers guide. We are also holding a user meeting in June. If you were able to make this we could also try and have a session on getting you going on the developmental side of things. Cheers, Spencer. On 17 Mar 2016, at 14:58, Serson, Douglas <d.serson14(a)imperial.ac.uk<mailto:d.serson14@imperial.ac.uk>> wrote: Hi Asim, I am glad that your simulation is now working. About your questions: 1. We have some work done on a filter for calculating Reynolds stresses as the simulation progresses, but it is not ready yet, and it would not provide all the statistics you want. Since you already have a lot of chk files, I suppose the best way would indeed be using a script to process all of them with FieldConvert. 2. Yes, this has been recently included in FieldConvert, using the new 'meanmode' module. 3. I just checked that, and apparently this is caused by a bug when using this module without fftw. This should be fixed soon, but as an alternative this module should work if you switch fftw on (just add to you session file, if the code was compiled with support to fftw). 4. I think there is some work towards a developer guide, but I don't how advanced is the progress on that. I am sure Spencer will be able to provide you with more information on that. Cheers, Douglas ________________________________________ From: Asim Onder <ceeao(a)nus.edu.sg<mailto:ceeao@nus.edu.sg>> Sent: 17 March 2016 09:10 To: Serson, Douglas; Sherwin, Spencer J Cc: nektar-users; Moxey, David Subject: Re: [Nektar-users] Parallel transposition not implemented yet for 3D-Homo-2D approach 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: 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<mailto:ceeao@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. 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<mailto:s.sherwin@imperial.ac.uk> +44 (0) 20 759 45052

2 1

Vortex-induced vibration of a cube box immerged in the air
by Hongfu Zhang 07 Apr '16

07 Apr '16

Hi all, Could nektar++ simulate vortex-induced vibration of a cube box immerged in the air? I have read the user-guide and found that the "MoveBody" could do this, but "this force type is only supported for the Quasi-3D incompressible Navier-Stokes solver". What can I do? Any help would appreciate! Hongfu

2 1

a bug in function v_Assemble
by 高安康 06 Apr '16

06 Apr '16

Hi, I think I find a bug in function Nektar::MultiRegions::AssemblyMapCG::v_Assemble(const Array<OneD, const NekDouble> &loc, Array<OneD, NekDouble> &global) const, in file AssemblyMapCG.cpp. The fourth line of this function writes, "local = Array<OneD, NekDouble>(local.num_elements(),local.data());", which aims to make a copy of "loc" if "loc" and "global" have the same address. But this line makes a copy of "local", which hasn't been initialized yet. So this line should be substituted by "local = Array<OneD, NekDouble>(loc.num_elements(),loc.data());" Best regards, Ankang

3 2

Nektar++ 4.3.0 Released
by Chris Cantwell 22 Mar '16

22 Mar '16

Dear all, We are pleased to announce that Nektar++ v4.3.0, has been released. This release includes a number of significant new features, including: - Compression of mesh data; - New libraries: NekMeshUtils and GlobalMappings; - New modules and features in the post-processing FieldConvert tool; along with a whole host of fixes and improvements in both the libraries and solvers. There are also now packages of Nektar++ for OS X. Please see the Nektar++ website (www.nektar.info) for further details. Cheers, The Nektar++ Team

2 1

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

17 Mar '16

Hi Kamil, In comparison to DNS, any LES will have a coarser mesh (or a lower polynomial order in the same mesh), as the aim of an LES is to resolve the large and part of the intermediate flow scales. Note that as one keep refining an LES solution, one tends to the DNS limit where all the turbulent scales (down to the Kolmogorov ones) are resolved. The time step size should also be less stringent in an LES, but this will be naturally taken care of if a CFL-based step is used. In other words: when an LES solution is obtained from a DNS by coarsening the mesh (or reducing the polynomial order), a valid larger time step will automatically be set if the CFL number is mantained. Dealiasing is a technique by which numerical integration is performed consistently. This is not is a must for well-resolved smooth flows, but is very important for under-resolved computations (such as implicit LES) as higher-order polynomial modes retain more energy. In addition to that, as the LES mesh is coarsened from a DNS mesh, one will need extra dissipation added as the physical viscous term will be less effective in damping the turbulent scales (note that regular, second-order viscosity only acts significantly at the very small scales, which will be missing in an implicit LES). This is why you will need SVV, which is a type of high-order viscosity designed to affect the smallest resolved scales without interfering directly with the large ones. 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: . You can also tune it by setting the parameters SVVCutoffRatio and SVVDiffCoeff, but I would suggest starting with the default parameters. Cheers, Rodrigo . On Thu, Mar 17, 2016 at 12:53 PM, Kamil ÖZDEN <kamil.ozden.me(a)gmail.com> wrote: > Hi Rodrigo, > > I'm running my analysis now by just adding the flag > > inside section > <SOLVERINFO> of my XML file and I wondered two things: > > 1) What is the difference between SpectralVanishingViscosity and > SpectralhpDealising? Do I need to add anything to my xml file about > SpectralVanishingViscosity to run my case with Implicit LES? > > 2) What about the grid size and structure? Do I need to change grid > structure and/or grid size (number of elements, polynomial order etc.) to > run Implicit LES when compared with DNS ? > > 3) What about the time step size? Do I need to increase or decrease the > time step when compared with DNS? > > I'll be glad if you answer my questions. Thank you very much. > > Best Regards, > Kamil > > > > 02.03.2016 19:37 tarihinde Kamil ÖZDEN yazdı: > > Hi Rodrigo, > > Unfortunately I don't have any programming experience in any language > except Matlab. I'll try to make a trial by just adding the flag needed for > implicit Les to the xml file and share the results with you. Thank you very > much for your help. > > Best Regards, > Kamil > 1 Mar 2016 14:34 tarihinde "Rodrigo Moura" <r.moura13(a)imperial.ac.uk> > yazdı: > >> Dear Kamil, >> >> For the incompressible solver you should definitely include the >> dealiasing flag, namely, >> >> 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 >>> >>> >> > > Bu e-posta Avast tarafından korunan virüssüz bir bilgisayardan > gönderilmiştir. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >

1 0