April 2020 - Nektar-users - imperial.ac.uk

Rotating boundary conditions
by Silvia Ceccacci (HDR) 12 Apr '20

12 Apr '20

******************* 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 hope you are all well and you are enjoying Easter Sunday! I want to impose a time-dependent boundary condition, which derives from the rotation of a sphere about the y-axis. It would be easier to do this in spherical coordinates, but as far as I have understood Nektar takes cartesian coordinates. So, this is the expression I am implementing (where the radius of the sphere is 0.03 and t_s=0.05): <REGION REF="3">  <D VAR="u" USERDEFINEDTYPE="TimeDependent" VALUE="((2*t)/(sqrt((t_s-t)^2)+t_s+t))*(-1)*sqrt(0.03*0.03-y*y)*sin(atan2(x,z))" /> <D VAR="v" VALUE="0" /> <D VAR="w" USERDEFINEDTYPE="TimeDependent" VALUE="((2*t)/(sqrt((t_s-t)^2)+t_s+t))*sqrt(0.03*0.03-y*y)*cos(atan2(x,z))" /> <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> </REGION> However, I get this error: [lorenz-node01:46958] *** Process received signal *** [lorenz-node01:46958] Signal: Segmentation fault (11) [lorenz-node01:46958] Signal code: Address not mapped (1) [lorenz-node01:46958] Failing at address: 0x1f0000000c [lorenz-node01:46958] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7f3c103c5f20] [lorenz-node01:46958] [ 1] /usr/lib/x86_64-linux-gnu/libMultiRegions.so.5.0.0(_ZN6Nektar12MultiRegions14DisContField3D34GenerateBoundaryConditionExpansionERKSt10shared_ptrINS_14SpatialDomains9MeshGraphEERKNS3_18BoundaryConditionsERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x3f6)[0x7f3c12dcfd56] [lorenz-node01:46958] [ 2] /usr/lib/x86_64-linux-gnu/libMultiRegions.so.5.0.0(_ZN6Nektar12MultiRegions14DisContField3DC1ERKS1_RKSt10shared_ptrINS_14SpatialDomains9MeshGraphEERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb+0x391)[0x7f3c12ddd7c1] [lorenz-node01:46958] [ 3] /usr/lib/x86_64-linux-gnu/libMultiRegions.so.5.0.0(_ZN6Nektar12MultiRegions11ContField3DC1ERKS1_RKSt10shared_ptrINS_14SpatialDomains9MeshGraphEERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb+0x42)[0x7f3c12d9b9a2] [lorenz-node01:46958] [ 4] /usr/lib/x86_64-linux-gnu/libSolverUtils.so.5.0.0(_ZN6Nektar11SolverUtils14EquationSystem12v_InitObjectEv+0x1c16)[0x7f3c13543786] [lorenz-node01:46958] [ 5] /usr/lib/x86_64-linux-gnu/libSolverUtils.so.5.0.0(_ZN6Nektar11SolverUtils14UnsteadySystem12v_InitObjectEv+0x3c)[0x7f3c135865ac] [lorenz-node01:46958] [ 6] /usr/lib/x86_64-linux-gnu/libSolverUtils.so.5.0.0(_ZN6Nektar11SolverUtils15AdvectionSystem12v_InitObjectEv+0x36)[0x7f3c134cb346] [lorenz-node01:46958] [ 7] IncNavierStokesSolver(_ZN6Nektar15IncNavierStokes12v_InitObjectEv+0x31)[0x55ff2560ff01] [lorenz-node01:46958] [ 8] IncNavierStokesSolver(_ZN6Nektar24VelocityCorrectionScheme12v_InitObjectEv+0x2c)[0x55ff2561b7dc] [lorenz-node01:46958] [ 9] IncNavierStokesSolver(_ZN6Nektar24VelocityCorrectionScheme6createERKSt10shared_ptrINS_12LibUtilities13SessionReaderEERKS1_INS_14SpatialDomains9MeshGraphEE+0x116)[0x55ff2561f486] [lorenz-node01:46958] [10] /usr/lib/x86_64-linux-gnu/libSolverUtils.so.5.0.0(_ZN6Nektar12LibUtilities10NekFactoryINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS_11SolverUtils14EquationSystemEJRKSt10shared_ptrINS0_13SessionReaderEERKSA_INS_14SpatialDomains9MeshGraphEEEE14CreateInstanceES7_SE_SJ_+0xa1)[0x7f3c13522d51] [lorenz-node01:46958] [11] /usr/lib/x86_64-linux-gnu/libSolverUtils.so.5.0.0(_ZN6Nektar11SolverUtils6Driver12v_InitObjectERSo+0xbb5)[0x7f3c13522275] [lorenz-node01:46958] [12] /usr/lib/x86_64-linux-gnu/libSolverUtils.so.5.0.0(_ZN6Nektar11SolverUtils14DriverStandard6createERKSt10shared_ptrINS_12LibUtilities13SessionReaderEERKS2_INS_14SpatialDomains9MeshGraphEE+0x17c)[0x7f3c135347fc] [lorenz-node01:46958] [13] IncNavierStokesSolver(_ZN6Nektar12LibUtilities10NekFactoryINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS_11SolverUtils6DriverEJRKSt10shared_ptrINS0_13SessionReaderEERKSA_INS_14SpatialDomains9MeshGraphEEEE14CreateInstanceES7_SE_SJ_+0x114)[0x55ff255e7fa4] [lorenz-node01:46958] [14] IncNavierStokesSolver(main+0x2d1)[0x55ff255c6de1] [lorenz-node01:46958] [15] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f3c103a8b97] [lorenz-node01:46958] [16] IncNavierStokesSolver(_start+0x2a)[0x55ff255e254a] [lorenz-node01:46958] *** End of error message *** Segmentation fault (core dumped) Could anybody help me to understand what the problem could be? Thank you in advance for your help. Kind regards, Silvia

