August 2022 - Nektar-users

CoupledLNS
by A.P. 05 Sep '22

05 Sep '22

******************* 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, I am using CoupledLinearisedNS solver for 2D stabiblty analysis. To do this, it is needed to set the imaginary eigenvalue shift. Now it is possible only in 3D with a homogeneous direction. I set an appropriate 3D case and the BetaZero property that overrides LHom. As a result, eigenvalues look nice, but eigenfunctions are not. The eigenfunctions are not two-dimensional. How I can get the eigenfunctions? Or my proposition about the BetaZero property is wrong? Alex Proskurin Altai state technical university

2 3

Some Newbie Questions about Nektar++
by İlteber Özdemir 04 Sep '22

04 Sep '22

******************* 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, I am a beginner in Nektar++ and have compiled some of my questions below. I would be glad if you can help. 1. Does IncNavierStokesSolver or any other solver support adaptive time marching? It seems to me that TimeStep, NumSteps, IO_CheckSteps, IO_InfoSteps, IO_CFLSteps are required by the solver. I was wondering if it would be possible to control the time step with e.g. a CFL number constraint? Then all IO_* (most importantly CheckSteps) can be expressed in terms of simulation time (not time step). 2. Is it possible to calculate the gradient of only one specific variable? The gradient module calculates the gradients of all variables which produces unnecessary data, slowing down post-processing and increasing the size of the files. Is there a better way than calculating the gradient and removing the unnecessary fields using removefield module? 3. Where can I find a use of the isocontours module of FieldConvert? I couldn't figure out what kind of output it gives, and what it expects as input. 4. Is it possible to map the results of a case to another where the meshes are neither at same refinement level nor at the same order? 5. Is there a way to control solver tolerance? The standard residual level allowed seems to be 1e-09, and how can I change it? 6. When visualising with ParaView (and also if you write a python script), the best way I know is to convert the chk files into vtu files. In each of those vtu files, the mesh is included, which increases its size. Is there a way to use one mesh file (e.g. mesh.vtu or mesh.xml) and only convert the variables to some other format? This would reduce the storage space needed for a case. I would also appreciate it if you can suggest a totally new and a better way of visualising the results. 7. In the mesh.xml file created by NekMesh, the NUMMODES of the expansions are always 4, irrespective of the value of the ORDER parameter. Are those just placeholders, or should I change them after meshing? In the session file I set the NUMMODES as 1 + "the value of ORDER (in the mesh file)". Is this the correct way? 8. When using AeroForces filter, can you change the formatting of the output file? For example I want the time and the forces in scientific format with 10 digits precision, how can I make this happen? Thank you in advance for your help! Best regards, Ilteber -- İlteber R. Özdemir

3 2

Nektar++ Workshop 2022
by Chris Cantwell 01 Sep '22

01 Sep '22

Dear all, We are planning to hold the next Nektar++ workshop on the 13th-15th September 2022 at Imperial College London. So please save the date! We are finalising the exact timing of the event, but will put more information online soon, including how to register. The event is planned to be primarily an in-person meeting. However, we are, at a minimum, aiming to accommodate viewing of the talks by remote attendees for those unable to travel. We look forward to seeing you in London in September. Kind regards, Chris -- Chris Cantwell Senior Lecturer in Aeronautics Department of Aeronautics Imperial College London South Kensington Campus London SW7 2AZ Tel: +44 (0)20 759 45050 Email: c.cantwell(a)imperial.ac.uk www.imperial.ac.uk/people/c.cantwell

1 2

Installation of Nektar++ on Ubuntu 22.04
by subhasisar＠campus.technion.ac.il 31 Aug '22

31 Aug '22

******************* 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. I am Dr Subhasisa Rath from Technion - Israel Institute of Technology. I would like to install nektar++ on my Ubuntu 22.04 OS. I am not able to find any source-code for this OS. May I know whether I can install or not on OS? Best, Subhasisa

5 7

The solution method of pressure equation in Nektar
by ztdepyahoo 27 Aug '22

27 Aug '22

1 0

Nektar++ 5.2.0 Released.
by Chris Cantwell 23 Aug '22

23 Aug '22

Dear all, We are pleased to announce the release of Nektar++ v5.2.0. This release includes a range of new features and improvements over the 5.1.0 release: **Library** - Add Arm SVE backend to SIMD library (!1282) - Added support for manifold MatrixFree operators (2D in 3D space) (!1304) - Put in place automatic selection of explicit operations using an opt file (!1304) - Fixed the moving reference frame rotation (Solver Utils) (!1305) - Revised FilterAeroForces to accout for the moving reference frame (!1305) - Add MaxMinFields filter to record the max/min at each quadrature point and output the max/min fields. (!1256) - Simplify the logic in the MPI pairwise trace exchange (!1307) - Fix imaginary mode in HalfModeToFourier module (!1247) - Added a dummy output module OutputStdOut for NekMesh utilities that don't require an output file (!1318) - Fix compiler errors on ARCHER2 using PrgEnv-cray (!1315) - Fix cmake SIMD enable/disable options based on architecture (!1320) - Restrucutred the communicators to reduce direct dependence on session file communicator (!1337) - Fixed SIMD mask test (!1324) - Fix memory leak in Timer.cpp (!1330) - Fix cmake CWIPI option to remove Fortran check (!1331) - Fix excessive verbose output in GetBndElmtExpansions method (!1341) - Timer class was updated with safety checks to avoid wrong measurements (!1347) - Fix to adjust for warnings/errors from Monterey updated compiler (!1355) - Update `nektar` and `nektar-env` packages to Debian Bullseye (!1356) - Reformat code with clang-format (!1359) - Remove unnecessary IterPerExp methods (!1366) - Fix erronous call to FwdTrans from MR 1366 (!1374) - Fixed avx512 back-end for SimdLib (!1333) - Added float to scalar and avx2 back-end, disable avx512, sse2, sve (!1255) - Change MPI initialisation to allow MPI_Init call outside Nektar++ (!1376) - Fixed incorrect summary output for diffusion/reaction terms (!1383) **FieldConvert** - Add calculation of CFL number for the incompressilbe flow (!1332) - Added conditional to select the eNearestNeighbour method for 3D interpolation (!1335) - Fixed the output field names of WSS module of FieldConvert (!1352) - Add VTU output using VTK library (high-order & multi-block options) (!1343) **IncNavierStokesSolver** - Added Boundary conditions for moving reference frame (!1305) - Added the virtual functions overwriting the FluidInterface for moving reference frame (!1305) - Add Gradient Jump Penalty (GJP) Stabilisation into the solver (!1290) - Equation types are registered to the session reader (!1344) **ADRSolver:** - Add Gradient Jump Penalty (GJP) Stabilisation into the Unsteady Advection and Unsteady Advection Diffusion solvers (!1290) **PulseWaveSolver** - Parallelised solver (!1337) **NekMesh** - Allow for one or more blank lines between sections in Tecplot ascii (.dat) files (!1322) - Small bug-fix for Python API for unused configuration options (!1348) - Fix bug in ProcessVarOpti/ElUtil for segfault on non-tri or tet meshes (!1381) **CompressibleFlowSolver** - Added physical AV, dilatation sensor, Ducros's and smoothing (!1180) - Added timers around important functions using the Timer class. Timers are available by specifying IO_Timer_Level > -1 (!1347) - Fixed bug in the calculation of the discontinuity penalty factor for the DiffusionIP implementation (!1368) **Documentation** - Fix images not being displayed in HTML documentation and tutorials (!1370) **CI** - Remove unused build options (!1360) - Enable NEKTAR_USE_VTK across full builds and in docker image (!1358) **Packaging** - Fix various issues with debian unstable and centos8 packaging (!1362) - Fix missing texlive package dependency for centos packaging (!1382) As always, if you encounter any problems please feel free to contact us on the mailing list nektar-users(a)imperial.ac.uk. Cheers, Chris -- Chris Cantwell Senior Lecturer in Aeronautics Department of Aeronautics Imperial College London South Kensington Campus London SW7 2AZ Tel: +44 (0)20 759 45050 Email: c.cantwell(a)imperial.ac.uk www.imperial.ac.uk/people/c.cantwell

1 0

Re: [Nektar-users] [EXTERNAL] Re: Mapped boundaries
by Marc Goldbach 17 Aug '22

17 Aug '22

