RegressionsTests

From Yade

Revision as of 18:39, 15 August 2009 by Gladky.anton (talk | contribs) (Adding categories)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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)

Triaxial tests

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)

Comments

  • 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)


Python interface

This test would track (perhaps unintentional) interface changes in python. Additionally, it would watch results of a simple simulation. Points that should be covered:


  1. Basic wrappers: creating bodies from python, setting engines, timestep etc.
  2. Plotting module
  3. Packing module, including triaxial filling of a gts-defined solid, predicate operators etc.
  4. Timing module, getting runtime statistics about engines
  5. Wm3 module (try and verify some vector/quaternion calculations)
  6. Utils module: loading/saving python variables, labeling objects, interaction histograms
  7. yade-multi invocation (parametric studies etc)

--eudoxos 18:11, 28 July 2009 (UTC)