September 2024 - Nektar-users

Wiggles in turbulent dissipation rate profile
by Xiao, Chengnian 13 Oct '24

13 Oct '24

******************* This email originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address. ******************* Dear All, Hope everyone is doing well! We keep seeing wiggles in our time- and plane-averaged profile for the turbulent dissipation rate \epsilon obtained from Nektar++ DNS results, as shown in the attached plot. They seem to appear whenever calculating profiles of second or higher order flow statistics involving velocity gradients, whereas the time-averaged flow profiles themselves look alright. From earlier posts, it seems that similar issues have also been reported by other users. Is there a way to alleviate the issue either through adapting the simulation or the postprocessing procedure, i.e. smoothing? Best regards, Cheng

2 1

Memory leak with variable viscosity using Incompressible Navier-Stokes solver
by Debbahi Saad 03 Oct '24

03 Oct '24

******************* This email originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address. ******************* Dear all, Using a locally compiled version of nektar release 5.6.0 (which runs pretty well) to solve fully 3d plane Poiseuille flow geometry, I'm trying to add variable or temperature dependant viscosity, by defining a function in the nektar session file, to be evaluated and passed to VarCoeffMap D00, D11,D22 as suggested by M. R. Rouhanian, a while ago, indeed I've come to the conclusion that the Incompressible Navier-Stokes solvers use too much memory in a cumulative way without releasing it throughout the time advancement process. key points: - Correct behavior with constant viscosity. no problem, the IncNavierStokesSolver runs good - Source file modified: nektar-v5.6.0/solvers/IncNavierStokesSolver/EquationSystems/VelocityCorrectionScheme.cpp (*Line:890, VelocityCorrectionScheme::v_SolveViscous* function) - Monotonic memory usage increase when enabling variable viscosity through any of the possible 'nu' dependencies i.e.: nu(Temp),nu(x,y,z), nu(t), nu(x,y,z,t). - The memory usage reaches easily 10 gigabytes after 20 to 30 timesteps, obviously evenly spread over the 4 x IncNavierStokesSolver spawned processes, compared to 4x140MB=560MB for the constant viscosity case - The memory usage keeps increasing, never decreases, no release of the memory surplus from one timestep to the next, it just keeps adding up... - No crash the calculations do carry on, with a noticeable slowdown due to viscosity array update, however not usable from a practicality view point as any serious case simulation would claim few terabytes of leaked memory - Placing some "cout<<" printing arrays sizes show that the arrays involved do keep the same size no issues It seems to be a garbage collection issue or a missing destructor call that I'm not able to pinpoint or fix. Any help on this issue or suggestion to fix it are greatly appreciated, Thank you all in advance, wishing you all the best, Saad *Code details:* My *VelocityCorrectionScheme::v_SolveViscous* modified function (file attached herein) reads: void VelocityCorrectionScheme::v_SolveViscous( > const Array<OneD, const Array<OneD, NekDouble>> &Forcing, > const Array<OneD, const Array<OneD, NekDouble>> &inarray, > Array<OneD, Array<OneD, NekDouble>> &outarray, const NekDouble aii_Dt) > { > StdRegions::ConstFactorMap factors; > StdRegions::VarCoeffMap varCoeffMap = StdRegions::NullVarCoeffMap; > MultiRegions::VarFactorsMap varFactorsMap = MultiRegions > ::NullVarFactorsMap; > > AppendSVVFactors(factors, varFactorsMap); > ComputeGJPNormalVelocity(inarray, varCoeffMap); > /* > switch (coordim) > { > case 3: > Exp->GetCoords(xc0, xc1, xc2); > break; > default: > ASSERTL0(false, "Coordim not valid"); > break; > }*/ > > > //////////////////////////////////////////////////////////////////////////////// > /////////// Modifications to account for variable viscosity start > here:///////// > > int nuflag=0; //initialiazed to 0, fall back to constant viscosity if > nu(T) is not defined > time_t rawTime; > time(&rawTime); > NekDouble time = static_cast<NekDouble>(rawTime);//ensure time is of > NekDouble type > > // if the function nuOfT is defined in the session file, evaluate the > function and set variable viscosity > if(m_session->DefinesFunction("nuOfT")) > { > Array<OneD, NekDouble> xxc0,xxc1,xxc2;// declare NekDouble arrays to hold > coordinates > > int nqv;// total points > int coordim=3;// default dimension > LibUtilities::EquationSharedPtr nuOfTfunc; > nqv=m_fields[0]->GetTotPoints(); > > // allocate 0.0 valued arrays of totalpoints size, to receive the space > coordinates > xxc0 = Array<OneD, NekDouble>(nqv, 0.0); > xxc1 = Array<OneD, NekDouble>(nqv, 0.0); > xxc2 = Array<OneD, NekDouble>(nqv, 0.0); > > m_fields[0]->GetCoords(xxc0,xxc1,xxc2); > coordim=m_fields[0]->GetCoordim(0); > > Array<OneD,NekDouble> nuOfT(nqv,0.0);// 0.0 valued nekdouble array to > hold viscosity value at each point of space > nuOfTfunc=m_session->GetFunction("nuOfT",0); > > nuOfTfunc->Evaluate(xxc0,xxc1,xxc2,nuOfT);// evaluate the function nu(T) > varCoeffMap[StdRegions::eVarCoeffD00]=nuOfT;// assign the values of > viscosity for the three diagonal components (same) evaluated > varCoeffMap[StdRegions::eVarCoeffD11]=nuOfT;// at every point of space > using the decalred nu(T) function > varCoeffMap[StdRegions::eVarCoeffD22]=nuOfT; > > nuflag=1;// set the variable viscosity flag > > } > > // Solve Helmholtz system and put in Physical space > for (int i = 0; i < m_nConvectiveFields; ++i) > { > > // Add diffusion coefficient to GJP matrix operator (Implicit part) > if (m_useGJPStabilisation) > { > factors[StdRegions::eFactorGJP] = m_GJPJumpScale / m_diffCoeff[i]; > } > > // Setup coefficients for equation > factors[StdRegions::eFactorLambda] = 1.0 / aii_Dt / m_diffCoeff[i]; > if (nuflag==1) factors[StdRegions::eFactorTime]=time;//if the nuOfT nu(T) > function is defined set the tume factor, > //else continue with constant viscosity > > m_fields[i]->HelmSolve(Forcing[i], m_fields[i]->UpdateCoeffs(), factors, > varCoeffMap, varFactorsMap); > m_fields[i]->BwdTrans(m_fields[i]->GetCoeffs(), outarray[i]); > } > > > } > Sample function node from the xml session file: <FUNCTION NAME="nuOfT"> <E EVARS="c1" VALUE="Ra*Pr*c1" /> </FUNCTION>

