- Nektar-users - imperial.ac.uk

Re: [Nektar-users] FW: Restarting a 3D1D case with a 2D converged case
by Amitvikram Dutta 30 Jan '19

30 Jan '19

Hi Andrea, Thanks for your suggestions. I was not aware that we could use the modal energy filter as a diagnostic tool. I will try it. I also was not aware that the SVV cutoff frequencies in different directions could be set separately. I have just been applying a single global frequency so far. Could you describe how this is done in the parameters section? Sincerely, On Wed, Jan 30, 2019 at 3:40 AM Amitvikram Dutta < amitvikram.dutta(a)uwaterloo.ca> wrote: > > ------------------------------ > *From:* nektar-users-bounces(a)imperial.ac.ukOn Behalf OfCassinelli, Andrea > *Sent:* January 29, 2019 1:29:32 PM (UTC-05:00) Eastern Time (US & Canada) > *To:* nektar-users > > *Subject:* Re: [Nektar-users] Restarting a 3D1D case with a 2D converged > case > > Hi Amitvikram, > > What you described seems to be the correct procedure (initialise the 3DH1D > field with well-established 2D field). What kind of initial conditions are > you using for the spanwise direction? I would suggest using low-magnitude > noise to kick the Fourier modes (i.e. <E VAR="w" VALUE="0.0001*awgn(1.0)" > />). > > I would also suggest to turn on the modal filter to see if the simulation > blows up because energy accumulates in the high frequency modes. Are you > using SVV for the homogeneous direction or just in the spectral/hp plane? > You can try to lower the cutoff frequency for the spanwise direction and > see if you still observe this behaviour. > > Hope this helps. > > Kind regards, > > Andrea > > > > On 29 Jan 2019, at 18:10, Amitvikram Dutta <amitvdutta23(a)gmail.com> wrote: > > Hi all, > > I'm studying 3D devlopement of jets and am using a 3D1D setup with Fourier > coefficients in the spanwise directions. Instead of starting a 3D1D case > from scratch (the mesh contains 32 million DOF in 3D) I was thinking of > trying out a few strategies in order to speed up convergence. > > I have tried out the steady-state module but it seems to take a rather > long time to converge as well. > > I was thinking therefore, whether it would be possible to start the case > in 2D, and once it reaches convergence, to switch over to a 3D 1D mode > using a 2D .chk file as a restart point. > > I have tried out a few cases with the procedure described above, but cases > always seem to blow up after restarting in the 3D 1D mode. I could explore > the parameter space by reducing the time-step or number of expansion modes > etc, but I'd like to know if there is a fundamental block to this kind of > approach, or indeed if there are better approaches to speeding up > convergence. > > Sincerely, > -- > > *Amitvikram Dutta* > > Graduate Research Assistant > > Fluid Mechanics Research Lab > > Multi-Physics Interaction Lab > > University of Waterloo > _______________________________________________ > Nektar-users mailing list > Nektar-users(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/nektar-users > > > -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

2 1

Re: [Nektar-users] FW: FW: Restarting a 3D1D case with a 2D converged case
by Amitvikram Dutta 29 Jan '19

29 Jan '19

Thanks Stan, That seems to work. Although my solution still fails, I think it has more to do with too much dissipation in my z direction than with any other fundamental problem.... On Tue, Jan 29, 2019 at 2:39 PM Amitvikram Dutta < amitvikram.dutta(a)uwaterloo.ca> wrote: > *From:* nektar-users-bounces(a)imperial.ac.ukOn Behalf OfStanisław Gepner > *Sent:* January 29, 2019 2:38:37 PM (UTC-05:00) Eastern Time (US & Canada) > *To:* nektar-users(a)imperial.ac.uk > *Subject:* Re: [Nektar-users] FW: Restarting a 3D1D case with a 2D > converged case > > Hi Amitvikram, > > Here is an example of initializing with a mix of conditions. > > <FUNCTION NAME="InitialConditions"> > <E VAR="u" VALUE="0" /> > <E VAR="v" VALUE="0" /> > <F VAR="w" FILE="geom_2D.fld" /> > <E VAR="p" VALUE="0" /> > </FUNCTION> > > Best, > > Stan Gepner > On 1/29/19 8:21 PM, Stanisław Gepner wrote: > > Hi Amitvikram, > > Not in the chk file but in the XML session definition file. You should > have the initial conditions node. Inside you initialize u, v, p from the > file and, in a separate statement w, to whatever you want, value or > function. > > Pozdrawiam, > Stanisław Gepner > > 29 sty 2019 20:12 Amitvikram Dutta <amitvdutta23(a)gmail.com> > <amitvdutta23(a)gmail.com> napisał(a): > > Hi Stanislaw, > > How do you initialise 'w' in the 2D restart .chk file? > > Sincerely, > > On Tue, Jan 29, 2019 at 1:41 PM Amitvikram Dutta < > amitvikram.dutta(a)uwaterloo.ca> wrote: > > > ------------------------------ > *From:* nektar-users-bounces(a)imperial.ac.ukOn Behalf OfStanisław Gepner > *Sent:* January 29, 2019 1:40:52 PM (UTC-05:00) Eastern Time (US & Canada) > *To:* Amitvikram Dutta > *Cc:* nektar-users > *Subject:* Re: [Nektar-users] Restarting a 3D1D case with a 2D converged > case > > Hi, > > I do it all the time, so there should not be any fundamental problems with > using a 2d solution to start the homogeneous expansion case. > > Just make sure you initialize all variables, some with the chk file and > some manually. > > Pozdrawiam, > Stanisław Gepner > > 29 sty 2019 19:10 Amitvikram Dutta <amitvdutta23(a)gmail.com> napisał(a): > > Hi all, > > I'm studying 3D devlopement of jets and am using a 3D1D setup with Fourier > coefficients in the spanwise directions. Instead of starting a 3D1D case > from scratch (the mesh contains 32 million DOF in 3D) I was thinking of > trying out a few strategies in order to speed up convergence. > > I have tried out the steady-state module but it seems to take a rather > long time to converge as well. > > I was thinking therefore, whether it would be possible to start the case > in 2D, and once it reaches convergence, to switch over to a 3D 1D mode > using a 2D .chk file as a restart point. > > I have tried out a few cases with the procedure described above, but cases > always seem to blow up after restarting in the 3D 1D mode. I could explore > the parameter space by reducing the time-step or number of expansion modes > etc, but I'd like to know if there is a fundamental block to this kind of > approach, or indeed if there are better approaches to speeding up > convergence. > > Sincerely, > -- > > *Amitvikram Dutta* > > Graduate Research Assistant > > Fluid Mechanics Research Lab > > Multi-Physics Interaction Lab > > University of Waterloo > > > > 29 sty 2019 19:10 Amitvikram Dutta <amitvdutta23(a)gmail.com> napisał(a): > > Hi all, > > I'm studying 3D devlopement of jets and am using a 3D1D setup with Fourier > coefficients in the spanwise directions. Instead of starting a 3D1D case > from scratch (the mesh contains 32 million DOF in 3D) I was thinking of > trying out a few strategies in order to speed up convergence. > > I have tried out the steady-state module but it seems to take a rather > long time to converge as well. > > I was thinking therefore, whether it would be possible to start the case > in 2D, and once it reaches convergence, to switch over to a 3D 1D mode > using a 2D .chk file as a restart point. > > I have tried out a few cases with the procedure described above, but cases > always seem to blow up after restarting in the 3D 1D mode. I could explore > the parameter space by reducing the time-step or number of expansion modes > etc, but I'd like to know if there is a fundamental block to this kind of > approach, or indeed if there are better approaches to speeding up > convergence. > > Sincerely, > -- > > *Amitvikram Dutta* > > Graduate Research Assistant > > Fluid Mechanics Research Lab > > Multi-Physics Interaction Lab > > University of Waterloo > > > -- > > *Amitvikram Dutta* > > Graduate Research Assistant > > Fluid Mechanics Research Lab > > Multi-Physics Interaction Lab > > University of Waterloo > > > > _______________________________________________ > Nektar-users mailing listNektar-users@imperial.ac.ukhttps://mailman.ic.ac.uk/mailman/listinfo/nektar-users > > -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

1 0

Re: [Nektar-users] FW: Restarting a 3D1D case with a 2D converged case
by Amitvikram Dutta 29 Jan '19

29 Jan '19

Hi Stanislaw, How do you initialise 'w' in the 2D restart .chk file? Sincerely, On Tue, Jan 29, 2019 at 1:41 PM Amitvikram Dutta < amitvikram.dutta(a)uwaterloo.ca> wrote: > > ------------------------------ > *From:* nektar-users-bounces(a)imperial.ac.ukOn Behalf OfStanisław Gepner > *Sent:* January 29, 2019 1:40:52 PM (UTC-05:00) Eastern Time (US & Canada) > *To:* Amitvikram Dutta > *Cc:* nektar-users > *Subject:* Re: [Nektar-users] Restarting a 3D1D case with a 2D converged > case > > Hi, > > I do it all the time, so there should not be any fundamental problems with > using a 2d solution to start the homogeneous expansion case. > > Just make sure you initialize all variables, some with the chk file and > some manually. > > Pozdrawiam, > Stanisław Gepner > > 29 sty 2019 19:10 Amitvikram Dutta <amitvdutta23(a)gmail.com> napisał(a): > > Hi all, > > I'm studying 3D devlopement of jets and am using a 3D1D setup with Fourier > coefficients in the spanwise directions. Instead of starting a 3D1D case > from scratch (the mesh contains 32 million DOF in 3D) I was thinking of > trying out a few strategies in order to speed up convergence. > > I have tried out the steady-state module but it seems to take a rather > long time to converge as well. > > I was thinking therefore, whether it would be possible to start the case > in 2D, and once it reaches convergence, to switch over to a 3D 1D mode > using a 2D .chk file as a restart point. > > I have tried out a few cases with the procedure described above, but cases > always seem to blow up after restarting in the 3D 1D mode. I could explore > the parameter space by reducing the time-step or number of expansion modes > etc, but I'd like to know if there is a fundamental block to this kind of > approach, or indeed if there are better approaches to speeding up > convergence. > > Sincerely, > -- > > *Amitvikram Dutta* > > Graduate Research Assistant > > Fluid Mechanics Research Lab > > Multi-Physics Interaction Lab > > University of Waterloo > > > > 29 sty 2019 19:10 Amitvikram Dutta <amitvdutta23(a)gmail.com> napisał(a): > > Hi all, > > I'm studying 3D devlopement of jets and am using a 3D1D setup with Fourier > coefficients in the spanwise directions. Instead of starting a 3D1D case > from scratch (the mesh contains 32 million DOF in 3D) I was thinking of > trying out a few strategies in order to speed up convergence. > > I have tried out the steady-state module but it seems to take a rather > long time to converge as well. > > I was thinking therefore, whether it would be possible to start the case > in 2D, and once it reaches convergence, to switch over to a 3D 1D mode > using a 2D .chk file as a restart point. > > I have tried out a few cases with the procedure described above, but cases > always seem to blow up after restarting in the 3D 1D mode. I could explore > the parameter space by reducing the time-step or number of expansion modes > etc, but I'd like to know if there is a fundamental block to this kind of > approach, or indeed if there are better approaches to speeding up > convergence. > > Sincerely, > -- > > *Amitvikram Dutta* > > Graduate Research Assistant > > Fluid Mechanics Research Lab > > Multi-Physics Interaction Lab > > University of Waterloo > > > -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

2 2

Restarting a 3D1D case with a 2D converged case
by Amitvikram Dutta 29 Jan '19

29 Jan '19

Hi all, I'm studying 3D devlopement of jets and am using a 3D1D setup with Fourier coefficients in the spanwise directions. Instead of starting a 3D1D case from scratch (the mesh contains 32 million DOF in 3D) I was thinking of trying out a few strategies in order to speed up convergence. I have tried out the steady-state module but it seems to take a rather long time to converge as well. I was thinking therefore, whether it would be possible to start the case in 2D, and once it reaches convergence, to switch over to a 3D 1D mode using a 2D .chk file as a restart point. I have tried out a few cases with the procedure described above, but cases always seem to blow up after restarting in the 3D 1D mode. I could explore the parameter space by reducing the time-step or number of expansion modes etc, but I'd like to know if there is a fundamental block to this kind of approach, or indeed if there are better approaches to speeding up convergence. Sincerely, -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

3 2

AUSM3 Riemann solver
by Aidyn Aitzhan 24 Jan '19

24 Jan '19

Dear Nektar++ Developers, I was working on CompressibleFlowSolver and noticed, that AUSM3 Riemann solver behaves unstable attempting to solve subsonic flows. I was getting a NaN error every time I tried to use it at low Mach flows. Then I figured out that there is a bug in the code. As I understood AUSM3 is AUSM+up solver from paper by Meng-Sing Liou, "A sequel to AUSM, Part II: AUSM+-up for all speeds," *Journal of Computational Physics*, Vol. 214, No. 1, 2006, pp. 137-170. Comparing the code and section "3.3. Algorithm: AUSM+-up for all speeds" in the paper I made several corrections. // Parameters for specify the upwinding // Note: if fa = 1 then *AUSM3 = AUSM2* // AUSM3 = AUSM3 NekDouble Mco = 0.01; NekDouble Mtilde = 0.5 * (ML * ML + MR * MR); NekDouble Mo = *sqrt(std::min(1.0, std::max(Mtilde, Mco*Mco)));* //std::min(1.0, std::max(Mtilde, Mco*Mco)); NekDouble fa = Mo * (2.0 - Mo); NekDouble beta = 0.125; NekDouble alpha = *0.1875*(5.0*fa*fa - 4.0);* //0.1875; NekDouble sigma = 1.0; NekDouble Kp = 0.25; NekDouble Ku = 0.75; NekDouble rhoA = 0.5 * (rhoL + rhoR); NekDouble Mp = -(Kp / fa) * ((pR - pL) / (rhoA * cA * cA)) * std::max(1.0 - sigma * Mtilde, 0.0); NekDouble Mbar = M4Function(0, beta, ML) + M4Function(1, beta, MR) + Mp; NekDouble pu =* -2.0 * Ku * rhoA * cA * fa * (uR - uL) ** // -2.0 * Ku * rhoA * cA * cA * (MR - ML) * P5Function(0, alpha, ML) * P5Function(1, alpha, MR); An AUSM3Solver.cpp file is also attached. If you are agree with me please update the code in repository. Best regards, Aidyn

3 5

Error - interpolation of a field
by Albert Baars 23 Jan '19

23 Jan '19

Dear all, I tried to interpolate an existing field to a new grid using the command FieldConvert -m interpfield:fromxml=kkanal.xml:fromfld=kanal_97.chk kanal.xml start.fld and received an error message: *** Process received signal *** Segmentation fault (core dumped) Can anybody help? Thanks a lot in advance and kind regards, Albert Baars

3 4

Error was made when I run an example in 6.4.3 Advection dominated mass transport in a pipe,
by Dongmyung Suh 21 Jan '19

21 Jan '19

When I run an example in 6.4.3 Advection dominated mass transport in a pipe, I got the following error, which is *Signal: Segmentation fault (11).* How can I fix the problem? Please advise me to solve this problem. Best regards, Dongmyung Suh ---------------------------------------------------------------------------------------------------------------- T5500:~/Desktop/Nektar_exercise/AdvectionDiffusion$ ADRSolver AdvectionDiffusion.xml Warning: Level 0 assertion violation Using Default variable expansion definition for field: u [T5500:03146] *** Process received signal *** [T5500:03146] *Signal: Segmentation fault (11)* [T5500:03146] Signal code: Address not mapped (1) [T5500:03146] Failing at address: 0x8 [T5500:03146] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7fbe5b148f20] [T5500:03146] [ 1] /home/dongmyung/Software/nektar++-4.4.1/build/dist/lib64/nektar++-4.4.1/libSolverUtils.so.4.4.1(_ZN6Nektar11SolverUtils14UnsteadySystem17v_GenerateSummaryERSt6vectorISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_ESaISA_EE+0x28f)[0x7fbe5e33f9af] [T5500:03146] [ 2] /home/dongmyung/Software/nektar++-4.4.1/build/dist/lib64/nektar++-4.4.1/libSolverUtils.so.4.4.1(_ZN6Nektar11SolverUtils14DriverStandard9v_ExecuteERSo+0x4a4)[0x7fbe5e2e3b14] [T5500:03146] [ 3] ADRSolver(main+0x177)[0x55d5de973037] [T5500:03146] [ 4] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fbe5b12bb97] [T5500:03146] [ 5] ADRSolver(_start+0x2a)[0x55d5de98329a] [T5500:03146] *** End of error message *** Segmentation fault (core dumped)

