Is it safe to run JSBSim at a variable timestep?

[aarondewindt]

I want to run JSBSim in realtime with some code in the loop. I tried running it with a fixed timestep, but this didn't work reliably. So I tried adjusting the timestep by calling FGFDMExec.Setdt(...) on each iteration based on the realtime clock, simulation time and target timestep and it seems like this has done the trick.

However I'm not sure whether it's safe to do this, since it may have sideffects depending on what integration scheme is being used in JSBSim. Or maybe there is actual support for this and I need to enable some setting, change integrator, do nothing, etc.

[seanmcleod]

Is your issue that there is some amount of jitter between the simulation steps when run in realtime mode? And the amount of jitter was causing an issue with your own code within this loop?

I don't have a definitive answer in terms of the potential side-effects of varying the timestep during a simulation run. There could potentially be some code that caches the timestep value when it's initialized with the assumption that it would remain fixed for the run.

Coincidentally I was looking at the realtime case in JSBSim not that long ago because I noticed some amount of jitter when using JSBSim to update an aircraft pose in Prepar3d when trying to fly in close formation with a Prepar3d controlled aircraft.

JSBSim in realtime mode will basically check for any lag and if it detects any will then run multiple timesteps back to back to try and catch up.

jsbsim/src/JSBSim.cpp

Lines 532 to 550 in a35be5c

	} else { // ------------ RUNNING IN REALTIME MODE
	// "was_paused" will be true if entering this "run" loop from a paused state.
	if (was_paused) {
	initial_seconds += paused_seconds;
	was_paused = false;
	}
	current_seconds = getcurrentseconds(); // Seconds since 1 Jan 1970
	actual_elapsed_time = current_seconds - initial_seconds; // Real world elapsed seconds since start
	sim_lag_time = actual_elapsed_time - FDMExec->GetSimTime(); // How far behind sim-time is from actual
	// elapsed time.
	for (int i=0; i<(int)(sim_lag_time/frame_duration); i++) { // catch up sim time to actual elapsed time.
	result = FDMExec->Run();
	cycle_duration = getcurrentseconds() - current_seconds; // Calculate cycle duration
	current_seconds = getcurrentseconds(); // Get new current_seconds
	if (FDMExec->Holding()) break;
	}
	if (play_nice) sim_nsleep(sleep_nseconds);

[aarondewindt]

Thanks, I didn't actually realize there was a realtime mode, I'm linking against the library and interacting with the FGFDMExec instance directly.

I don't think the issue I had was related with jitter between JSBSim calls though, it was probably on our side. The difference was quite big, it would lag by about 1sec after just a 5sec simulation. I'll just try implementing it the same way you guys are doing.

[bcoconni]

Just for the record, using a variable time step with JSBSim is in most cases a terrible idea. The assumption of a constant time step is used almost everywhere in JSBSim code starting with the Adams-Bashforth integration schemes in FGPropagate. There are also classes such as FGFilter which initializes its parameters with the initial time step dt and never updates them after (unless one of the filter parameter was defined with a property in which case FGFilter::CalculateDynamicFilters is called at each time step - provided that the channel execution rate is set to 1).

So the rule of thumb is: unless you exactly know what you are doing (meaning you are very familiar with JSBSim inner workings), don't use a variable time step with JSBSim. Or even simpler, don't use variable time steps with JSBSim. I, for one, wouldn't wander in such murky waters 😉