Meso-Micro Coupling with no precursor for Terrain #1426

hgopalan · 2024-12-27T16:25:56Z

The current workflow in AMR - Wind requires a precursor simulation to generate boundary plane for running complex terrain simulations. However, this is not a requirement. This PR proposes an alternative path for running simulations over complex terrain.

Based on met-mast measurement, a 1-D vertical wind profile is created along with the required geostrophic wind.
The simulation is initialized with the 1-D profile.
All the horizontal boundary conditions are replaced with pressure-outflow boundary condition with a sponge layer, forcing the 1-D profile.
A forcing zone is added on the upper portion of the domain to drive the wind speed and temperature to be consistent with the 1-D vertical profile.

Future Work:

Adding the nudging terms within domain for met-mast or Lidar data
Replacing pressure-outflow with WRF-mesoscale boundary plane data and removing the flat terrain restrictions at the boundary.

Please check the type of change introduced:

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

SunZia Wind Farm LES - 150 kms

Flatirons - RANS - 150 kms

lawrenceccheung · 2024-12-27T18:15:16Z

Hi @hgopalan,

Thanks for documenting the process. One question I have about the MMC coupling with terrain is how we account for the fact that the turbulence will take time to spin-up, and how a time-varying MMC profile can be accounted for. One way to handle it is to include a large, flat inflow region where the turbulence can develop. Depending on the ABL stability state, it might require a shorter/longer region for the turbulence profile to adjust.

Once the 1D MMC profile is time-varying, though, that introduces a time delay between when the velocity/temperature changes and when that turbulence enters the domain. @mchurchf and @ewquon might have some ideas on what to do too.

Lawrence

hgopalan · 2024-12-27T18:27:26Z

Hi @hgopalan,

Thanks for documenting the process. One question I have about the MMC coupling with terrain is how we account for the fact that the turbulence will take time to spin-up, and how a time-varying MMC profile can be accounted for. One way to handle it is to include a large, flat inflow region where the turbulence can develop. Depending on the ABL stability state, it might require a shorter/longer region for the turbulence profile to adjust.

Once the 1D MMC profile is time-varying, though, that introduces a time delay between when the velocity/temperature changes and when that turbulence enters the domain. @mchurchf and @ewquon might have some ideas on what to do too.

Lawrence

The purpose of this workflow is mainly related to providing a simple method for AEP calculation for the RANS model similar to the method used in commercial RANS tools. The usability of the method and adoption for LES needs some investigation. If a terrain is complex, it does not need a lot of time to spin-up as the heterogeneity generate the flow structures. The terrain is smoothed in the horizontal boundaries and when they encounter a change in elevation it generated the structures for the cases I tested with mountains.

There is no restriction on specifying a time-varying 1-D profile. We just need to move the profile reader to be time-dependent. Will require some code changes but is doable.

There is some difference with the method proposed here. Our aim is to match the met-mast data while providing a reasonable boundary condition which will not cause divergence of the pressure poisson solver. We are not worried about flow spin-up and other issues and expect that the presence of complex terrain will generate the structure.

We may have to tweak the workflow in future if there are discrepancies with measured data. However, this method should be acceptable for RANS.

ewquon · 2025-01-07T17:06:29Z

Hi @hgopalan,

Thanks for documenting the process. One question I have about the MMC coupling with terrain is how we account for the fact that the turbulence will take time to spin-up, and how a time-varying MMC profile can be accounted for. One way to handle it is to include a large, flat inflow region where the turbulence can develop. Depending on the ABL stability state, it might require a shorter/longer region for the turbulence profile to adjust.

Once the 1D MMC profile is time-varying, though, that introduces a time delay between when the velocity/temperature changes and when that turbulence enters the domain. @mchurchf and @ewquon might have some ideas on what to do too.

Lawrence

What we could do for terrain is instead of a planar average, use a temporal average at a specified location (e.g., at the met mast). There is a question of whether you make the forcing constant with altitude or constant with height AGL; you can also blend from the latter to the former. Definitely should be explored further.

hgopalan · 2025-01-15T17:12:24Z

