yade-users team mailing list archive

[Václav Šmilauer <eudoxos@xxxxxxxx>]

>  For now, you could remember it in a vector<Vector3> inside the
> > integrator, though it is an ugly hack.
> 
> I thought that yade is currently just going through a period of
> purification from different hacks... But if they are needed again...

Sorry for not being clear. I meant while you develop and before we agree
on the best way (whether to put the prevAngMom to State directly or in a
derived class), you could use it as temporary workaround, to not be
blocked. Then, of course, that workaround would be removed.

> 1) I can use meta package approach.

Clearly not applicable to integrator.

> 2) I can copy NewtonDampedLaw
> to myNewtonDampedLaw and keep it in common yade tree. Thus, I certify
> that I have enough skills to manage myNewtonDampedLaw. But if someone
> wants a different algorithm, he will create, by analogy with me,
> my1NewtonDampedLaw. As a result, we will have the whole pleiad of
> my*NewtonDampedLaw (at least more than one), that contain a lot of
> common code and one half will not work, and second half will be support
> a different number of features... Bad situation for common part of code.
> What it looks like it was before...

Exactly, this is what we had with different *TriaxialEngines and others.

> I propose to use O??am razor for
> common part of yade: not the fruit essences unless absolutely necessary.
> So, I propose to add new integration algorithms into NewtonDampedLaw
> directly; and all necessary variables into State directly (with comments
> about the algorithm need them).

We could also make that part conditionally compiled. If someone is sure
to never need clumps etc, he/she will not compile that part at all. It
could also serve to see what is the overhead during simulations that
don't need it and to find out that it can be compiled all the time
without major impact.

v