Comments (10)
Strikes me that we could also change the log level so that warnings are not emitted.
from oceananigans.jl.
Some doctests for ImmersedBoundaryCondition
were converted to ordinary code blocks in #3692. It'd be nice to convert these back to doctests, if we can figure out how to filter the warnings.
Another solution is to eliminate the warnings themselves. ImmersedBoundaryCondition
may be ready for warnings to be removed and the example could use HydrostaticFreeSurfaceModel
in which case there'd be no warning.
from oceananigans.jl.
Some doctests for
ImmersedBoundaryCondition
were converted to ordinary code blocks in #3692. It'd be nice to convert these back to doctests, if we can figure out how to filter the warnings.
If I understand correctly I remember having to do this in #2990, specifically this file.
The header has to start with a regex expression like:
```jldoctest; filter = r"└ @ Oceananigans.BuoyancyModels.*"
from oceananigans.jl.
Hmm right... that filter stopped working. But now I am realizing there is something peculiar. The filter matches with the last line of the warning --- which acts to filter out the entire warning? Do you understand why that is?
That might be the key. The confusing thing about the issue here is that there are multiple warnings. But if we only need to filter the last line of the final warning, perhaps that's what we werent' doing...
from oceananigans.jl.
Hmm right... that filter stopped working.
I think it's still working. I found an instance of it still being used here:
Oceananigans.jl/src/MultiRegion/multi_region_grid.jl
Lines 85 to 97 in a18b81d
The filter matches with the last line of the warning --- which acts to filter out the entire warning? Do you understand why that is?
It matches the last line of the warning because that's the only line that changes from run to run. In particular the part tartarus-16
could be different it it ends up running on a different node:
Oceananigans.jl/src/BuoyancyModels/buoyancy.jl
Lines 33 to 36 in d705303
The other lines of the warning are always the same, so they don't need filtering.
from oceananigans.jl.
I think it's still working. I found an instance of it still being used here:
I meant for the specific instance that this issue refers to.
It matches the last line of the warning because that's the only line that changes from run to run. In particular the part tartarus-16 could be different it it ends up running on a different node:
My question is: why does matching the last line of the warning act to remove the whole warning? I am not asking about the intention of the filter. The intention is clear.
from oceananigans.jl.
Oof, ok I understand. I thought the filtering would allow us to remove the warnings from the docstring. But it doesn't. Instead we have to include the warning in the docstring (including a random path to someone's Oceananigans version, eg Research/OC11.jl
:
help?> MultiRegionGrid
search: MultiRegionGrid multi_region_grid MultiRegionField MultiRegionObject
MultiRegionGrid(global_grid; partition = XPartition(2),
devices = nothing,
validate = true)
Split a global_grid into different regions handled by devices.
Positional Arguments
≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡
• global_grid: the grid to be divided into regions.
Keyword Arguments
≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡
• partition: the partitioning required. The implemented partitioning are XPartition (division along the x direction) and
YPartition (division along the y direction).
• devices: the devices to allocate memory on. If nothing is provided (default) then memorey is allocated on the the CPU.
For GPU computation it is possible to specify the total number of GPUs or the specific GPUs to allocate memory on. The
number of devices does not need to match the number of regions.
• validate :: Boolean: Whether to validate devices; defautl: true.
Example
≡≡≡≡≡≡≡
julia> using Oceananigans
julia> grid = RectilinearGrid(size=(12, 12), extent=(1, 1), topology=(Bounded, Bounded, Flat))
12×12×1 RectilinearGrid{Float64, Bounded, Bounded, Flat} on CPU with 3×3×0 halo
├── Bounded x ∈ [0.0, 1.0] regularly spaced with Δx=0.0833333
├── Bounded y ∈ [0.0, 1.0] regularly spaced with Δy=0.0833333
└── Flat z
julia> multi_region_grid = MultiRegionGrid(grid, partition = XPartition(4))
┌ Warning: MultiRegion functionalities are experimental: help the development by reporting bugs or non-implemented features!
└ @ Oceananigans.MultiRegion ~/Research/OC11.jl/src/MultiRegion/multi_region_grid.jl:108
MultiRegionGrid{Float64, Bounded, Bounded, Flat} partitioned on CPU():
├── grids: 3×12×1 RectilinearGrid{Float64, RightConnected, Bounded, Flat} on CPU with 3×3×0 halo
├── partitioning: Equal partitioning in X with (4 regions)
├── connectivity: MultiRegionObject{Tuple{@NamedTuple{west::Nothing, east::Oceananigans.MultiRegion.RegionalConnectivity{Oceananigans.MultiRegion.East, Oceananigans.MultiRegion.West}, north::Nothing, south::Nothing}, @NamedTuple{west::Oceananigans.MultiRegion.RegionalConnectivity{Oceananigans.MultiRegion.West, Oceananigans.MultiRegion.East}, east::Oceananigans.MultiRegion.RegionalConnectivity{Oceananigans.MultiRegion.East, Oceananigans.MultiRegion.West}, north::Nothing, south::Nothing}, @NamedTuple{west::Oceananigans.MultiRegion.RegionalConnectivity{Oceananigans.MultiRegion.West, Oceananigans.MultiRegion.East}, east::Oceananigans.MultiRegion.RegionalConnectivity{Oceananigans.MultiRegion.East, Oceananigans.MultiRegion.West}, north::Nothing, south::Nothing}, @NamedTuple{west::Oceananigans.MultiRegion.RegionalConnectivity{Oceananigans.MultiRegion.West, Oceananigans.MultiRegion.East}, east::Nothing, north::Nothing, south::Nothing}}, NTuple{4, CPU}}
└── devices: (CPU(), CPU(), CPU(), CPU())
That's not as nice as I was hoping.
from oceananigans.jl.
I think warnings in docstrings are not nice. Perhaps the right solution here is to remove the warning for ImmersedBoundaryCondition
and also to change the doctest to use HydrostaticFreeSurfaceModel
.
from oceananigans.jl.
Personally I don't see a problem with warnings in the docstrings if that's how the code behaves.
Strikes me that we could also change the log level so that warnings are not emitted.
I'm not sure what the expected result of this is. But if this will create a situation where a given docstring won't have warnings, while users copy-pasting the contents from that same docstring may get a warning, then I think it'll be confusing and we should probably avoid that solution. If not, then that sounds like a great solution :)
from oceananigans.jl.
We wrote a more verbose version of the warning already in the docs. When 4 warnings print on top of each other, it makes the docs harder to read and therefore less effective.
from oceananigans.jl.
Related Issues (20)
- `Mem.free` is deprecated HOT 1
- Add in documentation for user defined vertical diffusivity profile in the hydrostatic model HOT 3
- Error in AveragedTimeInterval Output HOT 32
- Documentation 2.0 HOT 3
- Egregious errors in `NonhydrostaticModel` simulations on `ImmersedBoundaryGrid` when nonhydrostatic pressure is not separated HOT 21
- `cell_advection_timescale` (and CFL) does not account for `Flat` topologies HOT 1
- Support passing keyword arguments to `jldopen` when using `FieldTimeSeries` HOT 1
- `PartialCellBottom` needs to be adapted correctly for the GPU when using a `HydrostaticFreeSurfaceModel` HOT 4
- Performance benchmarks section of the README is super out of date HOT 3
- `view` fails on a `Field` indexed from `FieldTimeSeries`
- Ocenanigans license HOT 5
- Reducing parameter space usage by `LatitudeLongitudeGrid` HOT 3
- Why do we need 4 halo points in the vertical for `VectorInvariant(vertical_scheme=Centered())`? HOT 2
- `xspacings` is broken for `ImmersedBoundaryGrid`
- Change free surface displacement name from `η` to `displacement` for `HydrostaticFreeSurfaceModel`
- Docstring for `WENOVectorInvariant` is too terse and does not have examples
- Bottom drag on immersed boundaries may differ if implemented with `Forcing` vs `ImmersedBoundaryCondition`
- Re-licensing Oceananigans under Apache 2.0
- Do `intrinsic_vector` and `extrinsic_vector` belong in `Operators`?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oceananigans.jl.