yade-dev team mailing list archive

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

> I don't see how setBox can help. Is somebody fool enough to (1) start by
> defining a non-aligned cell, then (2) make it aligned again? I don't
> think so.
I don't know what you think, but I guess it is better to call it setBox, 
if it creates box... setBox defines the whole geometry, whereas 
assigning size depends on the previous state (if was perhaps deformed, 
who knows). Dunno, really.
> Anyway, we can have both setBox and size=... if setBox is also useful.
> I'll add "size=..."
Quite on the contrary, I don't see reason for assignable size. Matter of 
taste, keep it if you think it is useful, though.
> > 2. why removing hSize0?
> Because it is uselss. It's used nowhere in c++ and nowhere in scripts.
> If somebody wants trsf^-1*H one day (why would he need that btw?), he
> can compute it like trsf.inverse()*hSize.
Of course it is just trsf.inverse()*hSize, but... Perhaps useful. Not sure.
> Perhaps I don't understand what it is supposed to do, but please see the
> (3rd) paragraph on per-step loading here
> https://www.yade-dem.org/doc/2703/formulation.html#periodic-boundary-conditions.
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).

> With last change, the interval for scaled displacement is independant of
> what you do with trsf. Cell deformation and bodies disps are always
> consistent.
I think they should be actually dependent, no? I have this scenario in 
mind: under normal circumstances, velGrad changes trsf; then refHSize 
does not change, and displacements are correctly scaled (not that 
refHSize is decoupled from hSize0, which was an intention: when I want 
to make the current state "reference" for display, I don't want to 
affect the simulation itself). 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.

Ah, I see what you mean... crap. That refHSize will be modified, but ref 
positions not. That's true. I have to think about it. Perhaps you are 
right. Can we keep it as it is now, and I will change it when I make up 
my mind about it?
> The 3rd paragraph can be just removed.
Agreed, it is not clear at all (was it me who wrote it?/!)
> The point is the whole concept of reference size or
> reference state can be removed from cell. That's why I was a bit
> surprised to see it introduced again in hSize0, for instance. We could
> keep only refSize for compat, then move refHsize to OGL, so we could
> finally consider PBCs (cell and engines) "reference-free" (backward
> excepted).
For hSize0, it is just a shorthand which can be useful ocasionally, but 
can be removed really; I think perhaps useful for debugging, no? For the 
refHSize, I think it is better in Cell itself, because then it can react 
to direct changes of trsf/hSize, but as above, not sure how much is it 
actually useful.

Do you agree that what we have now is "good enough", we might or might 
not keep hSize0 as shorthand, and we leave refHSize pending now, until I 
see what works better?

Cheers, v.