#25 multiple FDM instances per process / threaded FDM?
Not sure if there are any plans to support something
like this, but we are using JSBSim together with
FlightGear and would find it useful if there was a way
to tell JSBSim to instantiate multiple FDM instances,
so that the FDM engine can simulate different aircraft
(i.e. for AI traffic) at the same time, feeding the
data back to FlightGear. Currently, we are about to
develop a simple workaround for this limitation, by
using different processes of JSBSim (standalone), we
hope to be able to finally tell FlightGear to simply
fork and use different JSBSim processes at the same
time. This is probably the easiest solution, certainly
much easier than trying to make the FDM itself
mult-threaded. Anyway, please consider this more as an
idea than a feature request, just in case anybody else
would find this useful, too.
Logged In: NO
This sounds like a pretty good idea, I would also like to
see such a feature eventually in FG, maybe we could add this
to jsbsim under the umbrella of a Google SoC project? Are
there any plans for jsbsim to become a SoC mentor project?
http://code.google.com/soc
Logged In: NO
instead of really using multiple simultaneous processes or
threads, it might be a easier to only reorganize the FDM
engine in a fashion, that allows for flight dynamics of
different aircraft to be calculated sequentially, using the
very same FDM instance that's used by FG anyway.
That way, priority to different aircraft in the simulation
could be given by simply running the FDM at a different
rate-that is, the FDM in FlightGear would by default only
calculate the flight dynamics of the current aircraft, i.e.
at 80hz-however, other aircraft could still be simulated
using proper flight dynamics, simply by afterwards iterating
over all other aircraft that are to be simulated, and
resetting the FDM loop accordingly-these calculations could
be done on an on demand basis, as it would usually be
sufficient to update the flight dynamics slowly-i.e. at
5-10hz, thus it would become feasible to simulate multiple
aircraft at once, without having to use threads or processes
(even though, this would not yet provide support for
machines with multiple processors).
Logged In: NO
something like this would also be useful in order to enable
multiplayer servers to do server-side flight validation,
that way a server could verify whether the provided flight
data is actually valid for a given aircraft-so that client
data is only dealt with if it matches an aircraft's known
performance characteristics. Basically, you would make sure
that no arbitrary data is fed to the server (i.e. a c172
flown at 0.8M).
Logged In: NO
yes, in the long run, support for multiple fdm instances is probably going to be the way for all fdm engines supported by flightgear
Logged In: NO
One could think about achieving support for multiple FDM instances by multiplexing the data for different aircraft, where depending on the required update rate, a state buffer is rotated/switched accordingly.
this was already more than 7 yrs ago, see this posting from Curt: http://www.mail-archive.com/flightgear-devel@flightgear.org/msg00881.html
Just a remark: You can run multiple JSBSim instances in one thread if each FGFDMExec instance has its own property tree. This is sufficient to simulate the AI air traffic. You just cannot access each other's property tree (cannot have fdm[1], fdm[2], fdm[3]).
this is in fact in line with the approach David Megginson proposed in a discussion about possible ways to prepare FlightGear for a multi-threaded future: subsystems would all have their own instances of a property tree so that reading/writing (subsystem-specific) values could happen in an organized fashion where each read/write request is dispatched to the corresponding subsystem in order to ensure that these requests are happening in a coordinated fashion. Still, each subsystem could publish "pointers" (or aliases) to a global property tree which would be accessible to all other subsystems, yet accesses would be dispatched so that subsystems could be arbitrarily threaded because each subsystem would handle its own property tree internally. Thus, the locking overhead would also be extremely minimized because the property tree would be partitioned into subsystem-specific toplevel nodes, where access to anyone property doesn't necessarily require other nodes to be inaccessible/locked
The following postings are related to this discussion:
http://www.mail-archive.com/flightgear-devel@flightgear.org/msg00891.html
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18063.html