- Nektar-users - imperial.ac.uk

Re: [Nektar-users] Linking ARPAC
by Sherwin, Spencer J 23 May '16

23 May '16

Hi Marcus, Glad it all worked out in the end. I am posting your summary back onto the nectar-users list so we can keep a record. Cheers, Spencer. On 23 May 2016, at 21:30, Lander, Marcus David <marcus.lander(a)okstate.edu<mailto:marcus.lander@okstate.edu>> wrote: Dr. Spencer, I was able to successfully link ARPACK to NEKTAR++. I followed what you asked, and I compiled Nektar++ using the same compiler as I was using for Nektar++. However, this still lead to some errors. Additionally, I needed to change multiple compile flags within ARPACK’s various makefiles. Finally, I figured out that instead of linking to libarpack_LINUX.a, I instead needed to link to libarpack_LINUX.so. At this point, Nektar++ compiled correctly, and I was able to confirm it by calling Arpack as is described in the tutorials. Thank you very much. Marcus Lander Graduate Research Student Oklahoma State University CC’d in this email: Balaji Jayaraman, Ph.D, Assistant Professor, School of Mechanical and Aerospace Engineering, Oklahoma State University, 211C Engineering North, Stillwater OK 74078-5016 Email: balaji.jayaraman(a)okstate.edu<mailto:balaji.jayaraman@okstate.edu> From: Sherwin, Spencer J [mailto:s.sherwin@imperial.ac.uk] Sent: Friday, May 20, 2016 9:27 AM To: Lander, Marcus David Subject: Re: [Nektar-users] Linking ARPAC Hi Marcus What you seem to be doing seems reasonable. However when you enter the details in cmake you mention below. What happens when you then configure the setup by pressing ’c’. Does the configuration complete correctly? I am using it from a system installation which is actually linking to a dynamic library libarpack.dylib but I think you should be able to use the static compilation. Are you compelling Arpack with the same compiler you are using for Nektar++ (@Chris, Dave: Do you have any suggestions)? Cheers, Spencer. On 19 May 2016, at 22:11, Lander, Marcus David <marcus.lander(a)okstate.edu<mailto:marcus.lander@okstate.edu>> wrote: I am having issues getting Nektar++ to recognize ARPACK. When I run through the channel-flow tutorial, in the Channel-Coupled.xml section, I get to the following command: IncNavierStokesSolver Channel-Coupled.xml Then, I receive the following error: Value ‘Arpack’ is not valid for property ‘DRIVER’ I’m very confused how to link Arpack (which is going to be installed to my personal directory rather than on the main section of the cluster, because I do not have permission to install Arpack globally). It is installed at $HOME/ARPACK/ In ccmake .., I point the ARPACK_LIBRARY flag to $HOME/ARPACK/libarpack_LINUX.a, and then I changed the NEKTAR_USE_ARPACK flag to on. Is there something I am missing??? _______________________________________________ Nektar-users mailing list Nektar-users(a)imperial.ac.uk<mailto:Nektar-users@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users Spencer Sherwin McLaren Racing/Royal Academy of Engineering Research Chair, Professor of Computational Fluid Mechanics, Department of Aeronautics, Imperial College London South Kensington Campus London SW7 2AZ s.sherwin(a)imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk> +44 (0) 20 759 45052 Spencer Sherwin McLaren Racing/Royal Academy of Engineering Research Chair, Professor of Computational Fluid Mechanics, Department of Aeronautics, Imperial College London South Kensington Campus London SW7 2AZ s.sherwin(a)imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk> +44 (0) 20 759 45052

1 0

Seg fault with driver adaptive
by Siddarth Chintamani 22 May '16

22 May '16

Hello all, I am tyring to run the IncNavierStokesSolver with adaptive polynomial order. My simulation fails with seg fault as soon as it restarts with adapted polynomial orders. I might be setting my input file wrong. It would be really helpful if someone could point me to an example with adaptive polynomial order. Thank you, Siddarth Chintamani

2 4

EulerCFE - performance issue & MPI problem
by Kühnelt Helmut 20 May '16

20 May '16

