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

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

Problem when using MPI
by Stanisław Gepner 28 May '15

28 May '15

Dear All, Has any of you have ever had any problems with GSMPI when in parallel? I am having some problems running Nektar in parallel on SHARCNET (https://www.sharcnet.ca) I have run Nektar in parallel before on other clusters (https://c-cfd.meil.pw.edu.pl/hpc/) and had no problems using it. Let me describe it: If I do: IncNavierStokesSolver geom.xml cond.xml all is good, If I do (also through the pbs system) mpirun -n 2 IncNavierStokesSolver geom.xml cond.xml I get a Segmentation fault. If I try to delay process communication (e.g. by loading prepartitioned meshes) I can see some output. So I think the problem starts with the first MPI send/recive. That is why think there is something with the GSMPI since it wraps the MPI communication (right?). I have already tried with different compilers (intel and gcc), different boost distributions etc. Are you aware if there might be any problems with certain OpenMPI versions, or something like this? Best Regards, Stan Gepner

2 2

Stability analysis - import base flow from other solver
by Rohner Adrian 28 May '15

28 May '15

Dear nektar-users, I want to perform stability analysis with nektar and I started with some Examples like the cylinder case. Now, the plan was to proceed as follows: 1. Flow simulation of symmetric model(to prevent the oscillations) with CFX or COMSOL in the higher RE-Range(instable region), think for the cylinder case it would be 45-160(2d) 2. Next step would be to import flow and pressure field into nektar and perform stability analysis Has anyone done similar things? How about importing, interpolation and so on? And if it is not possible to use data from another solver how can I do the defined progress In nektar? Best regards, adrian Adrian Rohner Projektmitarbeiter | BSc FHO in Maschinentechnik HSR Hochschule für Technik Rapperswil IET Institut für Energietechnik | +41 55 222 4263 | www.iet.hsr.ch<http://www.iet.hsr.ch/>

1 0

About Periodic Conditions
by YU Jian 27 May '15

27 May '15

Dear All, I am trying to using the periodic condition within the CompressibleFlowSolver. I have tested the IsentropicVortex case with periodic conditions imposed at all boundaries. The xml file(attached with this mail) was generated with MeshConvert from a Gmesh file. I found out that in the <COMPOSITE> part, the listing order of the faces on a pair of periodic boundaries must be one-to-one correspondance, otherwise the boundary condition will not be applied correctly. However, MeshConvert seems not to be able to ensure the correct orders. For example, Wrong(generated directly by MeshConvert): <C ID="2"> F[14,4,31,23] </C> <C ID="3"> F[8,17,26,33] </C> <C ID="4"> F[1,7,20,25] </C> <C ID="5"> F[18,13,34,30] </C> <C ID="6"> F[0,6,11,16] </C> <C ID="7"> F[24,28,32,35] </C> Correct(modified manually): <C ID="2"> F[14,4,31,23] </C> <C ID="3"> F[17,8,33,26] </C> <C ID="4"> F[1,7,20,25] </C> <C ID="5"> F[13,18,30,34] </C> <C ID="6"> F[0,6,11,16] </C> <C ID="7"> F[24,28,32,35] </C> I further checked the MeshConvert , and found out that at line 339 of the file 'OutputNekpp.cpp', there is a comment "Ensure that this composite is not used for periodic BCs!". Does this mean that MeshConvert can not be used when periodic BCs exist? Thank you in advance! Best wishes, Jian YU <?xml version="1.0" encoding="utf-8" ?> <NEKTAR> <GEOMETRY DIM="3" SPACE="3"> <VERTEX> <V ID="0">0.00000000e+00 -5.00000000e+00 0.00000000e+00</V> <V ID="1">5.00000000e+00 -5.00000000e+00 0.00000000e+00</V> <V ID="2">5.00000000e+00 0.00000000e+00 0.00000000e+00</V> <V ID="3">0.00000000e+00 0.00000000e+00 0.00000000e+00</V> <V ID="4">0.00000000e+00 -5.00000000e+00 5.00000000e+00</V> <V ID="5">5.00000000e+00 -5.00000000e+00 5.00000000e+00</V> <V ID="6">5.00000000e+00 0.00000000e+00 5.00000000e+00</V> <V ID="7">0.00000000e+00 0.00000000e+00 5.00000000e+00</V> <V ID="8">1.00000000e+01 -5.00000000e+00 0.00000000e+00</V> <V ID="9">1.00000000e+01 0.00000000e+00 0.00000000e+00</V> <V ID="10">1.00000000e+01 -5.00000000e+00 5.00000000e+00</V> <V ID="11">1.00000000e+01 0.00000000e+00 5.00000000e+00</V> <V ID="12">5.00000000e+00 5.00000000e+00 0.00000000e+00</V> <V ID="13">0.00000000e+00 5.00000000e+00 0.00000000e+00</V> <V ID="14">5.00000000e+00 5.00000000e+00 5.00000000e+00</V> <V ID="15">0.00000000e+00 5.00000000e+00 5.00000000e+00</V> <V ID="16">1.00000000e+01 5.00000000e+00 0.00000000e+00</V> <V ID="17">1.00000000e+01 5.00000000e+00 5.00000000e+00</V> <V ID="18">0.00000000e+00 -5.00000000e+00 1.00000000e+01</V> <V ID="19">5.00000000e+00 -5.00000000e+00 1.00000000e+01</V> <V ID="20">5.00000000e+00 0.00000000e+00 1.00000000e+01</V> <V ID="21">0.00000000e+00 0.00000000e+00 1.00000000e+01</V> <V ID="22">1.00000000e+01 -5.00000000e+00 1.00000000e+01</V> <V ID="23">1.00000000e+01 0.00000000e+00 1.00000000e+01</V> <V ID="24">5.00000000e+00 5.00000000e+00 1.00000000e+01</V> <V ID="25">0.00000000e+00 5.00000000e+00 1.00000000e+01</V> <V ID="26">1.00000000e+01 5.00000000e+00 1.00000000e+01</V> </VERTEX> <EDGE> <E ID="0"> 0 1 </E> <E ID="1"> 1 2 </E> <E ID="2"> 2 3 </E> <E ID="3"> 3 0 </E> <E ID="4"> 0 4 </E> <E ID="5"> 1 5 </E> <E ID="6"> 2 6 </E> <E ID="7"> 3 7 </E> <E ID="8"> 4 5 </E> <E ID="9"> 5 6 </E> <E ID="10"> 6 7 </E> <E ID="11"> 7 4 </E> <E ID="12"> 1 8 </E> <E ID="13"> 8 9 </E> <E ID="14"> 9 2 </E> <E ID="15"> 8 10 </E> <E ID="16"> 9 11 </E> <E ID="17"> 5 10 </E> <E ID="18"> 10 11 </E> <E ID="19"> 11 6 </E> <E ID="20"> 2 12 </E> <E ID="21"> 12 13 </E> <E ID="22"> 13 3 </E> <E ID="23"> 12 14 </E> <E ID="24"> 13 15 </E> <E ID="25"> 6 14 </E> <E ID="26"> 14 15 </E> <E ID="27"> 15 7 </E> <E ID="28"> 9 16 </E> <E ID="29"> 16 12 </E> <E ID="30"> 16 17 </E> <E ID="31"> 11 17 </E> <E ID="32"> 17 14 </E> <E ID="33"> 4 18 </E> <E ID="34"> 5 19 </E> <E ID="35"> 6 20 </E> <E ID="36"> 7 21 </E> <E ID="37"> 18 19 </E> <E ID="38"> 19 20 </E> <E ID="39"> 20 21 </E> <E ID="40"> 21 18 </E> <E ID="41"> 10 22 </E> <E ID="42"> 11 23 </E> <E ID="43"> 19 22 </E> <E ID="44"> 22 23 </E> <E ID="45"> 23 20 </E> <E ID="46"> 14 24 </E> <E ID="47"> 15 25 </E> <E ID="48"> 20 24 </E> <E ID="49"> 24 25 </E> <E ID="50"> 25 21 </E> <E ID="51"> 17 26 </E> <E ID="52"> 23 26 </E> <E ID="53"> 26 24 </E> </EDGE> <FACE> <Q ID="0"> 0 1 2 3</Q> <Q ID="1"> 0 5 8 4</Q> <Q ID="2"> 1 6 9 5</Q> <Q ID="3"> 2 6 10 7</Q> <Q ID="4"> 3 7 11 4</Q> <Q ID="5"> 8 9 10 11</Q> <Q ID="6"> 12 13 14 1</Q> <Q ID="7"> 12 15 17 5</Q> <Q ID="8"> 13 16 18 15</Q> <Q ID="9"> 14 16 19 6</Q> <Q ID="10"> 17 18 19 9</Q> <Q ID="11"> 2 20 21 22</Q> <Q ID="12"> 20 23 25 6</Q> <Q ID="13"> 21 23 26 24</Q> <Q ID="14"> 22 24 27 7</Q> <Q ID="15"> 10 25 26 27</Q> <Q ID="16"> 14 28 29 20</Q> <Q ID="17"> 28 30 31 16</Q> <Q ID="18"> 29 30 32 23</Q> <Q ID="19"> 19 31 32 25</Q> <Q ID="20"> 8 34 37 33</Q> <Q ID="21"> 9 35 38 34</Q> <Q ID="22"> 10 35 39 36</Q> <Q ID="23"> 11 36 40 33</Q> <Q ID="24"> 37 38 39 40</Q> <Q ID="25"> 17 41 43 34</Q> <Q ID="26"> 18 42 44 41</Q> <Q ID="27"> 19 42 45 35</Q> <Q ID="28"> 43 44 45 38</Q> <Q ID="29"> 25 46 48 35</Q> <Q ID="30"> 26 46 49 47</Q> <Q ID="31"> 27 47 50 36</Q> <Q ID="32"> 39 48 49 50</Q> <Q ID="33"> 31 51 52 42</Q> <Q ID="34"> 32 51 53 46</Q> <Q ID="35"> 45 52 53 48</Q> </FACE> <ELEMENT> <H ID="0"> 0 1 2 3 4 5 </H> <H ID="1"> 6 7 8 9 2 10 </H> <H ID="2"> 11 3 12 13 14 15 </H> <H ID="3"> 16 9 17 18 12 19 </H> <H ID="4"> 5 20 21 22 23 24 </H> <H ID="5"> 10 25 26 27 21 28 </H> <H ID="6"> 15 22 29 30 31 32 </H> <H ID="7"> 19 27 33 34 29 35 </H> </ELEMENT> <COMPOSITE> <C ID="1"> H[0-7] </C> <C ID="2"> F[14,4,31,23] </C> <C ID="3"> F[8,17,26,33] </C> <C ID="4"> F[1,7,20,25] </C> <C ID="5"> F[18,13,34,30] </C> <C ID="6"> F[0,6,11,16] </C> <C ID="7"> F[24,28,32,35] </C> </COMPOSITE> <DOMAIN> C[1] </DOMAIN> </GEOMETRY> <EXPANSIONS> <E COMPOSITE="C[1]" NUMMODES="15" FIELDS="rho,rhou,rhov,rhow,E" TYPE="MODIFIED" /> </EXPANSIONS> <CONDITIONS> <PARAMETERS> FinTime = 10. TimeStep = 0.002 NumSteps = 0 IO_CheckSteps = 500 IO_InfoSteps = 1 Gamma = 1.4 pInf = 101325 rhoInf = 1.225 uInf = 0.1 vInf = 0.0 wInf = 0.0 CFL = 0 </PARAMETERS> <SOLVERINFO> </SOLVERINFO> <VARIABLES> <V ID="0"> rho </V> <V ID="1"> rhou </V> <V ID="2"> rhov </V> <V ID="3"> rhow </V> <V ID="4"> E </V> </VARIABLES> <BOUNDARYREGIONS> C[2] C[3] C[4] C[5] C[6] C[7] </BOUNDARYREGIONS> <BOUNDARYCONDITIONS> <REGION REF="1"> </REGION> <REGION REF="2"> </REGION> <REGION REF="3"> </REGION> <REGION REF="4"> </REGION> <REGION REF="5"> </REGION> <REGION REF="6"> </REGION> </BOUNDARYCONDITIONS>   </CONDITIONS> </NEKTAR>

2 1

Update on Nektar++ workshop
by David Moxey 26 May '15

26 May '15

Dear all, Just a quick update on the Nektar++ workshop for those that are yet to register! The event is now definitely going ahead. You can find the most recent information here on location and accommodation options: http://sherwinlab.ae.ic.ac.uk/nektar-workshop-2015/ As the Doodle poll was just to ascertain the level of interest, in order to keep track of everyone, we have replaced it with a registration form through EventBrite, which you can access here: https://www.eventbrite.co.uk/e/nektar-workshop-2015-tickets-16799728440 I hope that you are able to attend and look forward to seeing you there. 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 1

weak form of diffusion term for 1d homogeneous problem
by Zhicheng Wang 23 May '15

23 May '15

Hi all, I'm trying to implement a stabilized method for incompressible N-S equation. Basically, the form of the stabilized term looks like nu*L_u, where nu is the the artificial viscosity which is varying across quadratue points, L_u is the Laplacian operation of a velocity component. My plan is using the explicit scheme to discretize this stabilized term to avoid assembling the system matrix at every time step. I'd like to add the stabilized term to the right hand side in the viscous correction stage of the velocity correction scheme. However I'm not very clear how to implement it using Nektar++ for the case of 3DHomogeneous1D . Here I attached a piece of my current code, hope someone could help me to correct the mistakes. // velocity_array[0] stored the first component of velocity vector in Fourier space // z direction is homogeneous // nu stored artificial viscosity // np is number of quadrature points in a 2D plane // nc is number of SEM coefficients in a 2D plane Vmath::Vadd(np*num_planes, nu ,1, velocity_array[0],1,velocity_array[0],1); m_fields[1]->PhysDeriv(0,velocity_array[0],velocity_derv[0]); // gradient in x direction m_fields[1]->PhysDeriv(1,velocity_array[0],velocity_derv[1]); // gradient in y direction cnt = 0; cnt1 = 0; for(unsigned int i=0; i<num_planes; ++i) { double beta = 2*M_PI*m_trans->GetK(i)/m_homoLen; beta *= beta; m_fields[0]->GetPlane(i)->IProductWRTDerivBase(0, &velocity_derv[0]+cnt, &wkCoef1[0] +cnt1); m_fields[1]->GetPlane(i)->IProductWRTDerivBase(1, &velocity_derv[1]+cnt, &wkCoef1[0]+cnt1); m_fields[1]->GetPlane(i)->IProductWRTBase(tmp1 = &velocity_array[0]+i*np, &wkCoef2[0]+i*nc,MultiRegions::eGlobal); Vmath::Smul(nc, beta, &wkCoef2[0] + i*nc, 1, &wkCoef2[0]+ i*nc, 1); cnt += np; cnt1 += nc; } Vmath::Vadd(NumTotCoeffs,wkCoef0,1,wkCoef1,1,visc,1); Vmath::Vadd(NumTotCoeffs,wkCoef0,1,wkCoef2,1,visc,1);

3 3

User Guide
by Kamil ÖZDEN 13 May '15

13 May '15

Dear All, I want to learn how to generate the necessary Fourier coefficients to use in Womersley Equation for generating pulsatile inlet flow boundary condition. However, I couldn't see any detail about this issue in the user-guide I downloaded from www.nektar.info. As far as I learned these issues are detailed in the user-guide of latest version of Nektar++ downladed from git-repository. This user guide seems in the nektar/docs/user - guide folder as *.tex file. I tried to compile this file but I always get the following error. /*user-guide.tex error line 377: File `../../VERSION.tex' not found. \titlepage */How can I reach the user-guide including information about the issues above. Regards, Kamil

2 1