Skip to content

Conversation

@manosser
Copy link

Summary

Adds a new optional ABL input parameter:

ABL.inflow_scaling_factor = # default = 1.0

When reading boundary inflow files, the velocity components (u, v, w) are multiplied by this factor before being injected into the simulation (i.e., 1.1 = +10%, 0.9 = -10% velocity magnitude). All other fields remain unchanged. This enables simple scaling (or fine-tuning) of inflow velocity time-series without having to re-run a precursor, and is particularly useful for custom boundary files that are not generated from AMR-Wind. I have been using this feature here at the Technical University of Munich on our CPU based HPC system.

Pull request type

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

Checklist

The following is included:

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

This PR was tested by running:

  • the unit tests
    • on GPU
    • on CPU
  • the regression tests
    • on GPU
    • on CPU

Manual testing:
Compiled successfully on linux HPC system
Verified that the inflow_scaling_factor is correctly read from the input file
Confirmed that only the "velocity" field is scaled, and other fields remain unchanged (mass_inflow, pressure_outflow)
Confirmed default behavior (inflow_scaling_factor = 1.0) produces identical results to the baseline
Confirmed behavior when the parameter is missing (defaults to 1.0)
Confirmed that negative or zero values are reset to 1.0 safely

image image image

Additional background

This feature allows rapid testing of different inflow magnitudes without regenerating boundary files. It hopefully adds minimal overhead, and preserves all existing solver behavior when the parameter is not set or set to 1.0.
Scaling the inflow in this way likely interferes with other physics in the boundary layer, but for fine tuning, or minimal wind speed changes, it seems to work well. I have only been able to test this on our CPU based system (LRZ supermuc) with OpenMP.
Open for any and all feedback, and please let me know if there is a better way to achieve this function.
Thanks :)

@hgopalan
Copy link
Contributor

Thank you for adding and testing the capability. @mchurchf Any suggestions for making this more general?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants