> 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? _______________________________________________ Mailing list: https://launchpad.net/~yade-users Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
