restart a run

[miniufo]

Sorry, I didn't find any information here about how to restart a simulation. For a high-resolution simulation, I need to check the spectrum to be the one I need after a spinup. Then I will decide to continue the run or not. So this is useful for my case.

I just got a 2D NS problem:

prob = TwoDNavierStokes.Problem(dev; nx=n, Lx=L, ν, nν, μ, nμ, dt, stepper="RK4",
                                calcF=calcF!, stochastic=true)

After spinup, I can get the solution prob.sol or prob.vars.ζh and output to a (jld2) file. Then if I need to continue the simulation, I could define a new problem and its initial state as the one from the (jld2) file:

prob_new = TwoDNavierStokes.Problem(dev; nx=n, Lx=L, ν, nν, μ, nμ, dt, stepper="RK4",
                                calcF=calcF!, stochastic=true)
TwoDNavierStokes.set_ζ!(prob_new, Array(prob.vars.ζh)) # this cause error because of array size
TwoDNavierStokes.set_ζ!(prob_new, Array(prob.vars.ζ)) # this works fine

Just want to make sure set_ζ works with ζ (in grid space), not ζh (in spectral space).

[glwagner]

I believe the time-steppers are all self-starting, so all that is needed to restart a simulation is the solution (either in spectral or grid space).

GeophysicalFlows.jl/src/twodnavierstokes.jl

Lines 352 to 360 in 98a830e

	function set_ζ!(prob, ζ)
	mul!(prob.sol, prob.grid.rfftplan, ζ)
	CUDA.@allowscalar prob.sol[1, 1] = 0 # enforce zero domain average
	updatevars!(prob)
	return nothing
	end

I think if you want to set the solution in spectral space, you can simply copy it into prob.sol (in this case) and then call updatevars!(prob). It'd be useful to have a set_sol! function though it seems like.

[miniufo]

Great, I'll try copying the sol only. Thank you very much @glwagner.

[glwagner]

If anyone wants to make a contribution to this package, which would be very nice and helpful, then I think set_sol! would be something like

 function set_sol!(prob, sol) 
   prob.sol .= sol
   updatevars!(prob) 
   return nothing 
 end 

some embellishments might also check if sol has is on the right device (eg CPU/GPU) and automatically move it over if needed, plus perhaps enforcing zero domain average, since this is enforced later (not sure why it isn't enforced within updatevars!, thats another choice)

[miniufo]

Well, that may not be too hard. Just want to know if this is general enough for all problems? I guess this only applies to 2D NS problem where sol is the vorticity only. Maybe we need a set of set_sol! for different problems? or the differences are already encoded in updatevars!?

[glwagner]

Hmm, what you say --- one set_sol! for every Module.Problem --- does seem possible in principle and would be clean, just a few lines. However, it requires that updatevars! is properly extended for different problem types. At the moment (just taking a glance) all of the updatevars! are defined independently rather than extended. It's a very small amount of work to change this though. @navidcy