July 2017 - Nektar-users - imperial.ac.uk

how to use HOBC?
by Kurt Sansom 25 Mar '18

25 Mar '18

Hi, I am trying to use the higher order outlet boundary conditions. I know that is formulated for truncated open domains, but am curious if I can use in the following way, where I want to specify the outlet pressure to some value to create back pressure in the system. I realize that for in-compressible flow it doesn't matter that much, but I am interested in implementing a time varying pressure condition at the outlet. I have tried the following boundary condition for a tube and it doesn't appear to apply the VALUE tag? I want to make sure before I file a bug. <REGION REF="2">  <N VAR="u" USERDEFINEDTYPE="HOutflow" VALUE="0" /> <N VAR="v" USERDEFINEDTYPE="HOutflow" VALUE="0" /> <N VAR="w" USERDEFINEDTYPE="HOutflow" VALUE="0" /> <D VAR="p" USERDEFINEDTYPE="HOutflow" VALUE="10665" /></REGION> Regards, ~Kurt -- Kurt Sansom

2 3

Nektar++ transition to C++11
by Chris Cantwell 09 Sep '17

09 Sep '17

Dear all, As part of our ongoing efforts to modernise our codebase, we are planning to transition to the C++11 standard in the near future. A consequence of this is that you will in future require a compiler which supports the C++11 standard (either as an option, such as --std=c++11, or by default). Current versions of popular compilers all fully support the standard, but older compilers may only have partial support. We recommend the following compiler versions to minimise the likelihood of problems going forward: - GCC: 4.8 or later - Clang: 3.3 or later - MSVC: 19.0 or later - Intel: 15.0 or later - PGI: 2015 or later We encourage users to test out support for basic C++11 by compiling the branch 'feature/libutils-c++11' from the code repository and updating build scripts and configuration as necessary. Please let us know if you have any problems or concerns. We will be making the transition after the Nektar++ Workshop in mid-June. Cheers, Nektar++ Development Team

2 2

Nektar
by Kurt Sansom 20 Jul '17

20 Jul '17

Does anyone have the source code for the original nektar code base. I keep finding things that mention it as open source, but it doesn't exist where I have looked. Regards, -Kurt

1 0

AeroForces in Compressible Flow Solver
by Ismael El Houas Ghouddana 17 Jul '17

17 Jul '17

Hello Nektar developers, Is there any way to use the AeroForces filter in a compressible flow simulation? Kind Regards, Ismael

2 1

FieldIO changes
by Julia Docampo (MTH) 10 Jul '17

10 Jul '17

Hello: I noticed some changes in the newest nektar version in the FieldIO class (?). This class had the constructor option: LIB_UTILITIES_EXPORT FieldIO(LibUtilities::CommSharedPtr pComm, bool sharedFilesystem = false); However, it is not there in the new one... I have a solver that uses this constructor like this LiibUtilities::FieldIO fIO(vSession->GetComm)) ie, with the default argument false. With the new version, there is no default argument but if I try to force the condition: fIO(vSession->GetComm,false)) I get errors $: cannot declare variable ‘fIO’ to be of abstract type ‘Nektar::LibUtilities::FieldIO’ How can I use this constructor like for the previous version? Thanks - Julia

2 1

a bug in ProcessInterpPointDataToFld
by Ankang Gao 10 Jul '17

10 Jul '17

Hello, ProcessInterpPointDataToFld assigns the coordinates values instead of values of physical quantities when I using it to interpolate a fld from given points set in version 4.4.0 I find it is because line 131 in void Nektar::FieldUtils::ProcessInterpPointDataToFld::Process(po::variables_map & vm) is not right. 131 m_f->m_exp[j]->SetPhys(i, outPts->GetPointVal(j, i)); It should use an offset=outPts->GetDim() when assigning value to m_exp, like the follows m_f->m_exp[j]->SetPhys(i, outPts->GetPointVal(outPts->GetDim()+j, i)); Best wishes Ankang

5 4

Bug during running with Larger Homogeneous Modes
by wasim sarwar 09 Jul '17

09 Jul '17

Hi, I am trying to run 3D simulations in parallel with 1D homogeneous in the span-wise direction. For a certain number of Fourier Modes the simulation runs smoothly, but increasing them beyond some critical value causes an error to pop up, and this error is not related to memory shortage. The cluster in which simulation is being run has the capacity of running 192 processors with 2GB Ram/core in parallel environment. Just to give you an idea, in my case with homogeneous modes 64 things are perfect and increasing them causes simulation to crash giving errors like: Fatal : Level 0 assertion violation Exceeded maximum number of iterations srun: error: s02r2b71: tasks 0-47: Exited with exit code 1 CG iterations made = 5001 using tolerance of 1e-09 (error = -nan, rhs_mag = 1) I would appreciate if someone could suggest something. Best Regards

2 1

Calculation on vorticity and other derivative quantities
by BF MA 03 Jul '17

03 Jul '17

Hello everyone, I am using the incompressible solver in Nektar++ for simulating vortex flows around bluff bodies or slender bodies. The results obtained look fine, and the velocity and pressure fields are smooth, but as I exported the results into post-process software, like Tecplot, for calculating vorticity, the vorticity obtained is not smooth. I looked into the reason and found that the vorticity inside each element was calculated separately, so the vorticty values at the boundary between elements are discontinuous. I guess that this should be a special issue existing in spectral element grids, and no this kind of problem exists in finite volume grids. This is also applicable to calculating other derivative quantities, like in Q or lambda2 methods for vortex identification. I'd like to know if there is some approaches to deal with this problem. Otherwise, it is difficult to visualize vortex structures. Many thanks. Baofeng Baofeng Ma, PH.D Associate Professor Institute of Fluid Mechanics School of Aeronautical Science and Engineering Beihang University Email: bf-ma(a)buaa.edu.cn Tel: 0086 (0)10 82338344

4 3

Mesh interpolation issue
by Ismael El Houas Ghouddana 03 Jul '17

03 Jul '17

Dear Nektar development team, I am writing to you in order to communicate some issues which I have experimented,while performing a mesh interpolation with FieldConvert module. I am originally working with a specific mesh, Mesh1, with which I have obtained some results, chk1. Now, I want to redefine this mesh and make it more detailed, so I generated a new mesh, Mesh2, which has the same dimensions and geometry as mesh1, but it is better meshed (more elements). Then, the problem appears when I want to interpolate the solution chk1 to the new mesh, Mesh2. In order to perform this interpolation, I have used the "interpfield" module from FieldConvert. The output file from this operation, file2.fld, is not correct at all, as some incoherent velocities have appeared. Specifically, it appeared extremely high velocities which have no reason to be. In more detail, those velocities are located at some nodes along the boundary of the domain of the solution file2.fld. These high speeds have propagated and blurred a few elements into the domain. The geometry of this boundary is a circumference arc, and its boundary conditions are HOutflow. I also have tried to smooth the file2.fld by using the C0Projection module, file2_C0.fld, but has blurred the velocities only a few. I have attatched some photos from file2_C0.fld showing some of those high velocities on the boundary. Must be noted that file2.fld is quite similar to file2_C0.fld, but less blurred. I remain at your disposal for any doubt or clarification, Ismael El Houas

2 1