Terrain-Aware Immersed Forcing Method

[hgopalan]

Summary

This draft PR introduces an immersed forcing method for representing terrain within AMR-Wind. The terrain is generated outside amr-wind and this method does not rely on the existing immersed boundary method. The terrain runs are performed in steps:

1. Run precursor
2. Generate the terrain using the included utility from the mmctools project and SRTM data
3. Generate roughness using NLCD database (under development and not fully integrated)
4. Run the terrain simulation with the terrain-related forcing terms included in the amp-wind input file and a terrain file created using the utilities.

The method can also be used to run cases without terrain such as an array of bluff bodies. The user has to create a XYZ file with the relevant information to do perform these simulations. The user can also use the stl2XYZ.py in tools/terrain folder to convert a STL file to XYZ file for AMR-Wind. It is recommended to have a smooth boundary near the inflow and outflow to reduce the number of iterations of the nodal and Mac projections.

The terrain modules have been designed to run with the Kosovic turbulence model. To use other turbulence models, the terrainBlanking information should be used to set the turbulent viscosity to zero in the solid region. It is also possible to specify a roughness file to include non-uniform roughness in the simulations.

The method is first-order accurate.

Reference Paper: https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2020MS002141 Implemented Code: FastEddy for urban microclimate without log-law. handling

Not included in the current PR:

1. Support for stratification with terrain
2. RANS model support for terrain
3. General turbulence model support (works only with the Kosovic model in non-hybrid mode).

Pull request type

PR is almost ready to be reviewed.

Please check the type of change introduced:

• [ ] Bugfix
• [x] Feature
• [ ] Code style update (formatting, renaming)
• [x] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] Documentation content changes
• [ ] Other (please describe):

Checklist

The following is included:

• [x] new unit-test(s)
• [x] new regression test(s)
• [ ] documentation for new capability

This PR was tested by running:

• the unit tests
  • [ ] on GPU
  • [x] on CPU (Kestrel and MacOS)
• the regression tests
  • [ ] on GPU
  • [x] on CPU (Kestrel and MacOS)

[hgopalan]

This PR adds the complex terrain capability within AMR-Wind. I will create a separate PR with additional documentations and multiple terrain examples and on using the python tools to setup the cases.

[hgopalan]

Have addressed the comments

[marchdf]

There's a stray update to the amrex submods that shouldn't be there. Can you remove that?

[michaelasprague]

@hgopalan Great to see the PR and all of the progress. I have several suggestions that should be considered before this is merged.

• Please provide more details in the description about the underlying formulation. If this is based on published work, please provide reference(s) so we can better understand the implementation. Based on the formulation/implementation is the method expected to be first or second order accurate in space and time?
• I see statement that the method is first-order accurate, and that is verified with your Poiseuille verification study. Can you explain why the method is only first-order accurate? First-order could be fine, but it would be good to document why. It would be nice to have more details about the Poiseuille verification study, too.
• Should the time-accuracy of the method be verified?
• Can you add the results from the ABL comparison study for flat terrain which uses the wall-forcing approach approximate the MO boundary condition? That seems key to demonstrating the capability.
• Can you confirm that this PR runs on GPUs?

Thanks, and I know the team is excited to get this merged.

[hgopalan]

@hgopalan Great to see the PR and all of the progress. I have several suggestions that should be considered before this is merged.

• Please provide more details in the description about the underlying formulation. If this is based on published work, please provide reference(s) so we can better understand the implementation. Based on the formulation/implementation is the method expected to be first or second order accurate in space and time?

Included the reference in the main text. They did not test for order of accuracy in space and time in any of the reference papers.

• I see statement that the method is first-order accurate, and that is verified with your Poiseuille verification study. Can you explain why the method is only first-order accurate? First-order could be fine, but it would be good to document why. It would be nice to have more details about the Poiseuille verification study, too.

I am not sure from the top of my mind why the accuracy drops to first-order. We will need to look at the forcing terms and see what may be causing it. The test case is one of the test files which comes with AMR-Wind and I tweaked it for Immersed Boundary.

• Should the time-accuracy of the method be verified?

I do not think it will be necessary.

• Can you add the results from the ABL comparison study for flat terrain which uses the wall-forcing approach approximate the MO boundary condition? That seems key to demonstrating the capability.

I am thinking of how to best do it while focusing only on the IBM and wall-model.

• Can you confirm that this PR runs on GPUs?

We are already running cases for Total with WFIP2 terrain on GPUs in Kestrel.

Thanks, and I know the team is excited to get this merged.

[hgopalan]

Need to perform one more test for turbulence + wall function and compare IB/no-IB methods. @rthedin has tested the output data with FAST.Farm and Misha has tested the data with FLORIS and one-way coupling works for both the cases.

[MaxPal]

I don't see any parameters in input file showing immersed boundary method is used. If I understand well, this is the implicit presence of file with a fixed name terrain.amrwind that activate the method. Is it the normal way to do it in AMR-Wind ?

[hgopalan]

I don't see any parameters in input file showing immersed boundary method is used. If I understand well, this is the implicit presence of file with a fixed name terrain.amrwind that activate the method. Is it the normal way to do it in AMR-Wind ?

Hi Maxime,

The terrain is setup in three steps.

1. In incflo.physics we add the text TerrainDrag
2. In ICNS.source_terms we add the text DragForcing
3. In Temperature.source_terms. we add the text DragTempForcing

Step 1 is called when the solver starts. It reads the terrain.amrwind file and setups up the terrain_blank, terrain_drag, terrain_height and terrainz0 variables.

terrain_blank is used to enforce the zero velocity within the terrain and the fixed temperature. terrain_drag enforces the MOST boundary condition at the first cell above the terrain. terrain_blank is also used to force the turbulent viscosity and diffusivity to zero within the terrain (currently only using Kosovic LES model).

For RANS modeling, the turbulent kinetic energy is enforced also enforced based on the terrain_drag variable.

A typical terrain setup is available here: https://github.com/hgopalan/amr-wind/blob/hgopalan-terrain/test/test_files/nrel_terrain/nrel_terrain.inp

[marchdf]

@hgopalan do you have an update on this? How close are you to feeling like this should be reviewed/tested/merged?

[hgopalan]

@hgopalan do you have an update on this? How close are you to feeling like this should be reviewed/tested/merged?

We still have one more test to be done with the Ekman Spiral case. Once it is done, the PR should be ready to be reviewed, tested and merged.

[marchdf]

Can you update the branch please? Looks like there are conflicts.