flexibility in box-size in NaluwindUtils

[tchatte3]

Hi Nalu-wind team,

I am writing to request for a feature request in NaluWindUtils, related to nestedrefinement.cpp. When we do multilayer refinements around the turbine the list of one layer of refinement looks like this.

[X1,X2,YY,ZZ]

X1 is the normalized distance upstream of the turbine, X2 is the normalized distance downstream of the turbine for the streamwise box size. The lateral extent of the box is y_hub - YYD to y_hub + YYD, and the vertical extent of the box is z_hub -ZZD, z_hub + ZZD.

While this is a workable solution, I am requesting more flexibility in the vertical direction, e.g., a list as follows

[X1, X2, YY, ZZ1, ZZ2]

The reason this will be extremely beneficial, is because in this way we can control the ground to remain unrefined. As an example,

in the existing feature, if we want the box to be 3D above the hub-height, then the lower corner of the box is at z = z_h - 3D, if z_h < 3D (which usually it is), the entire ground gets refined. This can be detrimental if we already have background mesh that is refined near the ground. So, I think this feature is enhanced to incorporate

[X1,X2,YY,ZZ1,ZZ2]

Then we can have something like this: ZZ1 = 0.5D, ZZ2 = 3D, so the vertical extent of the box is now z_h - 0.5D to z_h + 3D. This is similar to what is being done for the x-direction.

Best Regards,

[sayerhs]

@tchatte3 As a workaround you can currently achieve what you want by changing _turbineheights to be 0.5 * (ZZ1 + ZZ2) where zz1 and zz2 are the end points of the desired bounding box with z=0 (terrain) as reference height. Note that this still won't work for complex terrain.

Also, in future, can you please file wind-utils issues on that Github repo? It will make it easier to track and close issues as code is committed.

[tchatte3]

@sayerhs Thanks, I will shift to wind-utils issue on that GitHub repo. What you suggest makes sense. We have done something similar, but that imposes a limitation in the vertical extent of the box size or a limitation on the turbine hub-height we want to impose on the domain. This particularly becomes critical if we are already defining our domain size in km, and want a specific turbine of hub-height = 80 metres for test-simulation. We can have ZZ1 + ZZ2 = 2.0 X 80/D, and ensure that 2.0X 80/D = 160.0/D > ZZ2, or else ZZ1 will become negative.

This problem becomes more flairing if we have multiple turbines of different turbine heights ( list in the local refinement section) and if we want to use nestedrefinement for that matter.

[tchatte3]

Thanks, @sayerhs, We have been using what you suggested, and it is indeed very helpful if we are using a single layer of refinement. For multiple layers of refinement, this artificial hub-height needs to change depending on what the box size is, so at the moment we are using a wrapper to generate multiple refinement layers as separate .yaml files.