1 0

How can I run ADRSolver to solve the first example?
by Dongmyung Suh 20 Jan '19

20 Jan '19

Dear Nektar community, I am a newbie in Nektar. I am very interested in Spectral Element method. I have installed Nektar in my Ubuntu computer and completed test with ctest. Now I tried to run the first example in 6.4.1 1D Advection equation in the manual. I went to the folder and run ADRSolver Advection1D.xml. But, I got the following error message; ADRSolver: command not found. Please let me know how to do run it. Is there any other environmental setting? Best regards, Donmyung Suh

2 1

Zero gradient boundary condition for compressible flow solver
by Arash Nouri 14 Jan '19

14 Jan '19

Hi all, Happy new year! I need a kind of zero gradient boundary condition (BC) for the compressible flow solver. As Neumann BC is not implemented for “LDGNS,” I tried using ExtrapOrder0 BC, but I got oscillations on this boundary. In my 2D simulation I have one Dirichlet and one ExtrapOrder0 BCs as the input and output of my domain and two Symmetry BCs on the top and bottom. The Mach number is very small (~0.001). Is this combination OK for the compressible flow solver? Do you suggest any other option instead of ExtrapOrder0 or Dirichlet BCs? Thanks in advance, Arash ----------------------------- Arash G. Nouri Research Scientist 1127 Benedum Hall Mechanical Engineering and Materials Science University of Pittsburgh E-mail: arash.nouri(a)pitt.edu

