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 offabricTensor()[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
<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
<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
Unsubscribe :https://launchpad.net/~yade-dev
More help :https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
