I got the same idea this WE. Maybe commit scripts and results in trunk/scripts/checks, or upload them on wiki - as they can give at the same time simulation exemples?
Bruno On 06/12/10 09:06, Anton Gladky wrote: > Ok, I think it is good to have such tests anyway. We can keep them > separately from regression ones. > Let's call "check tests" or... > > And they should not be mandatory for packaging. "Just to check". If > somebody commits something and it sufficiently changes result value - it > can be serious. > > I usually do it, for my tests. I compile new YADE version and start > there my "standart" test with "-j 1" to have always the same results. If > it is ok - I use new YADE-version for work. > > I think it is relatively easy to do. Anybody can give their 'common" > test with usual result value (for example strength of specimen) and we > can compare this value from version to version. And it is good way to > check constitutive laws, geometry-modules etc. > > What do you think? > > Anton > > > > On Fri, Dec 3, 2010 at 8:26 PM, Bruno Chareyre > <bruno.chare...@hmg.inpg.fr <mailto:bruno.chare...@hmg.inpg.fr>> wrote: > > On 03/12/10 17:13, Václav Šmilauer wrote: > > Hi Anton, I am quite opposed to adding regression tests where the > result > > cannot be established analytically, because they don't indicate whether > > a failure is actually a "progression" or "regression". We discussed > that > > with Bruno, who does not agree, few months back already. v > >> As I understand TriaxialTest one of the most popular test in Yade. > >> Can anybody add a regression test for that? > > I see pros and cons. > > There is much implication on how yade is developped. > Currently, the situation when you work on someting, do other things > for a few days, then > update and find different behaviour when you resume coding is quite > common. Vaclav is > doing a lot to put warnings at compile- and run-time to help people > fix their code and > scripts. > But still, there are many ways for commiters to break someone-else's > work without notice. > With last changes in cohesive laws, all my scripts testing > cylinder-sphere-wall problems > were broken, if I had been away for a few days it would have taken > some time to figure out > why, because it concerns some code still in development, that didn't > work even before the > commit (not blaming Chiara, just mentionning the usefulness of the > corresponding reg. test). > > It explains a lot regarding why McGill FEM-DEM coupling, Feng-Chen's > CFD-DEM, Luc's > LBM-DEM are not in the trunk, and why so many users will never update. > If more people were putting a basic regression test corresponding to > what they are > developping, it would put more responsability on commiters, and it > would help to clearly > indentify what commit modified a given behaviour. > > OTOH, it is clear that (1) a change is not always a bad thing, and > that (2) global tests > can sometimes give false alarms. > > For (1), I think it is not really a difficult problem. For instance > : if I identify a > mistake in, lets say, Newton Integration, I can expect that all > "global" regression tests > using Newton will send warnings. I can even update the target values > in reg. tests before > commiting. I can't imagine a situation where someone would improve > something or fix a bug > that was affecting everybody, without realizing that it is really > affecting everybody. > Anyway, if someone fixes a bug that would have been affecting > triaxial test for so many > years, it should be notified to all TT users. > > For (2), it will happen. It happened, in fact, the first time > cohesive-chain test failed > (testing compiler-sensitive numerical noise). The second warning was > real though. Clearly, > one should think twice before defining target values and warning > threshold. > > Unit tests testing each small thing separately are very usefull. The > only problem is they > hardly identify 1% of the "oh god, why is it not like yesterday" > problems that makes the > daily life of yade users. > > My two cents. > > Bruno > > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > <https://launchpad.net/%7Eyade-dev> > Post to : yade-dev@lists.launchpad.net > <mailto:yade-dev@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~yade-dev > <https://launchpad.net/%7Eyade-dev> > More help : https://help.launchpad.net/ListHelp > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > Post to : yade-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp -- _______________ 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 : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
