-
Notifications
You must be signed in to change notification settings - Fork 194
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
Adds last_Δt
to Clock
#3508
The head ref may contain hidden characters: "jsw/add-\u0394t-to-clock"
Adds last_Δt
to Clock
#3508
Conversation
I like Also, do we need |
I think we also need to add something to Oceananigans.jl/src/Simulations/simulation.jl Lines 163 to 175 in 3bb62a6
|
Also Oceananigans.jl/src/Simulations/simulation.jl Line 164 in 3bb62a6
should just be sim.model.clock.time = 0 (at least --- this will also have to be changed to support dates @navidcy) |
@@ -112,7 +112,7 @@ Keyword arguments | |||
function ShallowWaterModel(; | |||
grid, | |||
gravitational_acceleration, | |||
clock = Clock{eltype(grid)}(0, 0, 1), | |||
clock = Clock{eltype(grid), eltype(grid)}(0, Inf, 0, 1), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I would add a constructor for Clock
that takes one type rather than writing this. But you can decide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also note that we might reasonably expect users to provide custom clocks with their own time and iteration --- but that the stage and time-step probably won't commonly be provided when building a clock. So I think it would make more sense to have a syntax that looks like
Clock{TT}(time, iteration, [optional args])
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the type of the time-step can probably be inferred from the time type TT
(ie if the time type is either a floating point or a DateTime or something like that).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There actually is already a constructor I can just change it a bit to infer the DT
Oceananigans.jl/src/TimeSteppers/clock.jl
Line 27 in 3bb62a6
Clock(; time::T, iteration=0, stage=1) where T = Clock{T}(time, iteration, stage) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like Dates
only stores things as integers and is never directly used but the timestep is always eltype(grid)
so I'm not sure it can be directly infered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't support dates right now -- to support it, we have to generalize how the time-step specification works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the timestep is always eltype(grid) so I'm not sure it can be directly infered.
We will have to change how time-step specification works to support DateTime properly.
Co-authored-by: Gregory L. Wagner <[email protected]>
Okay, so I've got a way we could do this. When a user specifies an clock = Clock{eltype(grid)}(time = DateTime(2020)) |
src/TimeSteppers/clock.jl
Outdated
""" | ||
Clock(; time::T, iteration=0, stage=1) where T = Clock{T}(time, iteration, stage) | ||
Clock(; time::TT, last_Δt::DT=Inf, iteration=0, stage=1) where {TT, DT} = Clock{TT, DT}(time, last_Δt, iteration, stage) | ||
Clock{TT}(; time, last_Δt=Inf, iteration=0, stage=1) where TT = Clock{TT, TT}(time, last_Δt, iteration, stage) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@glwagner is it too confusing to infer the types like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thikn taht's good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a little bit of a conundrum --- I need to understand all the possibilities with DateTime
a bit more. I think when we use DateTime
, there will be many possibilities for the time-step type (Second
, Minute
, etc...). But we can figure it out when the time comes though and no need to overworry right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I missed the line below
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest deleting the function with AbstractTime
. But we can put a little place-holder for the future.
BTW julia doesn't support dispatch on keyword argument types
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh thank you good to know
I think it'll work a little differently, because we will want the time-step to also be a period rather than a floating point. We don't support it yet, but we will have to convert the time-step to a floating point somewhere internally. It does look like this will affect the code you are about to write! But don't worry too much --- as long as you write clear, concise code we will be able to change it approprately in the future! |
src/Models/HydrostaticFreeSurfaceModels/hydrostatic_free_surface_model.jl
Show resolved
Hide resolved
Co-authored-by: Gregory L. Wagner <[email protected]>
Also going to change the title of this PR to use our convention --- try to do that in the future too! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this
Co-authored-by: Navid C. Constantinou <[email protected]>
These test failures are just testing problems not actual code problems right? |
I think so, I'll retry them. |
we close now |
doesn't this mean that we can get rid of previous_dt from |
It's fine if we do it in another PR. |
Could you try and run the docs again? |
I would have thought so |
This PR adds
last_Δt
toClock
to makeΔt
available in more places (particularly in boundary condition halo fills addressing a challenge in #3482).