LES structures are not generated when the terrain is smooth. Added thermal perturbations to generate the flow structures. Sample result are shown for a flat surface without precursor and LES (dx=dy=60m). The fringe zone is able to absorb the outgoing waves. This is still preliminary and need further analysis on the strength of the structure on numerical stability for complex terrains.

Horizontal Plane

Vertical Plane

hgopalan · 2025-01-23T15:39:33Z

Added regression tests with and without perturbation forcing

marchdf

Thanks for adding this in! I made a first pass. LMK when I can do a second one.

test/test_files/noprecursor_les_pert/terrain.amrwind.new

test/test_files/noprecursor_les_pert/rans_1d.info

docs/sphinx/walkthrough/noprecursorrans.rst

docs/sphinx/user/inputs_Temperature_Sources.rst

marchdf · 2025-01-24T16:59:39Z

docs/sphinx/user/inputs_Temperature_Sources.rst

+temperature field to generate flow structures for LES when the inflow data is coarse or uniform flow condition. Not 
+recommended for use with RANS models. 
+
+.. input_param:: PertForcing.xstart


To match other input file styles for specifying boxes, can we switch all these to

PerturbationForcing.start = x0 y0 z0 PerturbationForcing.end = x1 y1 z1

then parse these into a real box and we can use a .contain method on them. This will remove a lot of lines of code.

marchdf · 2025-01-24T17:01:41Z

docs/sphinx/user/features.rst

@@ -116,6 +116,8 @@ Flow physics

   * Arbitrarily spatially and time varying boundary conditions using Python tools [:ref:`inp <inputs_native_boundary_plane>`]

+   * Sponge layer driven ABL simulations 


I am a bit confused. Why is this in the boundary condition section? This feels like just another element in the bullet * Atmospheric boundary layer (ABL):

This is a different way of specifying the boundary conditions through a fringe or sponge layer to force the simulations.

amr-wind/equation_systems/temperature/source_terms/TemperatureFreeAtmosphereForcing.H

amr-wind/equation_systems/temperature/source_terms/PertForcing.H

marchdf · 2025-01-28T18:41:50Z

amr-wind/equation_systems/icns/source_terms/VelocityFreeAtmosphereForcing.H

+private:
+    const SimTime& m_time;
+    const amrex::AmrCore& m_mesh;
+    std::string m_1d_rans;


rename: m_1d_rans_filename or something like that.

marchdf · 2025-01-28T18:45:26Z

amr-wind/equation_systems/icns/source_terms/VelocityFreeAtmosphereForcing.cpp

