Add time-vary & spatially varying body force for MMC simulations

[lawrenceccheung]

Is this feature request related to a problem? Please describe.

For MMC coupled wind farm simulations, we need to add a body force which varies in both z and in time. The body forces are derived from the ABLMesoscaleForcing and are horizontally homogeneous. This feature was alluded to in #1022 and #1025, and would generalize the capabilities currently available.

Describe the preferred solution

One possibility is to have the body forces be read from the abl stats netcdf file directly, which would avoid any reformatting of data (the abl stats file contains abl_meso_forcing_mom_x and abl_meso_forcing_mom_y which is what we want).

The same body forcing term would be necessary for the temperature equation here: https://github.com/Exawind/amr-wind/blob/main/amr-wind/equation_systems/temperature/source_terms/BodyForce.cpp.

Additional context

This capability is/will be necessary for FLOWMAS, AWAKEN, and other such projects.

[github-actions]

This issue is stale because it has been open 30 days with no activity.

[ewquon]

Hi all, is anyone actively looking to implement this? Didn't realize this capability wasn't in the code yet. I also need to be able to apply momentum/temperature source terms that are time and height varying. Thanks

[marchdf]

I don't know that anyone is actively implementing this feature. Do you want to take a stab? Happy to discuss but I think you implemented the first part of this so you probably know more than I do ;)

[moprak-nrel]

I'm curious if the stuff in ABLMesoForcingMom can be used for this? It seems to have the forcing as a function of both z and t.

I don't have the context for this code path, but it seems to be adding a body force term based on the velocity plane averages and the mesoscale inputs from a netcdf file in this function:

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

Line 148 in 084db33

void ABLMesoForcingMom::mean_velocity_heights(

[ewquon]

@moprak-nrel that's the code I introduced for MMC applications with profile assimilation. That could certainly be a way to do this but I was wondering if there was a more streamlined approach already in place.

[udhaya-chandiran]

I am participating in the AWAKEN benchmark simulation campaign. AMR-Wind would best suit my needs if I can prescribe inflow velocity and surface temperature as a time series. I would like to know if there is a timeline for adding this feature.

[moprak-nrel]

@udhaya-chandiran The feature you're asking for is different from the MMC discussion here. Could you post this as a separate issue?

[ewquon]

@moprak-nrel come to think of it, I think the "tendency" or "budget components" forcing provided by ABLMesoForcing could work, I just have to do some intermediate processing and test it.

@udhaya-chandiran, I am planning to work on adding the capability to input a surface temperature time series — feel free to tag me in the separate issue.

[lawrenceccheung]

Also tagging @hgopalan, we had a discussion about the time varying surface temperature BC, could require some coordination.

[hgopalan]

I have an initial tree for spatial-temporal varying surface temperature: https://github.com/hgopalan/amr-wind/tree/MultiRough. I am not sure how soon you need the capability for the Awaken simulations. It will take me sometime before I can create a PR.

[moprak-nrel]

From my understanding, there are several pieces here:

1. @ewquon is looking into testing the tendency forcing in the ABLMesoForcingMom implementation to see if it is general enough for a time varying body force term in the ICNS system. This looks to have a body force term as a function of (z,t) and surface temperature flux as a function of t but constant in the boundary plane.
2. Separately, @hgopalan is looking into adding space-time varying surface temperatures
3. @udhaya-chandiran is asking about inflow BCs, and space-time varying surface temperature from 2. My understanding is that the inflow BCs from a precusor simulation have been around for a while now, but it is unclear if that's what is needed here.

For ease of discussion, I suggest we create separate issues for each of these.