Development schedule

Use https://blueprints.launchpad.net/yade/ for development tracking, not this page

Obsolete

1. automatic regression testing from cronjob, and upload results to wikia. Also automatically upload new dosxygen docs.
2. change all class names, as they appear in the CMAME article, Future plans
   1. modify yade::serialization to understand both old and new names during serialization (if everyone agrees that it's necessary)
3. add boost::serialization, don't remove yade serialization (becomes deprecated, be removed later)
4. about two week regression testing if nothing got broken with respect to simulation results.
5. remove yade ClassFactory and use boost counterpart (I got to check which one we need here: boost::extension, or class factory provided with boost::serialization)
   1. boost::extension (see documentation) is not yet formal part of boost, there will be a review this year, and I guess it will be released with 1.35:

      svn checkout http://svn.boost.org/svn/boost/sandbox/libs/extension svn checkout

      http://svn.boost.org/svn/boost/sandbox/boost/extension

   2. because boost::extension is not yet in boost, the boost::serialization has to use it's own micro-factory - because otherwise it would be impossible to instatinate classes during deserialization. And I know that this micro-factory works well with plugins (*.dll and *.so). So I got to check if it's enough for our needs, or whether we need boost::extension.
6. again two weeks of regression testing
7. remove remaining singletons, prepare grounds for real unit tests. (they work only without singletons). Learn boost::test, and start writing unit tests for every classes - will take a long time...
8. change the container layout to use boost::multi_index, drop BodyContainer and InterctionContainer. Look at this thread with words "good example" in the subject. This is a major change, and it is pending for quite a long time.
9. with container problems solved, we can now implament a correct version of collision detection, that works well with adding and removing bodies during simulation.

Smaller stuff

which should go in parallel, but not restricted to go somewhere between one thing and other thing.

1. investigate if my QT4-serialization applet works well with boost::serialization. Fix if it isn't. Then we have a GUI that can communicate with boost::serialization and we can drop REGISTER_ATTRIBUTE altogether.
2. Start slow switch to QT4, by writing a new simple QT4 gui. When it becomes usable the old gui will become depraceted. Removal of yade::serialization equals to removal of QT3 GUI.
3. finally separate BodyState from BodyConstitutiveParameters
4. Write documentation (when?, I dunno, we got a lot of work here :-P )
5. Perhaps implement a "serialization on demand" interface. It uses boost::serialization, and can be used to check values when their name is given. The name is provided using syntax similar to directory/file. So you would ask gimmie("SomeClass/SomeMember/torsionalStiffness"); and get the answer - the value. That could be later used for tracking variables maybe obtaining simulation results, and debugging.
6. implement some simple parallelization on single multi-core computer (shared memory), using boost::threads. Easy to do even now - just divide a container into several parts, and process each part on different CPU.
7. stop using yade::MultiMethods. Use a similar library from boost (that's a too complicated library to be part of yade, it should be outside)
   1. check if there is a similar library in boost (gotta look at the boost mailing list archives), if there is one, then start using it
   2. if there isn't any in boost, then clean our MultiMethods, boostify them and submit to become part of boost.
   3. In either way we will be using MultiMethods from boost ;-D
8. Use boost::units compilation time unit checking. Also not yet in boost, but already after a review (and accepted), so will be in a release pretty soon.

   svn checkout http://svn.boost.org/svn/boost/sandbox/units

9. if boost::logging will get accepted (currently during review), use it instead of logcxx, http://torjo.com/log2/doc/html/ and http://torjo.com/code/log2.zip
10. add other collistion detection methods, just for fun - like grid collider or parallelized collider
11. add other time integration algorithm, like runge kutta 4, which is waiting on my HDD to be adapted and added to sources.

Things to consider

1. use static variable for class index, assigned by YADE_PLUGIN, but check if it gives ANY speed up. I'm not entirely sure that it will.
2. use raw pointers instead of boost::shared_ptr (requires careful programming to avoid leaks!) Can speed things up considerably.
3. does boost::multi_index allow accessing by integer index interactions[i]; ?
4. callbacks : why we want outside loops.
   1. For example if we want to get a max velocity from all bodies, we can do this without another loop on all bodies - inherit from integrator, declare virtual function, call the function from the base class which does the usual job, and add one extra line which calculates max velocity. This is possible only because EngineFunctors have the loop outside.
   2. This is not possible to calculate the average contact force or average force on body, because the engines which do this (calculate force) have the loop inside. So currently to calculate average contact force and average force on body another extra loop on all bodies must be done! But if calculation of force had the loop outside - we would avoid extra loop. And the mechanism on of inheriting to perform this would be much simpler - as in the example above.
5. It is possible to parallelize SAPCollider on 3 processors - sorting the list independently in X, Y and Z directions.
6. boost::minmax library may speed up bounding volume calculations, nearly twice.
7. more diversity in /pkg/ directory. Because people tend to add, like 10 or 20 classes to achieve something specific: snow simulations, polyhedron collisions, capillary law, example of adding a custom element (MyTetrahedron) etc. How about making a directory for each of those achieved "tasks" ?

Voting: what to fix?

Please write here what things are most annoying in yade and should be fixed. We are going to vote on that later. Please sign each idea with your name, typing four tildas: ~~~~ will automatically put your name there.

• consistent coding style (when all files look similar, they are easier to navigate), I opt for a style guide for this. Janek Kozicki 00:22, 10 March 2008 (UTC)

• consistent naming of variables (same reason), I opt for a naming guide. Janek Kozicki 00:22, 10 March 2008 (UTC)

• go through the code and inline many methods that can be inlined. Janek Kozicki 02:33, 10 March 2008 (UTC)

• correctly indent all the files using tabs. Tabs are disallowed after any non-tab character on line. Janek Kozicki 02:33, 10 March 2008 (UTC)

• [DONE in r1678] Remove persistentInteractions and collapse them into what is not transientInteractions. Figure out how interactins work: who deletes them (not collider, though, since we do want distant interactions), rename the confusing "isReal" flag, adapt sample fileGenerators to work with that and document it well. eudoxos 20:07, 10 March 2008 (UTC)

• [DONE] Move dt and everything else which concerns simulation in the proper sense from Omega to rootBody. eudoxos 20:07, 10 March 2008 (UTC)

• [PROGRESS] Make inheritance among classes that duplicate lot of variables: SDECLinkPhysics and ElasticContactInteraction, for example. eudoxos 20:07, 10 March 2008 (UTC)

• [DONE] Make BOOST_FOREACH macro work with containers (to avoid ugly for loops we have now). eudoxos 20:07, 10 March 2008 (UTC)

• Prepare good regression tests and run them periodically. eudoxos 20:07, 10 March 2008 (UTC)

• [DONE] Actively use bugtracker. eudoxos 20:07, 10 March 2008 (UTC)

• [DONE] Implement a method to remove bodies from simulations (and also interactions with these bodies) Bruno 12:49, 11 March 2008 (UTC)