Automatically adding mandatory simulation callbacks

[ali-ramadhan]

Sometimes you have a boundary condition, or Lagrangian particles, or biogeochemistry that needs updating every time step (or every n time steps).

The current method of ensuring this update occurs is to add the appropriate boundary_conditions, particles, or biogeochemistry, then define an update function, e.g. update_particles!, and add it as a simulation callback with IterationInterval(1) schedule.

This is perfectly fine (and not a lot of work honestly) but from a user experience perspective it would be nice and less error-prone if there was a way for this update callback to be added automatically.

Although I'm not sure how to make this happen as most of these objects that require updates are defined before the model and simulation are constructed. They can't even be added after simulation construction.

I'm wondering if there's any way of automatically adding such "mandatory" simulation callbacks.

[glwagner]

Yes, there is a notion of "dependencies":

Oceananigans.jl/src/Simulations/run.jl

Lines 162 to 166 in fe4123f

	add_dependency!(diagnostics, output) = nothing # fallback
	add_dependency!(diags, wta::WindowedTimeAverage) = wta ∈ values(diags) || push!(diags, wta)
	add_dependencies!(diags, writer) = [add_dependency!(diags, out) for out in values(writer.outputs)]
	add_dependencies!(sim, ::Checkpointer) = nothing # Checkpointer does not have "outputs"

the WindowedTimeAverage uses this. For example, time-averages require some action every time-step, but output is only requested relatively infrequently.

What specifically do you have in mind?

[ali-ramadhan]

Ah would it be correct to describe add_dependency! as

it adds a dependency to simulation.diagnostics if it isn't in there already

?

Maybe I was thinking of something more along the lines of

if you use an open boundary condition but did not add a specific simulation callback, e.g. update_open_bcs!, then the simulation will error and tell you to add that callback.

[glwagner]

Oh sorry for giving an incomplete answer!

If you have something that requires updating every time-step, can that model feature be constructed as a FieldTimeSeries?

If so, we have built up some functionality for using FieldTimeSeries as forcing and boundary conditions. For example:

Oceananigans.jl/src/Models/NonhydrostaticModels/update_nonhydrostatic_model_state.jl

Lines 27 to 28 in 325866b

	# Update all FieldTimeSeries used in the model
	update_model_field_time_series!(model, model.clock)

I think the primary use case here is for components that are loaded from data, which is where there's a lot of functionality around which FieldTimeSeries is designed

Now, if you cannot construe this model component as a FieldTimeSeries then maybe we need to compute with another abstraction, some kind of FunctionUpdatedField which has two objects, a Field, plus a function that is used to update it?

[glwagner]

Then we could generalize the update_model_field_time_series! to something that updates both FieldTimeSeries and other objects, like FunctionUpdatedField. Right now we are relying on this concept

Oceananigans.jl/src/Models/Models.jl

Line 143 in 325866b

update_field_time_series!(fts, time)

which can be generalized to something like

update!(obj, model)

then we have

update!(fts::FieldTimeSeries, model) = update_field_time_series!(fts, Time(model.clock.time))
update!(f::FunctionUpdatedField, model) = f.update(f.field, model)

for example.

We also need to generalize

Oceananigans.jl/src/Models/Models.jl

Line 139 in 325866b

time_series_tuple = extract_field_time_series(possible_fts)

This would increase reliance on flattened_unique_values, which is becoming a bit notorious because it is tough to differentiate through

Oceananigans.jl/src/Models/Models.jl

Line 140 in 325866b

time_series_tuple = flattened_unique_values(time_series_tuple)