*******************
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,
I am writing to report a problem that I am currently experiencing with Nektar++ that I am using. I am a PhD student at Peking University and I am currently working on a computational project involving a quasi-3D separated flow over a flat plate. The initial condition is a pre-computed instantaneous flow field file (format .chk), where HomModesZ is 32. I am running the calculation with HomModesZ of 128 on a supercomputer with 16 nodes and a total of 896 cores. The npz is set to 64. After the calculation is completed, the instantaneous flow field files are generated with 896 fld files. However, two of the fld files are problematic.
Specifically, the fld file with the number P0000171 is missing the <NEKTAR> tag at the beginning and the content is disordered. The fld file with the number P0000195 is an empty file. Both prevent me from converting the entire ".chk" folder to the .plt file format using the FieldConvert command. This issue has occurred multiple times in several computations, so it does not appear to be an isolated incident. The disk space usage during the computation did not reach full capacity, so I suspect there may be a bug in the calculation process. Additionally, in the similar calculations about 2 months ago, I didn’t find problems. It means that there’s probably nothing wrong with my case.
Could you please provide any suggestions on how to resolve this issue?
Thank you for your attention to this matter.
Best regards,
Du Zengzhi
*******************
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,
If I use "projectcad" on a mesh imported from Gmsh with "Set order 3", I
get the following error:
Fatal : Level 0 assertion violation
> Wrong number of modes?
> terminate called after throwing an instance of
> 'Nektar::ErrorUtil::NekError'
> what(): Level 0 assertion violation
> Wrong number of modes?
> [gra-login3:09668] *** Process received signal ***
> [gra-login3:09668] Signal: Aborted (6)
> [gra-login3:09668] Signal code: (-6)
If I import a mesh without applying the high-order option in Gmsh,
projectcad works fine!
How can I resolve this? Any kind of help is appreciated.
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,
After I converted the mesh to xml format with order=7 (using NekMesh), I
tried to split the first layer adjacent to a wall using the "bl" module
with nq=7. However, I get the following error:
Wrong number of modes?
Is there an incompatibility issue here?
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,
When I increase the polynomial order from 5 to 6, the flow field becomes
unphysical. It reaches a frozen state in which the solution does not change
with time anymore!
I have provided two planar snapshots of the flow fields for p=5 (first) and
p=6 (second) below:
[image: p=5.jpg]
[image: p=6.jpg]
As you can see in the images above, p=6 resulted in a weird wake pattern
(frozen in time) which is not physical either.
My case is a 3-D low-Re flow and I am using the incompressible solver.
I was wondering if something may be wrong with what I am doing, or if there
is a specific issue with the numerics. Any help would be appreciated.
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,
What could cause the iteration time to increase when halving the time step
size?
I have a 3-D simulation with an initial CFL 0f about 0.67. Once I halve the
time step, the CFL reduces to 0.34 but the iteration time increases! I
would expect to have a reduction in the iteration time as well.
Thanks
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,
I would like to test the efficiency of p-adaptive method in
CompressibleFlowSolver. But I could not find any sample which shows me how
to modify the session file. I have tried the same set up found in
incompressible solver Tests, as follows,
<SOLVERINFO>
<I PROPERTY="Driver" VALUE="Adaptive" />
</SOLVERINFO>
<PARAMETERS>
<P> AdaptiveMaxModes = 7 </P>
<P> AdaptiveMinModes = 4 </P>
</PARAMETERS>
The CompressibleFlowSolver ran successfully (simulated forward step
problem). But I didn't find any difference between the results of "Adaptive
Driver" and "Standard Driver".
Any suggestions are appreciated.
Regrads,
Chengeng
*******************
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,
How can I compute the velocity gradient during runtime? I see a module for
FieldConvert but I need to have the gradients during the simulation.
Velocity gradients are to be used to calculate the TKE dissipation term.
The latter may be used to calculate the Kolmogorov length scale.
Is there any filter for this? Or can anyone suggest a workaround?
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 added the ReynoldsStresses filter to the main Nektar block in my
session file:
<FILTER TYPE="ReynoldsStresses">
> <PARAM NAME="OutputFile">step95_4_averageField.fld</PARAM>
> <PARAM NAME="OutputFrequency">10</PARAM>
> <PARAM NAME="SampleFrequency"> 1 </PARAM>
> </FILTER>
I am doing parallel simulations using 128 cores.
However, I get no Reynolds stress fields in my directory. I don't get any
errors or warnings either.
Am I missing something?
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,
I'm currently working on a project involving the periodic hill geometry, and I've encountered an issue with the mesh simulation using Nektar. Despite successfully creating a decent mesh and correctly labeling all physical groups (inlet, outlet, top, and bottom boundary), I've noticed that the vertices at the inlet seem to exhibit a no-slip boundary condition, while the edges themselves seem to follow a periodic inlet/outlet condition. This behavior is unexpected since I've specified a periodic inlet/outlet boundary condition during the simulation. Has anyone experienced this problem before and found a way to resolve it? Any suggestions or insights would be greatly appreciated! A figure of P order of 5 is attached to demonstrate the problem visually.
[cid:image001.png@01D966D9.475EC5B0]
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.
*******************
Hi,
I have recently installed the development versions of Lapack and Blas
(along with some other libraries) on my local machine. I have tried to
rebuild nektar, without any modification to the make file, and it failed
because of different errors. I have also tried to with a clean installation
of the latest version, also without success - same error. I could not
manage to find the issue. I am attaching the CMake log files as well as
part of the screen output.
Some useful information:
mpirun (Open MPI) 4.1.1
cmake version 3.24.2
g++ (GCC) 11.3.1 20220421
Package lapack-devel-3.10.1-1.fc35.x86_64 is already installed.
Package lapack-3.10.1-1.fc35.x86_64 is already installed.
Package blas-devel-3.10.1-1.fc35.x86_64 is already installed.
Package blas-3.10.1-1.fc35.x86_64 is already installed.
Any help will be appreciated.
Thank you
Guillermo