Re: [Yade-dev] SPH and DEM and QM :) in Yade,
Hi Janek, I think Anton is only experimenting at the moment, hence the hack. Ultimately, the additional data (density, pressure, etc) should go in some Body::State or Body::Material, or even Body::shape instead of Body:: directly. So I'm not sure it needs a new body class. For QMBody, which are the variables you don't need? Another question is, do QMBody's have to be in O.bodies? It should be the case only if the QM particles are supposed to interact with DEM things. Cheers. Bruno On 26/09/14 16:42, Janek Kozicki wrote: 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 WhatIsSPHBody WhatIsLIQBody 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 -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ 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
Re: [Yade-dev] SPH and DEM and QM :) in Yade,
On 26/09/14 17:59, Janek Kozicki wrote: Also - Bruno, Francois, I think that your ChainedCylinder which uses variable Body-chain should also use its own type of Body, for the purpose of adding this `chain` attribute. Maybe call it DEMChainedBody ? Body is not the right place for chain number. It should go to body-state. Actually ChainedCylinder is deprecated and will be removed at some point, then chain will disappear. :) Bruno -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ 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
Re: [Yade-dev] SPH and DEM and QM :) in Yade,
Bruno Chareyre said: (by the date of Sun, 28 Sep 2014 12:19:37 +0200) I think Anton is only experimenting at the moment, hence the hack. Ultimately, the additional data (density, pressure, etc) should go in some Body::State or Body::Material, or even Body::shape instead of Body:: directly. So I'm not sure it needs a new body class. ok For QMBody, which are the variables you don't need? Body::chain, Body::clumpId, Body::flags though I can live with them :) And the latter two might indeed come handy later... we will see. I only raised this because I think that adding new packages should not require editing the stuff in core/ directory. Which is the case with chain, SPH and LIQMIGRATION. Another question is, do QMBody's have to be in O.bodies? definitely, that's where the particles that are part of the simulation are stored. Besides, where else would you put them? :) It should be the case only if the QM particles are supposed to interact with DEM things. It should be the case only if O.bodies are supposed to interact with other O.bodies. If there will be a functor that will handle DEM and QM interaction it will work. Though I do not plan at first to write a functor for this. For start I am working first only on the basic fundamental things covered by basic nonrelativistic quantum mechanics, i.e. the Schrodinger equation. And later move to relativistic case. The object oriented architecture, which I designed, is definitely good for quantum mechanics. If we encounter any problems that will be only due to some misunderstandings :) So let's be patient and talk about it. There are similar problems with Material, where I don't need Material::density, and with State where I don't need State::angMom, State::angVel, State::blockedDOFs, State::densityScaling, State::inertia, State::isDamped, State::mass, State::vel, State::inertia now you conclude that QM particle is not a DEM particle, and you start to understand :) For example until the discovery of Higgs boson the State::mass was a huge mystery in quantum physics. But I am not that advanced yet to implement Higgs boson. Same about inertia. Sure, sometimes mass appears in QM, but not always. As another example State::angMom id different because in quantum mechanics angular momentum is quantized (surprise!), and it is not a property of the most basic quantum particle, it appears only in the more advanced ones, so State::angMom would appear in the future in some derived class. I am thinking that maybe a class above State, called StateEmpty could fix this, or maybe rename State to ClassicalState. But I really don't want a revolution here, I can live with those attributes for now. (temporarily I only implemented qtHide attribute to hide them in 'inspect'). Now I am more focused on implementing the main things, writing documentation and getting it all to work :) 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