Hi Spencer, hi All, I experience that CompressibleFlowSolver for EulerCFE in 1D is really slow. A computation on a grid with 5000 elements, with P=5 and a 5th order RK_SSP (self-implemented) needs ~1 s per time step on an up-to-date workstation (single core execution). (A calculation of 1e5 steps (1s with a time step = 1e-5s) needs 27 hours...) The profiler shows that 68% ot the time the code spends releasing of shared pointers, constructing and destructing Array(), lock() and unlock() and the = operator. Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 32.05 1.38 1.38 10032 0.14 0.14 boost::detail::sp_counted_base::release() 9.56 1.79 0.41 20514 0.02 0.02 Nektar::Array<Nektar::OneD, double const>::Array(unsigned int, double const&) 9.09 2.18 0.39 7693730 0.00 0.00 Nektar::Array<Nektar::OneD, double const>::~Array() 8.86 2.56 0.38 137658633 0.00 0.00 boost::unique_lock<boost::mutex>::lock() 8.04 2.90 0.35 137608137 0.00 0.00 boost::mutex::unlock() 7.69 3.23 0.33 20528 0.02 0.02 Nektar::Array<Nektar::OneD, double const>::operator=(Nektar::Array<Nektar::OneD, double const> const&) 7.23 3.54 0.31 2500500 0.00 0.00 Nektar::ExactSolverToro::v_PointSolve(double, double, double, double, double, double, double, double, double, double, double&, double&, double&, double&, double&) 4.31 3.73 0.19 74253 0.00 0.01 Nektar::MemPool::Allocate(unsigned long) 2.33 3.83 0.10 Nektar::Array<Nektar::OneD, int const>::~Array() ... Running CompressibleFlowSolver with MPI gives a segmentation fault somewhere in the mesh partitioning (1D mesh) MeshPartition::MeshPartition() MeshPartition::ReadGeometry() 0x15d70d0 0x15d71a0 0x15d71a0 0 [node92:28879] *** Process received signal *** [node92:28879] Signal: Segmentation fault (11) [node92:28879] Signal code: Address not mapped (1) [node92:28879] Failing at address: 0x38 [node92:28879] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x36d40) [0x7f7e7a781d40] [node92:28879] [ 1] /home/hkuehnelt/nektar++/build/library/LibUtilities/libLibUtilities.so.4.3.0(_ZN6Nektar12LibUtilities13MeshPartition12ReadGeometryERKN5boost10shared_ptrINS0_13SessionReaderEEE+0x1268) [0x7f7e7be44118] [node92:28879] [ 2] /home/hkuehnelt/nektar++/build/library/LibUtilities/libLibUtilities.so.4.3.0(_ZN6Nektar12LibUtilities13MeshPartitionC1ERKN5boost10shared_ptrINS0_13SessionReaderEEE+0x40f) [0x7f7e7be44a5f] [node92:28879] [ 3] /home/hkuehnelt/nektar++/build/library/LibUtilities/libLibUtilities.so.4.3.0(_ZN6Nektar12LibUtilities18MeshPartitionMetisC2ERKN5boost10shared_ptrINS0_13SessionReaderEEE+0x17) [0x7f7e7be519f7] [node92:28879] [ 4] /home/hkuehnelt/nektar++/build/library/LibUtilities/libLibUtilities.so.4.3.0(_ZN6Nektar12LibUtilities18MeshPartitionMetis6createERKN5boost10shared_ptrINS0_13SessionReaderEEE+0xc5) [0x7f7e7be53505] [node92:28879] [ 5] /home/hkuehnelt/nektar++/build/library/LibUtilities/libLibUtilities.so.4.3.0(_ZN6Nektar12LibUtilities10NekFactoryISsNS0_13MeshPartitionERKN5boost10shared_ptrINS0_13SessionReaderEEENS0_4noneES9_S9_S9_E14CreateInstanceESsS8_+0x96) [0x7f7e7be77c26] [node92:28879] [ 6] /home/hkuehnelt/nektar++/build/library/LibUtilities/libLibUtilities.so.4.3.0(_ZN6Nektar12LibUtilities13SessionReader13PartitionMeshEv+0x3fd) [0x7f7e7be6cb5d] [node92:28879] [ 7] /home/hkuehnelt/nektar++/build/library/LibUtilities/libLibUtilities.so.4.3.0(_ZN6Nektar12LibUtilities13SessionReader11InitSessionEv+0x55) [0x7f7e7be6de55] [node92:28879] [ 8] /home/hkuehnelt/nektar++/build/solvers/CompressibleFlowSolver/CompressibleFlowSolver(_ZN6Nektar12LibUtilities13SessionReader14CreateInstanceEiPPc+0x14c) [0x4396bc] [node92:28879] [ 9] /home/hkuehnelt/nektar++/build/solvers/CompressibleFlowSolver/CompressibleFlowSolver(main+0x4d) [0x4291ed] [node92:28879] [10] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f7e7a76cec5] [node92:28879] [11] /home/hkuehnelt/nektar++/build/solvers/CompressibleFlowSolver/CompressibleFlowSolver() [0x430b99] [node92:28879] *** End of error message *** -------------------------------------------------------------------------- mpirun noticed that process rank 0 with PID 28879 on node node92 exited on signal 11 (Segmentation fault). -------------------------------------------------------------------------- Do you have any advice how to speed up the code and to fix the MPI issue? Best regards, Helmut ________________________________________ Helmut Kühnelt Scientist Mobility Department Electric Drive Technologies AIT Austrian Institute of Technology GmbH Giefinggasse 2 | 1210 Vienna | Austria T: +43 50550-6245 | M: +43 664 815 78 38 | F: +43 50550-6595 helmut.kuehnelt(a)ait.ac.at<https://aitmail.ait.ac.at/owa/redir.aspx?C=LR7CP_NRwEmvpxwWXICJVa6k5FhGic8I…> | http://www.ait.ac.at/<https://aitmail.ait.ac.at/owa/redir.aspx?C=LR7CP_NRwEmvpxwWXICJVa6k5FhGic8I…> FN: 115980 i HG Wien | UID: ATU14703506 This email and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient, please notify the sender by return e-mail or by telephone and delete this message from your system and any printout thereof. Any unauthorized use, reproduction, or dissemination of this message is strictly prohibited. Please note that e-mails are susceptible to change. AIT Austrian Institute of Technology GmbH shall not be liable for the improper or incomplete transmission of the information contained in this communication, nor shall it be liable for any delay in its receipt.

