It is probably easy to create a "proxy" function, but I don't know how honestly + checking that equations are the same, yes I could have... But when the initial objective is to fix one line in PeriTriax, it means work time is multiplied by 10 at least. As for cpu time being no big deal... it is for me, since I compute energy by default in all triaxial simulations.
> It works in parallel (of course). The string comparison is there only > the first time, then it is stored in the index variable Nice. > I would think that you just don't know that the energy is > not conserved, because you don't look at all the contributions, that's > perhaps how your scripts "conserve" energy? I mean, come on, the plastic > dissipation it clearly not computed correctly, you don't agree? Mmmmh... No. I sent a mail today reporting energy conservation with an error 2e-4 after 60k iterations. There is no contribution ignored (well, ok, I ignore Cundall damping. Does it matter when damping=0?), and plastic dissipation is about 80% of the total input from boundaries, not under the carpet. I reported a similar result about one year ago, with an error about 0.5% (due to the approximation in PeriTriax stress). Did you consider this result? This is in quasistatic conditions. A soft test maybe, but still, it would be nice to see all laws in yade validated at least in this specific situation. Only ScGeom_CundallStrack passed this test IIRC. The other laws/configurations we tested actually failed before comparing energy (https://bugs.launchpad.net/yade/+bug/399963, https://bugs.launchpad.net/yade/+bug/675955, https://bugs.launchpad.net/yade/+bug/585771). Bruno _______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
