mdot0 for periodic turbulent channel flow

[watchapon]

Hi

I am trying to run a periodic turbulent channel flow by turning on the body force calculation for periodic channel shown in eles.cpp. However, it seems to me that I have to provide the value for mdot0, which I don't know how to compute it. Could you please suggest me how can I compute mdot0, please?

By the way, I guess that 'area' is the cross-sectional area of my computational domain and 'vol' is the volume of my computational box. Are these correct?

Thank you very much in advance for you help.

Watchapon

[mlopez14]

This case comes from the 3rd International High Order Workshop . Here is the pdf related to this case. From what the document says, mdot0 is imposed, no need to calculate it. Yes, 'area' is the inflow area. 'vol' is not used in any calculations (I'm not sure why it is not commented out).

[watchapon]

Hi,

Thank you very much indeed for you answer.

I understand that mdot0 is imposed, but you have to know it value in advance in order to impose it. I guess that mdot0 is 'u_bulk' x 'area'. Is this right?

I would like to ask you how to estimate \Delta y+ for the first grid point for various order of polynomial, please. I ran the channel flow with \Delta y for the first grid about 0.011 and use \nu = 3.57e-4. This would correspond to Re_\tau about 180 and I would get \Delta y+ about 2.05 if the scheme is second order (p=1). How can I estimate the \Delta y+ for different order of polynomial?

Regarding the dt used, it seems to me that I have to specify very low dt in order to make the code stable. I ran the channel flow with p=3 and had to use dt = 1e-5. This is quite low compare to using a finite-difference or finite-volume code to run this case, in which dt can be up to about 1e-3 (corresponding to CFL about 1 for RK4). Is it normal for the DG-based scheme that its CFL limit is lower than FD/FV? How could I estimate CFL for HiFiLES for hexahedral grid?

If I change the number of element used (assuming using the same computational domain), is there any option in HiFiLES to interpolate the old restart file into the new mesh file? Can the code interpolate the data if I simply set the restart_flag to 1 to read the old restart file into the new mesh_file?

Best wishes,
Watchapon

[jrbull]

Watchapon,
Thank you for your questions. I have tried to answer them satisfactorily below.
Regards,
Jonathan
Postdoctoral Fellow
Department of Information Technology
Uppsala University

On 18 May 2016, at 07:50, watchapon <[email protected]mailto:[email protected]> wrote:

Hi,

Thank you very much indeed for you answer.

I understand that mdot0 is imposed, but you have to know it value in advance in order to impose it. I guess that mdot0 is 'u_bulk' x 'area'. Is this right?

Yes, mdot0 has to be known in advance and it is ubulk*area.

I would like to ask you how to estimate \Delta y+ for the first grid point for various order of polynomial, please. I ran the channel flow with \Delta y for the first grid about 0.011 and use \nu = 3.57e-4. This would correspond to Re_\tau about 180 and I would get \Delta y+ about 2.05 if the scheme is second order (p=1). How can I estimate the \Delta y+ for different order of polynomial?

For higher than p=1, use the estimate dy = dy_1/p where I have called Delta y+ dy_1 (for p=1) and dy (for p>1). Although the quadrature points are not uniformly distributed inside an element, it is a good enough approximation.

Regarding the dt used, it seems to me that I have to specify very low dt in order to make the code stable. I ran the channel flow with p=3 and had to use dt = 1e-5. This is quite low compare to using a finite-difference or finite-volume code to run this case, in which dt can be up to about 1e-3 (corresponding to CFL about 1 for RK4). Is it normal for the DG-based scheme that its CFL limit is lower than FD/FV? How could I estimate CFL for HiFiLES for hexahedral grid?

Yes, this is completely normal. Higher polynomial orders require very small timesteps. It is because the explicit time integration schemes we use (Euler or RK4) impose a timestep limit for stability that is generally smaller than that imposed by the CFL limit. The solution is to use implicit schemes, but this is a matter for ongoing research.
As far as I am aware there is no well-defined viscous CFL condition for these schemes, so timestep selection is currently by trial-and-error unfortunately.

If I change the number of element used (assuming using the same computational domain), is there any option in HiFiLES to interpolate the old restart file into the new mesh file? Can the code interpolate the data if I simply set the restart_flag to 1 to read the old restart file into the new mesh_file?

It cannot currently read in data on a different mesh. However, it would be fairly straightforward to write a script to do linear interpolation. Higher-order interpolation might be more tricky. If you have time, we would be very grateful if you could contribute an interpolator to the HiFiLES project.

Best wishes,
Watchapon

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/122#issuecomment-219931422