3 5

Problem With Fedora Nektar++ Installation and HDF5
by Isaac Rosin 02 Oct '24

02 Oct '24

******************* This email originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address. ******************* Hello Nektar++ users, I just installed Fedora 36 on my computer. I chose this distribution specifically because Nektar++ supports it. I made sure to install all of the required packages for each utility and solver I needed before installing libnektar++, libnektar++-openmpi and libnektar++-mpich. Then I installed the libnektar++ packages, nekmesh, fieldconvert serial and mpi versions and the incnavierstokes-solver and tried to run the command `NekMesh geometry.msh geometry.nekg` and got the following message: ``` Fatal : Level 0 assertion violation No such module: HDF5 Available classes: Xml: IO with Xml geometry XmlCompressed: IO with Xml geometry terminate called after throwing an instance of 'Nektar::ErrorUtil::NekError' what(): Level 0 assertion violation No such module: HDF5 Available classes: Xml: IO with Xml geometry XmlCompressed: IO with Xml geometry Aborted (core dumped) ``` I know that my files are not the issue because I have been able to execute this command with my past installations of Nektar++. I got the same error when I tried FieldConvert too using a version of the .nekg mesh I had already created on a previous installation. It seems like NekMesh does not see my HDF5 installations. How may I resolve this? Best regards, Isaac

4 11

Inquiry About the Availability of Thick-Strip Method and Tutorials for Non-Linear Slender Structures
by Zhipeng Yu 30 Sep '24

30 Sep '24

******************* This email originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address. ******************* Hello Nektar++ users, I have been working with Nektar++ and noticed that references to the thick-strip method have been removed from the current user guide. I would like to inquire if this method is still available in the latest version of Nektar++ and, if so, where I might find any updated documentation or tutorials. Additionally, I am particularly interested in tutorials or examples related to non-linear slender structures, similar to those discussed in the work by Mohsen Lahooti et al. (2022), Computer Physics Communications, 282, 108528. If such resources exist, I would greatly appreciate any guidance or links to relevant materials. Thank you very much for your time and assistance. Best regards, Zhipeng Yu

1 0

Bug in IncNavierStokes solver terminal output for SVV with MPI
by Alexander Schukmann 19 Sep '24

19 Sep '24