2 1

Helmholtz solver
by Aidyn Aitzhan 13 Jan '19

13 Jan '19

Dear All, I was working on Helmholtz equation solver and found, that DG projection produces errors on periodic boundaries (XML file attached). Check the following log: ======================================================================= EquationType: Helmholtz Session Name: Helmholtz2D Spatial Dim.: 2 Max SEM Exp. Order: 7 Expansion Dim.: 2 Advection Type: Projection Type: Continuous Galerkin Lambda: 0 Forcing func [0]: -(Lambda + 2*alpha*alpha)*sin(alpha*x)*sin(alpha*y) ======================================================================= Writing: "Helmholtz2D.fld" (0.0222731s, XML) ------------------------------------------- Total Computation Time = 4s ------------------------------------------- L 2 error (variable u) : 0.00017053 L inf error (variable u) : 2.93867e-05 ======================================================================= EquationType: Helmholtz Session Name: Helmholtz2D Spatial Dim.: 2 Max SEM Exp. Order: 7 Expansion Dim.: 2 Advection Type: Projection Type: Discontinuous Galerkin Lambda: 0 Forcing func [0]: -(Lambda + 2*alpha*alpha)*sin(alpha*x)*sin(alpha*y) ======================================================================= Writing: "Helmholtz2D.fld" (0.0316639s, XML) ------------------------------------------- Total Computation Time = 5s ------------------------------------------- L 2 error (variable u) : 3.94935 L inf error (variable u) : 1.00002 As we can see L2 and Linf of DG solution are too high. Plotting the results I figured out that the error is on the boundaries. I have got the same results for both nektar-master version and nektar-4.4.1. Am I doing something incorrect? One more short question, there is a factor "eFactorTau" in discontinuous Helmholtz solver, which is not present in continuous one. What is this factor responsible for? I cannot run the solver not specifying it, but I get the same results for factors[StdRegions::eFactorTau] = 1.0 and factors[StdRegions::eFactorTau] = 1000. Thank you very much and Happy New Year, Aidyn

2 1