yade-dev team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

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/  |