← Back to team overview

yade-dev team mailing list archive

Re: periodic boundary consolidation

 

 
> Eh, to be honest, I think that it is exactly the problem, that you
> don't know what is it for: refHSize is irrelevant unless one uses
> OpenGLRenderer.dispScale!=(1,1,1).
>
This statement indicates you don't read the documentation I'm typing
(I've been mentioning the fact that it applies only if dispscale is
used), .
>  When you change trsf by hand (for instance, trsf=Id), then it is a
> discontinuous point in the simulation, and you probably want to scale
> displacements starting from that positions.
Hint: if this is what you want, then use setRefSe3 between each steps.
Tell me when it's clear for you, then I'll recommit r2703 (keeping
setBox if you need it, though I would recommend calling it setAlignedBox
- an inclined box is still a box). Please don't tell me "I understand
now, let me commit because I understand the code better than you";
obviously, it is not true.

It is funny that you mentioned Newton previously. The similarity in both
situations is you keep reverting a change that you don't understand,
until it is finally adopted. It means I should explain changes more
maybe, but at the same time I have the impression the explanations are
not read (example above).
If cooperation is difficult, then it should be minimized. In the present
case, I still don't understand why you suddenly felt the need to work on
Cell after the initial 2663. It would have been simpler to let me
improve the code alone, no? If I break something, send a mail or open a
bug, but don't revert commits as a whole please. All changes have been
explained in the list.

Please don't commit to Cell because it will conflict with my trunk.

Cheers.

Bruno










Follow ups

References