1 0

Quasi-3D outlet boundary condition
by Moto Light 12 Apr '20

12 Apr '20

******************* 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. ******************* Hi All, First i wish all of you are fine and these bad days will past and you always be healthy, I am asking if I can implement *convective boundary conditions* in Quasi-3D simulations for my cases, for now i am using Robin boundary conditions for my 2D cases but still have a problem in Quasi-3D cases. any ideas for this outlet boundary conditions for my case *I am using for 2D * ---------------------------- <REGION REF="5">  <R VAR="u" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="D0/TimeStep" /> <R VAR="v" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="D0/TimeStep" /> <R VAR="p" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="1.0/(D0*Kinvis)" /> </REGION> -------------------- *and for my *Quasi-3D* using* -------------------------------------------- <REGION REF="5">  <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="0" /> </REGION> --------------------------------------- is there any modifications in the new ver 5.0 regarding outlet boundary conditions? Thanks, Regards, Reda UPC Spain

2 2

Flow around a sphere
by Silvia Ceccacci (HDR) 11 Apr '20

11 Apr '20

******************* 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 hope this email finds you all well. I am trying to simulate flow around a sphere. I get an error of segmentation fault. I am generating a mesh from gmsh, converting it into Nektar format, then using the IncNavierStokesSolver. I am wondering whether it may be a problem with the association of composite IDs in boundary conditions. However I do not seem to find the problem. I attach the files I am using. If anyone could have a look and help me understand what I am doing wrong I would be very grateful. Anyways, I also have another question that may be related with the issue above. What is the way to know which composite ID corresponds to the related physical surface of your geometry? In other words, is there a way to associate a composite ID to a specific surface in order to assign boundary conditions? For example, in my case, in file s_session.xml, I say C[1] (ID="0") is the inlet surface because in file s.xml it is the first composite, which, I am assuming, corresponds to the first physical surface I have defined in file s.geo (Physical Surface("inlet")={2};). Is this correct? I hope my questions make sense. Thank you in advance for your help, and Happy Easter! Kind regards, Silvia

3 3

Re: [Nektar-users] Flow around a sphere
by Laughton, Edward 11 Apr '20

11 Apr '20