Hi James, I reviewed the details of the paper you referenced regarding the synthetic turbulence specification based on Davison's method. Is this something that is already implemented in Nektar++, and if so, how do you specify it? I cannot find details on how to implement it in the user guide or in the paper. Regards, *Marc Goldbach* PhD Student, Department of Mechanical Engineering University of North Carolina at Charlotte On Fri, Aug 12, 2022 at 4:21 PM Marc Goldbach <mgoldbac(a)uncc.edu> wrote: > You may be onto something here... > > I am copying the method from the implementation of the Womersley BC. For > my boundary, it is specified as: > > <REGION REF="0"> > <D VAR="u" USERDEFINEDTYPE="Mapped:x:8.0" VALUE="0" /> > <D VAR="v" USERDEFINEDTYPE="Mapped:x:8.0" VALUE="0" /> > <D VAR="w" USERDEFINEDTYPE="Mapped:x:8.0" VALUE="0" /> > <N VAR="p" USERDEFINEDTYPE="Mapped:x:8.0" VALUE="0" /> > </REGION> > > And if I modify the value of "VALUE" to something else, e.g.: > > <REGION REF="0"> > <D VAR="u" USERDEFINEDTYPE="Mapped:x:8.0" VALUE="1" /> > <D VAR="v" USERDEFINEDTYPE="Mapped:x:8.0" VALUE="0" /> > <D VAR="w" USERDEFINEDTYPE="Mapped:x:8.0" VALUE="0" /> > <N VAR="p" USERDEFINEDTYPE="Mapped:x:8.0" VALUE="0" /> > </REGION> > > The value at the inlet boundary is modified to reflect the "VALUE" entry. > > *Marc Goldbach* > PhD Student, Department of Mechanical Engineering > University of North Carolina at Charlotte > > > On Fri, Aug 12, 2022 at 10:46 AM Slaughter, James W < > j.slaughter19(a)imperial.ac.uk> wrote: > >> Hi Marc, >> >> Possibly, should work. But I have no idea whether the ordering on a >> boundary is the same as an internal element. Might be something worth >> checking? >> >> Are you creating a whole new BC type? If so, have you setup the >> appropriate syntax for the session file reader. And what syntax are you >> using for the BC in the session file? If you have <D VAR="u" VALUE="0" /> >> then you've still only set a zero-Dirchlet BC. I'd then double check in the >> solver how this is called - Dirichlet BCs are handled separately than >> internal nodes - so perhaps your values are just getting overwritten? >> >> Cheers, >> James. >> >> >> ------------------------------ >> *From:* Marc Goldbach <mgoldbac(a)uncc.edu> >> *Sent:* 12 August 2022 14:49 >> *To:* Slaughter, James W <j.slaughter19(a)imperial.ac.uk>; nektar-users < >> nektar-users(a)imperial.ac.uk> >> *Subject:* Re: [EXTERNAL] Re: [Nektar-users] Mapped boundaries >> >> Hi James, >> >> Just to clarify, since sending my original email, I have moved away from >> trying to use the history points filter. My mesh is structured hexahedral, >> so every mesh point on the boundary corresponds to a mesh point on the >> source plane from which I'd like to extract values. Rather than >> interpolating I use something like the following to get a list of points >> that define the source plane. >> >> for (int i=0; i < nBndPts; ++i) //for each point in boundary >> { >> dist = 1e6; >> srcPointi = {location, bndYCoords[i], bndZCoords[i]}; >> for (int j=0; j < nVolPts; ++j) //for each point in volume >> { >> volPointj = {volXCoords[j], volYCoords[j], volZCoords[j]}; >> tdist = Nektar::distanceBetween(srcPointi, volPointj); >> if (tdist < dist) >> { >> dist = tdist; >> srcPtsIdx = j; >> } >> } >> } >> m_mappedParams[fldid][bndid]->m_mapidx.push_back(srcPtsIdx); >> >> Here, location is the x-coordinate of the plane I want to extract values >> from. This populates the fromptsidx array, and then I read values from >> volume field using: >> >> MultiRegions::ExpListSharedPtr &VolFieldExp = m_fields[fldid]; >> VolFieldExp->GetPhys(fromptsidx[i]) >> >> And then I am attempting to simply set the boundary values for each mesh >> point to be the same as the value from the corresponding point of the >> source plane: >> >> Bvals = BndCondExp->UpdatePhys(); >> >> for (int i; i < exp_npts; ++i) >> { >> Bvals[i] = VolFieldExp->GetPhys(fromptsidx[i]); >> } >> >> I understand that this is not going to work for the general case of an >> arbitrary mesh, but for my case with the hexahedral mesh, I suppose it >> should work? >> >> *Marc Goldbach* >> PhD Student, Department of Mechanical Engineering >> University of North Carolina at Charlotte >> >> >> On Thu, Aug 11, 2022 at 8:54 PM Slaughter, James W < >> j.slaughter19(a)imperial.ac.uk> wrote: >> >> Hi Marc, >> >> Yep, so with regards to the plane in History points it will create >> something equispaced. Data at these points will just be interpolated and >> dumped essentially as a vector rather than containing any connectivity >> information etc. You'd need to translate that data to the inlet and then >> interpolate to the boundary and onto the mesh. We do have a utility for >> that - if you check the functionality in >> FieldUtils/ProcessModules/Interpdatatofield.cpp it should take in a >> somewhat of a n x m array and interpolate it to a field object. But just >> trying to grab an ID from the HistoryPoints object won't work. >> >> I suppose if you got the bounding box of the boundary region - then used >> that to translate and then interpolated to the boundary - it might be >> feasible. Just may take a fair bit of tweaking to get setup. >> >> I'm not sure of the problem you're considering as well but with our >> stabilisation methodologies and if you have much heterogeneity in your mesh >> you can actually filter any of the inlet turbulence as well. This is >> probably still more of an issue in FVM because of the >> diffusivity/dispersion characteristics of the methods. But it is one of the >> advantages of the method Andrea uses in the paper - that its local to the >> body/region of interest so can have greater control over the desired >> characteristics of the noise or whatever thats applied. >> >> Good luck with it! And let me know if you get it running - its definitely >> something I'd like to consider in the future. >> >> Cheers, >> James. >> ------------------------------ >> *From:* Marc Goldbach <mgoldbac(a)uncc.edu> >> *Sent:* 12 August 2022 01:38 >> *To:* Slaughter, James W <j.slaughter19(a)imperial.ac.uk>; nektar-users < >> nektar-users(a)imperial.ac.uk> >> *Subject:* Re: [EXTERNAL] Re: [Nektar-users] Mapped boundaries >> >> Thanks James for your response. You are correct… I am trying to setup a >> turbulent inlet bc. I will check the reference you provided. >> >> In regards to writing the data to file, I was hoping to be able to read >> the values from memory to avoid the need to write a large amount of data, >> but I am guessing there is something wrong with my approach here. >> >> Regards, >> Marc >> >> On Thu, Aug 11, 2022 at 8:19 PM Slaughter, James W < >> j.slaughter19(a)imperial.ac.uk> wrote: >> >> [*Caution*: Email from External Sender. Do not click or open links or >> attachments unless you know this sender.] >> >> Hi Marc, >> >> I'm guessing you're trying to setup a mapped inlet turbulent bc? >> >> If you look at a paper by Andrea Cassinelli titled ON THE EFFECT OF >> INFLOW DISTURBANCES ON THE FLOW PAST A LINEAR LPT VANE USING SPECTRAL/HP >> ELEMENT METHODS you'll see some of the ways we usually set turbulence >> parameters. >> >> The mapped plane method isn't something we really can do easily at the >> moment. I guess when we have python wrappers for the solvers this might be >> a lot more possible. But you'll need to translate then interpolate the >> HistoryPoints sampled plane to the inlet points. This coupling I'm not sure >> would be easily achievable given what we have there at the moment. >> >> Dumping to file as you suggest as well is the obvious solution but >> considering the length and timescales of the turbulent structures you >> probably want at the inlet - it'd be a lot of files and a lot of data. >> >> I'd wait and see if you get a response from one of the Senior Devs who >> might have a bit more of an idea on if it might be achievable - but from my >> experience this would be extremely tricky and would require a fair bit of >> development time. >> >> Cheers, >> James. >> ------------------------------ >> *From:* nektar-users-bounces(a)imperial.ac.uk < >> nektar-users-bounces(a)imperial.ac.uk> on behalf of Marc Goldbach < >> mgoldbac(a)uncc.edu> >> *Sent:* 11 August 2022 21:45 >> *To:* nektar-users <nektar-users(a)imperial.ac.uk> >> *Subject:* Re: [Nektar-users] Mapped boundaries >> >> >> This email from mgoldbac(a)uncc.edu 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. >> >> >> Hi All, >> >> To accomplish what I had described below, I am trying to implement a new >> boundary condition. Basically, I have implemented "SetUpMappedBoundary" >> and "SetMappedBoundary" functions in " >> solvers/IncNavierStokesSolver/EquationSystems/IncNavierStokes.cpp" >> similar to how the Womersly boundary is implemented. In " >> SetUpMappedBoundary", a "fromptsidx" array is populated where each >> element in the array corresponds to a node on the boundary, and the values >> of the "fromptsidx" array stores the corresponding index in the volume >> field expansion from which the physical value is to be extracted. >> >> In "SetMappedBoundary", I expect to be able to set the boundary using: >> >> Bvals = BndCondExp->UpdatePhys(); >> >> for (int i; i < exp_npts; ++i) >> { >> Bvals[i] = VolFieldExp->GetPhys(fromptsidx[i]); >> } >> >> However, when running the simulation the boundary values are not updated >> (but are set to a 0 value everywhere on the boundary). When printing >> debugging information from SetMappedBoundary function it seems that the >> Bvals array does contain non-zero values: >> >> Setting mapped boundary... >> min volField, fldid = 0: -0.236872 >> max volField, fldid = 0: 0.0905436 >> avg volField, fldid = 0: -0.00344391 >> nVolField: 198 >> min Bval, fldid = 0: -0.233878 >> max Bval, fldid = 0: 1 >> >> Any suggestions on how I can correctly update inlet boundary values from >> the Bvals array? >> >> Regards, >> >> *Marc Goldbach* >> PhD Student, Department of Mechanical Engineering >> University of North Carolina at Charlotte >> >> >> On Sun, Jun 5, 2022 at 6:44 PM Marc Goldbach <mgoldbac(a)uncc.edu> wrote: >> >> Hi All, >> >> I would like to sample data from a plane within my domain (turbulent >> channel), and use those values as the inlet boundary. The plane at which >> data is sampled is in the middle of the domain, so a periodic boundary is >> not suitable. Is this possible, and if so how can I do this? >> >> So far I have looked at using the "HistoryPoints" filter to extract data >> from the simulation along a plane, but I cannot quite figure out how to >> read the time dependent boundary data from file: >> >> 88 <BOUNDARYCONDITIONS> >> 95 <REGION REF="0"> >> 96 <D VAR="u" FILE="periodicInlet_"/> >> 97 <D VAR="v" VALUE="0" /> >> 98 <D VAR="w" VALUE="0" /> >> 99 <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> >> 100 </REGION> >> ... >> 185 </BOUNDARYCONDITIONS> >> ... >> 256 <FILTER TYPE="HistoryPoints"> >> 257 <PARAM NAME="OutputFile">periodicInlet</PARAM> >> 258 <PARAM NAME="OutputFrequency">1</PARAM> >> 259 <PARAM NAME="OutputOneFile">false</PARAM> >> 260 <PARAM NAME="plane"> >> 261 100, 100, >> 262 0, 0, 0, >> 263 0, 7, 0, >> 264 0, 0, 2, >> 265 0, 7, 2 >> 266 </PARAM> >> 267 </FILTER> >> >> When using <PARAM NAME="OutputOneFile">false</PARAM>, the history point >> data is saved in files based on index (e.g. periodicInlet_0, >> periodicInlet_1, periodicInlet_2, etc.) >> >> Any suggestions are appreciated. >> >> Regards, >> >> *Marc Goldbach* >> PhD Student, Department of Mechanical Engineering >> University of North Carolina at Charlotte >> >> -- >> >> *Marc Goldbach* >> PhD Student, Department of Mechanical Engineering >> University of North Carolina at Charlotte >> >>

1 0

NekTar++ Compilation of MacOS Monterary
by Shukla, Khemraj 16 Aug '22

16 Aug '22

******************* 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- I have to add a couple of cpp routines to NeTar++ and I was trying to compile the NekTar++ on my MacOS monterey. I am landing up in the following issue. I am using the Clang compiler. I also switched it to the gcc compiler but in that case the issue was coming from the Boost Library. I tried to compile Boost from source but no luck. Therefore I had to switch to clang and installed it through macport. I will appreciate your help in this regard. Thanks! Raj /nektar++/library/LibUtilities/SimdLib/scalar.hpp:124:12: error: definition of implicit copy assignment operator for 'scalarT<unsigned long long, void>' is deprecated because it has a user-declared copy constructor [-Werror,-Wdeprecated-copy] inline scalarT(const scalarT &rhs) = default; ^

2 7

Re: [Nektar-users] [EXTERNAL] Re: Mapped boundaries
by Marc Goldbach 12 Aug '22

12 Aug '22

Hi James, Just to clarify, since sending my original email, I have moved away from trying to use the history points filter. My mesh is structured hexahedral, so every mesh point on the boundary corresponds to a mesh point on the source plane from which I'd like to extract values. Rather than interpolating I use something like the following to get a list of points that define the source plane. for (int i=0; i < nBndPts; ++i) //for each point in boundary { dist = 1e6; srcPointi = {location, bndYCoords[i], bndZCoords[i]}; for (int j=0; j < nVolPts; ++j) //for each point in volume { volPointj = {volXCoords[j], volYCoords[j], volZCoords[j]}; tdist = Nektar::distanceBetween(srcPointi, volPointj); if (tdist < dist) { dist = tdist; srcPtsIdx = j; } } } m_mappedParams[fldid][bndid]->m_mapidx.push_back(srcPtsIdx); Here, location is the x-coordinate of the plane I want to extract values from. This populates the fromptsidx array, and then I read values from volume field using: MultiRegions::ExpListSharedPtr &VolFieldExp = m_fields[fldid]; VolFieldExp->GetPhys(fromptsidx[i]) And then I am attempting to simply set the boundary values for each mesh point to be the same as the value from the corresponding point of the source plane: Bvals = BndCondExp->UpdatePhys(); for (int i; i < exp_npts; ++i) { Bvals[i] = VolFieldExp->GetPhys(fromptsidx[i]); } I understand that this is not going to work for the general case of an arbitrary mesh, but for my case with the hexahedral mesh, I suppose it should work? *Marc Goldbach* PhD Student, Department of Mechanical Engineering University of North Carolina at Charlotte On Thu, Aug 11, 2022 at 8:54 PM Slaughter, James W < j.slaughter19(a)imperial.ac.uk> wrote: > Hi Marc, > > Yep, so with regards to the plane in History points it will create > something equispaced. Data at these points will just be interpolated and > dumped essentially as a vector rather than containing any connectivity > information etc. You'd need to translate that data to the inlet and then > interpolate to the boundary and onto the mesh. We do have a utility for > that - if you check the functionality in > FieldUtils/ProcessModules/Interpdatatofield.cpp it should take in a > somewhat of a n x m array and interpolate it to a field object. But just > trying to grab an ID from the HistoryPoints object won't work. > > I suppose if you got the bounding box of the boundary region - then used > that to translate and then interpolated to the boundary - it might be > feasible. Just may take a fair bit of tweaking to get setup. > > I'm not sure of the problem you're considering as well but with our > stabilisation methodologies and if you have much heterogeneity in your mesh > you can actually filter any of the inlet turbulence as well. This is > probably still more of an issue in FVM because of the > diffusivity/dispersion characteristics of the methods. But it is one of the > advantages of the method Andrea uses in the paper - that its local to the > body/region of interest so can have greater control over the desired > characteristics of the noise or whatever thats applied. > > Good luck with it! And let me know if you get it running - its definitely > something I'd like to consider in the future. > > Cheers, > James. > ------------------------------ > *From:* Marc Goldbach <mgoldbac(a)uncc.edu> > *Sent:* 12 August 2022 01:38 > *To:* Slaughter, James W <j.slaughter19(a)imperial.ac.uk>; nektar-users < > nektar-users(a)imperial.ac.uk> > *Subject:* Re: [EXTERNAL] Re: [Nektar-users] Mapped boundaries > > Thanks James for your response. You are correct… I am trying to setup a > turbulent inlet bc. I will check the reference you provided. > > In regards to writing the data to file, I was hoping to be able to read > the values from memory to avoid the need to write a large amount of data, > but I am guessing there is something wrong with my approach here. > > Regards, > Marc > > On Thu, Aug 11, 2022 at 8:19 PM Slaughter, James W < > j.slaughter19(a)imperial.ac.uk> wrote: > > [*Caution*: Email from External Sender. Do not click or open links or > attachments unless you know this sender.] > > Hi Marc, > > I'm guessing you're trying to setup a mapped inlet turbulent bc? > > If you look at a paper by Andrea Cassinelli titled ON THE EFFECT OF INFLOW > DISTURBANCES ON THE FLOW PAST A LINEAR LPT VANE USING SPECTRAL/HP ELEMENT > METHODS you'll see some of the ways we usually set turbulence parameters. > > The mapped plane method isn't something we really can do easily at the > moment. I guess when we have python wrappers for the solvers this might be > a lot more possible. But you'll need to translate then interpolate the > HistoryPoints sampled plane to the inlet points. This coupling I'm not sure > would be easily achievable given what we have there at the moment. > > Dumping to file as you suggest as well is the obvious solution but > considering the length and timescales of the turbulent structures you > probably want at the inlet - it'd be a lot of files and a lot of data. > > I'd wait and see if you get a response from one of the Senior Devs who > might have a bit more of an idea on if it might be achievable - but from my > experience this would be extremely tricky and would require a fair bit of > development time. > > Cheers, > James. > ------------------------------ > *From:* nektar-users-bounces(a)imperial.ac.uk < > nektar-users-bounces(a)imperial.ac.uk> on behalf of Marc Goldbach < > mgoldbac(a)uncc.edu> > *Sent:* 11 August 2022 21:45 > *To:* nektar-users <nektar-users(a)imperial.ac.uk> > *Subject:* Re: [Nektar-users] Mapped boundaries > > > This email from mgoldbac(a)uncc.edu 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. > > > Hi All, > > To accomplish what I had described below, I am trying to implement a new > boundary condition. Basically, I have implemented "SetUpMappedBoundary" > and "SetMappedBoundary" functions in " > solvers/IncNavierStokesSolver/EquationSystems/IncNavierStokes.cpp" > similar to how the Womersly boundary is implemented. In " > SetUpMappedBoundary", a "fromptsidx" array is populated where each > element in the array corresponds to a node on the boundary, and the values > of the "fromptsidx" array stores the corresponding index in the volume > field expansion from which the physical value is to be extracted. > > In "SetMappedBoundary", I expect to be able to set the boundary using: > > Bvals = BndCondExp->UpdatePhys(); > > for (int i; i < exp_npts; ++i) > { > Bvals[i] = VolFieldExp->GetPhys(fromptsidx[i]); > } > > However, when running the simulation the boundary values are not updated > (but are set to a 0 value everywhere on the boundary). When printing > debugging information from SetMappedBoundary function it seems that the > Bvals array does contain non-zero values: > > Setting mapped boundary... > min volField, fldid = 0: -0.236872 > max volField, fldid = 0: 0.0905436 > avg volField, fldid = 0: -0.00344391 > nVolField: 198 > min Bval, fldid = 0: -0.233878 > max Bval, fldid = 0: 1 > > Any suggestions on how I can correctly update inlet boundary values from > the Bvals array? > > Regards, > > *Marc Goldbach* > PhD Student, Department of Mechanical Engineering > University of North Carolina at Charlotte > > > On Sun, Jun 5, 2022 at 6:44 PM Marc Goldbach <mgoldbac(a)uncc.edu> wrote: > > Hi All, > > I would like to sample data from a plane within my domain (turbulent > channel), and use those values as the inlet boundary. The plane at which > data is sampled is in the middle of the domain, so a periodic boundary is > not suitable. Is this possible, and if so how can I do this? > > So far I have looked at using the "HistoryPoints" filter to extract data > from the simulation along a plane, but I cannot quite figure out how to > read the time dependent boundary data from file: > > 88 <BOUNDARYCONDITIONS> > 95 <REGION REF="0"> > 96 <D VAR="u" FILE="periodicInlet_"/> > 97 <D VAR="v" VALUE="0" /> > 98 <D VAR="w" VALUE="0" /> > 99 <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> > 100 </REGION> > ... > 185 </BOUNDARYCONDITIONS> > ... > 256 <FILTER TYPE="HistoryPoints"> > 257 <PARAM NAME="OutputFile">periodicInlet</PARAM> > 258 <PARAM NAME="OutputFrequency">1</PARAM> > 259 <PARAM NAME="OutputOneFile">false</PARAM> > 260 <PARAM NAME="plane"> > 261 100, 100, > 262 0, 0, 0, > 263 0, 7, 0, > 264 0, 0, 2, > 265 0, 7, 2 > 266 </PARAM> > 267 </FILTER> > > When using <PARAM NAME="OutputOneFile">false</PARAM>, the history point > data is saved in files based on index (e.g. periodicInlet_0, > periodicInlet_1, periodicInlet_2, etc.) > > Any suggestions are appreciated. > > Regards, > > *Marc Goldbach* > PhD Student, Department of Mechanical Engineering > University of North Carolina at Charlotte > > -- > > *Marc Goldbach* > PhD Student, Department of Mechanical Engineering > University of North Carolina at Charlotte >

