October 2015 - Nektar-users

Stability of channel flow with Nektar++
by Stanisław Gepner 05 Nov '15

05 Nov '15

Dear Sirs, First of all thank you for developing this great software and making it available. I am planing to investigate stability of an incompressible channel flow using Nektar. I have studied the manual and the source (the version from the git repo) and repeated some of the examples from the IncNavierStokesSolver folders Tests and Examples. The channel flow stability test (Tests/ChanStability.xml) uses a base flow (.bse) and an initial guess (.rst) and converges to an expected result. Now, as practice I tried to play around with the settings, first by changing the Driver to Arpack (this works as well). Since I might not know the initial approximation I tried to get rid of the initial guess, and replaceed it with some random initial vector (I have put zeros, non zeros, the awgn()). This time the problem did not coverage at all (I increased the numbers of iterations, tried to modify the number and size of the time steps, change the dimension of the Krylov space). Is this an expected behaviour? And since this is a test, the problem is set up to be small and quick and would only converge with the proper initial vector? Should I expect a similar problem for a larger 3D case? My second question concerns the base flow. I tried to recover the base flow using the stationary solver (both classical and adaptive) but I failed. Could you point me at an example of how to set this up? Also I noticed (or I think I did) that the Example/ChanStability-Base.xml does not produce a correct flow field. Am I right? I would appreciate if you would comment on my questions. Best Regards, Stan Gepner

2 8

Navier-Stokes: Linear Stability Analysis pressure field
by Péter Tamás Nagy 31 Oct '15

31 Oct '15

Dear All, I would like to carry out a linear stability analysis. Is it possible to obtain the pressure field of the direct or the adjoint eigenmodes? Best regards, Péter

2 1

interpfield error
by Kamil ÖZDEN 26 Oct '15

26 Oct '15

Dear All, I'm trying to interpolate the field data of one mesh to another mesh with the following command: *./FieldConvert -m interpfield:fromxml=V_F_Re500_Mesh2_N11.xml:fromfld=V_F_Re500_Mesh2_N11.fld V_F_Re500_Mesh4_N5.xml V_F_Re500_Mesh4_N5.fld *Nektar said *Interpolating[....* for a long time but abruptly it gives an error as below and cut the interpolating operation. *[Dell-Workstation:06507] *** Process received signal ***** **[Dell-Workstation:06507] Signal: Segmentation fault (11)** **[Dell-Workstation:06507] Signal code: Address not mapped (1)** **[Dell-Workstation:06507] Failing at address: 0x41c3c0ab0** **[Dell-Workstation:06507] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x36d40) [0x7f80a60efd40]** **[Dell-Workstation:06507] [ 1] ./FieldConvert(_ZN6Nektar9Utilities18ProcessInterpField16InterpolateFieldERSt6vectorIN5boost10shared_ptrINS_12MultiRegions7ExpListEEESaIS7_EESA_NS_5ArrayINS_4OneDEdEESD_SD_dd+0x186) [0x46a426]** **[Dell-Workstation:06507] [ 2] ./FieldConvert(_ZN6Nektar9Utilities18ProcessInterpField7ProcessERN5boost15program_options13variables_mapE+0x10e0) [0x46da60]** **[Dell-Workstation:06507] [ 3] ./FieldConvert(main+0x1d60) [0x435a70]** **[Dell-Workstation:06507] [ 4] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f80a60daec5]** **[Dell-Workstation:06507] [ 5] ./FieldConvert() [0x445881]** **[Dell-Workstation:06507] *** End of error message **** What can be the reason for such a problem? 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 1

Initial Conditions for Shock
by Jian Yu 26 Oct '15

26 Oct '15

Dear all, I am computing the one dimensional Shu-Osher problem using DG of the CompressibleFlowSolver. I found one tricky problem. The initial condition contains a shock. When I set the initial conditions like the following <FUNCTION NAME="InitialConditions"> <E VAR="rho" VALUE="3.857143*(x<=-4.0) + (1.0+0.2*sin(5*x))*(x>-4.0)"/> <E VAR="rhou" VALUE="3.857143*2.629369*(x<=-4.0) + 0.0*(x>-4.0)" /> <E VAR="rhov" VALUE="0.0" /> <E VAR="E" VALUE="(10.33333/(Gamma-1) + 0.5*3.857143*2.629369*2.629369)*(x<=-4.0) + (1.0/(Gamma-1))*(x>-4.0)"/> </FUNCTION> spurious oscillations would occur in the initial condition around x=-4.0 where the shock is located. Although I can arrange the mesh to make the shock lie just at the interface of two elements, only one value can be specified at x=-4.0, causing the spurious oscillations. However, for the DG method, two different values should be accepted at one element interface. Can anybody help me with this ? P.S.: Where can I find the version history of Nektar++, illustrating what is new in the newer version software compared with the older one? Best, Jian Yu

2 1

