May 2019 - Nektar-users - imperial.ac.uk

Element with max CFL
by Vishal Saini 02 Apr '20

02 Apr '20

Hi all, Quick question: Has anyone tried to check the location of a particular element in the mesh? A log file reports the maximum (?) CFL and the corresponding element as: "CFL: 0.0337915 (in elmt 94488)"? Is there a quick way to locate "elmt 94488"? Cheers, Vishal

2 2

Re: [Nektar-users] Possibility of adding velocity dependent terms to the existing Incompressible Navier Stokes solver
by Swagat Kumar Nayak 31 May '19

31 May '19

Hi, Thanks for the reply. I think I should be able to do that. Thanks again! Swagat On Fri, May 31, 2019, 7:03 PM Stanisław Gepner <sgepner(a)meil.pw.edu.pl> wrote: > Hi Swagat, > > The MovingReferenceFrame has been implemented only for constant > velocity of the Frame. That is it can not be a function of time and > space. So I am afraid it will not work the way you are trying to do it > here, only by putting appropriate values in the xml file. > > What I meant is, that if you know what terms you need to add to the NS > equation, you could manipulate the source of Nektar - essentially write > a new Forcing function - very mych like the MovingReferenceFrame is > written. There the NS equation is supplemented by sth. like > > c_x * \partial u / \partial x > > with c_x the speed of the moving frame. > > Cheers, > Stan > > On pią, 2019-05-31 at 18:20 +0900, Swagat Kumar Nayak wrote: > > Hi Stanisław, > > > > Thanks for your reply. I checked the files. I think that if I add the > > frame velocity and the appropriate Initial and Boundary conditions, > > then I hope that it should work for me. Though, I am unsure about its > > implementation. Does the way I am implementing it, seem correct? > > > > <NEKTAR> > >  > > <EXPANSIONS> > > ............................. > > </EXPANSIONS> > > > >  > > <FILTERS> > > ............................. > > </FILTERS> > > > >  > > <CONDITIONS> > > <SOLVERINFO> > > .............................. > > </SOLVERINFO> > > > > <PARAMETERS> > > ............................. > > </PARAMETERS> > > > >  > > > > <VARIABLES> > > <V ID="0"> u </V> > > <V ID="1"> v </V> > > <V ID="2"> w </V> > > <V ID="3"> p </V> > > </VARIABLES> > > > >  > > <BOUNDARYREGIONS> > > ........................................ > > </BOUNDARYREGIONS> > > > > <BOUNDARYCONDITIONS> > > ................................................. > > </BOUNDARYCONDITIONS> > > > >  > > > > <FUNCTION NAME="InitialConditions"> > > <E VAR="u" VALUE="F(y)" /> > > <E VAR="v" VALUE="G(x)" /> > > <E VAR="w" VALUE="0" /> > > <E VAR="p" VALUE="0" /> > > </FUNCTION> > > > > <FORCE TYPE="MovingReferenceFrame"> > > <FRAMEVELOCITY> > > <FUNCTION NAME="MovingReferenceFrame"> > > <E VAR="u" VALUE="f(y,z,t)" /> > > <E VAR="v" VALUE="g(y,z,t)" /> > > <E VAR="w" VALUE="0" /> > > </FUNCTION> > > <FRAMEVELOCITY/> > > </FORCE> > > > > </CONDITIONS> > > </NEKTAR> > > > > Thank you ! > > Swagat Kumar Nayak > > > > On Wed, May 29, 2019 at 7:14 PM Stanisław Gepner < > > sgepner(a)meil.pw.edu.pl> wrote: > > > Hi Swagat, > > > > > > Not sure anyone answered this. > > > > > > 1) You could try to add a Forcing term. Much like ForcingBody in > > > library/Solverutils/Forcing. I think something similar to what you > > > describe has been done for the moving reference frame > > > (ForcingMovingReferenceFrame) i.e. additional terms that are > > > gradient > > > of velocity. > > > > > > 2) At the end of the .geo file there is a protion where Physical > > > objects are declared. Sth. like: > > > > > > Physical Line(1) = {3,1,2,4}; > > > Physical Surface(2) = {6}; > > > > > > My experience with NekMesh is that composite 2 is the 2D domain and > > > composite 1 the boundary. > > > > > > Cheers, > > > Stan > > > > > > On czw, 2019-05-23 at 14:25 +0900, Swagat Kumar Nayak wrote: > > > > Hi everyone, > > > > > > > > I am trying to simulate the flow of a precessing cylinder in the > > > > cylinder frame of reference. I have got some additional terms in > > > the > > > > incompressible Navier-stokes equation which are velocity > > > dependent. > > > > (1) How do I add these additional terms to the incompressible > > > Navier- > > > > stokes equation? > > > > > > > > (2) When I create a mesh in Gmsh and try to convert it into the > > > .xml > > > > file format, how do I identify the composites corresponding to > > > the > > > > global boundaries? > > > > > > > > I am new to this framework. So, any help will be largely > > > appreciated. > > > > > > > > > > > > Thank you, > > > > > > > > _______________________________________________ > > > > Nektar-users mailing list > > > > Nektar-users(a)imperial.ac.uk > > > > https://mailman.ic.ac.uk/mailman/listinfo/nektar-users > > > > > > > > >

