yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

On 29/09/14 18:42, Janek Kozicki wrote:
>> Materials are shared. So this one is ok.
> Do you mean it would be ok to move Material::density to some derived
> class, or by "ok" you meant something else?
The typical wasted memory in a simulation would be one double (if there
is only one material defined). The situation is different with "state",
where you really waste memory proportionaly to the number of objects.
Only problem could be if you define one independant material for each body.

>
>>> State::angMom, State::angVel, State::blockedDOFs,
>>> State::densityScaling, State::inertia, State::isDamped,
>>> State::mass, State::vel, State::inertia
>> This is more a problem indeed.  We should find a way to solve that
>> without casts.
> I assume that by word "casts" you mean "inheritance" and "derived classes" ?
I meant typecasting, i.e. if a more basic State class was introduced,
then everywhere in the code:
b->state->vel
would have to be replaced by:
YADE_CAST<DEMState>(b->state)->vel
Same for inertia, mass, etc.
Or did I miss something?

> As I said I can live with those extra attributes. They just waste
> memory, and do not hurt.
>
> I hope that I will come up with a solution that would be compatible
> with all currently written yade scripts. I was thinking about making
> StateEmpty right above State. But I don't know now if it would work.
> Maybe some of those attributes are used in some places that will make
> this approach not possible. We will see :)
My feeling is that they are used in many places. It needs to be checked
more precisely.
Considering a typical list of engines now, which one would you keep for
QM simulation?
Probably not much. That's why I was thinking about using a different
list of bodies, so DEM engines can keep working on O.bodies by assuming
a list DEM bodies.
And QM engines would have only what they need. Just an idea, there are
maybe other options.

Cheers.

Bruno