yade-dev team mailing list archive

[Jerome Duriez <Jerome.Duriez@xxxxxxxxxxx>]

Ok, I have no particular objection to reintroduce non spherical objects in the loop.

I had a little concern regarding boundary interactions, but I can live with it if I'm the only one, especially if there is no perfect method to disregard such interactions without breaking someone else's habits.


In the end, do we agree we keep all the interactions in the loop ?


Jerome

________________________________
From: Yade-dev <yade-dev-bounces+jerome.duriez=ucalgary.ca@xxxxxxxxxxxxxxxxxxx> on behalf of Bruno Chareyre <bruno.chareyre@xxxxxxxxxxxxxxx>
Sent: June-07-16 2:55 AM
To: yade-dev@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

In [1] it was a good move to remove the periodic barrier.
Filtering spheres is another independent question and I don't see a clear reason for that (testing isDynamic was maybe a bit hacky but less restrictive finally).
Making split=0 and split=1 return the same thing [2] sounds good, but the problem was to filter spheres with split=0 in the first place [1].
Before, it was possible to get fabric in a periodic packing of cylinders for instance. Now it is not. Not a progress overall.

What is the problem if non spherical objects are kept in the loop? We should solve this problem without regression.

Bruno


On 06/06/2016 10:47 PM, Jerome Duriez wrote:

I'm replying to http://www.mail-archive.com/yade-dev@xxxxxxxxxxxxxxxxxxx/msg11970.html (sorry to break the thread, but there has been a major email shutdown at my university last week, and I just discover now this message, browsing the archives)


So, in fact I started to introduce such kind of spherical shape-test in a previous commit [1], where I let fabricTensor() accept non-periodic simulations (before this first commit [1], fabricTensor() crashed in such non-periodic cases).


At that time, this shape test was intended to let fabricTensor() disregard any boundary effects, by comparison with the previous behavior restricted to periodic simulations.



However, I introduced in [1] this shape test only in the main workflow of fabricTensor() code, which has a role when split = 0 (default). For the special case split=1, other lines of code do the job, where I did not introduce any shape test.


Then, considering classical dry simulations (with interactions at geometrical contact only) of spherical packings loaded by plates, you may get slightly different results between

- fabricTensor()[0] that disregards boundary interactions

- and fabricTensor(splitTensor = 1,thresholdForce =0)[0] that included boundary interactions

Even though, both should apply to the same contact interactions network, from my point of view



This second commit [2] aimed thus to correct this mistake, introducing the shape test in the "split=1 code part" as well, and reconciling the two results of fabricTensor()[0] and fabricTensor(splitTensor = 1,thresholdForce =0)[0] for such classical dry simulations.



As you see, all this arises from my current point of view that non-spherical bodies are always used as boundary elements in non-periodic simulations. I can introduce changes (in addition to the ClassIndex suggestion, thanks) if you think other behaviors are required / meaningfull



[1] https://github.com/yade/trunk/commit/562d4c952f4b7f67a88ed954caa20b68a041e207

[2] <https://github.com/yade/trunk/commit/562d4c952f4b7f67a88ed954caa20b68a041e207> https://github.com/yade/trunk/commit/e063ea12479a56f85ca456aef8f52be19cbed84d

[X]<https://github.com/yade/trunk/commit/e063ea12479a56f85ca456aef8f52be19cbed84d>

fabricTensor(): unify the behavior regarding boundary interactions wh... · yade/trunk@e063ea1<https://github.com/yade/trunk/commit/e063ea12479a56f85ca456aef8f52be19cbed84d>
github.com
...ether split=0 or 1: they are now disregarded in both cases


[X]<https://github.com/yade/trunk/commit/562d4c952f4b7f67a88ed954caa20b68a041e207>

fabricTensor() now ok for non-periodic simulations. revertSign attrib... · yade/trunk@562d4c9<https://github.com/yade/trunk/commit/562d4c952f4b7f67a88ed954caa20b68a041e207>
github.com
...ute removed as well




--------------------------------------------------

Jerome Duriez, Research Associate

University of Calgary, Dpt of Civil Engineering

+1 403 220 7367



_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx<mailto:yade-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp