*******************
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 average the solutions of planes across the homogenous direction
in a Quasi 3-D simulation?
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 Community,
I am running a full 3D DNS simulation at Re=400 of a flow past a rectangular prism using the incompressible solver. This flow is laminar but 3D effects are present. I am using a structured mesh generated using gmsh with a p order of 4 which comes to roughly 2.6 million degrees of freedom. A colleague is able to run a similar but slightly more complex DNS simulation at Re=3900 on 1/8 the number of processors and he still obtains results much faster. All signs indicate I should be able to use far fewer resources than I currently am, but neither of us can figure out how to optimise further than I already have. I followed the optimisation section of the Nektar user guide, tweaked my mesh several times, changed the time step size, etc., but all of these adjustments showed marginal improvements at best. I would be very grateful if anyone has any suggestions. I am providing my case files here: https://drive.google.com/drive/folders/1iT0GvZgE0MyfmjNe1GYMlAKJp-8fh57X?us… the slurm file called P4.sh has the script I normally use on clusters.
I look forward to hearing from you!
All the best,
Isaac
*******************
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.
*******************
TCS Confidential
Dear support team
I am working with TCS research and trying to model liquid metal batteries. Can Nektar++ be used to model electro vortex flows arising due to interaction with current carrying conductors?
Regards
Murali
TCS Confidential
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
*******************
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 Users,
I'm trying to implement some new Nektar++ solvers for various fluid
equations (derived from plasma physics).
Let's say I have a pair of discontinuous Galerkin fields (n & omega). I've
got an advection velocity, which works fine in the API for advecting
stuff. But I also want a term in the RHS of n_dot (where _dot means d/dt)
and omega_dot which is proportional to d^2 n / dz^2.
I can easily evaluate this term in the ExplicitTimeInt method but I think I
need to do something to modify the numerical fluxes as well. I think this
is done in the GetFluxVector method, so I went into that and modified the
output (basically adding something like (0, 0, dn/dz) into the flux so when
the div is taken, there is the second derivative).
The question is whether this is the right thing to do to get this system
working correctly. Will it work and are there likely to be problems (e.g.
will it upwind correctly, as the resulting code seems to have poor
stability).
Sorry for what might seem a bit of an obscure question, I can supply more
details if it helps.
Thanks,
Ed.
*******************
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,
I am unable to restart a simulation after moving the case files to a new cluster. I began the simulation on one cluster and ran it to the end of the transient flow stage. Once finished, took the final .fld file, put it on another cluster and tried to run it from that time step. My expansion section is
<EXPANSIONS>
<F VAR="u,v,w,p" FILE="session.fld" />
</EXPANSIONS>
and my initial conditions are
<FUNCTION NAME="InitialConditions">
<F VAR="u,v,w,p" FILE="session.fld" />
</FUNCTION>
When I try to start the simulation on the new cluster, I get the same CG iterations problem every time (see output file as text at the bottom of this email). The new cluster uses different CPUs, so I thought this could have something to do with it, but I am still getting the same problem when I try different CPUs. The only thing I tried which had any effect was changing the time step size. This shouldn't have been necessary because the one I was using was already keeping the CFL low (~0.5) during the transient flow. Decreasing CFL only lowered the size of the error on the CG iterations made... line displayed before the Level 0 assertion violation, and not by much.
I would be grateful for your assistance.
Regards,
Isaac
=======================================================================
EquationType: UnsteadyNavierStokes
Session Name: session
Spatial Dim.: 3
Max SEM Exp. Order: 5
Num. Processes: 208
Expansion Dim.: 3
Projection Type: Continuous Galerkin
Advect. advancement: explicit
Diffuse. advancement: implicit
Time Step: 0.004
No. of Steps: 187500
Checkpoints (steps): 63
Integration Type: IMEX
Splitting Scheme: Velocity correction (strong press. form)
Dealiasing: spectral/hp
Smoothing-SpecHP: SVV (spectral/hp DG Kernel (diff coeff = 1*Uh/p))
=======================================================================
Initial Conditions:
- Field u: from file session.fld
- Field v: from file session.fld
- Field w: from file session.fld
- Field p: from file session.fld
CG iterations made = 5001 using tolerance of 1e-09 (error = 9.57894e-07, rhs_mag = 15.6227)
Fatal : Level 0 assertion violation
Exceeded maximum number of iterations
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpiexec detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[2602,1],4]
Exit code: 1
--------------------------------------------------------------------------
*******************
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,
Where can I find the indexing convention for field data and how it translates to spatial coordinates, and do I even need this information for postprocessing .fld files with python? I would like to read my velocity field, dealiase it by the cell boundaries, and save it in a new .fld file which I can then convert to .dat or .plt. I had looked at NekPy for this but could only find information about preprocessing when I am interested in postprocessing. So far I have been using the PyTables library to read the field file and .nekg mesh file. I have gained some useful insight from this but I can see it taking a lot of time and effort to decode the indexing and there are several other issues I will encounter along the way before I have full control over the fields. Before I continue down this path, could anyone advise me if this is the best way to go about my postprocessing? I would like to continue using python if possible but am open to other suggestions.
Also, how is the data arranged within cells when NUMMODES>2?
Thank you,
Isaac
Hi Alexandra,
I have attached the output log of the simulation with dt=0.00025 with
verbosity. Do you spot anything unusual? I guess by error, you meant the
one associated with the tolerance.
Kind regards
syavash
On Fri, Jul 28, 2023 at 1:32 PM Alexandra Liosi <liosi.alex(a)gmail.com>
wrote:
> Hi Syavash,
>
> Thank you for sharing your log files with me. There are 2 things that I
> noticed:
> 1. In both cases, the element with ID 31453 has the largest CFL value, I
> would check how the mesh looks around this element.
> 2. I would recommend to run with verbosity activated to see the error from
> the Conjugate Gradient solver. To activate the verbosity, you need to use
> the -v option after your solver. For example, the command would look like
> this:
> IncNavierStokesSolver mesh.xml session.xml -v > results
> Could repeat these tests with verbosity on to see what is happening with
> the conjugate gradient solver ?
>
> Kind regards,
> Alexandra
>
> On Fri, 28 Jul 2023 at 12:46, Alexandra Liosi <liosi.alex(a)gmail.com>
> wrote:
>
>>
>>
>> ---------- Forwarded message ---------
>> From: Ehsan Asgari <eh.asgari(a)gmail.com>
>> Date: Fri, 28 Jul 2023 at 09:49
>> Subject: Re: [Nektar-users] problem with changing time-step
>> To: Alexandra Liosi <liosi.alex(a)gmail.com>
>>
>>
>> Hi Alexandra
>>
>> Following your comments, I made an attempt to compare two cases with
>> different time steps, one with dt=0.0005 and the other with dt=0.00025.
>> Both runs started from the same initial condition.
>> I have attached the log files of both simulations. It is very strange, as
>> the case with lower time-step is taking significantly more time to
>> converge!!
>> I really have no clue how this can be explained. I run simulations on a
>> pure hex mesh with wall-resolved boundary layer.
>> Do you have any suggestions?
>>
>> Kind regards
>> syavash
>>
>>
>>
>>
>> On Wed, Jul 26, 2023 at 10:10 PM Alexandra Liosi <liosi.alex(a)gmail.com>
>> wrote:
>>
>>> Hi Syavash,
>>>
>>> Thank you for the explanation!
>>>
>>> Is there a reason why you choose to start from a higher CFL and then
>>> reduce it? Also, where do you notice the oscillations? Would it be possible
>>> for your to rerun the case even for a couple of time-steps to print the
>>> error of the CG iterations? In my simulations using the incompressible
>>> solver, I have noticed that the forces were oscillating because the
>>> pressure and velocity tolerances for the conjugate gradient(CG) solver were
>>> very relaxed. There could be other reasons as well, hence my list of
>>> questions.
>>>
>>> Kind regards,
>>> Alexandra
>>>
>>> On Wed, 26 Jul 2023 at 11:40, Ehsan Asgari <eh.asgari(a)gmail.com> wrote:
>>>
>>>> Hi Alexandra
>>>>
>>>> Thanks for your kind reply.
>>>> I let the simulation run for a while with CFL=0.4 for instance. Then I
>>>> modify the time-step size so that I have CFL=0.2 and restart the simulation
>>>> from the latest field file.
>>>>
>>>> I use the following session file:
>>>>
>>>> <NEKTAR>
>>>>> <EXPANSIONS>
>>>>> <E COMPOSITE="C[30011]" NUMMODES="6" FIELDS="u,v,w"
>>>>> TYPE="MODIFIED" />
>>>>> <E COMPOSITE="C[30011]" NUMMODES="6" FIELDS="p" TYPE="MODIFIED" />
>>>>> </EXPANSIONS>
>>>>> <CONDITIONS>
>>>>> <FUNCTION NAME="InitialConditions">
>>>>> <F VAR="u,v,w,p" FILE="step98_Cubic7_restartFieldHdf5.fld"
>>>>> />
>>>>> </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="SpectralVanishingViscosity" VALUE="True"/>
>>>>> <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-7"/>
>>>>> </V>
>>>>> <V VAR="p">
>>>>> <I PROPERTY="GlobalSysSoln"
>>>>> VALUE="IterativeStaticCond" />
>>>>> <I PROPERTY="Preconditioner"
>>>>> VALUE="FullLinearSpaceWithLowEnergyBlock"/>
>>>>> <I PROPERTY="IterativeSolverTolerance" VALUE="1e-6"/>
>>>>> </V>
>>>>> </GLOBALSYSSOLNINFO>
>>>>
>>>>
>>>> I don't have the log file as it was overwritten.
>>>>
>>>> Kind regards
>>>> syavash
>>>>
>>>> On Wed, Jul 26, 2023 at 12:00 PM Alexandra Liosi <liosi.alex(a)gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Syavash,
>>>>>
>>>>> Thank you for your email. Are you using as an initialisation field the
>>>>> one that you received with the higher time-step? How large are your
>>>>> starting CFL and the CFL using the new time-step? Could you provide the log
>>>>> file and the session file that you use?
>>>>>
>>>>> Kind regards,
>>>>> Alexandra
>>>>>
>>>>> On Wed, 26 Jul 2023 at 05:25, Ehsan Asgari <eh.asgari(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>> This email from eh.asgari(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.
>>>>>>
>>>>>>
>>>>>> Dear All,
>>>>>>
>>>>>> When I change the time-step size to reduce the CFL and restart the
>>>>>> simulation, I get oscillations in both pressure and velocity that won't go
>>>>>> away.
>>>>>> Is there any explanation for this?
>>>>>>
>>>>>> Kind regards
>>>>>> syavash
>>>>>> _______________________________________________
>>>>>> Nektar-users mailing list
>>>>>> Nektar-users(a)imperial.ac.uk
>>>>>> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
>>>>>>
>>>>>
Alexandra,
I will do as you suggest. However I don't get what you mean by the error. I
don't see any in the log files. Would you clarify that for me?
Kind regards
syavash
On Fri, Jul 28, 2023, 13:32 Alexandra Liosi <liosi.alex(a)gmail.com> wrote:
> Hi Syavash,
>
> Thank you for sharing your log files with me. There are 2 things that I
> noticed:
> 1. In both cases, the element with ID 31453 has the largest CFL value, I
> would check how the mesh looks around this element.
> 2. I would recommend to run with verbosity activated to see the error from
> the Conjugate Gradient solver. To activate the verbosity, you need to use
> the -v option after your solver. For example, the command would look like
> this:
> IncNavierStokesSolver mesh.xml session.xml -v > results
> Could repeat these tests with verbosity on to see what is happening with
> the conjugate gradient solver ?
>
> Kind regards,
> Alexandra
>
> On Fri, 28 Jul 2023 at 12:46, Alexandra Liosi <liosi.alex(a)gmail.com>
> wrote:
>
>>
>>
>> ---------- Forwarded message ---------
>> From: Ehsan Asgari <eh.asgari(a)gmail.com>
>> Date: Fri, 28 Jul 2023 at 09:49
>> Subject: Re: [Nektar-users] problem with changing time-step
>> To: Alexandra Liosi <liosi.alex(a)gmail.com>
>>
>>
>> Hi Alexandra
>>
>> Following your comments, I made an attempt to compare two cases with
>> different time steps, one with dt=0.0005 and the other with dt=0.00025.
>> Both runs started from the same initial condition.
>> I have attached the log files of both simulations. It is very strange, as
>> the case with lower time-step is taking significantly more time to
>> converge!!
>> I really have no clue how this can be explained. I run simulations on a
>> pure hex mesh with wall-resolved boundary layer.
>> Do you have any suggestions?
>>
>> Kind regards
>> syavash
>>
>>
>>
>>
>> On Wed, Jul 26, 2023 at 10:10 PM Alexandra Liosi <liosi.alex(a)gmail.com>
>> wrote:
>>
>>> Hi Syavash,
>>>
>>> Thank you for the explanation!
>>>
>>> Is there a reason why you choose to start from a higher CFL and then
>>> reduce it? Also, where do you notice the oscillations? Would it be possible
>>> for your to rerun the case even for a couple of time-steps to print the
>>> error of the CG iterations? In my simulations using the incompressible
>>> solver, I have noticed that the forces were oscillating because the
>>> pressure and velocity tolerances for the conjugate gradient(CG) solver were
>>> very relaxed. There could be other reasons as well, hence my list of
>>> questions.
>>>
>>> Kind regards,
>>> Alexandra
>>>
>>> On Wed, 26 Jul 2023 at 11:40, Ehsan Asgari <eh.asgari(a)gmail.com> wrote:
>>>
>>>> Hi Alexandra
>>>>
>>>> Thanks for your kind reply.
>>>> I let the simulation run for a while with CFL=0.4 for instance. Then I
>>>> modify the time-step size so that I have CFL=0.2 and restart the simulation
>>>> from the latest field file.
>>>>
>>>> I use the following session file:
>>>>
>>>> <NEKTAR>
>>>>> <EXPANSIONS>
>>>>> <E COMPOSITE="C[30011]" NUMMODES="6" FIELDS="u,v,w"
>>>>> TYPE="MODIFIED" />
>>>>> <E COMPOSITE="C[30011]" NUMMODES="6" FIELDS="p" TYPE="MODIFIED" />
>>>>> </EXPANSIONS>
>>>>> <CONDITIONS>
>>>>> <FUNCTION NAME="InitialConditions">
>>>>> <F VAR="u,v,w,p" FILE="step98_Cubic7_restartFieldHdf5.fld"
>>>>> />
>>>>> </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="SpectralVanishingViscosity" VALUE="True"/>
>>>>> <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-7"/>
>>>>> </V>
>>>>> <V VAR="p">
>>>>> <I PROPERTY="GlobalSysSoln"
>>>>> VALUE="IterativeStaticCond" />
>>>>> <I PROPERTY="Preconditioner"
>>>>> VALUE="FullLinearSpaceWithLowEnergyBlock"/>
>>>>> <I PROPERTY="IterativeSolverTolerance" VALUE="1e-6"/>
>>>>> </V>
>>>>> </GLOBALSYSSOLNINFO>
>>>>
>>>>
>>>> I don't have the log file as it was overwritten.
>>>>
>>>> Kind regards
>>>> syavash
>>>>
>>>> On Wed, Jul 26, 2023 at 12:00 PM Alexandra Liosi <liosi.alex(a)gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Syavash,
>>>>>
>>>>> Thank you for your email. Are you using as an initialisation field the
>>>>> one that you received with the higher time-step? How large are your
>>>>> starting CFL and the CFL using the new time-step? Could you provide the log
>>>>> file and the session file that you use?
>>>>>
>>>>> Kind regards,
>>>>> Alexandra
>>>>>
>>>>> On Wed, 26 Jul 2023 at 05:25, Ehsan Asgari <eh.asgari(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>> This email from eh.asgari(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.
>>>>>>
>>>>>>
>>>>>> Dear All,
>>>>>>
>>>>>> When I change the time-step size to reduce the CFL and restart the
>>>>>> simulation, I get oscillations in both pressure and velocity that won't go
>>>>>> away.
>>>>>> Is there any explanation for this?
>>>>>>
>>>>>> Kind regards
>>>>>> syavash
>>>>>> _______________________________________________
>>>>>> 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 change the time-step size to reduce the CFL and restart the
simulation, I get oscillations in both pressure and velocity that won't go
away.
Is there any explanation for this?
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 everyone,
I'm solving the interaction system of an incompressible fluid flowing past a flexible moving bodies and encontoured some problems. I wander whether the SolverType of VCSMapping support the mixed CG-DG projection, such as BDFImplicitOrder2 in the TimeIntegrationMethod? Since I want to apply the Substepping scheme in my simultiaon, the code experiences error when the TimeIntegrationMethod is set as BDFImplicitOrder2.
The solverinfo is shown as follows:
<I PROPERTY="EQTYPE” VALUE="UnsteadyNavierStokes” />
<I PROPERTY="SolverType” VALUE="VCSMapping"” />
<I PROPERTY="EvolutionOperator” VALUE="Nonlinear"/>
<I PROPERTY="Projection" VALUE="Mixed CG Discontinuous" />
<I PROPERTY="TimeIntegrationMethod” VALUE="IMEXOrder2”/>
<I PROPERTY="TimeIntegraticonMethod" VALUE="BDFImplicitorder2”/>
<I PROPERTY="Extrapolation" VALUE="Substepping" />
<I PROPERTY="SubstepIntScheme” VALUE="RungeKutta2 ImprovedEuler”/>
Kind regards
Zhipeng Yu