yade-users team mailing list archive

["Sergei D." <sj2001@xxxxxxxxx>]

> I would prefer to add this a new state. 
> But it shouldn't be
> "RigidBodyState" (current State is what would be called rigid-body
> state, no?), but something expressing that it remembers last angular
> momentum.

Yes, it is a rigid-body state... Then, may be accRotIntegratorState? or
auxAngMomState, when "aux" from "auxiliary"?

 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...
Maybe somehow refine the architecture or to develop a clear rules of
expanding the project? For example, if I would new contact model, I
need: new Material, new InteractionPhysics, new Ip2_myMat_myMat_myPhys
and new ConstitutiveLaw. I can create all it in my meta package (for
example, as it is in ConcretePM, RockPM and ViscoelasticPM now). I can
copy any another code in my package and this would not to be influence
on everything else. Those who want to use my code, will have to copy it
yourself and modify accordingly (and maintain it yourself). But, he
would not have to adjust their code under a my architecture and I do not
have to worry about backward compatibility with their code when I
modifying my model. So, my model's code is leaf on tree. This is
justified, because each model usualy is individual... and its
implementation should not require much experience from the user.
But, what if I need new integrator? 1) I can use meta package approach.
So, I derive new State class (but I will have redundant variables) and
copy+modify NewtonDampledLaw. But in NewtonDampedLaw we have a
standalone bodies, clumps, BEX, velocityBins, Open MP... huh... One
needs many experience in order to maintain all these. So, new integrator
is not for user's meta package in general. 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... 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). I think this is the appropriate method,
because the new integration algorithms definitely will not be added very
often. Everybody just requires a working algorithm, and nothing more.
Thus, several options can be combined in one class.
What are you all think about it?