Re: [Flightgear-devel] Re: code optimisation

2005-07-06 Thread Christian Mayer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Campbell schrieb:
> Hi,
> One comment and some documentation has indicted that FDM doesnt consume
> much CPU.
> I ask myself why?
> The modelling of a generalised rigid body with six degrees of freedom in
> a rotating frame of
> reference should max out anyones and everyones CPU!

Calculating the updating 6 DOF is a real simple task. It only takes a
few operations.

It can be far more challenging to calculate change in the 6 DOFs. This
can be done cheaply on the basis of functions / lookup tables (like the
FDMs we use).
Or it can be done by solving navier stokes equations at each timestep.
This would max out the CPUs for quite a while (especially when it comes
to direct numerical simulation - there are even current supercomputers
maxed out for simpler tasks than the flow around an air foil)

Oh, btw, we are currently updating our 6 DOF much more often than the
image gets redrawn...

> I notice that JSBSim uses a simple single step method for integration
> whereas LaRCSim uses
> a multi-step method. Spare CPU could be utilised in doing a multi-step
> predictor/corrector integration
> with variable step size especially for more esoteric aircraft types with
> high speeds and high altitudes
> and even near orbital capability in JSBSim.

I doubt that changing the integration method will cause any performance
problem. So you might try it.
But making delta t smaller also helps, so that might give you more
precision for the time spend tweaking the code.

And as we've got an interactive application I guess that the absolute
error in the integration doesn't bite us. Any turbulence in the real
world will change the position more than precision errors will (assuming
perfect FDM parameters)

CU,
Christian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCzC7xlhWtxOxWNFcRAstrAJ9F5IodbEMqjrRUQxvOjDAEJAXR/QCgnxCD
yavFP/qrqy1BScpH8FFzOEE=
=saYF
-END PGP SIGNATURE-

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: code optimisation

2005-07-06 Thread Andy Ross
Jim Campbell wrote:
> The modelling of a generalised rigid body with six degrees of
> freedom in a rotating frame of reference should max out anyones and
> everyones CPU!

People were doing that in real time with VAX 11/780's in 1981. :)

Seriously, no: the FDM takes up comparatively little CPU.  Of the two
main ones, YASim is the slowest, because it breaks the fuselage down
into a bunch of discrete units that need to be individually handled.
The last time I looked at this YASim took up about 5-7% of so of the
total CPU budget for the flight model I was looking at.  I honestly
forget when this was, on what computer, or what plane I was using.

Sorry, but the 3D graphics are the lions share of the performance
budget, and always will be.

> Of course any model is only as good as the approximations used so we
> apply symmetry to an aircraft (what happens if an engine drops off!)
> and various other restrictions.

YASim is perfectly happy with asymmetric aircraft, FWIW.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Re: code optimisation

2005-07-06 Thread Jim Campbell

Hi,
One comment and some documentation has indicted that FDM doesnt consume 
much CPU.

I ask myself why?
The modelling of a generalised rigid body with six degrees of freedom 
in a rotating frame of

reference should max out anyones and everyones CPU!
Of course any model is only as good as the approximations used so we 
apply symmetry to
an aircraft (what happens if an engine drops off!) and various other 
restrictions. From my point

of view I would rather devote spare CPU to the accuracy of the FDM.
I notice that JSBSim uses a simple single step method for integration 
whereas LaRCSim uses
a multi-step method. Spare CPU could be utilised in doing a multi-step 
predictor/corrector integration
with variable step size especially for more esoteric aircraft types 
with high speeds and high altitudes

and even near orbital capability in JSBSim.
Anyone with any comments or advice or done anything similar?
cheers
Jim


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d