yade-dev team mailing list archive

[Janek Kozicki <cosurgi@xxxxxxxxx>]

Václav Šmilauer said:     (by the date of Tue, 20 Feb 2007 19:45:13 +0100)

> 1. as noted in the source of NewtonsForceLaw and NewtonsMomentumLaw,
> there should be an engine resetting both accelerations at every 
> timestep so that forces from multiple sources may accumulate. Since I 
> need that, i am going to write it.

good! :)

 

> The question is what is the performance impact of adding one more loop
> over all bodies, if this could be done for example at the end of
> LeapFrogOrientationntegrator (which would have to be, conventionally,
> the last one that works with accels). I imagine objections. OK.

I have tested that - one loop more has not any impact (smaller than
the the standard deviation of time from 5 test runs). You can check it
yourself. 

So it's better to have a separate engine for that, instead of putting
it at the end of leap frog integrator. Bundling stuff together is a
practice employed by a one software giant ;p Don't do that :)

Think that someone may want to use an AccelerationRecorder, and
typically recorders come at the end of the simulation loop (after
leapfrog integration). This is the exact reason why all the
Resetters* are at the beginning of the loop.



> 2. The second question is what about LeapFrogSe3Integrator that would do
> Force and Momentum at once - I can barely imagine someone will want to
> integrate positions with leapfrog and orientation with Newmark.

don't bundle Force and Momentum together: think about particle
that has no orientation. It will integrate only position. Think about
other possibilities like integrating temperature. It would be bad to have:

  LeapFrogPositionIntegrator
  LeapFrogOrientationIntegrator
  LeapFrogSe3Integrator         <- redundant!
  SomeTemperatureIntegrator

The solution must be of different type: when rewriting yade to be
parallelization capable we must make two kind of calculation flows:
parallel and serial. Both of them connectable in any configuration.
That's the work for Andrzej Oszer.

That means that Engine class (a basic building brick of simulation
loop) will be able to be connected in customisable way with other
Engines. And then we will have several parallel threads that run two
serially connected Engines one after another:
LeapFrogPositionIntegrator and LeapFrogOrientationIntegrator.

Then in the case of a single thread a one loop is removed, and both
engines are ran in the same loop (because they are serially connected).

So by solving parallelization issues we also solve your doubts about
extra loops :)



(BTW where does "se3" come from? Is it supposed to mean something?)

I vaguely remember that people who work in computer graphics use this
term. So we have it from Oliver. But don't worry - upon rewritting
containers it will be removed. The position and orientation will be
separated, because it will ease handling of DOFs (degrees of freedom)
and handling of their boundary conditions. That's a non-trivial
change, but I've thought about this very carefully. 
(BTW, DeusExMachina will become BoundaryCondition )



> 3. I suggest removing DeusExMachina::subscribedBodies. Most engines
> don't use it at all and those who do (currently only Triaxial) can
> declare it in the derived class. For me it was confusing at first as I
> thought that yade core will take of calling the engine only for
> subscribedBodies.

a very good point. changing containers will enforce this change :)

-- 
# Janek Kozicki
_______________________________________________
yade-dev mailing list
yade-dev@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/yade-dev