Re: [Nektar-users] Reflection using APE Solver
by Sherwin, Spencer J 20 Oct '15

20 Oct '15

Dear Miguel, Kilian Lackhove (cc’ed above) has been working on this solver most closely so may be in a better position to response. However if you have set up a Riemann type solution at the boundary they should be a reasonable first attempt at non-reflecting boundaries. Can I ask what boundary conditions you are currently setting up? Cheers, Spencer. On 16 Oct 2015, at 13:30, Miguel Moratilla-Vega <M.A.Moratilla-vega(a)lboro.ac.uk<mailto:M.A.Moratilla-vega@lboro.ac.uk>> wrote: Dear Spencer, I am trying to solve the simple acoustic wave problem, imposing a Gausian pulse as an initial condition. I am using the APE solver to obtain the acoustic propagation, but at the boundaries of the domain I am having reflections. For that reason I was wondering if there is any method in Nektar implemented to avoid these reflection in the outer boundaries of the domain. I have tried using the Absorption forcing but it is not giving me any changes in the solution. I have noticed as well that for the Compressible Flow Solver there is a PressureOutletNonReflective boundary condition, so I don’t know if implementing this in the APE solver would solve the problem. In addition, I have found in a paper of Tam and Webb, that they developed a Radiation Boundary Condition that it has been applied by Groschel, Schroder et al. to minimize the reflection and applied to an APE problem. Thank you very much and kind regards, Miguel --------------------------- Miguel Moratilla-Vega PhD Student Aeronautical and Automotive Engineering Department Stewart Miller Building Loughborough University Leicestershire LE11 3TU 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

Floquet stability analysis update
by Chris Cantwell 14 Oct '15

14 Oct '15

Dear all, We have now fixed one of the bugs which prevented the Floquet stability analysis part of Nektar++ from working correctly. The updates to the code are currently in the fix/floquet branch in the code repository. This will most likely be merged into the main codebase in the near future. We have tested the HalfMode variation of the code with a cylinder testcase and this accurately reproduces results from Barkley & Henderson (1996). I have attached example files for reproducing the critical case at Re=188.5/beta=1.585, which you should be able to run directly as follows. 1. Generate the time-periodic 2D base flow. IncNavierStokesSolver m32_base.xml This will also extract the field variables at a few history points which can be used to calculate the base flow frequency parameter "Freq", required for the following steps. Note that this simulation runs for 2000 time units, necessary to ensure the flow reaches a truly periodic state. 2. Generate the 2D base-flow slices for stability analysis IncNavierStokesSolver m32_slices.xml This will evolve the base flow for one period and create 32 slices (33 files, numbered 0 to 32) as checkpoint files which will be Fourier-interpolated to provide the base flow. 3. Run the 3D stability analysis. IncNavierStokesSolver m32.xml Note the specification of the base flow now uses the C-style printf format for specifying the baseflow slices. It should converge in around 20-30 iterations and the leading eigenvalue should be very close to 1.0. The "Re" (and therefore the "Freq") and "beta" parameters can be adjusted to compute the other Floquet multipliers from the paper. Note: there is still a bug with the SingleMode and MultipleModes mode types. We will update you when these are also fixed. Please let us know if you encounter any further bugs while using the HalfMode setting. Cheers, Chris -- Chris Cantwell Imperial College London South Kensington Campus London SW7 2AZ Email: c.cantwell(a)imperial.ac.uk www.imperial.ac.uk/people/c.cantwell

1 0

Adding Body force for the Channel flow
by Jian Yu 06 Oct '15

06 Oct '15

Dear all, I am now trying to compute the channel flow using the Compressible Flow Solver. I have found the body force with derivatives non-trivial to add. Once the flow in a channel has reached a fully developed state, inertial forces in the channel, which are related to the mean favourable streamwise pressure gradient (pressure drop in a duct), are balanced with the wall friction forces. In this case, the body force f would be in the following form f=-tw/h, where tw is the wall friction containing velocity derivatives, h is the channel scale. Can anybody tell me how to perform this flow in Nektar? Thank you very much! Best Jian Yu

3 3

OS X 10.11
by David Moxey 06 Oct '15

06 Oct '15

Dear all, For anyone that is interested in upgrading to OS X 10.11 (El Capitan), I can confirm that Nektar++ compiles, installs and passes regression tests. You will need to install the latest Xcode and install the new command line tools (go to the Terminal and run the command "xcode-select --install"). Additionally, for those that use MacPorts or Homebrew: 1) If you use MacPorts, you need to junk /opt/local and reinstall your ports. 2) If you use Homebrew, you probably need something along the lines of of brew update && brew doctor && brew upgrade. You will also need: 1) A small Nektar++ patch that can be found in the fix/osx-10.11-elcapitan branch. 2) A patch that you should apply to the boost static_assert.hpp header: https://svn.boost.org/trac/boost/ticket/11664 This will fix compiler warnings related to BOOST_STATIC_ASSERT. 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