Hi Jacques, thank you for your message. I‘m sorry, I send my last answer with some additional info and the files directly to Henrik (see below). The files are attached to this message as txt. Thanks and all the best Alex > Hello Henrik, > > thank you very much for your answer and pointing out the relevant routines, I'll have a look! > Attached to this mail you'll find the necessary files (mesh + session). > > Please note that no Homo1D-SVV option is included in the SOLVERINFO, but the respective parameters are set under PARAMETERS. I tested it with a containerized Nektar++ 5.5.0 on my local machine, Nektar++ 5.5.0 on our hpc and a local installation of Nektar++ 5.3.0 and the issue always came up. Sometimes you have to re-start it several times before the terminal output changes, but most of the time an incorrect output is shown (Homo1D-SVV activated) with the Homo1D-SVV parameter values according to the session file, even though it's not included in the SOLVERINFO. > > Just for the sake of completeness: I invoke the solver with > mpirun -n 16 IncNavierStokesSolver -f mesh.xml session.xml > > All the best > Alex > > Sicher versendet mit [Proton Mail](https://proton.me/). > > Henrik Wüstenberg <henrik.wuestenberg(a)hotmail.de> schrieb am Freitag, 30. August 2024 um 10:41 vorm.: > >> Hi Alex, >> >> I have had a quick look, the output you are reporting is generated by a call to EquationSystem::PrintSummary which then calls v_GenerateSummary. The function is only called if rank == 0. So, I am not sure why you would see different behaviour for MPI or serial execution. >> >> If you are keen to take a look yourself. The parent function is in library/SolverUtils/EquationSystem.cpp::GenerateSummary and for the VelocityCorrectionScheme you would have virtual calls from child to parent in the files: >> >> - solvers/IncNavierStokesSolver/VelocityCorrectionScheme.cpp >> - (library/SolverUtils/AdvectionSystem.cpp) - no definition here >> - library/SolverUtils/UnsteadySystem.cpp >> - library/SolverUtils/EquationSystem.cpp >> >> Could you share the session file for your case? (without the .xml ending as outlook filters those) >> >> Best wishes, >> Henrik >> >> --------------------------------------------------------------- >> >> Von: nektar-users-bounces(a)imperial.ac.uk <nektar-users-bounces(a)imperial.ac.uk> im Auftrag von Alexander Schukmann <alexander.schukmann(a)protonmail.com> >> Gesendet: Dienstag, 27. August 2024 18:02 >> An: nektar-users(a)imperial.ac.uk <nektar-users(a)imperial.ac.uk> >> Betreff: [Nektar-users] Bug in IncNavierStokes solver terminal output for SVV with MPI >> >> This email from alexander.schukmann(a)protonmail.com originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your [safe senders list](https://spam.ic.ac.uk/SpamConsole/Senders.aspx) to disable email stamping for this address. >> >> Hello everyone, >> >> I noticed some odd behavior of the IncNavierStokesSolvers terminal output regarding SVV when using MPI for Quasi-3D cases. When I try to use SVV in the spectral/hp planes only, i.e. without SVV along the homogeneous direction, the terminal output sometimes includes the SVV-Homo1D info, eventhough it's not specified under the SOLVERINFO tag in the session file! >> When I re-run the same case, it will randomly disappear as you can see here for two consecutive runs with identical settings: >> >> nektar@0d6fdc64e227:~/host_pwd/run$ mpirun -n 16 IncNavierStokesSolver mesh.xml session.xml >> ======================================================================= >> EquationType: UnsteadyNavierStokes >> Session Name: CylReD3900_quad_coarse2_Pgeo3 >> Spatial Dim.: 3 >> Max SEM Exp. Order: 4 >> Num. Processes: 16 >> Quasi-3D: Homogeneous in z-direction >> Expansion Dim.: 3 >> Num. Hom. Modes (z): 64 >> Hom. length (LZ): 3.14159 >> FFT Type: FFTW >> Projection Type: Continuous Galerkin >> Advect. advancement: explicit >> Diffuse. advancement: implicit >> Time Step: 0.004 >> No. of Steps: 1 >> Checkpoints (steps): 1 >> Integration Type: IMEX >> Splitting Scheme: Velocity correction (strong press. form) >> Dealiasing: Homogeneous1D + spectral/hp >> Smoothing-SpecHP: SVV (spectral/hp DG Kernel (diff coeff = 0.10000000000000001*Uh/p)) >> ======================================================================= >> >> nektar@0d6fdc64e227:~/host_pwd/run$ mpirun -n 16 IncNavierStokesSolver -f mesh.xml session.xml >> ======================================================================= >> EquationType: UnsteadyNavierStokes >> Session Name: CylReD3900_quad_coarse2_Pgeo3 >> Spatial Dim.: 3 >> Max SEM Exp. Order: 4 >> Num. Processes: 16 >> Quasi-3D: Homogeneous in z-direction >> Expansion Dim.: 3 >> Num. Hom. Modes (z): 64 >> Hom. length (LZ): 3.14159 >> FFT Type: FFTW >> Projection Type: Continuous Galerkin >> Advect. advancement: explicit >> Diffuse. advancement: implicit >> Time Step: 0.004 >> No. of Steps: 1 >> Checkpoints (steps): 1 >> Integration Type: IMEX >> Splitting Scheme: Velocity correction (strong press. form) >> Dealiasing: Homogeneous1D + spectral/hp >> Smoothing-SpecHP: SVV (spectral/hp DG Kernel (diff coeff = 0.10000000000000001*Uh/p)) >> Smoothing-Homo1D: SVV (Homogeneous1D - Exp Kernel(cut-off = 0.75, diff coeff = 0.10000000000000001)) ======================================================================= >> >> The first run does not output the "Smoothing-Homo1D" info, while the second one includes it, which makes it impossible to know whether it is activated or not. It'll use the SVV parameters that are set for the spectral/hp SVV if no parameters for the Homo1D-SVV are specified under the PARAMETERS tag. Otherwise the values will be overwritten, eventhough - as I said before - the feature is turned off under the SOLVERINFO tag. >> >> Running on one CPU shows the expected behavior. >> >> So it would be interesting to know whether this only concerns the terminal output or if the feature really is activated despite not being defined by the user. >> >> All the best >> Alex >> >> Sicher versendet mit [Proton Mail](https://proton.me/).

