September 2014 - Nektar-users

Nektar++ running problem with .xml files including curved edges
by Kamil Ozden 04 Oct '14

04 Oct '14

Dear All, About 3 weeks ago I made an update in my computer and after that installed the last version of Nektar in the repository without problem. However, after this installation when I tried to run an analysis with an xml file including Curved edges I got the following error: Initial Conditions: - Field u: 0 - Field v: 0 - Field w: 1 - Field p: 0 Writing: "Re100_v11_2_0.chk" [Dell-Workstation:56500] *** Process received signal *** [Dell-Workstation:56500] Signal: Segmentation fault (11) [Dell-Workstation:56500] Signal code: Address not mapped (1) [Dell-Workstation:56500] Failing at address: 0x9a1b000 [Dell-Workstation:56500] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x36c30) [0x7f5d2d442c30] [Dell-Workstation:56500] [ 1] /usr/lib/libblas.so.3(dgemm_incopy_NEHALEM+0x39e) [0x7f5d2e9a979e] [Dell-Workstation:56500] *** End of error message *** Segmentation fault (core dumped) What may be the reason for this error? Regards, Kamil

3 2

Re: [Nektar-users] Transferring curved edge information to Nektar++
by Kamil Ozden 03 Oct '14

03 Oct '14

Dear All, Regarding my previous question I found that there is an option in Gmsh to get higher order elements for reflecting curvature of the edges into .xml file. However, when I increase the order of the element from 1 to a higher order (e.g. 3) and convert the .xml file to .vtu file I got the message: /*Warning: Level 0 assertion violation*//* *//*3D deformed Jacobian not positive (element ID = 359) (first vertex ID = 206)*/ and the mesh that MeshConvert obtained from Gmsh's .msh file looks like: As far as I know "Jacobian not positive" means there are intersecting elements. What may be the reason for this problem? Regards, Kamil On 18-09-2014 11:36, Kamil Ozden wrote: > Dear All, > > I mesh a circular pipe in Gmsh very coarsely as below and turn it into > a xml file via MeshConvert. However, the curved edge information is > not transferred to the xml file (as seen in the figure at right). How > can I succeed this? Is there any way of doing it in Gmsh or is this > directly related with Nektar++ ?

4 5

Expansion Types and IncNavierStokesSolver
by Kamil Ozden 28 Sep '14

28 Sep '14

Dear All, I searched the web site of Nektar++ but I couldn't find any detailed information about the EXPANSION types (MODIFIED, GLL_LAGRANGE & GLL_LAGRANGE_SEM) used when using IncNavierStokesSolver. What are the differences between these Expansion types? Which one of these expansion types is the most suitable for problems like pipe flow or blood flow in vessels etc. ? Regards, Kamil

2 1

Does FieldConverts interppointdatatofld module do 3D?
by Kilian Lackhove 28 Sep '14

28 Sep '14

Dear All, i am trying to convert a 3D .pts file to a .fld file using FieldConverts "interppointdatatofld" module. Is that possible? What would i need to specify for the interpcoord option then? I also found a typo in FieldConvert. This is the MR: http://gitlab.nektar.info/nektar/merge_requests/389 Cheers, Kilian PS: I am currently running: ~/code/nektar/utilities/PostProcessing/FieldConvert/Tests # FieldConvert -v -e -m interppointdatatofld:interpcoord=3 chan3D.xml chan3D_pts.pts chan3D_pts.fld with the file chan3D_pts.pts containing: <?xml version="1.0" encoding="utf-8"?> <NEKTAR> <POINTS DIM="3" FIELDS="p"> -1.0 -1.0 -1.0 1.0E5 -1.0 -1.0 1.0 1.1E5 -1.0 1.0 1.0 1.2E5 -1.0 1.0 -1.0 1.3E5 1.0 -1.0 -1.0 1.4E5 1.0 -1.0 1.0 1.5E5 1.0 1.0 1.0 1.6E5 1.0 1.0 -1.0 1.7E5 </POINTS> </NEKTAR> but that doesnt seem to work. -- Kilian Lackhove, M.Sc. Fachgebiet für Energie- und Kraftwerkstechnik L1|08 114 Technische Universität Darmstadt Jovanka-Bontschits-Straße 2 D-64287 Darmstadt Germany Tel.: +49 6151 16 - 5186 Fax: +49 6151 16 - 6555 e-mail: lackhove(a)ekt.tu-darmstadt.de

2 1

The grid using GLL expansion type
by Kamil Ozden 18 Sep '14

18 Sep '14

Dear All, When I specify my expansion type as GLL_LAGRANGE or GLL_LAGRANGE_SEM, I see in the grid that the spectral elements are divided in an equispaced way. As far as I know, for GLL expansions the grid should be divided as getting finer through the edges. Is there any other way that Nektar++ handles this issue? Regards, Kamil

2 1