yade-dev team mailing list archive

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

> 1/ refH vs. trsf : do you agree that it is better to make them independant?
> 2/ refH can be kept in Cell if you prefer.
Yes, yes. I was thinking that I take care of the first one, since I 
sort-of maintain the rendering part, but if you do it, no problem.
> 3/ I'll remove H0.
It is just a function returning trsf^-1*hSize, what is the problem? Keep it.
> 4/ I'll add size back.
As you want.
> 5/ I'll revert the comment for size: size is not normalStrain x refSize
> (refSize is not a member, size is not 0 if strain is 0, even (1+strain)x
> refSize would not work in large strain).
Sorry, I didn't keep your change here by accident, of course it should 
be as you say.
> 6/ I'll rename setBox->setAxisAlignedBox, or setAABox, unless you think
> it is not necessary.
I think setBox is clear, as long as it is documented what it does.

> If you
> know what I could change on my part to interact better, please tell me,
> because getting commits reverted makes work cycles awkward. I'll
> consider any solution to avoid that (forking excepted ;-) ). Should I
> explain more before commits in your opinion?
I think this problem arised because it is quite a central part of Yade. 
I acknowledge that your explanations are sometimes pythian to me, 
perhaps because we have different backgrounds (you have geomechanics, 
while I have no good theoretical bg) and I frequently don't understand 
the motivations for such-or-such change.

I think fork would be the best alternative in some respects, but let's 
see before we go there if it works better in the future. I am sometimes 
thinking how much I need the code of other contributors (not that it is 
not very good sometimes, just that I don't use it) and if it is worth 
the synchronization/communication/etc "pain". The problem now is that I 
am not working on any "big" things currently and there does not seem to 
be anyone else having vision, producting something really generally 
interesting, creative (such as robust and documented couplings code, 
working on parallelization, FEM interface, ...), or technically 
important things (windows support, documentation infrastructure free of 
hacks, ipython/gui/... interoperability, network access). Maybe it only 
means that the programming challenge with Yade is over, and now comes 
the "scientific" challenge, which is less less in the code and more in 
testing and theoretical ingenuity; that would be only good. I sound 
nostalgic, perhaps I should retire. Managers advise to not stay more 
than 5 years with one project anyway. Someone willing to pay my rent? :-)

Cheers, v.