Regression tests discussion & specification
- Results that are checked for accuracy should stored in some nice format (say, pickled python dictionary)
- Results that are 100% predictable should have the results hardcoded in the test script
- Using the python's standard unittest module looks like a good idea (takes care of running the tests, reports and so on)
The triaxial test is a complex simulation. It is probably necessary to have also simpler tests with only two bodies to test contact laws for instance. The interest of triaxial-testing e.g. ElasticContactLaw (or viscousLaw, or CohesiveFrictionalLaw, but perhaps not all of them) is that it is a hard test. One test could be to generate an initial loose packing from a txt file (200 spheres is enough) and run the compaction until a prescribed state is reached (better than keeping an xml, which could become incompatible at a point). Then use the generated "compacted.xml" to run a triaxial compression on it.
The timestep could be automaticaly computed or not (the automatic way would let us check that there is no problem with timestep initialisation/serialization).
Points for comparison :
A. Compaction :
1. Number of iterations to get the compacted state.
2. Compacted porosity.
B. Triaxial Compression :
3. Peak stress.
For point 3 :
peak stress is exactly the same -> regression test succeeded
difference is less than X -> give a warning (something has changed somewhere, perhaps for good)
difference is more than X -> regression test failed.
I suggest X = 0.5%-1% (the difference between the incremental and total formulations for shear force is around 1% at peak)
The same mechanics apply for Compacted porosity. Number of iteration in 1) should be exactly the same.
Such test would succeed ONLY IF : timestep definition, contactGeometry, contactLaw, the Triaxial* classes, saving/loading, time integration scheme, and probably more, are unaffected. Which is almost all Yade.
Bchareyre 08:04, 6 July 2009 (UTC)
- Can you define the test in a more algorithmic way? E.g. I have no idea how to get peak stress from triaxial test. --eudoxos 18:11, 28 July 2009 (UTC)
This test would track (perhaps unintentional) interface changes in python. Additionally, it would watch results of a simple simulation. Points that should be covered:
- Basic wrappers: creating bodies from python, setting engines, timestep etc.
- Plotting module
- Packing module, including triaxial filling of a gts-defined solid, predicate operators etc.
- Timing module, getting runtime statistics about engines
- Wm3 module (try and verify some vector/quaternion calculations)
- Utils module: loading/saving python variables, labeling objects, interaction histograms
- yade-multi invocation (parametric studies etc)
--eudoxos 18:11, 28 July 2009 (UTC)