*******************
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 Nektar++ users and developers:
Sorry to bother everyone here, however, I need some help with boundary condition setting in the IncNS solver.
My case is a 3D model with xz-symmetric plane:
1. Is there a boundary condition of symmetry surfaces in Nektar++ IncNS solver (such as symmetry boundary in Ansys Fluent), and is there an alternative scheme (if xz-plane is the symmetric plane how could I properly set [u v w p] bc-vector on the y=0 mid-plane? Neumann u=0, Dirichlet v=0, Neumann w=0, Dirichlet p=0?)
2. If there is a boundary condition such as a symmetry surface, whether the flow field of the full-model can be generated from the half-model fld files utilizing the FieldConvert tool. Could it be reliably implemented using pointwise file (calculate the half-mode (if possible), write out the DAT (tecplot) file, write the data symmetrically to a pointwise file, and then write the full-mode mesh)?
Thank you for your help and look forward to your discussion and response.
Thanks to the Nektar++ project team.
Best Regards,
Wang Zhouyang
*******************
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 am trying to compare the performance of different expansion types.
However, when I set TYPE="GLL_LAGRANGE_SEM", I get the following error:
=======================================================================
> EquationType: UnsteadyNavierStokes
> Session Name: MeshWith3PrismsLayers
> Spatial Dim.: 3
> Max SEM Exp. Order: 5
> Num. Processes: 128
> Expansion Dim.: 3
> Projection Type: Continuous Galerkin
> Advect. advancement: explicit
> Diffuse. advancement: implicit
> Time Step: 0.0005
> No. of Steps: 1000000
> Checkpoints (steps): 1000
> Integration Type: IMEX
> Splitting Scheme: Velocity correction (strong press. form)
> =======================================================================
> Initial Conditions:
> - Field u: 1.0
> - Field v: 0.0
> - Field w: 0.0
> - Field p: 0.0
> renaming "MeshWith3PrismsLayers_0.chk" ->
> "MeshWith3PrismsLayers_0.bak0.chk"
> Writing: "MeshWith3PrismsLayers_0.chk"
> (0.186233s, HDF5)
> [gra723:25064:0:25064] Caught signal 11 (Segmentation fault: address not
> mapped to object at address 0x3025)
Here is my setup:
<?xml version="1.0" encoding="utf-8" ?>
> <NEKTAR>
> <EXPANSIONS>
> <E COMPOSITE="C[30011]" NUMMODES="5" TYPE="GLL_LAGRANGE_SEM"
> FIELDS="u,v,w,p" />
> </EXPANSIONS>
> <CONDITIONS>
> <FUNCTION NAME="InitialConditions">
> <E VAR="u" VALUE="1.0" />
> <E VAR="v,w,p" VALUE="0.0" />
> </FUNCTION>
> <SOLVERINFO>
> <I PROPERTY="SolverType"
> VALUE="VelocityCorrectionScheme"/>
> <I PROPERTY="EqType" VALUE="UnsteadyNavierStokes"
> />
> <I PROPERTY="Projection" VALUE="Continuous"
> />
> <I PROPERTY="EvolutionOperator" VALUE="Nonlinear"
> />
> <I PROPERTY="TimeIntegrationMethod" VALUE="IMEXOrder2"
> />
> <I PROPERTY="GlobalSysSoln" VALUE="IterativeStaticCond" />
> <I PROPERTY="Driver" VALUE="Standard"
> />
> </SOLVERINFO>
> <GLOBALSYSSOLNINFO>
> <V VAR="u,v,w">
> <I PROPERTY="GlobalSysSoln" VALUE="IterativeStaticCond"
> />
> <I PROPERTY="Preconditioner" VALUE="LowEnergyBlock"/>
> <I PROPERTY="IterativeSolverTolerance" VALUE="1e-8"/>
> </V>
> <V VAR="p">
> <I PROPERTY="GlobalSysSoln"
> VALUE="IterativeStaticCond" />
> <I PROPERTY="Preconditioner"
> VALUE="FullLinearSpaceWithLowEnergyBlock"/>
> <I PROPERTY="IterativeSolverTolerance" VALUE="1e-7"/>
> </V>
> </GLOBALSYSSOLNINFO>
Everything works fine with TYPE="MODIFIED". Noteworthy, I tried
TYPE="GLL_LAGRANGE_SEM" with the periodic pipe tutorial and it worked
there, which is adding to my confusion!
Could you kindly point out if something is wrong with my setup?
Kind regards
syavash
*******************
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 Everyone
What is the best strategy to have a high-order mesh starting from a Hex
mesh around a wall-mounted cylinder?
So far, I have tried spherigon, high-order cylinder, and projectcad but I
couldn't get a valid mesh.
When I try projectcad, it gives me an error message that it only works with
tets and prisms.
The initial Hex mesh is created in Nastan format and then revised in Gmsh.
Subsequently, NekMesh is used to convert it to xml. It is a valid mesh but
building a high-order grid has been a challenge for me so far.
I appreciate your kind help.
Kind regards
syavash
*******************
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.
*******************
Hello NeEKTAR++ users,
I have a simple question. Does NKETAR++ have the ability to simulate real scale models or not?
So far, I always used it in dimensionless form. But for some cases, it is impossible to make the whole model dimensionless.
Does the code work properly for cases with real dimensions and actual velocities?
Best regards,
Mahdi Erfanian Nakhchi
Lecturer, Northumbria University
This message is intended solely for the addressee and may contain confidential and/or legally privileged information. Any use, disclosure or reproduction without the sender's explicit consent is unauthorised and may be unlawful. If you have received this message in error, please notify Northumbria University immediately and permanently delete it. Any views or opinions expressed in this message are solely those of the author and do not necessarily represent those of the University. Northumbria University email is provided by Microsoft Office365 and is hosted within the EEA, although some information may be replicated globally for backup purposes. The University cannot guarantee that this message or any attachment is virus free or has not been intercepted and/or amended.
Dear all,
We are pleased to announce the release of Nektar++ v5.3.0.
As always, if you encounter any problems please feel free to contact us
on the mailing list nektar-users(a)imperial.ac.uk. You can also report
bugs and issues on our issue tracker
(https://gitlab.nektar.info/nektar/nektar/-/issues)
This release includes a range of new features and improvements over the
5.2.0 release:
**Library**
- Fixed avx512 back-end for SimdLib (!1333)
- Remove unnecessary IterPerExp methods (!1366)
- Added float to scalar and avx2 back-end, disable avx512, sse2, sve (!1255)
- Updated the library to use m_phys and m_coeff as function arguments
(!1412)
- Added float and restored SVE back-end for SimdLib (!1373)
- Fix VmathSIMD by adding optional mapping with # of lanes (!1388)
- Added float and restore avx512 back-end for SimdLib (!1387)
- Fix namespace pollution which causes boost 1.74+ errors (!1389)
- Fix missing copy assignment operator warnings in clang 13+ (!1391)
- Added checkpoint file writing start time in the checkpoint filter (!1401)
- Fix boost 1.77 compatibility errors (!1420)
- Replaced depricated "sprintf" with "std::to_string" (!1406)
- Add compatiblity patch to solve conflict between flex 2.6.3 and scotch
6.0.4 (!1410)
- Add Parareal Driver module (!1317)
- Maintenance for C++-17 compatibility: removed std::unaray_function
base class due to removal from the std (!1419)
- Fixed the comment of function Vvtvvtp in VmathArray (!1408)
- Add a FieldConvert utility to compute the divergence of the velocity
(!1413)
- Added new filter to calculate variables integral on composite mesh (!1409)
- Overload PhysEvaluate to give first derivatives using barycentric
interpolation (!1323)
- Non-conformal interface support (!1323)
- Fix a I/O issue related to the IO_InfoSteps parameter (!1422)
- Fix a I/O issue related to the IO_CheckSteps parameter (!1423)
- Fix boost 1.77 compatibility errors (!1402)
- Replaced depricated "sprintf" with "std::to_string" (!1406)
- Add compatiblity patch to solve conflict between flex 2.6.3 and scotch
6.0.4 (!1410)
- Templating FieldUtils::Interpolator class (!1420)
- Fix virtual function overrides in StdRegions and LocalRegions classes
(!1435)
- Disable -Werror by default (!1443)
- Add missing override keyword to virtual functions in FieldUtils (!1452)
- Add override keyword to virtual functions in GlobalMapping and
MultiRegions (!1450)
- Add fmod and modulus operator to interpreter (!1089)
- Add command line option and environment variable to disable backup
field files (!1154)
- Add override keyword to virtual functions in SpatialDomains (!1448)
- Add missing override keyword to virtual functions in Collections (!1453)
- Update tutorial submodule (!1511)
- Add missing override keyword to virtual functions in SolverUtils (!1451)
- Add missing override keyword to virtual functions in LibUtilities (!1459)
- Enable ARM macOS runner, fixes for SCOTCH allocation and PETSc
detection on macOS (!1462)
- Add FieldConvert module and filter to project velocity into
body-fitted coordinate system (!1467)
- Fix uninitialized coordinates in the Bodyforcing (!1472)
- Fix body-fitted velocity filter and also record the max/min for
density, pressure, and temperature field (!1490)
- Fix typos in Vmath and VDmath (!1480)
- Fix minor typo and removed unused functions in
LibUtilities/TimeIntegration (!1476)
- Fix RK5 time integration scheme (!1482)
- Fix fld file import for SingleMode expansion (!1487)
- Fix ESDIRK time integration scheme (!1484)
- Fix IMXGear time-integration scheme for consistent second-order
accuracy (!1489)
- Fix ESDIRK time integration scheme (!1484)
- Fix TimeIntegrationDemo.cpp and add ESDIRK tst files to the CI (!1485)
- Add DIRKOrder1, BDFImplicitOrder3, BDFImplicitOrder4, RungeKutta1, and
RungeKutta3 schemes to the register (!1485)
- Use DIRK (instead of IMEXdirk) schemes for the start-up phase of
high-order BDF and AM schemes (!1485).
- Fix IMEXdirk_1_2_2 and IMEXdirk_2_3_3 time-integration schemes (!1499)
- Add extrapolation time-integration scheme (!1488)
- Fix CNAB/MCNAB time-integration schemes (!1493)
- Slightly tidy-up time integration algorithms (!1496)
- Reduced memory usage in the FilterHistoryPoint (!1458)
- Remove redundant functor typedef (!1498)
- Add missing m_ prefix to member variables in FFTW (!1504)
- Make some virtual functions protected (!1506)
- Remove trailing CONDITIONS tag in xml files (!1510)
- Disable problematic
Movement_fixed_3D_stacked_cylinders_curved_hdf5_par test (!1507)
- Fix I/O issue related to Hdf5 that was unable to open file and fixed
similar issue in other IO classes in BasicUtils (!1512)
- Remove unused function SetUpXmlDoc (!1513)
- Add new interpolation function to FieldUtils (!1514)
- Generalize the use of the space communicator (!1518)
- Add parallel-in-time feature to FieldConvert (!1520)
- Add Spectral Deferred Correction (SDC) time integration schemes (!1481)
- Redesign of Spectral Deferred Correction (SDC) algorithm (!1523)
- Modify SessionReader to read restart/exact solution files
parallel-in-time (! 1521)
- Fix Polylib_test.cpp (!1524)
- Update to Parareal file output (!1517)
- Add convergence criteria to Parareal driver (!1457)
- Add time metadata to tecplot output (!1525)
- Fix segmentation fault when no time integration method specified for
unsteady problem (!1526)
- Set adjacent elements for m_bndcondExpansions for both CG and DG (!1491)
- Fix inconsistent treatment of 1D and 2D/3D expansions in
DisContField::v_GetBoundaryToElmtMap (!1491)
- Tidy-up parallel-in-time processing in FieldConvert (!1529)
**Python**
- Add wrappers for Interpreter and Equation classes (!1329)
**CompressibleFlowSolver**
- Added Laplacian (NonSmooth) AV to the explicit Navier Stokes solver
(!1372)
- Added Physical AV to the implicit Navier Stokes solver (!1372)
- Fixed Segmentation Fault when using C0 Smoother with Shock Capturing
(!1394)
- The Incomplete IP method was made the default method for the IP method
(!1377).
- Add additional parameters for the Isentropic Vortex equation system
(!1323)
- Improve performance of the perconditioner and diffusion operator (!1393)
- Re-add the SFD test with an updated restart file (!1399)
- Improve performance of the block diagonal operator of the
preconditioner (!1404)
- ExtractSurface2DCSF utility is updated to use the boost program option
(!1407)
- Fix a Wuninitialized-const-reference warning (!1449)
- New implementation of the Stagnation Inflow Boundary Condition (!1478)
- Remove m_root in PreconCfs to avoid possible future conflict with
parallel-in-time driver (!1515)
- Update to Parareal file output (!1517)
**CardiacEPSolver**
- Fix a shadowed loop counter variable in the benchmark filter (!1436)
- Update functions in derived classes to be consistent with the base
class and add override keyword to virtual functions (!1439)
- Add dummy projection to CardiacEPSolver (!1527)
**IncNavierStokesSolver**
- Replaced depricated "sprintf" with "std::to_string" (!1406)
- Extended Reynolds Stresses filter to passive scalars (!1430)
- Fixed Taylor-Hood expansion for VCSWeakPressure (!1444)
- Fix filename in LinearisedAdvection (!1479)
- Added scalar advection terms to AdjointSolver (!1466)
- Remove member variables as funtion parameters in LinearisedAdvection
solver (!1522)
**VortexWaveInteractionSolver**
- Replaced depricated "sprintf" with "std::to_string" (!1406)
**DummySolver**
- Fix CWIPI test to use DirectFull for projection of received data (!1502)
**NekMesh**
- Replace VTK pointers with VTK smart-pointers to avoid memory leaking,
when exporting in .vtu format (!1386)
- Preserve CAD face labels and save in to session file as a "NAME=" tag
on the composites (!1396)
- Fix a header include which caused compilation errors on OCC versions
newer than v7.4 (!1395)
- Add option to refine curves in the same manner as the line refinement
functionality (!1298)
- Add refined curves and refined lines now prompt the octree to
subdivide until the desired refined delta is reached (!1298)
- Fix a segmentation fault with WriteOctree due to missing 'order'
parameter (! 1418)
- Multi domain input/output for Nekpp and HDF5 file formats (!1323)
- Fix CADSurfOCE curvature bug where negative curvature values could be
returned causing incorrect mesh spacing (!1442)
- Fix ProjectCAD bug with findAndProject where the projection was
missing and variable was passed without reference (!1442)
- Fix 3d_bl_wing test case for STEP files where the wrong surfaces were
selected for the BL (!1442)
- Fix error when setting BL progression to 1.0 due a division by 0 (!1455)
- Changed the BOOLPARAMETERS tag in InputMCF to allow disabling the high
order surface optimisation with "DisableSurfaceOptimiser" (surface
optimisation is still enabled by default) (!1455)
- Fix 3d_bl_wing test case for STEP files - updated to use an improved
CAD definition for the NACA aerofoil (!1486)
**FieldConvert**
- Add vars and dirs options in the gradient module to specify fields and
partial derivative directions (!1415)
- Fix range option so that it also works with hdf5 (!1414)
- Fix halfmodetofourier module with triangles (!1492)
- Fix the output field names of WSS module of FieldConvert, revert !1352
(!1528)
**Miscellaneous**
- Updated gitignore to be friendly with CLion IDE (!1405)
- Correct header section of .cpp, .hpp, and .h files (!1426)
- Linux format .cpp, .hpp, and .h files (!1432)
- Fix wsign compare warning (!1437)
- Fix some Woverloaded-virtual warning (!1439)
- Add missing override keyword to virtual functions in solvers (!1440)
- Fix some Wunused-variable (!1438)
- Fix unused parameter warnings in virtual functions (!1441)
- Fix a Wreorder warning (!1445)
- Fix some Wimplicit-fallthrough warnings (!1446)
- Switch to using pkg-config for finding PETSc (!1454)
- Use Nektar::LibUtilities::Timer for better accuracy (!1468)
- Make some virtual functions protected (!1469)
- Extend clang-format checks to solvers, utilities, tests and templates
(!1434)
- Fix documentation for exponential scheme (!1519)
**CI**
- Enable packaging for Fedora 35, removed Fedora 33/34 from package
builds. (!1424)
- Add header checking for \*.cpp, \*.hpp and \*.h files to the CI (!1431)
- Enable packaging for Fedora 36. (!1429)
- Fix XML files indentation (!1428)
- Update solvers CMakeList.txt to fix some warnings detection issue (!1447)
- Remove -fpermissive from NektarCommon.cmake (!1460)
- Remove old distribution versions, added Fedora 35/36 testing to CI (!1461)
- Kill orphan Tester-g processes on Windows and remove source tree after
build (!1471)
- Fixed path issue and warning in the nektar-workbook image (!1470)
Cheers,
Chris
--
Chris Cantwell
Senior Lecturer in Aeronautics
Department of Aeronautics
Imperial College London
South Kensington Campus
London SW7 2AZ
Tel: +44 (0)20 759 45050
Email: c.cantwell(a)imperial.ac.uk
www.imperial.ac.uk/people/c.cantwell
Dustin
I was wondering if you were referring to the difference in scales of two
geometrically similar configuration. If so, you could create a mesh with
H=28 mm (Reference [31] in the paper you provided) and then scale it up to
achieve a geometry with H=1 m.
Kind regards
syavash
On Tue, Mar 21, 2023, 22:43 Ma, Ting-Hsuan <TIM48(a)pitt.edu> wrote:
> Hi Syavash,
>
>
>
> I have not been able to find cases where H = 1 [m]. The only from scratch
> creation, I was able to find is for H = 28 [mm]. If you could point me in
> the right direction, that would be most helpful.
>
>
>
> The current mesh that I am working with is from the example provided in my
> previous thread. This mesh however doesn’t allow for me to separate between
> a top and bottom boundary. Although, there are ways around this, it is time
> consuming and prone to errors. I am just trying to keep the same mesh as
> the baseline case that I am currently running, while including this
> modification on the boundaries so I can make slight changes and see how
> that effects the simulation overall.
>
>
>
> Thanks,
>
> --
>
> Dustin (Ting-Hsuan) Ma
>
> Graduate Researcher
>
> Department of Mechanical and Materials Science
>
> University of Pittsburgh
>
> Tim48(a)pitt.edu
>
>
>
>
>
> *From: *Ehsan Asgari <eh.asgari(a)gmail.com>
> *Date: *Tuesday, March 21, 2023 at 3:07 PM
> *To: *Ma, Ting-Hsuan <TIM48(a)pitt.edu>, nektar-users(a)imperial.ac.uk <
> nektar-users(a)imperial.ac.uk>
> *Subject: *Re: [Nektar-users] Extract .geo file from .xml file
>
> Hi Dustin
>
>
>
> Is there a specific reason for not creating a mesh from scratch? The
> period hill is a well-known benchmark with analytical geometry definition.
>
>
>
> Kind regards
>
> syavash
>
>
>
> On Tue, Mar 21, 2023, 21:47 Ma, Ting-Hsuan <TIM48(a)pitt.edu> wrote:
>
> This email from TIM48(a)pitt.edu 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspam.ic.a…>
> to disable email stamping for this address.
>
>
>
> Hi,
>
>
>
> I am working on reverse creating the periodic hill case provided in
> appendix A of
> https://www.sciencedirect.com/science/article/pii/S0010465515000533?via%3Di…
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.scien…>
> . Whist working on this, I was able to use python to extract the vertex and
> line information from the .xml file provided However, even doing so does
> not provide a straight forward way for me to separate the noslip boundaries
> into a top and bottom boundary. Furthermore, when I loaded this extracted
> version into Gmsh, some errors did arise and the mesh seems to be more
> complicated than what I would have hoped.
>
>
>
> I would like to know if anyone has done this in the past? If so, could you
> give me a walkthrough of how you could successfully recreate this mesh? Or
> if there are ways existing out there that’ll allow me to separate the
> noslip boundary condition into 2 sub categories.
>
>
>
> Thanks,
>
> Dustin Ma
>
>
>
> _______________________________________________
> Nektar-users mailing list
> Nektar-users(a)imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.i…>
>
>
*******************
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,
I am working on reverse creating the periodic hill case provided in appendix A of https://www.sciencedirect.com/science/article/pii/S0010465515000533?via%3Di… . Whist working on this, I was able to use python to extract the vertex and line information from the .xml file provided However, even doing so does not provide a straight forward way for me to separate the noslip boundaries into a top and bottom boundary. Furthermore, when I loaded this extracted version into Gmsh, some errors did arise and the mesh seems to be more complicated than what I would have hoped.
I would like to know if anyone has done this in the past? If so, could you give me a walkthrough of how you could successfully recreate this mesh? Or if there are ways existing out there that'll allow me to separate the noslip boundary condition into 2 sub categories.
Thanks,
Dustin Ma
*******************
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 have installed version 5.3, but I have come across the following error
when using projectcad module:
No such module: Process: projectcad
Is something wrong with my installation?
Kind regards
syavash
*******************
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 have just started studying Nektar++ for the purpose of adding a new type of element for my research. It is my pleasure to join this great user group.
As a first step, I'm exploring the function for reading my mesh in Swansea .plt format, which is virtual void Nektar::NekMesh::InputSwan::Process() within file library/NekMesh/Module/InputModules/InputSwan.cpp. Some improvements have been made to the function so it successfully converts a linear .plt mesh in Swansea format to a Nektar++ .xml session file with boundary faces on each surface fall into an individual COMPOSITE.
However, the function seems able to read the 3rd order tetrahedral mesh (at least for the connectivity), but the boundary faces are just linear triangles. Would the subsequent processing convert the linear faces into curved ones?
In fact, the NekMesh main function will crash after a successful return from InputSwan::Process():
[InputSwan] Reading Swansea mesh file 'm6.plt'
[InputSwan] # tetrahedra : 235377
[InputSwan] # points : 1079083
[InputSwan] mesh order : 3
[InputSwan] ND : 20
[InputSwan] Mesh statistics:
[InputSwan] - Mesh dimension : 3
[InputSwan] - Element dimension : 3
[InputSwan] - Has CAD attached : no
[InputSwan] - Node count : 41093
[InputSwan] - Edge count : 281235
[InputSwan] - Face count : 475520
[InputSwan] - Elements : 235377
[InputSwan] - Bnd elements : 9532
[InputSwan] - Number of composites : 19
[InputSwan] - Lower mesh extent : -125 0 -125
[InputSwan] - Upper mesh extent : 125 124.901 125
[InputSwan] Element counts (regular/deformed/total):
[InputSwan] - Triangle : 0 9532 9532
[InputSwan] - Tetrahedron : 0 235377 235377
[InputSwan] Finished reading mesh.
[InputSwan] - Element dimension : 3
[InputSwan] - Space dimension : 3
[InputSwan] - No. of nodes : 41093
[InputSwan] - No. of 3D elements : 235377
[InputSwan] - No. of boundary elements : 9532
[InputSwan] - Elapsed time: 156.314s.
[OutputNekpp] Writing Nektar++ file 'm6.xml'
Fatal : Level 0 assertion violation
Where : /lustre/xi.zou/Documents/work_folder/nektar/nektar-v5.2.0/library/NekMesh/MeshElements/Face.cpp[79]
Message : Face nodes of tensor product only supported for quadrilaterals.
terminate called after throwing an instance of 'Nektar::ErrorUtil::NekError'
what(): Level 0 assertion violation
Where : /lustre/xi.zou/Documents/work_folder/nektar/nektar-v5.2.0/library/NekMesh/MeshElements/Face.cpp[79]
Message : Face nodes of tensor product only supported for quadrilaterals.
I look forward to hearing from the experts on NekMesh and a further discussion.
Best regards,
Xi
Dr. Xi Zou
xi.zou(a)swansea.ac.uk<mailto:xi.zou@swansea.ac.uk>
Research Assistant
Zienkiewicz Institute for Modelling, Data and AI
Faculty of Science and Engineering
Swansea University
Swansea, UK
*******************
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 went through the user-guide to see how to convert the parallel files into
a single field using FieldConvert. Unfortunately, I wasn't able to do it.
Is there any specific command to do this? For example, I have 128 parallel
fields inside a solution directory. I'd like to reconstruct them into a
single file to post-process the solution.
Kind regards
syavash