Skip to content
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

Merged
merged 19 commits into from
Mar 21, 2024
Merged

Adds last_Δt to Clock #3508

merged 19 commits into from
Mar 21, 2024

Conversation

jagoosw
Copy link
Collaborator

@jagoosw jagoosw commented Mar 13, 2024

This PR adds last_Δt to Clock to make Δt available in more places (particularly in boundary condition halo fills addressing a challenge in #3482).

@jagoosw jagoosw marked this pull request as ready for review March 13, 2024 17:09
@glwagner
Copy link
Member

I like last better than previous. But it's not perfect because "last" can also mean "final". Can anyone think of a better name?

Also, do we need previous_dt in the time-stepper anymore?

@glwagner
Copy link
Member

I think we also need to add something to reset!:

function reset!(sim::Simulation)
sim.model.clock.time = 0.0
sim.model.clock.iteration = 0
sim.model.clock.stage = 1
sim.stop_iteration = Inf
sim.stop_time = Inf
sim.wall_time_limit = Inf
sim.run_wall_time = 0.0
sim.initialized = false
sim.running = true
reset!(timestepper(sim.model))
return nothing
end

@glwagner
Copy link
Member

Also

sim.model.clock.time = 0.0

should just be

 sim.model.clock.time = 0

(at least --- this will also have to be changed to support dates @navidcy)

src/TimeSteppers/clock.jl Outdated Show resolved Hide resolved
@@ -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),
Copy link
Member

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.

Copy link
Member

@glwagner glwagner Mar 13, 2024

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])

Copy link
Member

@glwagner glwagner Mar 13, 2024

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).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that makes sense

Copy link
Collaborator Author

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

Clock(; time::T, iteration=0, stage=1) where T = Clock{T}(time, iteration, stage)

Copy link
Collaborator Author

@jagoosw jagoosw Mar 13, 2024

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.

Copy link
Member

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.

Copy link
Member

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.

@jagoosw
Copy link
Collaborator Author

jagoosw commented Mar 13, 2024

Okay, so I've got a way we could do this. When a user specifies an AbstractTime we can then use the type they've given to set the timestep type like:

clock = Clock{eltype(grid)}(time = DateTime(2020))

"""
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)
Copy link
Collaborator Author

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?

Copy link
Member

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

Copy link
Member

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.

Copy link
Member

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

Copy link
Member

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

Copy link
Collaborator Author

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

@glwagner
Copy link
Member

glwagner commented Mar 13, 2024

Okay, so I've got a way we could do this. When a user specifies an AbstractTime we can then use the type they've given to set the timestep type like:

clock = Clock{eltype(grid)}(time = DateTime(2020))

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/TimeSteppers/clock.jl Outdated Show resolved Hide resolved
@navidcy navidcy added the abstractions 🎨 Whatever that means label Mar 14, 2024
Co-authored-by: Gregory L. Wagner <[email protected]>
@glwagner
Copy link
Member

Also going to change the title of this PR to use our convention --- try to do that in the future too!

@glwagner glwagner changed the title Added last_Δt to Clock Adds last_Δt to Clock Mar 15, 2024
src/TimeSteppers/clock.jl Outdated Show resolved Hide resolved
Copy link
Collaborator

@navidcy navidcy left a 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]>
@jagoosw
Copy link
Collaborator Author

jagoosw commented Mar 18, 2024

These test failures are just testing problems not actual code problems right?

@glwagner
Copy link
Member

I think so, I'll retry them.

@glwagner
Copy link
Member

we close now

@glwagner
Copy link
Member

doesn't this mean that we can get rid of previous_dt from QuasiAdamsBashforth2TimeStepper ?

@glwagner
Copy link
Member

It's fine if we do it in another PR.

@jagoosw
Copy link
Collaborator Author

jagoosw commented Mar 18, 2024

Could you try and run the docs again?

@jagoosw
Copy link
Collaborator Author

jagoosw commented Mar 18, 2024

doesn't this mean that we can get rid of previous_dt from QuasiAdamsBashforth2TimeStepper ?

I would have thought so

@navidcy navidcy merged commit e243e5b into main Mar 21, 2024
48 checks passed
@navidcy navidcy deleted the jsw/add-Δt-to-clock branch March 21, 2024 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abstractions 🎨 Whatever that means
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants