-
Notifications
You must be signed in to change notification settings - Fork 191
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
'Simulation' type for managing time stepping #447
Comments
I think it would be great to have these features so you can time step a model with fancy bells and whistles without an explicit loop. I have mixed feelings about the Not sure what to call it, maybe struct SimulationManager
Δt :: Union{Number, TimeStepWizard}
simulation_stop_time
wall_time_limit
simulation_stop_iteration
progress
end |
I think modular is better and that If you want, you can write a special constructor that builds both a |
I think you instantiate a model to do many things; one of them is time-stepping, but another may be analysis. Another is testing. Even now we can't actually solve poisson's equation without a I think it makes sense The way I envision a logical course for the development of complex software in general is that we start with the fundamental building blocks and make them as easy to use in their low-level form as possible. When we've decided we can proceed no farther, we add another layer of abstraction that fuses these underlying building blocks into a higher-order coherent object. And so on. I think its a better design strategy to add layers of abstraction, rather than embedding abstraction within already complex objects. The latter strategy would lead to unmanageable complexity. |
Thinking about this more, I think it would make sense to make an even more radical change. I think we should add The This orthogonalizes the design a bit: I think scripts become clearer. The user writes model = Model(; model_parameters...)
simulation = Simulation(model; simulation_parameters...)
simulation.diagnostics[:diag] = # something
run!(simulation) As an example to illustrate why model = Model(; model_parameters...)
set!(model; first_interesting_initial_condition...)
first_simulation = Simulation(model, first_simulation_parameters...)
first_simulation[:diag] = diag_specific_to_first_simulation
run!(first_simulation)
set!(model; second_interesting_initial_condition...) # same physical model, but different starting initial condition... no new memory allocated, no recompilation --- fast
second_simulation = Simulation(model, second_simulation_parameters...)
second_simulation[:diag] = diag_specific_to_second_simulation
run!(second_simulation) We can use |
After last week's discussions I think I'm on board with the separate I agree that I think the I think this is what we have so far for a design: struct Simulation
model
Δt
diagnostics
output_writers
simulation_stop_time
simulation_stop_iteration
wall_time_limit
progress
end
Note: |
Agree about |
It could be nice to have a type for managing time stepping --- eg,
Simulation
--- rather than requiring the writing of explicit loops as inhttps://github.com/climate-machine/Oceananigans.jl/blob/4b7e5bced1019b1a6804d3797cfe0ed41fda4a51/examples/ocean_wind_mixing_and_convection.jl#L190
Simulation
could look likeOr something along those lines. The field
progress
could either be a function or callable object, or tuple / list of functions or callable objects. The fieldΔt
could either be a constant time-step or aTimeStepWizard
.We might also need a new type called
ProgressMessage
for managing logging / emitting progress messages for simulations. Then we can give it afrequency
(andinterval
) of emission and support some other nice behaviors like a default format and auto-emission of diagnostic / monitoring results.xref: #432 #431
The text was updated successfully, but these errors were encountered: