June 2018 - Nektar-users - imperial.ac.uk

Incompressible Navier-Stokes solver result problem
by Csaba Biró 15 Jul '18

15 Jul '18

Dear all, I am trying to solve an edge tone configuration related problem. I am using the Incompressible Navier.Stokes Solver to calculate the effects of blowing a jet flow, that impinges a wedge-shaped object. My problems are, that there seems to be an insufficient amount of outflow at the outlet ("u" velocity doesn't change), as if the airflow got stuck and that the errors shown after the calculation is complete are very high. Changing the time step or the number of modes did not decrease these errors considerably. Following the link you can see the used xml file (inc.xml). I attached a picture about the resulting "u" velocity and the geo+mesh. https://drive.google.com/open?id=1PYMXzPJo26wcIEns4OA71oI1lwWMCoYH I am only simulating half of the the problem. (hence the symmetry axis). I think there should be a much greater change in the "u" velocity overall. I double checked my boundary conditions. Please give me your opinion. Best regards, Csaba Biró

2 1

Problem in vtk fields
by Asım Önder 15 Jul '18

15 Jul '18

Dear all, I am postprocessing turbulent channel flow data from a 3D1H simulation, in which I used a coordinate mapping to impose a waviness on the bottom wall and specified NUMMODES="9" TYPE="GLL_LAGRANGE_SEM" in inhomogeneous directions. To analyze the data, I calculate the gradient (FieldConvert -m mapping -m gradient) of instantaneous fields and write the output in vtu format. After the conversion to physical coordinates in Paraview, I extract a horizontal plane from the resulting vtk fields where I see some spurious peaks on element borders in the streamwise derivative fields (u_x, v_x, w_x). I attached a figure showing an example of this, where on the left the problematic "u_x" is shown and on the right "u_x" derived from the continuity equation is shown, i.e., "-v_y-w_z". It can be seen that the fields are the same except some artifacts on element borders in direct "u_x". Is this maybe a bug? Thanks for any feedback. Regards, Asim

2 1

Calling Fortran modules in compressible flow solver
by Aidyn Aitzhan 15 Jul '18

15 Jul '18

Hi all, I am planning to call an external Fortran module in the compressible flow solver of Nektar++ 4.4.1. Could you please guide me about how I should modify the make (CMakeLists.txt) files? Basically, I have Fortran subroutines that allow me to compute temperature for non-constant heat capacities, so I want to use them. Thanks in advance, Aidyn

2 1

Vortex induced Vibration
by wasim sarwar 08 Jul '18

08 Jul '18

Hi all, I am interested to simulate flow past cylinder with vortex induced vibration. I went through a tutorial where finite-strip theory was used to model VIV of flexible cable. In the xml file of the tutorial they have already prescribed the motion of the cable via analytic expressions. Is it possible to compute the displacements and velocities of the cable arising from fluid forces, i.e. lift and drag rather than giving an explicit expression beforehand? Regards

2 1

Optimize solver settings for half billion mesh
by Sandeep Pandey 28 Jun '18

28 Jun '18

Hello all, I am running a 3DH1D turbulent channel flow at Re_tau=550 (MKM590, larger domain) which has a resolution of ~0.5 billion DoF and streamwise direction is the homogeneous direction with FFT. Our target is to achieve the solver setting to have fastest computation time on Cray- XC40 machine. We have tried a plenty of options e.g. Direct Solver, Iterative solver with 1D FFT and different pre-conditioners. But our CPU Time per time step is ~5 seconds, which is quite slow as per our experience. - We compare "DirectMultiLevelStaticCond" and "DirectStaticCond" solver and finds that the first one is slightly faster than the second one. It was due to 1D decomposition of the direct solver (--npz). We cannot utilize a large number of processors (e.g. 480 processors for 960 HomModeZ). Is 2D decomposition of direct solver exist? - If we use FFTW together with the iterative solver, can I expect better performance than the direct solver? What would be the optimal choice for the solver/preconditioner combination? Would the options in PETCS help? - According to my experience in full 3D DNS case (50 mio. mesh), around 0.2 sec/time step can be expected. Although this requires a large number of cores. Can I achieve something similar with 3DH1D cases? Part of xml file: <EXPANSIONS> <E COMPOSITE="C[0]" NUMMODES="7" FIELDS="u,v,w" TYPE="MODIFIED" /> <E COMPOSITE="C[0]" NUMMODES="7" FIELDS="p" TYPE="MODIFIED" /> </EXPANSIONS> <CONDITIONS> <SOLVERINFO> </SOLVERINFO> <PARAMETERS> TimeStep = 10e-05 FinalTime = 10.0 NumSteps = FinalTime/TimeStep NumSteps = 1000000 IO_CheckSteps = 2000 IO_InfoSteps = 5 IO_CFLSteps = IO_InfoSteps Re = 10000 Kinvis = 1.0/544.0 HomModesZ = 960 LZ = 8.0*PI SVVCutoffRatio = 0.7 SVVDiffCoeff = 0.1 </PARAMETERS> Thank you! Sandeep

2 1

I am new and need help
by shahab zeraati 23 Jun '18

23 Jun '18

Hi, I have just started working with Nektar++. Currently, I am trying to get familiar with it by doing the basic tutorials. But there is a major issue. Although I have compiled Nektar++ 4.3.4, and tested it successfully by "ctest" command, when I enter the command "NekMesh" in the terminal, it prints "command not found". I don't know what to do. Can you guys help me with it? Kind regards, Shahab

2 1

Unreproducible results and NaN appears following the incompressible Navier-Stokes tutorial
by Oliver Pola 19 Jun '18

19 Jun '18

Dear Nektar-users, we, a students team at Hamburg University, are trying to follow the "Incompressible Navier-Stokes" tutorial on our HPC cluster. Suggested by the hints we extended the tutorial to the 128^3 case, have MPI plus FFTW enabled and are running via mpirun. See attached "tutorial-setup.txt" for exact setup of the extended tutorial. Intel-Parallel-Studio is used as compiler and provider for MPI and BLAS/LAPACK via MKL. We installed using spack and its recent nektar package (plus enabling MKL). Trying to analyze scaling we failed to get any reproducible results. We had a few runs completing all checkpoints without error so we consider our setup correct. But other identical runs quit most times early or sometimes late giving "NaN found during time integration" error. We successfully run earlier tutorials and the 64^3 version with default conditions on a single process. Going back to Nektar version 4.4.0 or 4.3.5 also throws NaN error. We did not start enough runs in those versions to get a successful one. I found this NaN error mentioned in the mailing list archive, but it was pointed out that this was due to an improper physical setup. This should be fine in the tutorial, right? Could anyone provide some hints how to solve this problem? Can this be considered a bug of Nektar or may there be a hidden problem in our MKL setup? Regards Oliver

1 0

curved elements and BL splitting
by Vishal Saini 15 Jun '18

15 Jun '18

Hi all, This is regarding NekMesh utility. I would like to mesh a pipe which has coarse elements to begin with (inlet cross section shown in figure). In order to make the outer surface smooth I applied "spherigons" which worked fine (see attached). However, when I try to use "boundary layer splitting", NekMesh says: No elements detected to split. The element type on the outer surface are hexahedra. Is it the problem? Can anyone suggest a way out? Cheers, Vishal

2 1

Basis functions for Quasi 3D formulation
by Amitvikram Dutta 15 Jun '18

15 Jun '18

Hi all, I wanted to clear up a certain confusion regarding the quasi-3D approach. As I understand it, a 2D solution is extruded in the third direction using the fourier transform as basis functions. Considering that a default 2D solver uses the Galerkin formulation as basis functions, does the use of a different basis function for the theird direction not cause conflict? I feel I'm missing a critical theoretical intuition here. I would be greatful if someone cast some light on this. Sincerely, -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

2 1

Re: [Nektar-users] Regarding CSV to FLD convertor
by Abhishek Kumar 13 Jun '18

13 Jun '18

Dear Kilian, Thanks a lot... This works :) With regards Abhishek On Wed, Jun 13, 2018 at 9:05 AM, Kilian Lackhove <kilian(a)lackhove.de> wrote: > Hi Abhishek, > > yes, you can use the "interppointdatatofld" module of FieldConvert. The > current version 4.4.1 only reads pts files, which use a similar syntax as > csv > (check out the userguide for a description of the format). The upcoming > version 5.0 (and the current master branch from git) support direct csv > input. > > Cheers, > > Kilian > > Am Montag, 11. Juni 2018, 16:47:26 CEST schrieb Abhishek Kumar: > > Dear friends, > > > > I am trying to modify the output of Nektar++ data. For that, I convert > the > > data to csv and done the process in python. Now, I want to convert the > > csv data to fld to run on Nektar++. > > > > Is there any way to convert csv file to fld file? > > > > > > > > With regards > > Abhishek Kumar > > > > ------------------------------------------------------------ > ---------------- > > ----------- Abhishek Kumar > > Research Associate > > Applied Mathematics Research Centre > > Coventry University, Coventry CV1 5FB > > The United Kingdom > > > > Email # ac7600(a)coventry.ac.uk, abhishek.kir(a)gmail.com > > ------------------------------------------------------------ > ---------------- > > ----------- > > > -- With regards Abhishek Kumar --------------------------------------------------------------------------------------- Abhishek Kumar Research Associate Applied Mathematics Research Centre Coventry University, Coventry CV1 5FB The United Kingdom Email # ac7600(a)coventry.ac.uk, abhishek.kir(a)gmail.com ---------------------------------------------------------------------------------------

1 0