*******************
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,
This may be a dumb question, but when we are setting a flowrate for a 3D1H problem (flow in the x-y and homogenous expansion in the Z). How would I set my Kinvis such that it follows the Reynolds number I am targeting? Within the parameters, enables the tag "Flowrate = 1.0". If I am doing a homogenous expansion in the z-direction, would I need to take into account LZ? or is this done automatically through the code?
I am getting confused by the notations that is used within the user manual, and looking within the source code does not help me too much as both versions do not explicitly state to take into account the area of just the line.
Any insight is appreciated,
Dustin
*******************
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 use a "Modfied" type for expansions everything works fine. But if I
specify the expansions in detailed mode:
<E COMPOSITE="C[30011]"
> BASISTYPE="Modified_A,Modified_A,Modified_A"
> NUMMODES="7,7,7"
> POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre,GaussRadauMAlpha1Beta0"
> NUMPOINTS="8,8,7"
> FIELDS="u,v,w" />
> <E COMPOSITE="C[30011]"
> BASISTYPE="Modified_A,Modified_A,Modified_A"
> NUMMODES="6,6,6"
>
> POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre,GaussRadauMAlpha1Beta0"
> NUMPOINTS="7,7,6"
> FIELDS="p" />
Then I get a bunch of errors:
[xxx518:29773] *** Process received signal ***
> [xxx518:29773] Signal: Segmentation fault (11)
> [xxx518:29773] Signal code: Address not mapped (1)
> [xxx518:29773] Failing at address: 0x27b2000
I have a fully hex mesh.
Could you kindly point out if something is wrong with the way I specify the
expansions?
Kind regards
syavash
4
7
Help
by Flávio Valberto Barrionuevo Rodrigues
15 May '23
15 May '23
*******************
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 dear Nektar users. I am trying to import mesh from Gmesh and run a
code function called SteadyAdvectionDiffusionReaction. But I have a
"segmentation fault" every time. If someone could help with this, I would
be grateful.
*******************
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++,
I am using the FieldConvert filter in my session file to output vorticity. I then isolate regions of my domain using the range option (-r) of FieldConvert in post-processing. To enable the isolation of these regions, I have found that I should produce .fld files with my filter as opposed to .plt, .dat, etc. Here is my filter:
<FILTER TYPE="FieldConvert">
<PARAM NAME="OutputFile">Fields.vtu</PARAM>
<PARAM NAME="OutputFrequency">1</PARAM>
<PARAM NAME="Modules">vorticity</PARAM>
</FILTER>
When running in parallel, this filter will output .fld directories with .fld files in them each corresponding to the processors used. This is where the issue arises: I am running simulations on a cluster using many processors and I need to save lots of time steps. My cluster has a 1 million file limit, and I will quickly hit this if I do not convert and overwrite the .fld directories into single .fld files in-situ. I know the command to do this in post-processing:
FieldConvert -f session.xml Fields_#_fc.fld/ Fields_#_fc.fld
but so far, have not been successful in implementing this in-situ.
I would be very grateful if you could offer a solution or at least steer me in the right direction with this issue. Thank you very much in advance, and I look forward to hearing from you.
Sincerely,
Isaac
Dear all,
This is a quick announcement to say that registration for the Nektar++ workshop is now open. You can register directly here: https://cassyni.com/s/nektar-workshop-2023
A few notes:
- More details regarding the workshop are now online here: https://www.nektar.info/community/workshops/nektar-workshop-2023/
- We plan to hold the workshop as a hybrid event, although we encourage in-person attendance if possible!
- If you would like to give a talk and/or present a poster, please tick the appropriate box/boxes on the registration page, and send me an email with a title/short abstract.
- We encourage those who wish to present to let us know by Monday 22nd May so that we can finalise the schedule.
If you have any questions, please do let me know!
Many thanks,
Dave
--
Dr David Moxey, PhD MMath FHEA
Reader in Engineering
david.moxey(a)kcl.ac.uk | web: davidmoxey.uk
Department of Engineering,
King's College London,
Strand, London, WC2R 2LS.
*******************
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 would recommend using the script method in Gmsh to add in the physical groups for 1d elements. A lot of time they are in incremental numbers, so it is easy to iterate through them. Below I'll provide the python code I wrote for my own use. I will emphasize here that you should double check the curves are set up in incremental numbers before applying the codes below.
##### Below this section is setting parameters for NekMesh #####
## Note that this could be done in Gmsh, but it's faster to automate it
## Note that Curve loop will need to be defined after all physical groups like
# inlet, outlet, top, and bottom boundary. If this is not done in order,
# mesh verticies will exhibit a no-slip boundary condition onto the interior
# flow. The order is paramount!
loopRange = range(1,result.shape[0])
botRange = range(0,rows.shape[0]-1)
outRange = range(rows.shape[0]-1, (rows.shape[0]+inlet.shape[0]))
topRange = range((rows.shape[0]+inlet.shape[0]), (rows.shape[0]+inlet.shape[0]+top.shape[0])-1)
inRange = range((rows.shape[0]+inlet.shape[0]+top.shape[0])-1, result.shape[0])
idx = loopRange[-1]+2 # define physical groups for rest of the assignment
## Bottom Boundary
print("//+")
print('Physical Curve("Bottom", %d) = {' % (int(idx)), end= '')
for i in botRange:
if i == botRange[-1]:
print("%d" % (int(i)+1), end = '};\n')
print("//+")
else:
print("%d," % (int(i)+1), end = '')
## Outlet
print('Physical Curve("Outlet", %d) = {' % (int(idx+1)), end= '')
for i in outRange:
if i == outRange[-1]:
print("%d" % (int(i)+1), end = '};\n')
print("//+")
else:
print("%d," % (int(i)+1), end = '')
## Top Boundary
print('Physical Curve("Top", %d) = {' % (int(idx+2)), end= '')
for i in topRange:
if i == topRange[-1]:
print("%d" % (int(i)+1), end = '};\n')
print("//+")
else:
print("%d," % (int(i)+1), end = '')
## Inlet
print('Physical Curve("Inlet", %d) = {' % (int(idx+3)), end= '')
for i in inRange:
if i == inRange[-1]:
print("%d" % (int(i)+1), end = '};\n')
print("//+")
else:
print("%d," % (int(i)+1), end = '')
# Physical Groups
print("Curve Loop(1) = {", end="")
for i in loopRange:
print("%d," % (int(i)), end="")
if i == loopRange[-1]:
print("%d" % (int(i)+1), end="};\n")
print("//+")
print("Plane Surface(1) = {1};")
print("//+")
print('Physical Surface("Fluid", %d) = {1};' % (int(idx+4)) )
Thank you for your kind reply. I appreciate it.
The problem is that I am using another package, GridPro, and when I load my
2-D mesh (a boundary layer flow) into Gmsh, the boundaries are not
recognized.
I have tried several ways to fix this but no success yet.
Kind regards
syavash
On Tue, May 9, 2023, 19:21 Matt Duran <matt.duran60(a)gmail.com> wrote:
> I have used mostly gmsh. Without seeing your exact details, make sure you
> are defining your boundary conditions and the domain in gmsh first in the
> geometry file. Then once you have specified the boundary conditions and the
> domain you can export the mesh to use in Nektar++. I'm sending you a text
> file where I have basically defined my boundary conditions and domain in a
> gmsh file.
>
> The 'Physical Line(1)' is my inlet which consists of a few curves,
> 'Physical Line(2)' is the outlet and so on.
> Physical Surface(0) is the domain, you have to manually specify every
> surface that makes up the domain.
>
> If you still have issues I can try to assist you. Or we could perhaps talk
> on zoom if I think I can help with your issue.
>
> Matt
>
>
>
>
>
>
> On Tue, May 9, 2023 at 11:26 AM Ehsan Asgari <eh.asgari(a)gmail.com> wrote:
>
>> No worries. I hope you will get satisfactory results.
>> I had a question though, how did you generate your 2-D mesh? Did you use
>> Gmsh or other commercial packages? Because I
>> have difficulty converting my 2-D mesh to Nektar format.
>>
>> syavash
>>
>> On Tue, May 9, 2023, 18:47 Matt Duran <matt.duran60(a)gmail.com> wrote:
>>
>>> Hello Syavash,
>>>
>>>
>>> That is very useful to know, 60% overprediction of drag certainly could
>>> fit with some of the strange results I'm experiencing. I will attempt to
>>> recreate some of the 3D results you have suggested to me from Jiang et al
>>> then.
>>>
>>> I appreciate the help,
>>> Matt
>>>
>>> On Tue, May 9, 2023 at 2:50 AM Ehsan Asgari <eh.asgari(a)gmail.com> wrote:
>>>
>>>> Hi Matt
>>>>
>>>> I noticed you are simulating the benchmark cylindrical flow at Re=3900.
>>>> As you may see in literature, the flow and the wake at this Re are highly
>>>> 3-D and 2-D representative will lead to overprediction of drag, as high as
>>>> 60%. So, I would not expect to have a physical vortex shedding with this
>>>> 2-D setup.
>>>>
>>>> Kind regards
>>>> syavash
>>>>
>>>>
>>>>
>>>> On Tue, May 9, 2023, 04:09 Lahooti, Mohsen <m.lahooti(a)imperial.ac.uk>
>>>> wrote:
>>>>
>>>>> Hi Matt,
>>>>>
>>>>> The vortices certainly look odd. But I wouldn't expect that much of
>>>>> symmetry at this Re either.
>>>>>
>>>>> Nevertheless, I noticed in your condition file no expansions are set.
>>>>> This means you are using the default expansion in the mesh file? I would
>>>>> explicitly set the expansion in the condition file.
>>>>> Also, I would suggest using high order out flow for the outlet boundary
>>>>>
>>>>> From your plots, the inlet and sides are also too close. Particularly
>>>>> the side walls can affect your vortex structure
>>>>>
>>>>> After your 2D is sorted out, you also might want to try 3DH1D too
>>>>>
>>>>> We have a tutorial for flow over cylinder (
>>>>> https://www.nektar.info/notebooks//tutorials/basics-incns-solver/)
>>>>> that might be helpful. It is quite through, and you might find it helpful
>>>>>
>>>>> Hope this helped
>>>>>
>>>>> Cheers
>>>>> Mohsen
>>>>>
>>>>> Mohsen Lahooti
>>>>> Lecturer in Fluid-Structure Interaction
>>>>> Mechanical Engineering
>>>>>
>>>>> Newcastle University
>>>>> School of Engineering
>>>>> Stephenson Building
>>>>> Newcastle upon Tyne
>>>>> NE1 7RU
>>>>> UK
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> *From:* nektar-users-bounces(a)imperial.ac.uk <
>>>>> nektar-users-bounces(a)imperial.ac.uk> on behalf of Matt Duran <
>>>>> matt.duran60(a)gmail.com>
>>>>> *Sent:* Tuesday, May 9, 2023 1:24:44 AM
>>>>> *To:* nektar-users <nektar-users(a)imperial.ac.uk>
>>>>> *Subject:* [Nektar-users] Turbulent cylinder flow simulation errors
>>>>>
>>>>>
>>>>> This email from matt.duran60(a)gmail.com 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 Nektar++ users,
>>>>>
>>>>> I have been experiencing unusual results while simulating cylinder
>>>>> flow with the incompressible Navier-Stokes Solver. When running the
>>>>> simulation at higher Reynolds numbers such as Re = 3900, the flow does not
>>>>> appear as would be expected. The early wake looks too unsymmetric, with
>>>>> one of the first vortex growing to an unusually large size before
>>>>> shedding. After running the simulation for a long period of time the
>>>>> vortices still look quite unusual, lacking the symmetry that would be
>>>>> expected in the vortex street.
>>>>>
>>>>> In trying to solve this issue I have checked the turbulent length
>>>>> scale and ensured I have enough mesh resolution. I also have used a small
>>>>> time scale of 0.0001.
>>>>>
>>>>>
>>>>>
>>>>> I was wondering whether anyone had advice on what I might be doing
>>>>> wrong or how I may attempt to fix the issue. I have included some of the
>>>>> results of the vorticity contours and the .xml conditions in hopes someone
>>>>> recognizes why the simulation is not behaving as expected.
>>>>>
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Matt Duran
>>>>>
>>>>> PhD student
>>>>>
>>>>> University of Central Florida
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Nektar-users mailing list
>>>>> Nektar-users(a)imperial.ac.uk
>>>>> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
>>>>>
>>>>
*******************
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 import a 3-D mesh in Gmsh, it can recognise 2-D surfaces and I label
them as physical groups for Nektar to be used as boundary conditions.
However, in case of a 2-D mesh, Gmsh cannot recognise 1-D line elements so
I cannot label them to use as boundary conditions in Nektar.
How can I get these 1-D elements recognised in Gmsh?
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 Nektar++ users,
I have been experiencing unusual results while simulating cylinder flow
with the incompressible Navier-Stokes Solver. When running the simulation
at higher Reynolds numbers such as Re = 3900, the flow does not appear as
would be expected. The early wake looks too unsymmetric, with one of the
first vortex growing to an unusually large size before shedding. After
running the simulation for a long period of time the vortices still look
quite unusual, lacking the symmetry that would be expected in the vortex
street.
In trying to solve this issue I have checked the turbulent length scale and
ensured I have enough mesh resolution. I also have used a small time scale
of 0.0001.
I was wondering whether anyone had advice on what I might be doing wrong or
how I may attempt to fix the issue. I have included some of the results of
the vorticity contours and the .xml conditions in hopes someone recognizes
why the simulation is not behaving as expected.
Thank you,
Matt Duran
PhD student
University of Central Florida
![https://res.cdn.office.net/assets/mail/file-icon/png/generic_16x16.png]geom…](https://res.cdn.office.net/assets/mail/file-icon/png/generic_16x16.png]geometry.geo){kind=link}