Hi Silvia, Your setup seems to run fine for me on master. Could you please let me know the exact command you are running and the seg fault it produces and I will try to figure out what is going on? The composite ID in the .xml corresponds to the physical surface/volume tag in the .msh file, which in turn is filled from the .geo file if a numeric tag is specified. In your case as you have provided a char-expression instead, the .msh file is assigned a unique numeric tag automatically in the order of the physical surface/volume definitions in the .geo file. Here that is from 1-5 and the corresponding part in the .msh file is: $PhysicalNames 5 2 1 "inlet" 2 2 "outlet" 2 3 "walls" 2 4 "sphere" 3 5 "domain" $EndPhysicalNames This then corresponds to the C ID="1" to C ID="5" you see in the .xml file. You can assign a specific numeric tag in the .geo file by adding it after the char-expression e.g. Physical Surface("inlet", 101) = {2}; would correspond to 101 in the .msh file and then also in the .xml file as C ID="101". Hopefully that helps explain it! Thanks, Ed From: <nektar-users-bounces(a)imperial.ac.uk> on behalf of "Silvia Ceccacci (HDR)" <silvia.ceccacci(a)hdr.mq.edu.au> Date: Friday, 10 April 2020 at 03:09 To: nektar-users <nektar-users(a)imperial.ac.uk> Subject: [Nektar-users] Flow around a sphere This email from silvia.ceccacci(a)hdr.mq.edu.au 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspam.ic.a…> to disable email stamping for this address. Dear all, I hope this email finds you all well. I am trying to simulate flow around a sphere. I get an error of segmentation fault. I am generating a mesh from gmsh, converting it into Nektar format, then using the IncNavierStokesSolver. I am wondering whether it may be a problem with the association of composite IDs in boundary conditions. However I do not seem to find the problem. I attach the files I am using. If anyone could have a look and help me understand what I am doing wrong I would be very grateful. Anyways, I also have another question that may be related with the issue above. What is the way to know which composite ID corresponds to the related physical surface of your geometry? In other words, is there a way to associate a composite ID to a specific surface in order to assign boundary conditions? For example, in my case, in file s_session.xml, I say C[1] (ID="0") is the inlet surface because in file s.xml it is the first composite, which, I am assuming, corresponds to the first physical surface I have defined in file s.geo (Physical Surface("inlet")={2};). Is this correct? I hope my questions make sense. Thank you in advance for your help, and Happy Easter! Kind regards, Silvia

2 1

Hi All, convective boundary conditions
by Moto Light 10 Apr '20

10 Apr '20

******************* 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. ******************* Hi All, First i wish all of you are fine and these bad days will past and you always be healthy, I am asking if I can implement *convective boundary conditions* in 2.5D simulations for my cases, for now i am using Robin boundary conditions for my 2D cases but still have a problem in 2.5D cases. any ideas for this outlet boundary conditions for my case *I am using for 2D * ---------------------------- <REGION REF="5">  <R VAR="u" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="D0/TimeStep" /> <R VAR="v" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="D0/TimeStep" /> <R VAR="p" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="1.0/(D0*Kinvis)" /> </REGION> -------------------- *and for my 2.5D using* -------------------------------------------- <REGION REF="5">  <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="0" /> </REGION> --------------------------------------- is there any modifications in the new ver 5.0 regarding outlet boundary conditions? Thanks, Regards, Reda UPC Spain

1 1

New group chat service
by David Moxey 09 Apr '20

09 Apr '20

******************* 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 hope you are all doing well and keeping healthy in these rather strange times! With most of the Nektar++ development team now working from home, we thought it might be useful to establish a group chat for discussing our activities and the broader community. To make this as accessible as possible, we're using Mattermost, which is built into our Gitlab server. To access it, you can visit the website: https://chat.nektar.info/ Click on the gitlab button, and then sign in using your gitlab username/password. There are a number of clients for all OSs, including Android/iOS, which you can download here: https://mattermost.com/download/#mattermostApps The hope is that this can be a bit more reactive than the mailing list, particularly for a quick question or discussion, so I do encourage you to try it out. Cheers, Dave -- Dr David Moxey, PhD MMath MIMA FHEA Senior Lecturer in Engineering d.moxey(a)exeter.ac.uk | tel: 01392 724764 | web: davidmoxey.uk Room 1.24, Hope Hall, University of Exeter, Exeter, EX4 4PL, UK.

1 0

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

Groups using Nektar++
by Sherwin, Spencer J 01 Apr '20

01 Apr '20

Hi, We are interested in knowing who is using Nektar++ since it is useful in our reporting and to keep the framework going. Could I ask you to have a look at this document: https://docs.google.com/document/d/18hzI1aMSp0K0lxv4EXZAouXJpg_n-uzQaCcpkaB… and send me the name and location of any missing groups or indeed correct any mistakes. You should be able to add comments to this document. Once we have a reasonably complete list we will also post this information on the Nektar++ webpage. Many thanks, Spencer Spencer Sherwin FREng, FRAeS Head of Aerodynamics Section, Director of Research Computing Service, Professor of Computational Fluid Mechanics, Department of Aeronautics, s.sherwin(a)imperial.ac.uk<mailto:s.sherwin@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/

1 0