March 2018 - Nektar-users - imperial.ac.uk

Interpolate scattered point data to a field problems
by Manuel F. Mejía De Alba 27 Mar '18

27 Mar '18

Dear all I am trying to interpolates point field to xml field using the FieldConvert module. When I run the command on one older version of Nektar, works without any issue. nektar++-4.3.5/build/utilities/FieldConvert/FieldConvert -m interppointdatatofld FlowCorner.xml FlowCorner.wear.pts FlowCorner.wear.fld Interpolating: 100% [=================================================] Writing: "FlowCorner.wear.fld" But, when I try to run on the master branch I get the next error message nektar++/build/utilities/FieldConvert/FieldConvert-g -m interppointdatatofld FlowCorner.xml FlowCorner.wear.pts FlowCorner.wear.fld Fatal : Level 0 assertion violation Where : /home/mejia/nektar++/utilities/FieldConvert/FieldConvert.cpp[587] Message : Module(s): InputPts should not use xml or fld inputs. terminate called after throwing an instance of 'ErrorUtil::NekError' what(): Level 0 assertion violation Where : /home/mejia/nektar++/utilities/FieldConvert/FieldConvert.cpp[587] Message : Module(s): InputPts should not use xml or fld inputs. Aborted (core dumped) The files that made the interpolation are in a different path on each version nektar++-4.3.5/utilities/FieldConvert/ProcessModules/ProcessInterpPointDataToFld.cpp nektar++/library/FieldUtils/ProcessModules/ProcessInterpPointDataToFld.cpp Does someone have any idea or could help me with some hint? --- Manuel Felipe Mejía De Alba.

2 1

memory usage and computation time in Taylor-Green problem
by Vishal Saini 26 Mar '18

26 Mar '18

Hi all, After obtaining exciting error vs. computational cost results from relatively heavy 2D computations, I've been setting up the 3D Taylor Green vortex (TGV) problem using Nektar++ Incompressible solver. The Reynolds number used is 1600 (same as in the TGV tutorial from Nektar++ team). A 3D grid of 64^3 elements with NumModes=5 was used to obtain a 256^3 simulation (close to a DNS). I ran this problem on Midlands+ Tier 2 machine using 4 nodes (112 cores, 512 GB RAM in total). http://www.hpc-midlands-plus.ac.uk/about/system-description/ The memory consumption during the run was ~450GB and it took ~330 wall-clock-minutes for 1000 time-steps (with dt=1e-4). For a reference, I ran a 256^3 TGV simulation of the same case in OpenFOAM using same resources. The memory consumption was ~40GB and it took ~20 minutes for 1000 time-steps. So for this case, I observe high resource consumption in terms of memory and computation time. I was not expecting this on the basis of my experience with Nektar++ on 2D simulations, at least in terms of computation time. Is this normal? In addition to my set-up file, I'm suspecting my installation of Nektar++ on the aforementioned cluster. Could anyone please try and run a few hundred time-steps on their machines using the files attached? FYI, I'm partitioning on-the-fly. The calculation seems to scale well on 8 nodes in terms of wall clock time while increasing the memory consumption by ~10%. Any input is highly appreciated. Best regards, Vishal --- *Vishal SAINI* Master of Research, University of Cambridge.

2 4

Re: [Nektar-users] How to write FLD file in uncompressed format.
by ashok jallepalli 26 Mar '18

26 Mar '18

Thank you David and Mike, Do you have an example for a small xml mesh file which has both face curvature block as well as edge curvature block that you can share? Thanks in advance, Cheers, Ashok. On Mon, Mar 26, 2018 at 3:37 AM David Moxey <D.Moxey(a)exeter.ac.uk> wrote: > Hi Ashok, > > 1) This description is pretty nontrivial, but in brief: data are organised > into a contiguous block by element IDs (as dictated in the ELEMENT tag) > which describes the coefficient space of the basis that's defined in the > ELEMENT tag. It's then zlib-compressed and written as a base64 string into > the XML file. > > Honestly, based on the above, I wouldn't recommend to anyone writing their > own FLD writer, so I have two suggestions: > > - either extract the FieldIO classes from Nektar++ that handle this or > link against LibUtilities to write this for you (may not be ideal); > - a better option may be writing a FieldConvert module to handle this for > you. An example of how we do this for Nek5000 (Lagrange-basis SEM code) is > in library/FieldUtils/InputModules/InputNek5000.cpp > > 2) If no interior nodes are specified then they are blended automatically > into the interior of the element through the basis functions, which > essentially do a Gordon-Hall blending from what I remember. If you want to > define the interior points explicitly, you can define a face curvature > block as well as an edge curvature block. > > Cheers, > > Dave > > > On 26 Mar 2018, at 08:20, ashok jallepalli <ash.nani(a)gmail.com> wrote: > > > > Hi, > > I am trying work with an external group to import high-order dG > data written by their custom software into Nektar. As a part of the data > transfer, they pose the following questions: > > > > 1) How is the data organized in the FLD file? (Is it possible to print > the data in the FLD file uncompressed format to help engineer backward.)? > > > > 2) The documentation only explains what to do with an edge, but I’m not > sure how that holds up for curved triangles. There are extra nodes on the > interior of curved triangles, and where those go in the file. > > > > Cheers, > > Ashok. > > _______________________________________________ > > Nektar-users mailing list > > Nektar-users(a)imperial.ac.uk > > https://mailman.ic.ac.uk/mailman/listinfo/nektar-users > >

