Re: [Yade-dev] SPH and DEM and QM :) in Yade,
On 29/09/14 18:42, Janek Kozicki wrote: Materials are shared. So this one is ok. Do you mean it would be ok to move Material::density to some derived class, or by ok you meant something else? The typical wasted memory in a simulation would be one double (if there is only one material defined). The situation is different with state, where you really waste memory proportionaly to the number of objects. Only problem could be if you define one independant material for each body. State::angMom, State::angVel, State::blockedDOFs, State::densityScaling, State::inertia, State::isDamped, State::mass, State::vel, State::inertia This is more a problem indeed. We should find a way to solve that without casts. I assume that by word casts you mean inheritance and derived classes ? I meant typecasting, i.e. if a more basic State class was introduced, then everywhere in the code: b-state-vel would have to be replaced by: YADE_CASTDEMState(b-state)-vel Same for inertia, mass, etc. Or did I miss something? As I said I can live with those extra attributes. They just waste memory, and do not hurt. I hope that I will come up with a solution that would be compatible with all currently written yade scripts. I was thinking about making StateEmpty right above State. But I don't know now if it would work. Maybe some of those attributes are used in some places that will make this approach not possible. We will see :) My feeling is that they are used in many places. It needs to be checked more precisely. Considering a typical list of engines now, which one would you keep for QM simulation? Probably not much. That's why I was thinking about using a different list of bodies, so DEM engines can keep working on O.bodies by assuming a list DEM bodies. And QM engines would have only what they need. Just an idea, there are maybe other options. Cheers. Bruno ___ 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 28/09/14 17:29, Janek Kozicki wrote: 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. To me it means a poor implementation of those, not a need to edit core/. 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. O.bodies is de facto composed of DEM objetcs (SPH is the unique exception and it is experimental, not sure we should use it as an exemple). Hence if non-DEM objects (and here I was anticipating that interactions between QM particles and newtonian particles would be nonsense, then not planned) are to be introduced they could as well go to O.QMbodies. I don't see it as a nice move to add some typecasting on State or Body for one single optional module. I am not big fan of renaming Body - DEMBody either. 99.99% of users use yade for DEM, we will not force them to type DEMBody, DEM is implicit. There are similar problems with Material, where I don't need Material::density, and with State where I don't need Materials are shared. So this one is ok. State::angMom, State::angVel, State::blockedDOFs, State::densityScaling, State::inertia, State::isDamped, State::mass, State::vel, State::inertia This is more a problem indeed. We should find a way to solve that without casts. Bruno ___ 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 Mon, 29 Sep 2014 11:29:20 +0200) On 28/09/14 17:29, Janek Kozicki wrote: 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. To me it means a poor implementation of those, not a need to edit core/. ok. So the should be moved. That will solve my problem. 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. O.bodies is de facto composed of DEM objetcs (SPH is the unique exception and it is experimental, not sure we should use it as an exemple). Hence if non-DEM objects are to be introduced they could as well go to O.QMbodies. Maybe you are right, but that will mean adding a new BodyContainer attribute to Scene. I think that doing this for the sole purpose of separating DEM and QM is a little superfluous. And then another attribute for QMInteractions? I think that current design works well. In fact exceptionally well, thanks to all those Functors 1D and 2D that handle all automatic dispatching, and thanks to Vaclav's hard work on polishing this approach with all those macros. If there is no functor to handle QM and DEM interaction - then it cannot occur. That's how it works currently, and I like it. However let's first see how it works, when I'm done implementing the first version. (and here I was anticipating that interactions between QM particles and newtonian particles would be nonsense, then not planned) that's mostly correct. There are some advanced multi-scale type simulations that calculate molecules insides (electrons) using quantum mechanics, and molecules outsides using classical mechanics (collisions between molecules). But I am not going in this direction. At least not for now. I don't see it as a nice move to add some typecasting on State or Body for one single optional module. I am not big fan of renaming Body - DEMBody either. 99.99% of users use yade for DEM, we will not force them to type DEMBody, DEM is implicit. About Body: You already said that those three (chain, SPH and LIQMIGRATION) are a poor implementation mistake. This makes me 100% happy and I withdraw my proposal to create DEMBody and QMBody. Instead I will help in cleaning Body class. So we are in full agreement here ;) About State and Material see below. There are similar problems with Material, where I don't need Material::density, and with State where I don't need Materials are shared. So this one is ok. Do you mean it would be ok to move Material::density to some derived class, or by ok you meant something else? State::angMom, State::angVel, State::blockedDOFs, State::densityScaling, State::inertia, State::isDamped, State::mass, State::vel, State::inertia This is more a problem indeed. We should find a way to solve that without casts. I assume that by word casts you mean inheritance and derived classes ? As I said I can live with those extra attributes. They just waste memory, and do not hurt. I hope that I will come up with a solution that would be compatible with all currently written yade scripts. I was thinking about making StateEmpty right above State. But I don't know now if it would work. Maybe some of those attributes are used in some places that will make this approach not possible. We will see :) 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
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
Re: [Yade-dev] SPH and DEM and QM :) in Yade,
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 -- 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
Re: [Yade-dev] SPH and DEM and QM :) in Yade,
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 _ At least for DEM, (whose meaning is surely known by each Yade user), I vote for DEMBody. At same clarity level, shorter names are better from my point of view. Maybe we can not assume that everyone has as good computer stuff (and can use it as well..) as you. For the idea of deriving new Body classes, I have no negative opinion (it won't hurt the python loops in BodyContainer, I guess ?) Jerome ___ 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,
Jerome Duriez said: (by the date of Fri, 26 Sep 2014 15:37:13 +) 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 _ At least for DEM, (whose meaning is surely known by each Yade user), I vote for DEMBody. At same clarity level, shorter names are better from my point of view. Maybe we can not assume that everyone has as good computer stuff (and can use it as well..) as you. I see your point. Also somehow I'm also inclined towards QMBody ... :) And historically we had FEMBody, not FiniteElementBody, I wonder why? For the idea of deriving new Body classes, I have no negative opinion (it won't hurt the python loops in BodyContainer, I guess ?) Don't worry it will work :) If not - I'll fix it ;) 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 ? I'm not hurrying towards all these changes. We have plenty of time so we can discuss :) 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
