subject:"Re\: \[Yade\-dev\] \[Branch \~yade\-pkg\/yade\/git\-trunk\] Rev 3874\: fabricTensor\(\)\: unify the behavior regarding boundary interactions whether split=0 or 1"

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

2016-06-09 Thread Bruno Chareyre


Thanks!
you are right on the cutoff thing. It can be improved on this side.
Bruno

On 06/08/2016 11:24 PM, Jerome Duriez wrote:


I just replaced the sphere test by such a cutoff criterion, see the 
corresponding commit [1]. (I also merged two loops in the function, in 
addition to other details)



It turns out the cutoff criterion is in the end still related with 
bodies shapes since such cutoff things always (in other functions, and 
I kept the same method here) enter into picture through 
aabbExtrema(cutoff), which computes the extrema of spheres packings 
only: see [2].



So, I'm not sure how fabricTensor() would behave with a packing of 
cylinders (and has someone ever tried such thing before any of "my" 
changes ?...)




Let me know,


Jerome


[1] 
:https://github.com/yade/trunk/commit/17b629d9c545033514a63694f8bc5e8a8d04c5ab



[2]: https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L690




<https://github.com/yade/trunk/commit/17b629d9c545033514a63694f8bc5e8a8d04c5ab>

<https://github.com/yade/trunk/commit/17b629d9c545033514a63694f8bc5e8a8d04c5ab>

fabricTensor(): re introducing all kind of interactions in the loop, … 
· yade/trunk@17b629d 
<https://github.com/yade/trunk/commit/17b629d9c545033514a63694f8bc5e8a8d04c5ab>

github.com
…with the new possibility defining a cutoff. See 
http://www.mail-archive.com/yade-dev@lists.launchpad.net/msg11982.html





--

Jerome Duriez, Research Associate

University of Calgary, Dpt of Civil Engineering

+1 403 220 7367




*From:* Yade-dev 
<yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net> on 
behalf of Bruno Chareyre <bruno.chare...@grenoble-inp.fr>

*Sent:* June-08-16 7:15 AM
*To:* yade-dev@lists.launchpad.net
*Subject:* Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: 
fabricTensor(): unify the behavior regarding boundary interactions 
whether split=0 or 1
Filtering out boundary effects can be done using the same method as in 
[1].
The "cutoff" criterion is purely geometric, it works independently of 
shapes.

Bruno

[1] 
https://yade-dem.org/doc/yade.utils.html#yade.utils.plotNumInteractionsHistogram


On 06/07/2016 05:43 PM, Jerome Duriez wrote:


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...@lists.launchpad.net> on 
behalf of Bruno Chareyre <bruno.chare...@grenoble-inp.fr>

*Sent:* June-07-16 2:55 AM
*To:* yade-dev@lists.launchpad.net
*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@lists.launchpad.net/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 disreg

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

2016-06-08 Thread Jerome Duriez

I just replaced the sphere test by such a cutoff criterion, see the 
corresponding commit [1]. (I also merged two loops in the function, in addition 
to other details)


It turns out the cutoff criterion is in the end still related with bodies 
shapes since such cutoff things always (in other functions, and I kept the same 
method here) enter into picture through aabbExtrema(cutoff), which computes the 
extrema of spheres packings only: see [2].


So, I'm not sure how fabricTensor() would behave with a packing of cylinders 
(and has someone ever tried such thing before any of "my" changes ?...)



Let me know,


Jerome


[1] 
:https://github.com/yade/trunk/commit/17b629d9c545033514a63694f8bc5e8a8d04c5ab


[2]: https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L690



<https://github.com/yade/trunk/commit/17b629d9c545033514a63694f8bc5e8a8d04c5ab>
<https://github.com/yade/trunk/commit/17b629d9c545033514a63694f8bc5e8a8d04c5ab>

[https://avatars1.githubusercontent.com/u/5427081?v=3=200]<https://github.com/yade/trunk/commit/17b629d9c545033514a63694f8bc5e8a8d04c5ab>

fabricTensor(): re introducing all kind of interactions in the loop, … · 
yade/trunk@17b629d<https://github.com/yade/trunk/commit/17b629d9c545033514a63694f8bc5e8a8d04c5ab>
github.com
…with the new possibility defining a cutoff. See 
http://www.mail-archive.com/yade-dev@lists.launchpad.net/msg11982.html





--

Jerome Duriez, Research Associate

University of Calgary, Dpt of Civil Engineering

+1 403 220 7367



From: Yade-dev <yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net> 
on behalf of Bruno Chareyre <bruno.chare...@grenoble-inp.fr>
Sent: June-08-16 7:15 AM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: 
fabricTensor(): unify the behavior regarding boundary interactions whether 
split=0 or 1

Filtering out boundary effects can be done using the same method as in [1].
The "cutoff" criterion is purely geometric, it works independently of shapes.
Bruno

[1] 
https://yade-dem.org/doc/yade.utils.html#yade.utils.plotNumInteractionsHistogram

On 06/07/2016 05:43 PM, Jerome Duriez wrote:

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...@lists.launchpad.net><mailto:yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net>
 on behalf of Bruno Chareyre 
<bruno.chare...@grenoble-inp.fr><mailto:bruno.chare...@grenoble-inp.fr>
Sent: June-07-16 2:55 AM
To: yade-dev@lists.launchpad.net<mailto:yade-dev@lists.launchpad.net>
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@lists.launchpad.net/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

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

2016-06-08 Thread Bruno Chareyre


Filtering out boundary effects can be done using the same method as in [1].
The "cutoff" criterion is purely geometric, it works independently of 
shapes.

Bruno

[1] 
https://yade-dem.org/doc/yade.utils.html#yade.utils.plotNumInteractionsHistogram


On 06/07/2016 05:43 PM, Jerome Duriez wrote:


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...@lists.launchpad.net> on 
behalf of Bruno Chareyre <bruno.chare...@grenoble-inp.fr>

*Sent:* June-07-16 2:55 AM
*To:* yade-dev@lists.launchpad.net
*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@lists.launchpad.net/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@lists.launchpad.net
Unsubscribe :https://launchpad.

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

2016-06-07 Thread Jerome Duriez

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...@lists.launchpad.net> 
on behalf of Bruno Chareyre <bruno.chare...@grenoble-inp.fr>
Sent: June-07-16 2:55 AM
To: yade-dev@lists.launchpad.net
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@lists.launchpad.net/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@lists.launchpad.net<mailto:yade-dev@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp


___
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] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

2016-06-07 Thread Bruno Chareyre


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@lists.launchpad.net/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/e063ea12479a56f85ca456aef8f52be19cbed84d




fabricTensor(): unify the behavior regarding boundary interactions wh… 
· yade/trunk@e063ea1 


github.com
…ether split=0 or 1: they are now disregarded in both cases




fabricTensor() now ok for non-periodic simulations. revertSign attrib… 
· yade/trunk@562d4c9 


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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp


___
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] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

2016-06-06 Thread Jerome Duriez

I'm replying to 
http://www.mail-archive.com/yade-dev@lists.launchpad.net/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/e063ea12479a56f85ca456aef8f52be19cbed84d

[https://avatars1.githubusercontent.com/u/5427081?v=3=200]

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



[https://avatars1.githubusercontent.com/u/5427081?v=3=200]

fabricTensor() now ok for non-periodic simulations. revertSign attrib... · 
yade/trunk@562d4c9
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1: they are...

2016-05-30 Thread Bruno Chareyre




On 05/27/2016 05:22 AM, nore...@launchpad.net wrote:


revno: 3874
committer: jduriez 


=== modified file 'pkg/dem/Shop_02.cpp'
+   if( !dynamic_cast(Body::byId(I->getId1(),scene)->shape.get()) || 
!dynamic_cast(Body::byId(I->getId2(),scene)->shape.get()) ) continue; // test intended to +  if( 
!dynamic_cast(Body::byId(I->getId1(),scene)->shape.get()) || 
!dynamic_cast(Body::byId(I->getId2(),scene)->shape.get()) ) continue; // test intended to disregard 
boundary interactions (in non-periodic simulations)


Hi Jérôme,
A problem I see is you made of fabricTensor() something which will work 
only for spheres while it was working perfectly for every possible shape 
before the above change.
I don't understand the relation between the "split" parameter and this 
change.

Could you please explain?

Besides, small tips on coding: better use getClassIndex() to check 
types, not plain cast<>'s (I know casts still appear here and there but 
we should certainly not introduce more of them).


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] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1: they are...

7 matches

Site Navigation

Mail list logo

Footer information