2 2

Bug in IncNavierStokes solver terminal output for SVV with MPI
by Alexander Schukmann 02 Sep '24

02 Sep '24

******************* This email originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address. ******************* Hello everyone, I noticed some odd behavior of the IncNavierStokesSolvers terminal output regarding SVV when using MPI for Quasi-3D cases. When I try to use SVV in the spectral/hp planes only, i.e. without SVV along the homogeneous direction, the terminal output sometimes includes the SVV-Homo1D info, eventhough it's not specified under the SOLVERINFO tag in the session file! When I re-run the same case, it will randomly disappear as you can see here for two consecutive runs with identical settings: nektar@0d6fdc64e227:~/host_pwd/run$ mpirun -n 16 IncNavierStokesSolver mesh.xml session.xml ======================================================================= EquationType: UnsteadyNavierStokes Session Name: CylReD3900_quad_coarse2_Pgeo3 Spatial Dim.: 3 Max SEM Exp. Order: 4 Num. Processes: 16 Quasi-3D: Homogeneous in z-direction Expansion Dim.: 3 Num. Hom. Modes (z): 64 Hom. length (LZ): 3.14159 FFT Type: FFTW Projection Type: Continuous Galerkin Advect. advancement: explicit Diffuse. advancement: implicit Time Step: 0.004 No. of Steps: 1 Checkpoints (steps): 1 Integration Type: IMEX Splitting Scheme: Velocity correction (strong press. form) Dealiasing: Homogeneous1D + spectral/hp Smoothing-SpecHP: SVV (spectral/hp DG Kernel (diff coeff = 0.10000000000000001*Uh/p)) ======================================================================= nektar@0d6fdc64e227:~/host_pwd/run$ mpirun -n 16 IncNavierStokesSolver -f mesh.xml session.xml ======================================================================= EquationType: UnsteadyNavierStokes Session Name: CylReD3900_quad_coarse2_Pgeo3 Spatial Dim.: 3 Max SEM Exp. Order: 4 Num. Processes: 16 Quasi-3D: Homogeneous in z-direction Expansion Dim.: 3 Num. Hom. Modes (z): 64 Hom. length (LZ): 3.14159 FFT Type: FFTW Projection Type: Continuous Galerkin Advect. advancement: explicit Diffuse. advancement: implicit Time Step: 0.004 No. of Steps: 1 Checkpoints (steps): 1 Integration Type: IMEX Splitting Scheme: Velocity correction (strong press. form) Dealiasing: Homogeneous1D + spectral/hp Smoothing-SpecHP: SVV (spectral/hp DG Kernel (diff coeff = 0.10000000000000001*Uh/p)) Smoothing-Homo1D: SVV (Homogeneous1D - Exp Kernel(cut-off = 0.75, diff coeff = 0.10000000000000001))======================================================================= The first run does not output the "Smoothing-Homo1D" info, while the second one includes it, which makes it impossible to know whether it is activated or not. It'll use the SVV parameters that are set for the spectral/hp SVV if no parameters for the Homo1D-SVV are specified under the PARAMETERS tag. Otherwise the values will be overwritten, eventhough - as I said before - the feature is turned off under the SOLVERINFO tag. Running on one CPU shows the expected behavior. So it would be interesting to know whether this only concerns the terminal output or if the feature really is activated despite not being defined by the user. All the best Alex Sicher versendet mit [Proton Mail](https://proton.me/).

3 2