1 0

Implementation of Force Type "MovingReferenceFrame" in Nektar++
by Swagat Kumar Nayak 31 May '19

31 May '19

Hi all, I intend to solve the Incompressible Navier Stokes equations in a rotating reference frame. Hence, I am adding the frame velocity of the rotating frame as a Force Type = "MovingReferenceFrame". Will it add the appropriate Coriolis term? Also, does the implementation seem correct? <NEKTAR>  <EXPANSIONS> ............................. </EXPANSIONS>  <FILTERS> ............................. </FILTERS>  <CONDITIONS> <SOLVERINFO> .............................. </SOLVERINFO> <PARAMETERS> ............................. </PARAMETERS>  <VARIABLES> <V ID="0"> u </V> <V ID="1"> v </V> <V ID="2"> w </V> <V ID="3"> p </V> </VARIABLES>  <BOUNDARYREGIONS> ........................................ </BOUNDARYREGIONS> <BOUNDARYCONDITIONS> ................................................. </BOUNDARYCONDITIONS>  <FUNCTION NAME="InitialConditions"> <E VAR="u" VALUE="F(y)" /> <E VAR="v" VALUE="G(x)" /> <E VAR="w" VALUE="0" /> <E VAR="p" VALUE="0" /> </FUNCTION> <FORCE TYPE="MovingReferenceFrame"> <FRAMEVELOCITY> <FUNCTION NAME="MovingReferenceFrame"> <E VAR="u" VALUE="f(y,z,t)" /> <E VAR="v" VALUE="g(y,z,t)" /> <E VAR="w" VALUE="0" /> </FUNCTION> <FRAMEVELOCITY/> </FORCE> </CONDITIONS> </NEKTAR> Thank you ! -- *Swagat Kumar Nayak * *Department of Mechanical Engineering* *IIT Kharagpur*

2 1

Possibility of adding velocity dependent terms to the existing Incompressible Navier Stokes solver
by Swagat Kumar Nayak 29 May '19

29 May '19

Hi everyone, I am trying to simulate the flow of a precessing cylinder in the cylinder frame of reference. I have got some additional terms in the incompressible Navier-stokes equation which are velocity dependent. (1) How do I add these additional terms to the incompressible Navier-stokes equation? (2) When I create a mesh in Gmsh and try to convert it into the .xml file format, how do I identify the composites corresponding to the global boundaries? I am new to this framework. So, any help will be largely appreciated. Thank you, -- *Swagat Kumar Nayak * *Department of Mechanical Engineering* *IIT Kharagpur*

2 1

Womersley boundary condition for blood flow simulation
by zxiong＠sas.upenn.edu 29 May '19

29 May '19

Dear all, We are trying to do blood flow simulation on a vessel geometry model. When we try to apply Womersley boundary condition to the inlet, we meet some problems. In Womersley boundary condition, we need to specify the property "axispoint" which should be the center of the vessel's inlet and the property "axisnormal" which should be the flow direction. However, we can only estimate these two value because they are not in the standard position(all the numbers are floating points). This causes the failure of simulation. So I want to know does Nektar++ require 100% accuracy in these two property? If so, does anyone have some suggestion? Many thanks! Best, Zhen

2 4

womersley boundary condition
by zxiong＠sas.upenn.edu 28 May '19

28 May '19

Dear all, We are trying to do blood flow simulation on a vessel geometry model. When we try to apply Womersley boundary condition to the inlet, we meet some problems. In Womersley boundary condition, we need to specify the property "axispoint" which should be the center of the vessel's inlet. However, we can only estimate the center of the inlet and this causes failure of simulation. Also, we are facing the same issue for the property "axisnormal". Does anyone have some suggestion? We are trying to change the coordinate system, but since the inlet is not a plane, it's still hard for us the accurately specify those two properties in Womersley boundary condition. Many thanks! Best, Zhen

2 1

Re: [Nektar-users] History point cannot be found in the mesh on the latest version
by Jeremy Cohen 28 May '19

28 May '19

