| Thread Previous • Date Previous • Date Next • Thread Next |
I don't think this reasoning applies here, L3Geom is not an incrementally "fixed" version of ScGeom, they are substantially different (local vs. global coords). Even if it were not the case, you know that cooperation is difficult, due to both technical (difficult to communicate, lack of documentation and derivations of formulas for other people to understand) and personal (everybody has his/her own piece of code and doesn't like other to touch it, for the fear of others breaking it) reasons -- look at PeriIsoCompressor/PeriTriaxController/Peri3dController, recall our discussion in Grenoble, read recent e-mails on dynCell & mass: it just costs too much energy, which is a scarce resource.Let's go back to yade development here. Perhaps it would be more constructive to improve existing code (and if there is one line you don't understand, just ask) than writing a full new set of Ig_+Ip_+Law2's. It would give better cooperation than you writing from scratch and deleting, and me strugling to get functional things out of attic. Don't you think?
When you say that they are "in Yade", what does it mean? Yade is a toolkit of pieces, some of them fit together, some don't. Everybody is working on his own part anyway and I don't think there is (for good or bad) some substantial convergence. I see Yade now more as software platform (which provides things like data persistence, python bridge, gui, 3d, math libs, the functors/dispatchers framework and a few common engines like the intergrator or collider), not necessarily as a complete DEM solution. Of course the question is what hold the whole code together then (I don't see anything).Periodic velocity shift (Vincent told me it was so tricky that nobody would have been implemented it yet), plasticity, and other things, are already in Yade. It would be a pitty to derive everything again.
Cheers, v.
| Thread Previous • Date Previous • Date Next • Thread Next |