3 14

Fwd: profiling screenshot
by Sherwin, Spencer J 19 May '16

19 May '16

Hi Helmut, Chris ran the 1D solver and profiled it locally. When using Collections with auto-tuning he got the attached profile. If he turned off auto-tuning we did observe the mutex_lock being second highest and dgemv being the top of the list. However in your earlier profiling you had a boost method we do not recognise at the top. Could you perhaps try profiling your run again but with the auto-tuning turned on to see if this boost method is still at the top of your profiling list. If so the discrepancy is presumably related to this method and we should try and find out why this is arising. Cheers, Spencer PS We do have a threading library which has some lock on the memory pool and is probably why the no-auto-tuning is leading to high number of lock. We will look into turning off this feature if threading is not being used PPS Douglas is going to look into using boost 1.57 (since we are generally using 1.58 or higher) to see if he observes a similar slow down to what you see. Begin forwarded message: From: Chris Cantwell <c.cantwell(a)imperial.ac.uk<mailto:c.cantwell@imperial.ac.uk>> Subject: profiling screenshot Date: 18 May 2016 at 18:04:26 BST To: Spencer Sherwin <s.sherwin(a)imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk>> [cid:0BEE0A69-B4F0-4DCC-BA56-28B13FFC4E9A@ae.ic.ac.uk] Spencer Sherwin McLaren Racing/Royal Academy of Engineering Research Chair, Professor of Computational Fluid Mechanics, Department of Aeronautics, Imperial College London South Kensington Campus London SW7 2AZ s.sherwin(a)imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk> +44 (0) 20 759 45052

2 1

Smoothing a specified field
by Jian Yu 06 May '16

06 May '16

