*******************
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 a 2.5D solution (2D in the x-y plane with Fourier expansion in the z
direction) run with the incompressible Navier-Stokes solver and I need to
replicate it N times in the homogeneous direction. If the solution has
HomModesZ for an extension LZ, I need the new solution to fit N replica in
an extension N*LZ with a resolution N*HomModesZ. I have tried several
modules of FieldConvert, but rather than N replicas of the original
solution, the result I get is a stretched version of it.
In principle this should be a very simple thing to do, as the coefficients
of mode k of the original solution should be copied to mode k*N of the new
solution, leaving all modes that are not multiples of N empty (zeroes). The
trouble is that implementing this requires an understanding of how modes
are labeled and I don't manage to get the hold of it. For a simple
1D-periodic solution whose Fourier expansion modes are saved in a
sequential complex array, replicating three times would be as simple as:
A_original = {a0, a1, a2, a3, ..., an}
A_new = {a0, 0, 0, a1, 0, 0, a2, 0, 0, a3, ..., 0, 0, an}
Could someone please give me some hints as to how to implement this?
Perhaps an existing module that I can take as a reference and the sort of
changes that could get the intended result? I believe this would not take
more than a few minutes for someone that is familiar with the code. Perhaps
someone acquainted with the working can help me implement such a
replication module for FieldConvert?
Thank you.
Cheers,
Guillermo
*******************
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 get the following error in the first iteration (or sometimes after some
iterations):
CG iterations made = 5001 using tolerance of 1e-09 (error = -nan, rhs_mag =
13729.7)
Fatal : Level 0 assertion violation
Exceeded maximum number of iterations
My question is a bit general: What are the possible causes of this error?
What I understand is that the solvers are unable to converge to a solution
(in finite iterations). The mesh is okay. I sometimes solve it by tweaking
the initial conditions or increasing/decreasing the time step. But, this is
a bit heuristic. As long-time users/developers, do you know other roots of
this error? Does this type of error indicate to you a certain kind of
problem?
For example, if the solver diverges quickly or doesn't even complete one
iteration I usually suspect the mesh (provided all the other schemes are
set reasonably). However, I am able to get results with a very similar mesh
and meshing technique, so I think it is okay in this case.
Happy holidays,
Best regards,
Ilteber
--
İlteber R. Özdemir
*******************
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 tried to run Sod problem using Nektar. The solver information is as
follows,
<SOLVERINFO>
<I PROPERTY="EQType" VALUE="EulerCFE"
/>
<I PROPERTY="Projection" VALUE="DisContinuous"
/>
<I PROPERTY="AdvectionType" VALUE="WeakDG"
/>
<I PROPERTY="TimeIntegrationMethod" VALUE="ForwardEuler"
/>
<I PROPERTY="UpwindType" VALUE="HLLC"
/>
<I PROPERTY="LocalTimeStep" VALUE="True"
/>
<I PROPERTY="ShockCaptureType" VALUE="NonSmooth"
/>
</SOLVERINFO>
The information of expansion is
<E COMPOSITE="C[1]" NUMMODES="3" FIELDS="rho,rhou,rhov,E" TYPE="MODIFIED" />
The mesh is generated by Gmsh. For simplicity, I use qausi-structured mesh
with dx=0.0047 and dy=0.0036. According to my knowledge of numerical
scheme, CFL is usually between 0.1 and 0.5. However, I found out that CFL
must be 0.01 to ensure stable simulation. Why is CFL so small in Nektar?
Chengeng