Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

connected_regions_allowed #277

Closed
uganzedo1974 opened this issue Nov 26, 2024 · 4 comments
Closed

connected_regions_allowed #277

uganzedo1974 opened this issue Nov 26, 2024 · 4 comments

Comments

@uganzedo1974
Copy link

Hello;
Good job with this package, it's excellent. I have a question, in some example in the regrid_bathymetry option there was the connected_regions_allowed option that is now not available. I would like to see the possibility of doing a downscaling in a simulation of a certain area. In an area, increase the simulation resolution. Is this possible? Thank you for your work
Unai

@simone-silvestri
Copy link
Collaborator

simone-silvestri commented Nov 26, 2024

Hello @uganzedo1974. The connected_regions_allowed option has been changed to major_basins.
For example:

bottom = regrid_bathymetry(grid; connected_regions_allowed = 2)

with the new syntax is

bottom = regrid_bathymetry(grid; major_basins = 2)

That keyword argument, however, might have been a misnomer before. It was not there to specify the number of connected domains in the simulation but to specify the number of "independent major basins", or fluid regions fully encompassed by land, that are retained in the bathymetric map. This is probably much better expressed with the major_basins keyword argument. There is an example in the examples folder (examples/generate_bathymetry.jl) that shows the effect of this keyword argument.

Concerning downscaling certain areas, we cannot run coupled nested simulations yet because the open boundary conditions required to connect different domains have not yet been implemented in Oceananigans.

@uganzedo1974
Copy link
Author

Thank you for your quick response. Maybe you can give me an idea to solve an issue with your package.
I have seen that there is a good example of downscaling in the Mediterranean area, which is a closed sea and the contour limits are the coast.
But I would like to do a study of the Canary Islands and I have done so but the contour limits are ocean, so u and v rotate in that contour limit, something that is not realistic. Is there any way to eliminate that condition?
Thanks again
Unai

@simone-silvestri
Copy link
Collaborator

I think what you need to have are open boundary conditions that allow you to prescribe boundary conditions for the velocity field from a "parent" large-scale simulation. This is the typical procedure when doing regional simulations.
However, to do so you would need an implementation of open boundary conditions in Oceananigans (the parent package of ClimaOcean) which at the moment is missing. Therefore, realistically, you can only do simulations that do not involve inflows or outflows.

A way you could try solving this issue would be to make your domain as large as possible (such that boundary conditions do not influence excessively your region of interest) and prescribe a strong restoring to climatology near the lateral boundaries. You do this using the ECCORestoring functionality.

"""
ECCORestoring([arch=CPU(),]
variable_name::Symbol;
version=ECCO4Monthly(),
dates=all_ECCO_dates(version),
dates = all_ECCO_dates(version),
time_indices_in_memory = 2,
time_indexing = Cyclical(),
mask = 1,
rate = 1,
grid = nothing,
inpainting = NearestNeighborInpainting(prod(size(metadata))),
cache_inpainted_data = true)
Create a forcing term that restores to values stored in an ECCO field time series.
The restoring is applied as a forcing on the right hand side of the evolution equations calculated as
```julia
F = mask ⋅ rate ⋅ (ECCO_variable - simulation_variable[i, j, k])
```
where `ECCO_variable` is linearly interpolated in space and time from the ECCO dataset of choice to the
simulation grid and time.
Arguments
=========
- `arch`: The architecture. Typically `CPU()` or `GPU()`. Default: `CPU()`.
- `variable_name`: The name of the variable to restore. Choices include:
* `:temperature`,
* `:salinity`,
* `:u_velocity`,
* `:v_velocity`,
* `:sea_ice_thickness`,
* `:sea_ice_area_fraction`.
Keyword Arguments
=================
- `version`: The version of the ECCO dataset. Default: `ECCO4Monthly()`.
- `dates`: The dates to use for the ECCO dataset. Default: `all_ECCO_dates(version)`.
- `time_indices_in_memory`: The number of time indices to keep in memory; trade-off between performance
and memory footprint.
- `time_indexing`: The time indexing scheme for the field time series≥
- `mask`: The mask value. Can be a function of `(x, y, z, time)`, an array, or a number.
- `rate`: The restoring rate, i.e., the inverse of the restoring timescale (in s⁻¹).
- `time_indices_in_memory:` how many time instances are loaded in memory; the remaining are loaded lazily.
- `inpainting`: inpainting algorithm, see [`inpaint_mask!`](@ref). Default: `NearestNeighborInpainting(Inf)`.
- `grid`: If `isnothing(grid)`, ECCO data is interpolated on-the-fly to the simulation grid.
If `!isnothing(grid)`, ECCO data is pre-interpolated to `grid`.
Default: nothing.
- `cache_inpainted_data`: If `true`, the data is cached to disk after inpainting for later retrieving.
Default: `true`.
It is possible to also pass an `ECCOMetadata` type as the first argument without the need for the
`variable_name` argument and the `version` and `dates` keyword arguments.
"""

This is demonstrated in the Mediterranean example in #244. I can copy here the code:

# ## ECCO Restoring
#
# The model is restored to at the surface to the temperature and salinity fields from the ECCO dataset.
# We build the restoring using the `ECCORestoring` functionality.
# This allows us to nudge the model towards realistic temperature and salinity profiles.
# `ECCORestoring` accepts a `mask` keyword argument to restrict the restoring region.
@inline surface_mask(x, y, z, t) = z > - 50
dates = DateTimeProlepticGregorian(1993, 1, 1) : Month(1) : DateTimeProlepticGregorian(1993, 12, 1)
FT = ECCORestoring(GPU(), :temperature; dates, mask=surface_mask, version=ECCO4Monthly(), rate=1/5days)
FS = ECCORestoring(GPU(), :salinity; dates, mask=surface_mask, version=ECCO4Monthly(), rate=1/5days)
# Constructing the Simulation
#
# We construct an ocean simulation that evolves two tracers, temperature (:T), salinity (:S)
# and we pass the previously defined forcing that nudge these tracers
ocean = ocean_simulation(grid; forcing = (T = FT, S = FS))

You can also take a look at the docstring by doing in julia by doing:

julia> ? ClimaOcean.ECCO.ECCORestoring

You probably also need to implement a sponge region for velocities, you can take a look at this example to see how:

@inline function restoring_mask(λ, φ, z, t=0)
ϵN =- 75) / 5
ϵN = clamp(ϵN, zero(ϵN), one(ϵN))
ϵS = -+ 75) / 5
ϵS = clamp(ϵS, zero(ϵS), one(ϵS))
return ϵN + ϵS
end
restoring_mask_field = CenterField(grid)
set!(restoring_mask_field, restoring_mask)
@inline sponge_layer(λ, φ, z, t, c, ω) = - restoring_mask(λ, φ, z, t) * ω * c
Fu = Forcing(sponge_layer, field_dependencies=:u, parameters=1/1days)
Fv = Forcing(sponge_layer, field_dependencies=:v, parameters=1/1days)

@glwagner
Copy link
Member

Should we move this to a discussion?

@CliMA CliMA locked and limited conversation to collaborators Nov 27, 2024
@simone-silvestri simone-silvestri converted this issue into discussion #279 Nov 27, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants