August 2016 - Nektar-users

extracting 1D line data in homogeneous direction
by Asim Onder 29 Aug '16

29 Aug '16

Dear all, I'm doing 3D1H DNS simulations, and I would like to do some statistical analysis (power-spectra, PDF, etc.) on certain lines in the homogeneous direction. Is there any practical way to extract line data in z-direction? I guess I can seed a family of points with probes filter in the direction of a line. However, I have around 2000 modes in the homogeneous direction, which would make this method probably expensive for increasing number of lines. Thanks, Asim ________________________________ Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you.

1 0

I can not obtain correct results for 2D Lid Driven cavity problem.
by 丁老师 27 Aug '16

27 Aug '16

Dear Nektar group: I am conducting numerical simulation for 2D lid driven cavity problem with Re=1000. Attachment please find my xml file. But i found the output results at monitor point is different from benchmark solution from open literature. I have changed the order from 20 to 40, the nothing changed. but the stream line pattern is the same with benchmark solution. what should i do further> Regards Your Sincerely Ding

3 3

Nektar++-4.3.3 compilation errors
by Sharma, Manish (sharmamh) 26 Aug '16

26 Aug '16

Dear All, I am trying to compile the latest version of the code, nektar++-4.3.3, and I am getting the following error: In file included from /home/manish/nektar++-4.3.3/library/NekMeshUtils/SurfaceMeshing/CurveMesh.h:44:0, from /home/manish/nektar++-4.3.3/library/NekMeshUtils/SurfaceMeshing/CurveMesh.cpp:36: /home/manish/nektar++-4.3.3/library/NekMeshUtils/Octree/Octree.h:76:18: error: 'string' does not name a type const string uds) ^ /home/manish/nektar++-4.3.3/library/NekMeshUtils/Octree/Octree.h:183:5: error: 'string' does not name a type string m_udsfile; ^ /home/manish/nektar++-4.3.3/library/NekMeshUtils/Octree/Octree.h: In constructor 'Nektar::NekMeshUtils::Octree::Octree(Nektar::NekMeshUtils::CADSystemSharedPtr, bool, Nektar::NekDouble, Nektar::NekDouble, Nektar::NekDouble, int)': /home/manish/nektar++-4.3.3/library/NekMeshUtils/Octree/Octree.h:78:27: error: class 'Nektar::NekMeshUtils::Octree' does not have any field named 'm_udsfile' m_verbose(ver), m_udsfile(uds) ^ library/NekMeshUtils/CMakeFiles/NekMeshUtils.dir/build.make:307: recipe for target 'library/NekMeshUtils/CMakeFiles/NekMeshUtils.dir/SurfaceMeshing/CurveMesh.cpp.o' failed make[2]: *** [library/NekMeshUtils/CMakeFiles/NekMeshUtils.dir/SurfaceMeshing/CurveMesh.cpp.o] Error 1 CMakeFiles/Makefile2:904: recipe for target 'library/NekMeshUtils/CMakeFiles/NekMeshUtils.dir/all' failed make[1]: *** [library/NekMeshUtils/CMakeFiles/NekMeshUtils.dir/all] Error 2 Makefile:146: recipe for target 'all' failed make: *** [all] Error 2 This error showed up when compiling the 4.3.2 version of the code too. What could I be doing wrong, and how can I resolve it? Looking forward to hearing from you soon. Thank you, Manish Sharma

3 7

How to compile the Nektar for the remote HPC computation.
by 丁老师 23 Aug '16

23 Aug '16

Dear Nektar group: I have compiled Nektar sucessfully on my local workstation. But the solver can not run in the remote HPC cluster, it seems many .so file is missing. Then how to compiled it again for the remote HPC computation. Regards Regards Your Sincerely Ding

2 1

Re: [Nektar-users] I can not obtain correct results for 2D Lid Driven cavity problem.
by Chris Cantwell 23 Aug '16

23 Aug '16

Dear Ding, Glad to hear you have resolved your problem. Although both your discretisations admit the same number of degrees of freedom they do not necessarily capture a solution equally well. If a solution is not smooth, or there are discontinuities, an increased number of elements and lower order polynomial is usually a better choice. Cheers, Chris On 23/08/16 02:49, 丁老师 wrote: > Dear friends: > I resolved the problem by increase the number of elements in the > cavity. > But i am confused why it doesn't work by increase the order of > polynomials. > The mesh1 has 2*2 element , with an order of 40. > The mesh 2 has 8*8 element, with an order 0f 10. > why the second mesh system can give accurate results. > > > > > > > > > > At 2016-08-22 21:02:26, "Chris Cantwell" <c.cantwell(a)imperial.ac.uk> wrote: >>Dear Ding, >> >>In what way does your measurement differ from the literature. Is the >>difference substantial? Could you provide a plot of the output showing >>the differences? >> >>One challenge in this problem is the inconsistent boundary conditions at >>the ends of the top wall. The values used at the top left and top right >>corners depends on the order of the boundary conditions. You could >>therefore swap the order of the boundary regions/conditions in the XML >>file and see if that improves your solution? >> >>Cheers, >>Chris >> >> >>On 22/08/16 06:15, 丁老师 wrote: >>> Dear Nektar group: >>> I am conducting numerical simulation for 2D lid driven cavity >>> problem with Re=1000. Attachment please find my xml file. >>> But i found the output results at monitor point is different from >>> benchmark solution from open literature. I have changed the order from >>> 20 to 40, the nothing changed. >>> but the stream line pattern is the same with benchmark solution. >>> what should i do further> >>> >>> >>> Regards >>> Your Sincerely >>> Ding >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Nektar-users mailing list >>> Nektar-users(a)imperial.ac.uk >>> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users >>> >> >>-- >>Chris Cantwell >>Imperial College London >>South Kensington Campus >>London SW7 2AZ >>Email: c.cantwell(a)imperial.ac.uk >>www.imperial.ac.uk/people/c.cantwell >> >>_______________________________________________ >>Nektar-users mailing list >>Nektar-users(a)imperial.ac.uk >>https://mailman.ic.ac.uk/mailman/listinfo/nektar-users > > > > > -- Chris Cantwell Imperial College London South Kensington Campus London SW7 2AZ Email: c.cantwell(a)imperial.ac.uk www.imperial.ac.uk/people/c.cantwell

1 0

the xml file transformed by Nekmesh has a Dim=1?
by 丁老师 23 Aug '16

23 Aug '16

Dear Nektar group: I draw a 2D caivty with gmesh then transformed by NekMesh. But the xml file has a dimension 1. It does not define the "edge". what cause this problem. Attachement please find the xml file. Regards Regards Your Sincerely Ding

2 1

Where is the tutorial files.
by 丁老师 22 Aug '16

22 Aug '16

Dear Nektar group: I have successfully installed Nektar and passed all the tests. I can not find any examples or tutorial files in the Nektar directories. Could you please give me some information about that? Regards Your Sincerely Ding

2 1

How to restart the IncNSsolver with saved chk file
by 丁老师 22 Aug '16

22 Aug '16

Dear Nektar group: How to restart the IncNSsolver with saved chk file Regards Your Sincerely Ding

2 1

Re: [Nektar-users] what is the boundary condition for the first and second intermediate velocity field?
by David Moxey 20 Aug '16

20 Aug '16

Hi Ding, I don't believe there are any boundary conditions explicitly applied to \hat{v}. Indeed I think if you were to do this I suspect you would end up with the wrong pressure; the combination of the convective term without any BCs applied to them, together with the pressure boundary condition is then consistent with the original equations meaning that the Helmholtz solve for velocity (where the velocity BCs are imposed) will impose the divergence condition. Or at least I believe is the case. Others may have an alternative opinion. Cheers, Dave On Fri, 2016-08-19 at 22:53 +0800, 丁老师 wrote: > Thank you very much. I know the paper of the karniadakis. > what i mean is the value of the first intermediate velocity " v > caret" on the boundary, since we need to compute the "nabla dot v > caret " for the source term of the pressure equation. > Regards > > > > > > > > At 2016-08-19 21:27:05, "David Moxey" <d.moxey(a)imperial.ac.uk> wrote: > >Hi Ding, > > > >Sorry, a bit confused by the question. Do you mean in the velocity > correction scheme? If so, we use a so-called high-order pressure > boundary condition for the Poisson solve (this is documented in the > book by Karniadakis and Sherwin and is in a paper somewhere), and the > velocity conditions are imposed at the last Helmholtz solve step. > > > >Cheers, > > > >Dave > > > >> On 18 Aug 2016, at 10:40, 丁老师 <ztdepyahoo(a)163.com> wrote: > >> > >> Dear Nektar group: > >> Could you please give me some suggestions about the boundary > condition for the first and second intermediate velocity field? > >> Does it use the same with the real velocity boundary conditions. > >> > >> Regards > >> Your Sincerely > >> Ding > >> > >> > >> > >> _______________________________________________ > >> Nektar-users mailing list > >> Nektar-users(a)imperial.ac.uk > >> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users > > > > > > > >-- > >David Moxey (Research and Teaching Fellow) > >d.moxey(a)imperial.ac.uk | www.imperial.ac.uk/people/d.moxey > > > >Room 364, Department of Aeronautics, > >Imperial College London, > >London, SW7 2AZ, UK. > > > > > -- David Moxey (Research and Teaching Fellow) d.moxey(a)imperial.ac.uk | www.imperial.ac.uk/people/d.moxey Room 364, Department of Aeronautics, Imperial College London, London, SW7 2AZ, UK.

2 1

A Question about visualizing the output Hdf5 format
by Raman, Aditya 19 Aug '16

19 Aug '16

Hello everyone, I just recently tried the Hdf5 feature and found it to work well, even on 4104 processors. I noticed that the output I/O lacks the mesh connectivity information and so it cannot be directly opened in any visualization software for post-processing. and It has to be converted to either vtu or tecplot format. I don't have much experience with the hdf5 data format, and so I wanted to know if it would be possible to add the mesh info to the output hdf5 file so that i can directly open the file in visit for post-processing. Regards, Aditya Raman.

2 1