Many thanks for highlighting this Dave, I've just built a version based on MR 1019 and can confirm that this resolves the issue. Cheers, Jeremy On 28 May 2019, at 10:04, Moxey, David <D.Moxey(a)exeter.ac.uk> wrote: > Hi Jeremy, Song, > > You might want to try out MR 1019: > > https://gitlab.nektar.info/nektar/nektar/merge_requests/1019 > > My student and I found a bug in the GetExpIndex function last week that > might also impact the history point lookups. > > Cheers, > > Dave > > On 2019-05-28 09:51, Jeremy Cohen wrote: >> Dear Song, >> >> Just to confirm, I've been able to recreate the error you're >> experiencing with a recent master build and have verified that running >> the same test case with 4.4.1 works ok. We'll investigate what is >> causing the issue and get back to you. >> >> Cheers, >> Jeremy >> >> On 27 May 2019, at 20:59, Sherwin, Spencer J >> <s.sherwin(a)imperial.ac.uk> wrote: >> >>> Dear Song, >>> >>> What machine are you running the code on? As you can see form >>> >>> https://buildbot.nektar.info/#/grid >>> >>> The virtual machines we are currently testing the code on seem to be >>> passing the test we have set up so I would have hoped it is running >>> OK for you too. If you run Nektar4.5.0 on another machine do you >>> still see the same issue? >>> >>> Cheers, >>> Spencer. >>> >>>> On 27 May 2019, at 08:53, Song Xiang <sxnwpu(a)outlook.com> wrote: >>>> >>>> _Dear all,_ >>>> _ On the latest nektar version, 4.5.0, __there is a problem with >>>> the given case >>>> (AcousticSolver/Tests/APE_2DPulseAdv_WeakDG_MODIFIED.xml). When >>>> the program runs，it will report an error "History point cannot >>>> be found in the mesh". __However,_ >>>> when the same xml file is used on a previous nektar version, >>>> 4.4.1, it is properly done. >>>> >>>> The history point is not a node of mesh but in the domain. When i >>>> use a node of mesh as history point, the program performs well on >>>> the latest version. Can not use the points which are not nodes of >>>> mesh as history points now? >>>> >>>> Thank you. >>>> >>>> Cheers, >>>> _ Song_ >>>> _______________________________________________ >>>> Nektar-users mailing list >>>> Nektar-users(a)imperial.ac.uk >>>> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users >>> >>> Spencer Sherwin FREng, FRAeS >>> Head, Aerodynamics, >>> Director of Research Computing Service, >>> Professor of Computational Fluid Mechanics, >>> Department of Aeronautics, >>> s.sherwin(a)imperial.ac.uk South >>> Kensington Campus, >>> Phone: +44 (0)20 7594 5052 Imperial >>> College London, >>> Fax: +44 (0)20 7594 1974 London, SW7 >>> 2AZ, UK >>> http://www.imperial.ac.uk/people/s.sherwin/ >>> >>> _______________________________________________ >>> Nektar-users mailing list >>> Nektar-users(a)imperial.ac.uk >>> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users >> _______________________________________________ >> Nektar-users mailing list >> Nektar-users(a)imperial.ac.uk >> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users > > -- > Dr David Moxey, PhD MMath MIMA FHEA > Senior Lecturer in Engineering > d.moxey(a)exeter.ac.uk | tel: 01392 424764 | web: davidmoxey.uk > > Room K1, Innovation Centre, > University of Exeter, > Exeter, EX4 4RN, UK.

2 1

History point cannot be found in the mesh on the latest version
by Song Xiang 28 May '19

28 May '19

Dear all, On the latest nektar version, 4.5.0, there is a problem with the given case (AcousticSolver/Tests/APE_2DPulseAdv_WeakDG_MODIFIED.xml). When the program runs，it will report an error "History point cannot be found in the mesh". However, when the same xml file is used on a previous nektar version, 4.4.1, it is properly done. The history point is not a node of mesh but in the domain. When i use a node of mesh as history point, the program performs well on the latest version. Can not use the points which are not nodes of mesh as history points now? Thank you. Cheers, Song

3 2

Regarding pressure eigenmode
by Abhishek Kumar 27 May '19

27 May '19

Dear friends, I am working on the linear stability problem. Is it possible to write pressure field as well in the dominant eigenmode file? Specifically for the adjoint problem. With regards Abhishek -- --------------------------------------------------------------------------------------- Abhishek Kumar Research Associate Centre for Fluid and Complex Systems Coventry University, Coventry CV15FB United Kingdom Webpage: https://abhishekkir.wixsite.com/website Email # ac7600(a)coventry.ac.uk, abhishek.kir(a)gmail.com Phone: +44 24 7765 9150 Mobile: +44 7464026494 ---------------------------------------------------------------------------------------

2 2

problem with velocity gradients on wall element boundaries
by Soha Nirumandi 27 May '19

27 May '19

Dear all, I would like toimplement a kind of boundary condition on wall. I need to calculatethe velocity gradients over wall elements. The same as the high orderpressure boundary condition, I want to calculate the velocitygradient on each wall elements with the following command: (elmt>PhysDeriv(MultiRegions::DirCartesianMap[j],velocity,grad)) then I extract thegradients value of the boundary with the following command: (elmt->GetEdgePhysVals(boundary,bc,grad,grad boundary ), considerthat I just brought the main sentence and these variables should bedefine. Due to thecoordinates, I know that I could reach the wall nodes with thesecommands, The only problem is with the value of velocity gradients.Regarding the 3d mesh elements, tetrahedron or hexahedron, the valuescan not get their correct value. For example in a hexahedron mesh Iget the wrong values of gradients on the boundaries of the wallelements. Besides, in the tetrahedron mesh, in some elements thegradients can be calculated correctly and in some can not and theboundary problem still exists. Is there any problemwith the above commands?Is there any specialmethod or library available for correctingthe wall elements boundary values? Can the problem stemfrom the mesh type? Regards,Soha

2 1