Clarification on Turbinflow

[RSuryaNarayan]

Hello,

I want to understand what is the final expression for the total velocity imposed in the BC when a turbfile is used. The following inputs seem to be required when turbinflow is used anywhere:

turbinflow.lowX.turb_scale_loc = 633.151
turbinflow.lowX.turb_scale_vel = 0.5
turbinflow.lowX.turb_center    = 0.005 0.005
turbinflow.lowX.turb_conv_vel  = 5.
turbinflow.lowX.turb_nplane    = 32

After going through the gen_hit_ic.py script, I see that the fluctuations (call them u') are generated such that (u')_rms=1.0. So now does using the turbfile for the inputs impose a total velocity of u_mean + turb_conv_vel * u' * turb_scale_vel? (u_mean here is my mean flow)

[marchdf]

Ah there is confusion and it's because we do not have this turbinflow capability documented. I apologies for that. gen_hit_ic.py script is for something completely unrelated to the turbinflow stuff. So I would completely ignore that script. You can see how the fluctuations are used here: https://github.com/AMReX-Combustion/PeleC/blob/development/Exec/Production/ChallengeProblem/prob.H#L253 if that helps any.

[RSuryaNarayan]

Hey @marchdf thanks for the reply. I do understand gen_hit_ic.py does something different. However since turbfiles are generated from dat files that the script (gen_hit_ic.py ) generates, I used that to figure stuff out. I tried fiddling around with the case and I guess finally what is imposed is just turb_conv_vel + u' * turb_scale_vel as I don't see velocities "doubling" when I use turb_scale_vel=1 (i.e. if I use 100% intensity without scaling velocities the fluctuation velocities are the same order as that of the mean flow effectively adding it twice)

[drummerdoc]

turb_conv_vel is the "rate" at which the turbulence file is moved through. That is, the z location of the plane that the velocities are interpolated to is turb_conv_vel * time. The mean inlet flow is taken from the user BCs.

[drummerdoc]

Sorta, but I'm a little worried about details here. A turbulence file has 3 spatial dimensions, 2 of which correspond to the plane that is the inlet where the fluctuations will be applied. The third dimension, typically "z" in the turbulence file is mapped to the coordinate normal to the Pele boundary you're working with. Think of it as shoving a block of turbulent literally into the domain over time. The time value gets mapped to the z plane location in this BC-normal direction into the turbulence block using the turb_conv_vel value. If you set that to zero, it will only take value from the first plane of the file, and will be constant over all time... probably not the fluctuations you want to push in.

The reason this is a separate knob though is a bit subtle. Say that you want to push in a swirling turbulent flow and you have a profile that represents the mean swirl velocities in all three directions. At any given point on the inflow plane, which velocity do we use to map to z in the turbulence file, and is it the same over the plane? If it's varying over the plane, the infrastructure we have provided won't work....it interpolates a plane of data at a time to shove in. You can see then that no matter what you do, it's a bit weird, in terms of how the fluctuations get stretched in this case, but the best we could do is supply this conv_vel knob as one more control to play with.

The alternative, by the way, is to use that code in "the other mode" where the entire velocity profile (rather than fluctuations off the mean) is precomputed and stored in planes over time. In that case, you'd use the interpolated values directly - however, in that case, z=t, there no assumed periodicity in the fluctuations file, and you need to be sure that you have enough "z" to cover all "t" that will be needed over the simulation. That's complicated in a different way, but I can help with that as well if that's what you want to do.

I hope this isn't too much detail, but rather that you understand what this capability actually does now and have a sense for how to diagnose and believe what you trying to do with it.

[RSuryaNarayan]

@drummerdoc I see the issue you mention. Swirling flow would definitely make things complicated.
However, here, I am just dealing with a simple turbulent flow through a pipe (where we assume the inlet flow has already transitioned to a turbulent one). Consequently, what I want to really do is something like the following:

i.e. some temporally varying turbulent inlet (it is fine if it is just homogeneous and isotropic like what HIT gives).

Indeed with turb_conv_vel=0 there wouldn't be any temporal variation in the inlet turbulence so I did throw in some dummy velocity there to make sure the code traverses through the HIT cube that I used to generate the TurbFile. Statistically, I guess HIT would remain invariant at any plane so I think it should work out just fine.

One concern that I do have is the fact that slicing across a 3D HIT file wouldn't make the velocity field on the plane divergence free.

Your second part now about having "enough z" concerns me a little now. The turb file generated from the default gen_hit_ic.py script uses a 2pi^3 domain. Assuming I run out of "z" would the code (as it stands now) automatically impose periodicity and ensure some random fluctuations do get added?

[drummerdoc]

Yes, the default mode for the turbulence file interpolator is to "wrap-around" the time (or z) coordinate.

[drummerdoc]

Under the covers, the interpolator works in two modes. The default assumes that the planes are uniformly spaced and that the z coordinate is computed from time as time * turb_conv_vel (ignoring the scaling to deal with cgs/mks stuff). That version actually mods time with the interval to move at turb_conv_vel through the turb file (ie, wraps periodically), so one file would be good for all time.

Alternatively, there can be a specific time associated with each data plane. In that case, there is an extra vector of reals read in when initializing the turbulence that corresponds to these time values (one per plane). the interpolator then does the parabolic interpolation with the data that is uniform in the plane parallel to the BC, but non-uniformly spaced in the direction normal to the BC. This file can be create by slicing data from some other code's run and writing the time value of each slice. But then you need to run that "precursor" calc to generate that data in way that makes sure that the time value used to evaluate the LMeX boundary condition lays within the interval covered by the set of planes concatenated into that turbulence file.

Finally, in that latter mode, all that is really required is that the current run have access to time planes bounding the sim time currently being evaluated. If you were simultaneously running the precursor calc, you could occasionally build up a new turbulence data file to use with the LMeX run and slide that file into place between queue submissions, for example. That does complicate the job of babysitting the LMeX run though.

[RSuryaNarayan]

I think the first one just does my job for now! Thanks once again!