- Nektar-users - imperial.ac.uk

Convergence problem in constricted pipe flow problem
by Kamil ÖZDEN 16 Jan '16

16 Jan '16

Dear All, I'm trying to run a constricted pipe flow problem at Re=1000 in Nektar++ with the following boundary conditions: <BOUNDARYREGIONS> C[6]  C[8]  C[7]  </BOUNDARYREGIONS> <BOUNDARYCONDITIONS> <REGION REF="0"> <D VAR="u" VALUE="2*(1-(4*(y^2+z^2)))" /> <D VAR="v" VALUE="0" /> <D VAR="w" VALUE="0" /> <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> </REGION> <REGION REF="1"> <N VAR="u" VALUE="0" /> <N VAR="v" VALUE="0" /> <N VAR="w" VALUE="0" /> <D VAR="p" VALUE="0" /> </REGION> <REGION REF="2"> <D VAR="u" VALUE="0" /> <D VAR="v" VALUE="0" /> <D VAR="w" VALUE="0" /> <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> </REGION> </BOUNDARYCONDITIONS> The simulation seems converging but after a while starts to diverge and ended by Nektar due to exceedence of maximum iteration number. Time history plot of a node at the center of the pipe is attached to the mail. Does anybody have idea about the source of this problem? Is it directly related with the structure of the mesh I've used or do I set something wrong in my *.xml file? 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

1 0

Running first Nektar case after installation
by Amitvikram Dutta 14 Jan '16

14 Jan '16

Hi all, New Nektar user here. So, I've successfully managed to install Nektar++4.2.0 on my machine. The Ctest results are 100% and I assume nektar is up and running. The only problem is, when I download the basic Cyl case and try to run it, it seem the system does not recognize "nektar" as a valid command. To be clear, in a folder containing the files cyl.rea and cyl.rst, I tried the following command nektar -V cyl.rea I got the following response If 'nektar' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf nektar *Any help would be greatly appreciated. * ** *Sincerely,* *Amitvikram Dutta* *MASc Candidate* *Graduate Research Assistant * *Okanagan CFD Laboratory* *University of British Columbia | Okanagan Campus*

2 1

Gitlab update, 9th January
by David Moxey 10 Jan '16

10 Jan '16

Dear all, Happy new year! Just a quick email to let you know that I plan to take our Gitlab instance offline for a quick upgrade of the software that covers the usual security fixes. Currently I've planned this for the morning of the 9th of January (this Saturday). If you have any issues with the date then please let me know! 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

Code users
by Sherwin, Spencer J 10 Dec '15

10 Dec '15

Hi, It would be very useful for our funding and support activities to know who is using Nektar++ and for what activities. If possible could I ask you to drop us a one line response of where you are based and what you are doing with the code (in very broad terms). Many thanks, 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<mailto:s.sherwin@imperial.ac.uk> +44 (0) 20 759 45052

1 0

Euler CFE in 1D
by Kühnelt Helmut 02 Dec '15

02 Dec '15

Dear all, I want to implement a modified Euler equation in 1D, using Version 4.2.0. For testing of a 1D case I set up a simple session file (attached, 20 equi-spaced elements, time and spatially independent initial and boundary conditions). The simulation does not run successfully. There seem to be several issues in the code which I was not able to solve up to now. So I try to describe what I have found so far and where I got stuck. 0) Is there a bug in my session file? 1) I noticed that Nektar::StdRegions::StdSegExp::v_ReduceOrderCoeffs is missing and implemented it. 2) When the Riemann Solver is called for the first time, an exception is thrown: Fatal : Level 0 assertion violation Where : /home/hkuehnelt/nektar/solvers/CompressibleFlowSolver/RiemannSolvers/ExactSolverToro.cpp[211] Message : Vacuum is generated by given data. By dumping a lot of stuff, I think I confined the problem, but have no clue where this comes from: In the call MultiRegions::DisContField1D::v_AddTraceIntegral(), called from SolverUtils::Advection::AdvectionWeakDG::v_Advect(), for the first convective field input Fn = {0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225,0.1225} and the output is {0.245,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, i.e. the first value is non-zero. I assume, this is not correct. MultiRegions::DisContField1D::GetNegatedFluxNormal() returns the negatedFluxNormal = {0,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0} MultiRegions::DisContField1D::GetNegatedFluxNormal(): the problem seems to be in the first element of m_traceMap. Here the dump of IDs in the i and v loops. i v ID_elmtToTrace ID_leftAdjElem 0 0 0 0 0 1 0 0 1 0 1 0 1 1 1 1 2 0 2 1 2 1 2 2 3 0 3 2 3 1 3 3 ... 17 0 17 16 17 1 17 17 18 0 18 17 18 1 18 18 19 0 19 18 19 1 19 19 I tried to dig deeper, but then gave up, due to increasing complexity of the code. I am confident, that you help me. Best regards, Helmut

1 0

Naghdi shell model with spectral discretization using Nectar++ ?
by Lamjed Lounissi 11 Nov '15

11 Nov '15

Dear all, Is it possible to solve a Naghdi shell model with spectral discretization using Nectar++ ? This is the problem: [cid:d189e87a-05e4-44d7-8657-a2e3c7bbf168] Best regards, Lamjed

2 1

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