+    const auto* v_values_d = m_v_values_d.data();
+    const auto* w_values_d = m_w_values_d.data();
+    const bool has_terrain = this->m_sim.repo().field_exists("terrain_height");
+    if (has_terrain) {


let's consolidate these 2 branches since they look so similar. I think the only difference is the calculation of z? I would move the if has_terrain into the parallel for. It's not ideal but I would rather than then the code duplication.

Or do it like you do below with the perturbation forcing

marchdf · 2025-01-28T18:46:59Z

amr-wind/equation_systems/temperature/source_terms/PerturbationForcing.cpp

+                    prob_lo[2] + (k + 0.5) * dx[2] - height_arr_cell,
+                    0.5 * dx[2]);
+                const amrex::RealVect point{x, y, z};
+                if (pert_box.contains(point)) {


nicely done

marchdf · 2025-01-28T18:48:33Z

amr-wind/equation_systems/temperature/source_terms/TemperatureFreeAtmosphereForcing.cpp

+        auto* const m_terrain_height =
+            &this->m_sim.repo().get_field("terrain_height");
+        const auto& terrain_height = (*m_terrain_height)(lev).const_array(mfi);
+        amrex::ParallelFor(


this also looks like the one on L144. Think you can consolidate that?

marchdf · 2025-01-28T18:50:31Z

Good work, just had some thoughts for avoiding some duplicate code. I am running the tests on GPU now.

moprak-nrel

Good work! Have a few quick questions on the actual model.

amr-wind/equation_systems/icns/source_terms/VelocityFreeAtmosphereForcing.H

amr-wind/equation_systems/temperature/source_terms/TemperatureFreeAtmosphereForcing.H

moprak-nrel · 2025-01-29T17:59:28Z

amr-wind/equation_systems/tke/source_terms/KransAxell.cpp

            const amrex::Real m = std::sqrt(ux * ux + uy * uy);
-            const amrex::Real ustar = m * kappa / std::log(z / z0);
+            const amrex::Real ustar = m * kappa / std::log(3 * z / z0);


Is the 3 a model specific coefficient? Looks different from the standard ustar calculation.

Because we use the forcing term to set the boundary condition, cannot use the value of the cell in which the forcing term is set and we use something above it.

moprak-nrel · 2025-01-29T18:23:31Z

amr-wind/equation_systems/tke/source_terms/KransAxell.cpp

        const amrex::Real sponge_forcing =
-            zi * zi * (tke_arr(i, j, k) - ref_tke);
+            1.0 / dt * (tke_arr(i, j, k) - ref_tke);


Is the 1/dt fixing a previous bug? The dimensions of the sponge_forcing array should now be different right?

Changing to 1/dt helped in speeding the convergence and reducing oscillation in the free atmosphere

Does the dimensional change not matter? It changed from [No-units] * tke to [1/T] * tke? or is the 1 some type of dimensional constant?

The original zi also had a model constant which basically returns 1/s. It was never explicitly mentioned.

moprak-nrel · 2025-01-29T22:54:19Z

amr-wind/equation_systems/tke/source_terms/KransAxell.H

+    amrex::Real m_sponge_distance_east{1000};
+    amrex::Real m_sponge_distance_south{-1000};
+    amrex::Real m_sponge_distance_north{1000};
+    int m_sponge_west{0};


Are these always just 0/1? Should they be bools?

I kept them as ints for future modifications when the different boundaries can have other non-zero positive values when we use different driving winds

moprak-nrel · 2025-01-29T22:55:01Z

amr-wind/equation_systems/tke/source_terms/KransAxell.cpp

+            const amrex::Real start_west = problo[0] - m_sponge_distance_west;
+            const amrex::Real start_north = probhi[1] - m_sponge_distance_north;
+            const amrex::Real start_south = problo[1] - m_sponge_distance_south;
+            const int sponge_east = m_sponge_east;


Same question as before, are the ints or bools?

Same as above. Currently it is 1/0 but there will be future changes when they can be positive integers

one last question: would that int work with

amrex::Real xi_start = (start_west - x) / (start_west - problo[0]); xi_start = sponge_west * std::max(xi_start, 0.0); xstart_damping = sponge_west * sponge_strength * xi_start * xi_start;

That int seems to be multiplied as a cubed power in the damping calculation

Adding mesoscale-zone for no BC cases

9ea5486

hgopalan added the enhancement New feature or request label Dec 27, 2024

hgopalan added 2 commits December 27, 2024 10:54

Lint

18c27ff

Clang

cb19c7c

hgopalan added 8 commits December 30, 2024 10:03

Bug fixes

e798264

change tke profile meso-coupling

21a8844

Clang

ab81be8

Merge branch 'Exawind:main' into mesoscale_zone

ebb7929

Better confergence

c27d474

Merge branch 'Exawind:main' into mesoscale_zone

241d0e7

Merge branch 'Exawind:main' into mesoscale_zone

e818520

Merge branch 'Exawind:main' into mesoscale_zone

256326b

hgopalan requested review from mchurchf and marchdf January 7, 2025 02:21

hgopalan marked this pull request as ready for review January 7, 2025 02:22

hgopalan mentioned this pull request Jan 14, 2025

Read profile from file for RANS #1300

Closed

hgopalan added 3 commits January 15, 2025 09:55

Merge branch 'Exawind:main' into mesoscale_zone

6965fb0

Add perturbation

1aca8fd

Merge branch 'Exawind:main' into mesoscale_zone

1f7a910

hgopalan added 7 commits January 16, 2025 10:48

Rearrange

04cfe15

Merge branch 'main' into mesoscale_zone

090e885

Compatible

40971f3

Code rearrange

9f219da

Merge branch 'Exawind:main' into mesoscale_zone

4a92950

Changes after discussion with Marc

6657d7f

Merge branch 'Exawind:main' into mesoscale_zone

f95da9d

hgopalan added 2 commits January 23, 2025 08:37

Added Reg Test

cbf287d

Merge branch 'Exawind:main' into mesoscale_zone

e909c12

hgopalan added 6 commits January 23, 2025 08:46

tighten tolerance

e25c628

Adding base documentation

db48783

Update inputs_ABL.rst

523dba3

More doc

bbc7eb2

Walk through

785b1cc

s removed

419e99b

marchdf requested a review from moprak-nrel January 24, 2025 16:50

marchdf reviewed Jan 24, 2025

View reviewed changes

hgopalan added 2 commits January 24, 2025 11:23

Merge branch 'Exawind:main' into mesoscale_zone

27dc568

Changes

876ecef

hgopalan requested a review from marchdf January 24, 2025 19:01

marchdf requested changes Jan 28, 2025

View reviewed changes

hgopalan and others added 5 commits January 28, 2025 13:33

Consistency

d3b8c09

Merge branch 'Exawind:main' into mesoscale_zone

6260003

Clean

9d30920

Merge branch 'Exawind:main' into mesoscale_zone

6e4d0a9

Merge branch 'main' into mesoscale_zone

2841eb4

moprak-nrel reviewed Jan 29, 2025

View reviewed changes

moprak-nrel and others added 2 commits January 29, 2025 13:14

Merge branch 'main' into mesoscale_zone

4818929

Merge branch 'main' into mesoscale_zone

6f41039

moprak-nrel reviewed Jan 30, 2025

View reviewed changes

marchdf approved these changes Jan 30, 2025

View reviewed changes

Merge branch 'main' into mesoscale_zone

d3074f0

moprak-nrel approved these changes Jan 30, 2025

View reviewed changes

moprak-nrel enabled auto-merge (squash) January 30, 2025 20:09

moprak-nrel merged commit 82f64d2 into Exawind:main Jan 30, 2025
15 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Meso-Micro Coupling with no precursor for Terrain #1426

Meso-Micro Coupling with no precursor for Terrain #1426

hgopalan commented Dec 27, 2024 •

edited

Loading

lawrenceccheung commented Dec 27, 2024

hgopalan commented Dec 27, 2024 •

edited

Loading

ewquon commented Jan 7, 2025 •

edited

Loading

hgopalan commented Jan 15, 2025 •

edited

Loading

hgopalan commented Jan 23, 2025

marchdf left a comment

marchdf Jan 24, 2025

marchdf Jan 24, 2025

hgopalan Jan 24, 2025

marchdf Jan 28, 2025

marchdf Jan 28, 2025

marchdf Jan 28, 2025

marchdf Jan 28, 2025

marchdf Jan 28, 2025

marchdf commented Jan 28, 2025

moprak-nrel left a comment

moprak-nrel Jan 29, 2025

hgopalan Jan 29, 2025

moprak-nrel Jan 29, 2025

hgopalan Jan 29, 2025

moprak-nrel Jan 29, 2025

hgopalan Jan 29, 2025

moprak-nrel Jan 29, 2025

hgopalan Jan 30, 2025

moprak-nrel Jan 29, 2025

hgopalan Jan 30, 2025

moprak-nrel Jan 30, 2025

		@@ -116,6 +116,8 @@ Flow physics

		* Arbitrarily spatially and time varying boundary conditions using Python tools [:ref:`inp <inputs_native_boundary_plane>`]

		* Sponge layer driven ABL simulations

Meso-Micro Coupling with no precursor for Terrain #1426

Meso-Micro Coupling with no precursor for Terrain #1426

Conversation

hgopalan commented Dec 27, 2024 • edited Loading

lawrenceccheung commented Dec 27, 2024

hgopalan commented Dec 27, 2024 • edited Loading

ewquon commented Jan 7, 2025 • edited Loading

hgopalan commented Jan 15, 2025 • edited Loading

hgopalan commented Jan 23, 2025

marchdf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marchdf commented Jan 28, 2025

moprak-nrel left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hgopalan commented Dec 27, 2024 •

edited

Loading

hgopalan commented Dec 27, 2024 •

edited

Loading

ewquon commented Jan 7, 2025 •

edited

Loading

hgopalan commented Jan 15, 2025 •

edited

Loading