Hi, I'm committing a first update in minutes (3.6. Periodic boundary conditions). Do you agree Vaclav with those sentences (else feel free to fix or suggest changes) :
(1) "It is believed that the first method is generally more convenient, since it will let :yref:`Cell.trsf` reflect only the transformation produced during the simulation, independently of the initial period geometry." (2) "In all cases, the period geometry should not be modified during a simulation, be it via Hsize, trsf, or refSize. The velocity gradient :yref:`Cell.velGrad` is the only variable that let the period deformation be correctly accounted for in constitutive laws and Newton integrator" Side comment on (1) : it will need to change the behaviour of setTrsf one day if we really want to uncouple trsf and Hsize. For instance, one could like to type trsf=identity after a deformation process (i.e. after some iterations) in order to set the current state as the reference for further deformation. It should have no effect on Hsize. Currently, it would mess the simulation big time. For (2), am I too restrictive? Additional comments : - be carefull with cumulated deformations, it is a product, not a sum (the equation is fixed in doc). There are very few cases when (dF+I)F = dF+F (small strain assumption would make it true for instance). I've seen that flipCell is using a sum, it could well be one of the few cases giving sum/product equality, but I'm not really sure. Using a product would be on the safe side. - It seems you forgot to update the doc when you replaced Newton::homotheticResize by Cell::homoDeform, but I love extra work too. ;-) Bruno -- _______________ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 - 38041, Grenoble cedex 9 - France Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ________________ _______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
