Anton Gladky said: (by the date of Wed, 24 Sep 2014 20:13:21 +0200) > I have implemented it, but did not test it very well and do not use it > at the moment. We have a student now, which is trying to use/validate > Yade's SPH. So maybe it will be better validated.
About SPH maybe it would be wise to make a new class: class SPHBody: public Body; and put all SPH stuff there? That would remove this hack with #ifdef YADE_SPH and the same thing about #ifdef YADE_LIQMIGRATION and #ifdef YADE_MASK_ARBITRARY what is the last one by the way? It looks quite arbitrary to me ;) 1. I'm curious if you agree with this idea to make new derived classes? 2. if you agree, I could understand if you decide to do this kind of refactoring after debian jessie freeze. 3. On the same basis I made a new Body like this one: class QuantumMechanicalBody: public Body; However currently Body contains some DEM-only variables, so I think it would not hurt in the future to make generic Body class more empty, and move DEM stuff to DEMBody. 4. About naming - as far as I remember we tried to use longer names in yade in order to make stuff more easy to read. Also everyone has wide LCD screens and tab-completion. So there is no reason to try to make names shorter. So I propose those names: Body DiscreteElementBody QuantumMechanicalBody <WhatIsSPH>Body <WhatIsLIQ>Body did the conventions change along the years, or you agree with that? BTW, there were also a FEMBody and LatticeBody many years ago :) best regards -- Janek Kozicki http://janek.kozicki.pl/ | _______________________________________________ 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