Dear all, I am trying to develop a function in the CompressibleFlowSolver defined as void CompressibleFlowSystem::SmoothingFieldGlobal( const Array<OneD, NekDouble > &var, Array<OneD, NekDouble > &var_smooth) The basic process in this function is that 1. First the original field vaule var is projected onto a basis with lower accuracy orders; 2. Averaging is conducted for points along element edges to achieve C0 continuity; 3. Project modified values back to the original basis to obtain var_smooth. Through the above procedures, the specified field value is smoothed to some extent. Has anyone done similar work before or does Nektar++ already contains similar functions? Right now I am not sure where to start.I noticed that there is a C0Projection module in the FieldConvert modules. Is it feasible to transplant this module? Any suggestion would be a big help! Thank you! Best wishes, Jian Yu

1 0

Solve scalar transport equation along with Incompressible Navier Stokes
by Siddarth Chintamani 04 May '16

04 May '16

Hello all, I am trying to study scalar mixing from a jet. I can use the incompressible Navier Stokes solver to get the velocity at every time step. I am thinking of calling the advection-diffusion solver from the Navier Stokes solver every time step and solve for the scalar mixing. I was wondering if there is any other easier approach? Is there any example that I can look into? I greatly appreciate any help regarding this problem Thank you, Siddarth

3 6

Time dependent bodyforce
by Péter Tamás Nagy 03 May '16

03 May '16

Dear All, I have two questions in regard to the usage of the Nektar++ 4.2.0. 1. Is it possible to define time-dependent body-force for the Incompressible Navier-Stokes solver? Could anyone send me an example? 2. I read in the User Giude that the definition of the geometry can be stored in separate from the remaining configuration. It is not obvious for me how the solver will identify then the geometry or the configuration elements. In this case how should I call the IncNavierStokesSolver? Could anybody send me an example? I really appreciate any help. Best regards, Péter

3 2

Nektar++ Workshop 2016
by Chris Cantwell 03 May '16

03 May '16

Dear all, The programme for the Nektar++ Workshop 2016 is now available at http://www.nektar.info/community/workshops/nektar-2016/ We would like to encourage all participants, particularly those presenting during the main sessions, to bring a poster if possible, which can be displayed during the coffee and lunch breaks. If you would like to attend and have not already registered, please do so at https://www.eventbrite.co.uk/e/nektar-workshop-2016-tickets-22172591819 as this will help us greatly with the logistics and catering. The Nektar++ Team

1 0

Turbulent channel flow example
by César Alegre 03 May '16

03 May '16

3 2

Correct Designation of Boundary Conditions
by Amitvikram Dutta 26 Apr '16

26 Apr '16

Hi all, I'm having some confusion in applying appropriate boundary conditions to proper named surfaces in my mesh. I'm using v4.2.0 with the original mesh being constructed in gmsh. I subsequently use the MeshConvert utility to generate the partial xml file for the simulation. In my .msh file I have my surfaces set as $PhysicalNames 5 2 1 "Unspecified" 1 2 "Airfoil" 1 3 "Inlet" 1 4 "Outlet" 1 5 "Tandb" $EndPhysicalNames I want to apply no-slip condition to the airfoil, a velocity inlet , a constant pressure outlet and no slip wall to TandB as well. My relevant section of the xml case file is given below. I'd like to know if I'm implementing the boundary conditions correctly. <BOUNDARYREGIONS> C[2] C[3] C[4] C[5] </BOUNDARYREGIONS> <BOUNDARYCONDITIONS> <REGION REF="0"> <D VAR="u" VALUE="0" /> <D VAR="v" VALUE="0" /> <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> </REGION> <REGION REF="1"> <D VAR="u" VALUE ="1" /> <D VAR="v" VALUE="0" /> <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> </REGION> <REGION REF="2"> <N VAR="u" VALUE="0" /> <N VAR="v" VALUE="0" /> <D VAR="p" VALUE="0" /> </REGION> <REGION REF="3"> <D VAR="u" VALUE="0" /> <D VAR="v" VALUE="0" /> <N VAR="p" USERDEFINEDTYPE="H" VALUE="0" /> </REGION> </BOUNDARYCONDITIONS> <FUNCTION NAME="InitialConditions"> <E VAR= "u" VALUE="1" /> <E VAR="v" VALUE="0" /> <E VAR="p" VALUE="0" /> </FUNCTION> -- *Amitvikram Dutta* *MASc Candidate* *Graduate Research Assistant * *Okanagan CFD Laboratory* *University of British Columbia | Okanagan Campus*

2 2