1 0

Re: [Nektar-users] [EXTERNAL] Re: Mapped boundaries
by Marc Goldbach 12 Aug '22

12 Aug '22

Thanks James for your response. You are correct… I am trying to setup a turbulent inlet bc. I will check the reference you provided. In regards to writing the data to file, I was hoping to be able to read the values from memory to avoid the need to write a large amount of data, but I am guessing there is something wrong with my approach here. Regards, Marc On Thu, Aug 11, 2022 at 8:19 PM Slaughter, James W < j.slaughter19(a)imperial.ac.uk> wrote: > [*Caution*: Email from External Sender. Do not click or open links or > attachments unless you know this sender.] > > Hi Marc, > > I'm guessing you're trying to setup a mapped inlet turbulent bc? > > If you look at a paper by Andrea Cassinelli titled ON THE EFFECT OF INFLOW > DISTURBANCES ON THE FLOW PAST A LINEAR LPT VANE USING SPECTRAL/HP ELEMENT > METHODS you'll see some of the ways we usually set turbulence parameters. > > The mapped plane method isn't something we really can do easily at the > moment. I guess when we have python wrappers for the solvers this might be > a lot more possible. But you'll need to translate then interpolate the > HistoryPoints sampled plane to the inlet points. This coupling I'm not sure > would be easily achievable given what we have there at the moment. > > Dumping to file as you suggest as well is the obvious solution but > considering the length and timescales of the turbulent structures you > probably want at the inlet - it'd be a lot of files and a lot of data. > > I'd wait and see if you get a response from one of the Senior Devs who > might have a bit more of an idea on if it might be achievable - but from my > experience this would be extremely tricky and would require a fair bit of > development time. > > Cheers, > James. > ------------------------------ > *From:* nektar-users-bounces(a)imperial.ac.uk < > nektar-users-bounces(a)imperial.ac.uk> on behalf of Marc Goldbach < > mgoldbac(a)uncc.edu> > *Sent:* 11 August 2022 21:45 > *To:* nektar-users <nektar-users(a)imperial.ac.uk> > *Subject:* Re: [Nektar-users] Mapped boundaries > > > This email from mgoldbac(a)uncc.edu 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. > > > Hi All, > > To accomplish what I had described below, I am trying to implement a new > boundary condition. Basically, I have implemented "SetUpMappedBoundary" > and "SetMappedBoundary" functions in " > solvers/IncNavierStokesSolver/EquationSystems/IncNavierStokes.cpp" > similar to how the Womersly boundary is implemented. In " > SetUpMappedBoundary", a "fromptsidx" array is populated where each > element in the array corresponds to a node on the boundary, and the values > of the "fromptsidx" array stores the corresponding index in the volume > field expansion from which the physical value is to be extracted. > > In "SetMappedBoundary", I expect to be able to set the boundary using: > > Bvals = BndCondExp->UpdatePhys(); > > for (int i; i < exp_npts; ++i) > { > Bvals[i] = VolFieldExp->GetPhys(fromptsidx[i]); > } > > However, when running the simulation the boundary values are not updated > (but are set to a 0 value everywhere on the boundary). When printing > debugging information from SetMappedBoundary function it seems that the > Bvals array does contain non-zero values: > > Setting mapped boundary... > min volField, fldid = 0: -0.236872 > max volField, fldid = 0: 0.0905436 > avg volField, fldid = 0: -0.00344391 > nVolField: 198 > min Bval, fldid = 0: -0.233878 > max Bval, fldid = 0: 1 > > Any suggestions on how I can correctly update inlet boundary values from > the Bvals array? > > Regards, > > *Marc Goldbach* > PhD Student, Department of Mechanical Engineering > University of North Carolina at Charlotte > > > On Sun, Jun 5, 2022 at 6:44 PM Marc Goldbach <mgoldbac(a)uncc.edu> wrote: > > Hi All, > > I would like to sample data from a plane within my domain (turbulent > channel), and use those values as the inlet boundary. The plane at which > data is sampled is in the middle of the domain, so a periodic boundary is > not suitable. Is this possible, and if so how can I do this? > > So far I have looked at using the "HistoryPoints" filter to extract data > from the simulation along a plane, but I cannot quite figure out how to > read the time dependent boundary data from file: > > 88 <BOUNDARYCONDITIONS> > 95 <REGION REF="0"> > 96 <D VAR="u" FILE="periodicInlet_"/> > 97 <D VAR="v" VALUE="0" /> > 98 <D VAR="w" VALUE="0" /> > 99 <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> > 100 </REGION> > ... > 185 </BOUNDARYCONDITIONS> > ... > 256 <FILTER TYPE="HistoryPoints"> > 257 <PARAM NAME="OutputFile">periodicInlet</PARAM> > 258 <PARAM NAME="OutputFrequency">1</PARAM> > 259 <PARAM NAME="OutputOneFile">false</PARAM> > 260 <PARAM NAME="plane"> > 261 100, 100, > 262 0, 0, 0, > 263 0, 7, 0, > 264 0, 0, 2, > 265 0, 7, 2 > 266 </PARAM> > 267 </FILTER> > > When using <PARAM NAME="OutputOneFile">false</PARAM>, the history point > data is saved in files based on index (e.g. periodicInlet_0, > periodicInlet_1, periodicInlet_2, etc.) > > Any suggestions are appreciated. > > Regards, > > *Marc Goldbach* > PhD Student, Department of Mechanical Engineering > University of North Carolina at Charlotte > > -- *Marc Goldbach* PhD Student, Department of Mechanical Engineering University of North Carolina at Charlotte

1 0