1 0

How to write FLD file in uncompressed format.
by ashok jallepalli 26 Mar '18

26 Mar '18

Hi, I am trying work with an external group to import high-order dG data written by their custom software into Nektar. As a part of the data transfer, they pose the following questions: 1) How is the data organized in the FLD file? (Is it possible to print the data in the FLD file uncompressed format to help engineer backward.)? 2) The documentation only explains what to do with an edge, but I’m not sure how that holds up for curved triangles. There are extra nodes on the interior of curved triangles, and where those go in the file. Cheers, Ashok.

2 1

how to use HOBC?
by Kurt Sansom 25 Mar '18

25 Mar '18

Hi, I am trying to use the higher order outlet boundary conditions. I know that is formulated for truncated open domains, but am curious if I can use in the following way, where I want to specify the outlet pressure to some value to create back pressure in the system. I realize that for in-compressible flow it doesn't matter that much, but I am interested in implementing a time varying pressure condition at the outlet. I have tried the following boundary condition for a tube and it doesn't appear to apply the VALUE tag? I want to make sure before I file a bug. <REGION REF="2">  <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="10665" /></REGION> Regards, ~Kurt -- Kurt Sansom

2 3

incompressible navier stokes time dependent boundary coupling
by Kurt Sansom 21 Mar '18

21 Mar '18

Hi all, I am trying to implement a reduced order time dependent pressure boundary condition in nektar++. There is some work around this in the original nektar code by Leopold Grinberg on RC boundary conditions for vascular flows, (I haven't had any success any finding the code for this) However, I would like to couple the boundary condition with the backflow divergence boundary condition of S. Dong, the "Houtflow" condition that already exists. I have gotten as far as being able to hard code some things in Extrapolate.cpp to test that I can get a calculation for second order BFD, but I am confused/unsure about. 1.) best way to get variables from the xml file into extrapolate.cpp? 2.) best way to deal with the time dependency since time dependent boundaries are treated differently than constant values? 3.) where to add the additional pressure forcing term in the evaluation of the "Houtflow" condition code? Regards, ~Kurt -- Kurt Sansom

1 0

Nektar++ installation error
by Csaba Biró 20 Mar '18

20 Mar '18

Dear all, I am currently trying to install Nektar++ for Windows 10 following the instructions in user-guide-4.4.1. After completing the building/installation process (point 12.) I got 5 errors. Configuring and Generating in cmake seems successful, although some kind of error message is present (see in Message.txt). In the Output.log you can see the installation process (not my first attempt) and in pic1 and pic2 the appearance of cmake. I am using Visual Studio 2015 (x64). Should you have any questions or suggestions, please contact me. Any help is greatly appreciated! Kind Regards, Csaba Biró

3 2

New NekMesh mailing list
by Marcon, Julian 20 Mar '18

20 Mar '18

Dear Nektar++ users, Efforts have been made in recent years to develop a high-order mesh generation framework within Nektar++, called NekMesh. Popularity for the suite of tools has largely increased over the last months. The team behind NekMesh has recently created a mailing list (in the likes of Nektar-users) dedicated to NekMesh and would like to invite all NekMesh users and developers to subscribe and post to it for the benefit of the user community. The mailing list is hosted at https://mailman.ic.ac.uk/mailman/listinfo/nekmesh-users and you may post messages at nekmesh-users(a)imperial.ac.uk<mailto:nekmesh-users@imperial.ac.uk> after subscription. Best regards, The NekMesh Team

1 0

Questions on using HelmSolve, varCoeffMap and varFactorsMap
by Oliviu Sugar 19 Mar '18

19 Mar '18

Dear all, I have a few questions on using the HelmSolve function together with non-zero varCoeffMap and varFactorsMap input arguments. Consider the following equation on a given domain: div [ eps(x) * grad(U) ] + lambda(x) * U = f(x) Is it correct to say that varCoeffMap can be set up to provide eps(x), while varFactorsMap can be set up to provide lambda(x) for the HelmSolve function? If so, how does the constant factor [eFactorsLamdba] get treated if varFactorsMap is also defined? With these assumptions, I have moved forward to set up an example. The Unsteady Diffusion equation system from the ADR solver was used as the basis. The modified source files are attached. The example is not meant to represent a particular physical problem, rather it just check functionality. A varCoeffMap [StdRegins :: eVarCoeffLaplacian] and varFactorsMap [StdRegions :: eFactorDiffCoefff] were set up based on the total number of quadrature points and are simply filled with random small values at every time step. A 2D problem was set up in a unit square domain (the xml file is also attached). Time marching the problem has revealed that the RAM consumption steadily grows without limits if the varFactorsMap is recomputed at every timestep, regardless of the total RAM, if the total number of time steps if sufficiently high. I am running the code under Ubuntu, and all source files were updated from the repository on March 2nd, prior to any modifications. Is this due to an improper use of varFactorsMap within the example, or is it a memory management problem? Am I missing source files which should be updated to provide this intended functionality? It must be noted that updating varCoeffMap at every step does not generate the same memory problem. Any information or advice would be much appreciated, and apologies for the lengthy email :) Best regards, Oliviu

2 2

Cannot find corresponding element face
by A.P. 19 Mar '18

19 Mar '18

Hello, I ran NekMesh utility and recived the error message: "Cannot find corresponding element face for 2D element ..." What can I do in this situation? Alexander.

2 1