Re: [Yade-dev] Yade vs. war in Ukraine

[Jerome Duriez]

Hi everyone,

I agree with the idea. In case YADE could be an example for peace, we 
could even recall the present and past contributions by both Russian 
(sega, if I'm correct) and Ukrainian (Anton, for sure) colleagues.


Best

--
Chargé de Recherche / Research Associate
INRAE, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 03/03/2022 18:16, Bruno Chareyre wrote:

Hi guys,

My heart is broken since the beginning of that war on Ukraine.
I believe international cooperation is one of our value in the Yade 
community.


If you agree we could include a statement on the website in support of 
peace, like other scientific communities did [1].


Regards

Bruno

[1] 
https://www.interpore.org/index.php?page=acymailing_front=archive=view=120=559-kfFKWJJ3zkJa0l=1=1 




___
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] Submitting Yade to an "Open Software" prize (FYI)

[Jerome Duriez]

Hi guys,

Good news, I'm willing to join.

Best,

--
Chargé de Recherche / Research Associate
INRAE, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 25/10/2021 12:27, Bruno Chareyre wrote:

Hi Devs,

For your information, I will submit yade to a french "Open Science and 
Open Source Software Prize" that was opened recently.

I've been invited to to so by local colleagues from Gricad (HPC people).
The procedure is described here [1] (only in french unfortunately - the 
"english" button is only a broader overview).


I didn't go through the whole documents but the various prizes are: 
"science/technology", "community", "documentation", "all criteria together".

Deadline early December.
I'll try and circulate a preliminary document here for possible review.
If you want to be involved directly let me know.
Bruno


[1] 
https://www.ouvrirlascience.fr/ouverture-des-candidatures-du-prix-science-ouverte-du-logiciel-libre-de-la-recherche/

--


___
Bruno Chareyre
Associate Professor
3SR lab., ENSE³, Grenoble INP
Tél : +33 4 56 52 86 21


Email too brief?
Here's why: email charter 
<https://marcuselliott.co.uk/wp-content/uploads/2017/04/emailCharter.jpg>






___
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] Dev meeting next week

[Jerome Duriez]

Hi guys,

I plan to join (on July 21, I guess ;-) ), thank you Bruno.

Jérôme

--
Chargé de Recherche / Research Associate
INRAE, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 15/07/2021 11:13, Bruno Chareyre wrote:

Dear Yade devs,
For a few months now some of us started holding meetings to discuss dev 
aspects.
We figured it would be good to gather more of the devs in these 
meetings, so if you are interested and available you are welcome to join 
next meeting.

It will be on Wednesday next week, June 21th, at 11:00 EU time.

Please reply in this thread if you plan to join so we can send you the 
zoom link.


Cheers

Bruno



--


___
Bruno Chareyre
Associate Professor
3SR lab., ENSE³, Grenoble INP
Tél : +33 4 56 52 86 21


Email too brief?
Here's why: email charter 
<https://marcuselliott.co.uk/wp-content/uploads/2017/04/emailCharter.jpg>






___
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] Introducing Yade discord beta

[Jerome Duriez]

Hi,

I think that's a great idea, thank you Robert. I have not dared yet 
going through the creation of a new account (on Discord) though, would 
it be possible by chance to have something merged with Gitlab (and our 
accounts therein) ?


There seems to be like Gitlab-Slack or Gitlab-Mattermost [*] things. The 
latter seems to be available with our current Gitlab sign-in [**].




[*] https://docs.gitlab.com/omnibus/gitlab-mattermost/
[**] https://gitlab.com/gitlab-org/gitlab-mattermost#gitlab-mattermost


--
Chargé de Recherche / Research Associate
INRAE, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 06/05/2021 19:55, Robert Caulk wrote:

Hey Yade devs,

A few of us were discussing the *idea of encouraging more collaboration* 
among Yade devs and the idea came up to create a central server for 
chatting about various topics and exchanging ideas.


Discord seems to be a good candidate for this since we can organize the 
server into various topics (i.e. resources, polyhedra, fluid-couplings, 
geomechanics etc.) Also, we don't need to install any software to join 
and chat (there is a browser-based version)


*The goal of this discord* server is to bring yade devs and users 
together in one place to chat freely and openly. If we are lucky, some 
collaborations will pop up, if we are unlucky it may just become a 
landing spot for new users.


Before we open it to the public, I'd like to invite you yade devs to the 
"beta" server.  Come on over and say hey, start testing it out, and 
provide feedback. If you have any suggestions for the 
layout/organization, please let me know, and I will make sure to 
incorporate your recommendations.


So, see you over at the yade discord server:

https://discord.gg/kkZ4c3nQtV

Cheers,

Robert







___
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] Post Doc position particles' shape

[Jerome Duriez]

Dear Yade devs,

Attachment finally is at 
https://stratus.irstea.fr/f/5ef9fde069f24c35ba66/?dl=1 ...


(Not sure it was my mistake here or some Launchpad feature -- 
https://bugs.launchpad.net/launchpad/+bug/244673 ?)



Sorry again,

Jérôme


On 02/12/2020 09:34, Jerome Duriez wrote:

Dear Yade users and developers,

There is a 18 months post doc position in Aix-en-Provence (France) to 
work with me on https://yade-dem.org/doc/yade.wrapper.html#shape (maybe 
not all of them).


Please find all details in the attachment and feel free to forward to 
your colleague(s).


Best regards,

Jérôme Duriez
--
Chargé de Recherche / Research Associate
INRAE, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez 



___
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

[Yade-dev] Post Doc position particles' shape

[Jerome Duriez]

Dear Yade users and developers,

There is a 18 months post doc position in Aix-en-Provence (France) to 
work with me on https://yade-dem.org/doc/yade.wrapper.html#shape (maybe 
not all of them).


Please find all details in the attachment and feel free to forward to 
your colleague(s).


Best regards,

Jérôme Duriez
--
Chargé de Recherche / Research Associate
INRAE, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez
___
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] New Yade version, beginning of January 2021

[Jerome Duriez]

Dear all,

Sorry for the inconvenience but is there any flexibility in that schedule ?

I have been working on a new Shape child and I may get closer to the 
endpoint of my work in the form of a merge request.


It now represents "32 files changed, 2193 insertions(+), 178 
deletions(-)" since 2020.01(a ?) = commit 9964f5.



In case there is some flexibility in the schedule and if I'm not the 
only one interested in that flexibility (MPI maybe ?..), maybe we could 
discuss inclusion of that Shape child in the new release ?


If not, let it be, I would totally understand to miss that train.


Jérôme

--
Chargé de Recherche / Research Associate
INRAE, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 12/11/2020 22:18, Anton Gladky wrote:

Dear Yade users and developers,

As always at the beginning of January I am planning to prepare
a release of a new Yade version.

Please try to push your changes inyo the code at least till the mid
of December, so we will have enough time to test it on different
platforms during the Christmas period and release it on time.
Also please try not to push too much breaking changes at that
period..

The new Debian Bullseye release is scheduled already [1]. So we
should not be too late to prepare a new Yade for the next stable
Debian version.

Also it would be good to prepare short but meaningful release notes.
Current git-workflow has too many small log-messages, so it is
difficult to get meaningful information from there. Please use this
link to add some notes [2].

[1] https://wiki.debian.org/DebianBullseye
[2] https://pad.systemli.org/p/yade-2021-release-notes

Thank you

Anton Gladky

___
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] GitLab repo archives

[Jerome Duriez]

Indeed...

https://gitlab.com/yade-dev/trunk/-/archive/2020.01a/trunk-2020.01a.tar.gz 
does work..


(I had the "a" in my notes for the Launchpad URL but not for GitLab, do 
not know why.. And I could not re-find 
https://gitlab.com/yade-dev/trunk/-/tags with all the links earlier..)


Thanks !

--
Chargé de Recherche / Research Associate
INRAE, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 15/10/2020 15:28, Bruno Chareyre wrote:

Hi Jérôme,
Isn't it "2020.01*_a_*"?
B

On 15/10/2020 10:24, Jerome Duriez wrote:

Hi,

I think the following URL used to exist:

https://gitlab.com/yade-dev/trunk/-/archive/2020.01/trunk-2020.01.tar.gz

giving a GitLab access to releases (somewhat duplicating Launchpad, 
but I like maybe more our GitLab use than our Launchpad one)


That URL does not seem to exist anymore.


Do you confirm my observations ? Was that on purpose ?

Jérôme
--
Chargé de Recherche / Research Associate
INRAE, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez 



___
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

[Yade-dev] GitLab repo archives

[Jerome Duriez]

Hi,

I think the following URL used to exist:

https://gitlab.com/yade-dev/trunk/-/archive/2020.01/trunk-2020.01.tar.gz

giving a GitLab access to releases (somewhat duplicating Launchpad, but 
I like maybe more our GitLab use than our Launchpad one)


That URL does not seem to exist anymore.


Do you confirm my observations ? Was that on purpose ?

Jérôme
--
Chargé de Recherche / Research Associate
INRAE, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

___
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] Wiki FAQ

[Jerome Duriez]

https://www.yade-dem.org/wiki/FAQ#I_would_like_to_add_a_new_page_to_YADE_wiki._How_can_I_do_it.3F

--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 22/07/2020 11:03, Bruno Chareyre wrote:

Thanks.
I would keep that one too (even for myself):
=== I would like to add a new page to YADE wiki. How can I do it? ===
B



On Wed, 22 Jul 2020 at 09:22, Jerome Duriez <mailto:jerome.dur...@inrae.fr>> wrote:


See

https://www.yade-dem.org/w/index.php?title=FAQ=revision=1920=1332

Thanks for feedback

--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 21/07/2020 16:00, Jan Stránský wrote:
 > I also would not entirely delete the page / content.
 >
 >     maybe they should go somewhere else, but where?
 >
 >
 > one option is to put them to the source code in the .rst format and
 > create a new "main page link" similar to tutorial
 >
 > cheers
 > Jan
 >
 >
 >
 > út 21. 7. 2020 v 15:45 odesílatel Bruno Chareyre
 > mailto:bruno.chare...@3sr-grenoble.fr>
<mailto:bruno.chare...@3sr-grenoble.fr
<mailto:bruno.chare...@3sr-grenoble.fr>>>
 > napsal:
 >
 >     Hi,
 >     This page is indeed rather old. I would suggest to remove all the
 >     content that is irrelevant/obsolete, about Scons and stuff
and see
 >     what remains.
 >     Because there are a couple valid points, maybe they should go
 >     somewhere else, but where?
 >     - What is "Young" and "Poisson" in ElastMat material?
 >     - I want to get 2 plots, how can I do it?
 >     - Is it possible to make another color of the background from
python
 >     script?
 >     B
 >
 >
 >     On Tue, 21 Jul 2020 at 13:56, Jerome Duriez
mailto:jerome.dur...@inrae.fr>
 >     <mailto:jerome.dur...@inrae.fr
<mailto:jerome.dur...@inrae.fr>>> wrote:
 >
 >         Hi everyone,
 >
 >         This question [*] made me wander on
 > https://www.yade-dem.org/wiki/FAQ.
 >
 >         A nice place to remember old ages with mentions about bzr,
 >         scons, .. but
 >         maybe not really useful to any new user and, as it
appears, maybe
 >         impossible to maintain..
 >
 >         I'm thus proposing to remove this page from the wiki :-)
 >         (since I'll not propose here to remove the wiki ;-) )
 >
 >         Thoughts ?
 >
 >
 >         Jérôme
 >
 >         [*] https://answers.launchpad.net/yade/+question/691986
 >         But it seems this is not on that FAQ the OP found a
github URL
 >         --
 >         Chargé de Recherche / Research Associate
 >         Inrae, RECOVER
 >         3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex
5 FRANCE
 >         +33 (0)4 42 66 99 21
 >

https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez
 >
 >         ___
 >         Mailing list: https://launchpad.net/~yade-dev
 >         Post to     : yade-dev@lists.launchpad.net
<mailto:yade-dev@lists.launchpad.net>
 >         <mailto: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
<mailto:yade-dev@lists.launchpad.net>
 >     <mailto: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
<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] Wiki FAQ

[Jerome Duriez]

See 
https://www.yade-dem.org/w/index.php?title=FAQ=revision=1920=1332


Thanks for feedback

--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 21/07/2020 16:00, Jan Stránský wrote:

I also would not entirely delete the page / content.

maybe they should go somewhere else, but where?


one option is to put them to the source code in the .rst format and  
create a new "main page link" similar to tutorial


cheers
Jan



út 21. 7. 2020 v 15:45 odesílatel Bruno Chareyre 
mailto:bruno.chare...@3sr-grenoble.fr>> 
napsal:


Hi,
This page is indeed rather old. I would suggest to remove all the
content that is irrelevant/obsolete, about Scons and stuff and see
what remains.
Because there are a couple valid points, maybe they should go
somewhere else, but where?
- What is "Young" and "Poisson" in ElastMat material?
- I want to get 2 plots, how can I do it?
- Is it possible to make another color of the background from python
script?
B


On Tue, 21 Jul 2020 at 13:56, Jerome Duriez mailto:jerome.dur...@inrae.fr>> wrote:

Hi everyone,

This question [*] made me wander on
https://www.yade-dem.org/wiki/FAQ.

A nice place to remember old ages with mentions about bzr,
scons, .. but
maybe not really useful to any new user and, as it appears, maybe
impossible to maintain..

I'm thus proposing to remove this page from the wiki :-)
(since I'll not propose here to remove the wiki ;-) )

Thoughts ?


Jérôme

[*] https://answers.launchpad.net/yade/+question/691986
But it seems this is not on that FAQ the OP found a github URL
--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

___
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
<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

[Yade-dev] Wiki FAQ

[Jerome Duriez]

Hi everyone,

This question [*] made me wander on https://www.yade-dem.org/wiki/FAQ.

A nice place to remember old ages with mentions about bzr, scons, .. but 
maybe not really useful to any new user and, as it appears, maybe 
impossible to maintain..


I'm thus proposing to remove this page from the wiki :-)
(since I'll not propose here to remove the wiki ;-) )

Thoughts ?


Jérôme

[*] https://answers.launchpad.net/yade/+question/691986
But it seems this is not on that FAQ the OP found a github URL
--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

___
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] [PATCH] correct Law2_ScGeom_ViscElPhys_Basic documentation to match source code, see https://answers.launchpad.net/yade/+question/691021

[Jerome Duriez]

See https://gitlab.com/yade-dev/trunk/-/merge_requests/508 (I made 
further minor changes), thank you Daniel.


You may consider to join directly YADE development (as per 
https://yade-dem.org/doc/gitrepo.html#committing-and-updating for 
instance) next time, if you wish.


(As far as I'm concerned, I do not guarantee to always include patchs 
sent by email ;-) )



--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 20/07/2020 20:49, Daniel Kiracofe wrote:

Please find attached a quick patch to correct
Law2_ScGeom_ViscElPhys_Basic documentation to match source code, per
discussion https://answers.launchpad.net/yade/+question/691021

(apologies for the delay between the launchpad question and the patch)

Daniel



___
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] Sign convention or name O.energy['gravWork']

[Jerome Duriez]

Thanks for feedback, what about just a change in name: gravWork -> 
gravPotential ?


There would be no more doubts whether it is work by gravity or work 
against gravity ; and decrease of that quantity during a fall would seem 
more logical to me (and others ?)


I agree otherwise with your general remarks about O.energy, but since 
it's there (we won't remove it anyway, will we ?) I think it could be 
worth to make such a small improvement.


Jérôme


--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 28/04/2020 16:27, Bruno Chareyre wrote:

Hi Jérôme,
I feel like it is a question of perspective, and undecidable overall.
Is it work by gravity or work against gravity? You can find the two 
meanings easily. It's still a work in both cases.


OTOH it seems these energies are underdocumented overall. I did not find 
a list of available energies anywhere in the doc.
I must say trackEnergy=True is slow. It computes many un-needed things 
(gravitational work is a good example, why should we increment 
G-=g*vel*dt at every iteration while we can get at any point in time 
-g*pos? same issue with elastic work).
In current design I would not recommend it although it is elegant and 
handy for quick tests.

Cheers
Bruno
So

Bruno

On Mon, 20 Apr 2020 at 16:13, Jerome Duriez <mailto:jerome.dur...@inrae.fr>> wrote:


I now think the most logical would be to keep this expression with a
minus sign [*], but rename 'gravWork' into 'gravPotential' (like we
have
'elastPotential').

It would reconcile for me the name with the coded expression, and be
more logical with the existence of O.energy.total() function (which
sums
all terms in O.energy and certainly is expected to be constant)


Thoughts ?

[*]

https://gitlab.com/yade-dev/trunk/-/blob/master/pkg/dem/NewtonIntegrator.cpp#L85

--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 20/04/2020 10:25, Jerome Duriez wrote:
 > Hi,
 >
 > Is there a consensus (outside myself) for the extra minus sign in
 > O.energy['gravWork'], computed in NewtonIntegrator at [*].
 >
 > It seems that code line was initially introduced by Vaclav in
 > GravityEngine in commit [**] (and made finally its way into
 > NewtonIntegrator).
 >
 > As far as I'm concerned, I can not make sense of the comment
justifying
 > that sign, just above [*], neither of a consequent negative power of
 > weight during some free fall.
 >
 >
 > Jérôme
 >
 >
 > [*]
 >

https://gitlab.com/yade-dev/trunk/-/blob/master/pkg/dem/NewtonIntegrator.cpp#L85

 >
 >
 > [**]
 >

https://gitlab.com/yade-dev/trunk/-/commit/d41480acf2ad616268c9ed562b625952c87c98a5,

 > see also corresponding file from that time at
 >

https://gitlab.com/yade-dev/trunk/-/blob/d41480acf2ad616268c9ed562b625952c87c98a5/pkg/common/GravityEngines.cpp#L33

 >
 > --
 > Chargé de Recherche / Research Associate
 > Inrae, RECOVER
 > 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
 > +33 (0)4 42 66 99 21
 >

https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

 >

___
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



--
--
___
Bruno Chareyre
Associate Professor
ENSE³ - Grenoble INP
Lab. 3SR
BP 53
38041 Grenoble cedex 9
Tél : +33 4 56 52 86 21


Email too brief?
Here's why: email charter 
<https://marcuselliott.co.uk/wp-content/uploads/2017/04/emailCharter.jpg>


___
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] Sign convention or name O.energy['gravWork']

[Jerome Duriez]

I now think the most logical would be to keep this expression with a 
minus sign [*], but rename 'gravWork' into 'gravPotential' (like we have 
'elastPotential').


It would reconcile for me the name with the coded expression, and be 
more logical with the existence of O.energy.total() function (which sums 
all terms in O.energy and certainly is expected to be constant)



Thoughts ?

[*] 
https://gitlab.com/yade-dev/trunk/-/blob/master/pkg/dem/NewtonIntegrator.cpp#L85


--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 20/04/2020 10:25, Jerome Duriez wrote:

Hi,

Is there a consensus (outside myself) for the extra minus sign in 
O.energy['gravWork'], computed in NewtonIntegrator at [*].


It seems that code line was initially introduced by Vaclav in 
GravityEngine in commit [**] (and made finally its way into 
NewtonIntegrator).


As far as I'm concerned, I can not make sense of the comment justifying 
that sign, just above [*], neither of a consequent negative power of 
weight during some free fall.



Jérôme


[*] 
https://gitlab.com/yade-dev/trunk/-/blob/master/pkg/dem/NewtonIntegrator.cpp#L85 



[**] 
https://gitlab.com/yade-dev/trunk/-/commit/d41480acf2ad616268c9ed562b625952c87c98a5, 
see also corresponding file from that time at 
https://gitlab.com/yade-dev/trunk/-/blob/d41480acf2ad616268c9ed562b625952c87c98a5/pkg/common/GravityEngines.cpp#L33 


--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez 



___
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

[Yade-dev] Sign convention O.energy['gravWork']

[Jerome Duriez]

Hi,

Is there a consensus (outside myself) for the extra minus sign in 
O.energy['gravWork'], computed in NewtonIntegrator at [*].


It seems that code line was initially introduced by Vaclav in 
GravityEngine in commit [**] (and made finally its way into 
NewtonIntegrator).


As far as I'm concerned, I can not make sense of the comment justifying 
that sign, just above [*], neither of a consequent negative power of 
weight during some free fall.



Jérôme


[*] 
https://gitlab.com/yade-dev/trunk/-/blob/master/pkg/dem/NewtonIntegrator.cpp#L85


[**] 
https://gitlab.com/yade-dev/trunk/-/commit/d41480acf2ad616268c9ed562b625952c87c98a5, 
see also corresponding file from that time at 
https://gitlab.com/yade-dev/trunk/-/blob/d41480acf2ad616268c9ed562b625952c87c98a5/pkg/common/GravityEngines.cpp#L33

--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

___
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] Vector3 unsigned int

[Jerome Duriez]

Out of curiosity, do you have concrete usage in mind?
That would be to gather 3 (always positive) indices of some gridpoint 
(i,j,k)


What would be the return type of the difference operator between two 
Vector3ui?
Indeed, I did not really think about it.. But in my mind, that would be 
the job of Eigen (which seems to handle unsigned types [*] ?) to decide, 
and I would just introduce a new typedef.



Actually my question came from the fear of falling under our recently 
strengthened warning=error compilation policy, through possible signed 
<-> unsigned conversions.


But I eventually did not face any of those in the meantime (while using 
classical Vector3i and other unsigned int variables), so maybe there was 
no point...



Thanks,

Jérôme


[*] 
http://eigen.tuxfamily.org/index.php?title=Versatility#Eigen_supports_many_numeric_types


--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez

On 08/04/2020 16:49, Bruno Chareyre wrote:

Hi Jérôme,
Out of curiosity, do you have concrete usage in mind?
What would be the return type of the difference operator between two 
Vector3ui?

Cheers
Bruno

On Wed, 8 Apr 2020 at 16:10, Jerome Duriez <mailto:jerome.dur...@inrae.fr>> wrote:


Hi,

It seems, in [*], we're not using typedef'd types for possible Eigen
Vector3("Vector3ui" maybe).

Would you like / object to have one ?


[*]

https://gitlab.com/yade-dev/trunk/-/blob/master/lib/high-precision/MathEigenTypes.hpp

Jérôme

--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez


___
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



--
--
___
Bruno Chareyre
Associate Professor
ENSE³ - Grenoble INP
Lab. 3SR
BP 53
38041 Grenoble cedex 9
Tél : +33 4 56 52 86 21


Email too brief?
Here's why: email charter 
<https://marcuselliott.co.uk/wp-content/uploads/2017/04/emailCharter.jpg>



___
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

[Yade-dev] Vector3 unsigned int

[Jerome Duriez]

Hi,

It seems, in [*], we're not using typedef'd types for possible Eigen 
Vector3("Vector3ui" maybe).


Would you like / object to have one ?


[*] 
https://gitlab.com/yade-dev/trunk/-/blob/master/lib/high-precision/MathEigenTypes.hpp


Jérôme

--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez


___
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

[Yade-dev] Vector outputs in LOG macros vs cout

[Jerome Duriez]

Hi (Janek ?)

Is it on purpose (or imposed by Boost ?) that e.g.

LOG_DEBUG(someVector3r_Or3i_Or...)

will output the vector items in "column", while

cout << someVector3r_Or3i_Or...

would output them in the same row ?


Hoping that current boring lockdown times will give some interest to 
that question ! ;-)


Jérôme

--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez


___
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] Call for testing, updated yadedaily packages

[Jerome Duriez]

Hi Anton and everyone,

As of today, is it still meaningfull to have this 
"http://yadedaily.s3.amazonaws.com; in 
/etc/apt/sources.list.d/yadedaily.list ?


sudo apt-get update here returns

[...]
Ign:12 http://yadedaily.s3.amazonaws.com/debian bionic InRelease
Err:13 http://yadedaily.s3.amazonaws.com/debian bionic Release
  404  Not Found [IP: 52.216.134.75 80]
[...]


Best,

Jérôme

--
Chargé de Recherche / Research Associate
Inrae, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
https://www6.paca.inrae.fr/recover/personnel/equipes/jerome-duriez

On 27/06/2019 21:15, Anton Gladky wrote:

Dear all,

yadedaily packages are being under renovation at the moment. And now 
they need to be tested.

I want to ask you to do it and give a feedback.

3 Distributions are supported:
- Debian Buster
- Debian Stretch
- Ubuntu 18.04 Bionic

Packages are hosted on Amason S3 for the moment.
The following steps need to be taken to test the packages

1. Add yade GPG-key:
    If you have the yadedaily package, you can skip this step.

    wget -O - http://yadedaily.s3.amazonaws.com/yadedaily.gpg | sudo 
apt-key add -


2. Add repo into the apt:
    - *Debian Buster:*
      sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian 
buster main" >> /etc/apt/sources.list.d/yadedaily.list'


    - *Debian Stretch*:
      sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian 
stretch main" >> /etc/apt/sources.list.d/yadedaily.list'


    - *Ubuntu 18.04 Bionic:*
      sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian 
bionic main" >> /etc/apt/sources.list.d/yadedaily.list'


3. Install yadedaily:
     sudo apt update && sudo apt install yadedaily

After that you can run the software:

    yadedaily
    yadedaily --test
    yadedaily --check

Please let me know, whether everything is working as expected.

If you do not want to use yadedaily any more, just do:
   sudo apt purge yadedaily

Remove test-repo from sources:
    sudo rm  /etc/apt/sources.list.d/yadedaily.list

I will update packages manually within the test period. After that we 
can automate the process.


Thanks

Anton

___
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] AddressSanitizer is enabled in the CI-pipeline

[Jerome Duriez]

Hi,


you can see in the pipeline
Is there yet an example in recent pipeline jobs ? I looked at that job 
 from ASAN merge 
request #331 and could not see anything new.
What's the exact workflow ? Running --test and --check and look for some 
error/warning messages ? If there is one => problems, if there is none 
=> no problems ?



Thanks !

Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
www.irstea.fr/duriez

On 11/11/2019 18:39, Anton Gladky wrote:

Dear Yade developers,

last weekend [1] we enabled the new target in the pipeline: make_asan.
Also the new Yade option ENABLE_ASAN was added into the Cmake.
Documentation is updated correspondingly.

ASAN - is the abbreviation of AddressSanitizer [2] - memory error detector,
which finds heap corruptions, memory overflows etc.

Generally, Yade is being compiled with special compiler flags and then
'-test' and
'--check' steps are being executed. If you add a new engine or any other
class, which is executed by "--test" or "--check" step, you can see in
the pipeline, whether  your code is not doing something weird with the
memory.

It can help to increase the software stability, correctness of the results
and general quality of the software.

If you see some problems with this step in the pipeline - please let me know.

[1] https://gitlab.com/yade-dev/trunk/merge_requests/331
[2] https://github.com/google/sanitizers/wiki/AddressSanitizer

Best regards

Anton

___
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] Python inheritance

[Jerome Duriez]

Hi,

For your information, I also faced at some point segfaults with 
boost::python stuff during O.run() and not O.step() : 
https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg13223.html


(I never really solved / understood it.. If you know e.g. boost mutex 
more than me -- that won't be difficult -- maybe you will !)



Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
www.irstea.fr/duriez

On 07/10/2019 16:46, William Chèvremont wrote:


Dear Yade dev,

I'm facing an issue implementing a new interaction law into Yade.

To be quick, I would like to provide normal force norm from python and 
integrate this value into the lubrication law.


The current state of my work is on branch 'potential' on gitlab. 
What's new in this branch:


- pkg/dem/LubricationWithPotential.{cpp, hpp} : Lubrication law with 
arbitraty contact law + potential solver, and some potential coded in 
c++. This part work perfectly.


- py/wrapper/yadeWrapper.cpp: I've written a wrapping class and 
boost.python exposing expressions. I want to inherit this class in 
python in order to provide the value to the solver above.


It works perfectly if I call O.step();. Problems are coming as soon as 
I launch O.run(), I got a segfault signal when the c++ code call the 
python overrided function.


What's wrong???

Summary of the code:

:::python:::

classSimplePotential(GenericPotential):
    def contactForce(self, u):
#    print("pyContactForce!");
    return 0;
    def potentialForce(self, u):
#    print("pyPotentialForce!");
    return 1;
    def hasContact(sefl, u):
    return False;

:::C++:::


class pyGenericPotential : public GenericPotential, public 
py::wrapper {

public:

    Real potential(Real const& u, LubricationPhys const&) const {
    TRACE;
    return contactForce(u) + potentialForce(u);
    }

    void applyPotential(Real const& u, LubricationPhys& phys, Vector3r 
const) {

    TRACE;
    phys.normalContactForce = contactForce(u)*n;
    phys.normalPotentialForce = potentialForce(u)*n;
    phys.contact = hasContact(u);
    }

    virtual Real contactForce(Real const& u) const {
    TRACE;
    return get_override("contactForce")(u);
    }

    virtual Real potentialForce(Real const& u) const {
    TRACE;
    return get_override("potentialForce")(u);
    }

    virtual bool hasContact(Real const& u) const {
    TRACE;
    return get_override("hasContact")(u);
    }
};


    py::class_("GenericPotential")
.def("contactForce",py::pure_virtual(::contactForce),"This 
function should return contact force norm.")
.def("potentialForce",py::pure_virtual(::potentialForce),"This 
function should return potential force norm.")
.def("hasContact",py::pure_virtual(::hasContact),"This 
function should return true if there are contact.");


--



William Chèvremont

Doctorant, PhD student
04 56 52 01 86

Laboratoire de Rhéologie et Procédés
Bureau Bureau B-365
363 Rue de la chimie - bâtiment B
Domaine Universitaire - BP 53 - 38041 Grenoble cedex 9
www.univ-grenoble-alpes.fr 
http://www.laboratoire-rheologie-et-procedes.fr/


___
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] Call for testing, updated yadedaily packages

[Jerome Duriez]

On 05/07/2019 14:07, Janek Kozicki wrote:
I should write about this process in the developer documentation also. 


I actually just understood more (hopefully) what these dockers are..
And I just realized the docker files like this one 
 
are up-to-date lists of required packages for the different OS (are they 
?), which is a very useful piece of information to point to from 
https://yade-dem.org/doc/installation.html, as done in 
https://yade-dem.org/doc/installation.html#supported-linux-releases..


InSections of installation page may thus be reordered and written in a 
more independent fashion from our gitlab procedures. So that users 
wanting to compile source may be better guided, whatever their Linux OS ?


I may try to propose something this summer, but if someone agrees and 
wants to do it before me...



___
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] Call for testing, updated yadedaily packages

[Jerome Duriez]

Hi,

Here (Ubuntu 18.04 Bionic)

***

Your instructions worked like a charm (I already had yadedaily package).

I now have (note just the VERSIONYADEREPLACE that may need to be replaced)

jerome.duriez@AXP17003:~$ yadedaily
Welcome to Yade VERSIONYADEREPLACE
Using python version: 3.6.8 (default, Jan 14 2019, 11:02:34)
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]]
TCP python prompt on localhost:9000, auth cookie `dacsuk'
XMLRPC info provider on http://localhost:21000
[[ ^L clears screen, ^U kills line. F12 controller, F11 3D view (press 
"h" in 3D view for help), F10 both, F9 generator, F8 plot. ]]


In [1]:


Instead of "Welcome to Yade 2018.02b-290bf6a54e~bionic " previously

***
-- test ended with *** ALL TESTS PASSED ***
With, afterwards,
Entered the initialization functionjerome.duriez@AXP17003:~$
which was just maybe missing a newline character before my bash invite



***
--check ended with *** ALL CHECKS PASSED ***



Thank you !


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21
www.irstea.fr/duriez

On 27/06/2019 21:15, Anton Gladky wrote:

Dear all,

yadedaily packages are being under renovation at the moment. And now 
they need to be tested.

I want to ask you to do it and give a feedback.

3 Distributions are supported:
- Debian Buster
- Debian Stretch
- Ubuntu 18.04 Bionic

Packages are hosted on Amason S3 for the moment.
The following steps need to be taken to test the packages

1. Add yade GPG-key:
    If you have the yadedaily package, you can skip this step.

    wget -O - http://yadedaily.s3.amazonaws.com/yadedaily.gpg | sudo 
apt-key add -


2. Add repo into the apt:
    - *Debian Buster:*
      sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian 
buster main" >> /etc/apt/sources.list.d/yadedaily.list'


    - *Debian Stretch*:
      sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian 
stretch main" >> /etc/apt/sources.list.d/yadedaily.list'


    - *Ubuntu 18.04 Bionic:*
      sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian 
bionic main" >> /etc/apt/sources.list.d/yadedaily.list'


3. Install yadedaily:
     sudo apt update && sudo apt install yadedaily

After that you can run the software:

    yadedaily
    yadedaily --test
    yadedaily --check

Please let me know, whether everything is working as expected.

If you do not want to use yadedaily any more, just do:
   sudo apt purge yadedaily

Remove test-repo from sources:
    sudo rm  /etc/apt/sources.list.d/yadedaily.list

I will update packages manually within the test period. After that we 
can automate the process.


Thanks

Anton

___
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

[Yade-dev] Updating Launchpad (Code) page

[Jerome Duriez]

Hi,

I think https://code.launchpad.net/yade (reached eg after cliking on 
"Code" at the top of https://launchpad.net/yade) clearly needs to be 
updated:


- it still mentions about bazaar (I even can not remember when we left 
this tool...)

- it also still mentions about gitHub...

Obviously, some people still end on this page when they look for source 
code [*]



It seems I can not update (who does ?)


Jérôme





[*] https://answers.launchpad.net/yade/+question/680144

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
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] Web doc reflecting another branch than master ?

[Jerome Duriez]

Maybe not yet ?

Now, web doc is about 2019-03-19.git-2b43e45 i.e. 
https://gitlab.com/yade-dev/trunk/commit/2b43e45724cfa7613dba9c6a8d1c12675e9849ba 
that came after your commit (*) (in your message), and that is still 
part of the partialFix81FoamCouplingEngine branch.


We'll see.

Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 19/03/2019 13:16, Bruno Chareyre wrote:

Hi Jérôme,
Thanks for spotting, should be fixed with (*).
Bruno


(*) 
https://gitlab.com/yade-dev/trunk/commit/e2900d8552e7875623ef32ec0a20ad038e2469b3


On Tue, 19 Mar 2019 at 10:54, Jerome Duriez <mailto:jerome.dur...@irstea.fr>> wrote:


Hi,

As of now, https://yade-dev.gitlab.io/trunk/ tells me it describes
"Yade
version 2019-03-19.git-a36504b / 2019-03-19.git-a36504b"

As a matter of fact,
https://yade-dev.gitlab.io/trunk/installation.html#prerequisites
mentions as required packages "libopenmpi-dev libopenmpi1.10
openmpi-bin
openmpi-common openmpi-doc", which is included in that commit [*]


However, this commit number, and these required packages still
belong to
the "partialFix81FoamCouplingEngine
<https://gitlab.com/yade-dev/trunk/tree/partialFix81FoamCouplingEngine>"

branch.

If I browse master "branch" on the other hand, the installation
instructions should not mention the *openmpi* packages :
https://gitlab.com/yade-dev/trunk/blob/master/doc/sphinx/installation.rst



Is that normal ?


Jérôme


[*]

https://gitlab.com/yade-dev/trunk/commit/a36504ba2396db383e1f06987d9d7290013b5dd5

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
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



--
--
___
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


Email too brief?
Here's why! http://emailcharter.org

___
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

[Yade-dev] Web doc reflecting another branch than master ?

[Jerome Duriez]

Hi,

As of now, https://yade-dev.gitlab.io/trunk/ tells me it describes "Yade 
version 2019-03-19.git-a36504b / 2019-03-19.git-a36504b"


As a matter of fact, 
https://yade-dev.gitlab.io/trunk/installation.html#prerequisites 
mentions as required packages "libopenmpi-dev libopenmpi1.10 openmpi-bin 
openmpi-common openmpi-doc", which is included in that commit [*]



However, this commit number, and these required packages still belong to 
the "partialFix81FoamCouplingEngine 
" 
branch.


If I browse master "branch" on the other hand, the installation 
instructions should not mention the *openmpi* packages : 
https://gitlab.com/yade-dev/trunk/blob/master/doc/sphinx/installation.rst




Is that normal ?


Jérôme


[*] 
https://gitlab.com/yade-dev/trunk/commit/a36504ba2396db383e1f06987d9d7290013b5dd5


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
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

[Yade-dev] Deploy stage in Gitlab's pipeline

[Jerome Duriez]

Hello,

What is the deploy stage in Gitlab's pipeline ?
(which fails in the last changes on trunk-exp [*] just because deploy 
does not apply to trunk-exp ?)


I thought it should be defined in .gitlab-ci.yml but it's not ?


Thanks,

Jérôme

[*] 
https://gitlab.com/yade-dev/trunk-exp/commit/538c7e26f7602945e8752a101dab9b6cb8028e1d


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
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] [Yade-users] [Question #678982]: about TriaxialStressController

[Jerome Duriez]

Hi,

Regarding [*] and the comment "|the mask is the integer whose binary 
representation is xyz" at|[**], do we agree that


- 3 = 11 = 011 in binary [***] (and not 110) ?And that 1 = 001 (and not 
100 as in [**])


- and that the comment at [**] should read "|the mask is the integer 
whose binary representation is zyx"|(and not xyz) ?




If yes, I'm looking forward to a "better bitmask documentation" branch  
(by myself, one day..., or someone else) ;-)



Jérôme



[*] On 07/03/2019 11:03, Robert Caulk wrote:


stress x y 10 kpa, strain z 0.2 (bitmask -> 1 1 0):

triax.stressMask = 3



[**] 
https://gitlab.com/yade-dev/trunk/blob/master/examples/triax-tutorial/script-session1.py#L91


[***] 
https://en.wikipedia.org/wiki/Binary_number#/media/File:Binary_counter.gif


___
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] Fixing the examples

[Jerome Duriez]

Hello,

As for jointedCohesiveFrictionalPM, gravityBis.py is working and is 
intended to replace gravityLoading.py + packInGtsSurface.py.


While identificationSpheresOnJoint.py is not supposed to be called for 
itself, and could be replaced by identifBis.py (the latter being used by 
gravityBis.py). I'm reproposing [*] some removal of files (even though I 
won't do it myself in a near future, I still need to catch up with the 
gitlab workflow...)


Jérôme

[*] 
https://gitlab.com/yade-dev/trunk/commit/4788d0eeb50f5606c9f3fd8c9e3dd71987ee885f


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 24/01/2019 19:09, Bruno Chareyre wrote:

Hi Janek,
I went through list_of_examples.txt [1].
Impressive work, thanks. I just fixed two [2].

My impression is that some examples could be fixed quickly by the 
original authors, provided that they now the problem (many of them are 
probably not reading yade-dev). I'm then adding some of them in cc of 
this email for possible reaction.


Guys, you can fix thoses scripts on github or gitlab, doesn't matter. 
Please remember to insert your name and email in every script so we 
know what to do is a case like now.


FEMxDEM: Ning Guo (if this adress does not work I know Ning has 
successors in HK)
HydroForceEngine: Raphael MAURIN (postProcessing_sedim.py has a 
problem + some scripts need move to check scripts (great!))

jointedCohesiveFrictionalPM:  Luc Scholtès and/or (?) Jérôme Duriez
OAR:  William Chèvremont  (maybe a few lines in preamble of sim.py to 
explain why - obviously - it cannot work for Janek, or maybe link back 
to where it is explained?)
SPH: Anton, is there somewhere explanation of current state of SPH? Is 
it something someone could take over one day, or should it be simply 
removed?


Thanks all.

Bruno

[1] 
https://gitlab.com/yade-dev/trunk/blob/master/examples/list_of_examples.txt
[2] 
https://gitlab.com/yade-dev/trunk/commit/46f718ee2bc3c2198809145f1446865263d1453b



On 1/20/19 10:45 PM, Janek Kozicki wrote:

Sounds great!

You can see more info in file examples/list_of_examples.txt
would be great if mark in this file those that you have fixed.

it is already merged on gitlab :)
https://gitlab.com/yade-dev/trunk/merge_requests/27

best regards
Janek


Jan Stránský said: (by the date of Sun, 20 Jan 2019 21:44:29 +0100)


Hi Janek,

thanks for the detailed look :-)

If you have any hints on how to fix any of those examples, please 
tell!
several mentioned not working script is from me. I think than 
correcting

them and pushing to gitlab is better than telling :-)


Also I see that https://yade-dem.org/doc/tutorial-examples.html looks

very strange - the youtube videos are not shown

I don't remember the reason (have read it long time ago), but the 
youtube

videos does work using http (not https) in the address

cheers
Jan



ne 20. 1. 2019 v 20:27 odesílatel Janek Kozicki  
napsal:



Hi,

I did small or cosmetic fixes in 17 examples.
Currently 21% of examples (46 out of 215) are broken.

I tried every example in a very quick manner. I checked if it has any
explanations inside the comments, then I tried to just run it.
It is possible that some of them failed only because they need a bit
fiddling before starting them. In that case we need to explain the
fiddling inside the file, in comments. And tell me what is the 
fiddling to

do!

If you have any hints on how to fix any of those examples, please 
tell!


ResetRandomPosition.py
  : SIGSEGV/SIGABRT handler called;
  : gdb [with T = IGeomFunctor; typename
boost::detail::sp_member_access::type = IGeomFunctor*]: 
Assertion `px !=

0' failed.

DeformEngine/LOedometricDeform.py and OedometricDeform.py
  : NameError: name 'DeformControl' is not defined

FEMxDEM
  : ImportError: No module named esys.escript
  I am reading https://launchpad.net/escript-finley to fix this.

HydroForceEngine/twoWayCoupling/postProcessing_sedim.py
  : line:49 ValueError: operands could not be broadcast together with
shapes (900,) (901,) (900,)

LudingPM/LudingPM_1.py and LudingPM_2.py
  : NewtonIntegrator: NaN force acting on #0.

PotentialBlocks/WedgeYADE.py and cubePBscaled.py
PotentialParticles/basic.py and cubePPscaled.py
  : NameError: name 'PotentialBlock2AABB' is not defined
  I will recompile with ENABLE_POTENTIAL_BLOCKS=ON and see if they 
work.


agglomerate/simulation.py
  : AttributeError: 'Body' object has no attribute 'agglomerate'

capillary/liquidmigration/showcase.py
  : NameError: name 'LiqControl' is not defined
  I will recompile with LIQMIGRATION  and see if it works.

clumps/save-load-clumps.py
  : SIGSEGV/SIGABRT handler called; gdb
  : Assertion `member->isClumpMember()' failed.

deformableelem/Minimal.py
  : the graphs are empty

deformableelem/main.py
  : I suppose this file is here by mistake ?

jointedCohesiveFrictionalPM/packInGtsSurface.py and all other files
  : spams terminal with 

Re: [Yade-dev] gitlab work cycle

[Jerome Duriez]

Hi,


[1]https://yade-dev.gitlab.io/trunk/github.html?highlight=gitlab#pushing-changes-to-remote-repository 




What's this https://yade-dev.gitlab.io/trunk/ ?...

Is our doc now located at that place, and no more at 
https://yade-dem.org/doc/ ?...



Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 30/01/2019 13:55, Bruno Chareyre wrote:



On 1/29/19 11:24 PM, Janek Kozicki wrote:

Hi, have you seen merge request by Vasileios?

https://gitlab.com/yade-dev/trunk/merge_requests/48

I remember that you said something about pipelines not working from
other people's accounts.

Yes.


There should be a way to solve this in general manner.
There could a way with future versions of gitlab, but current behavior 
is that the pipeline has to run on the account where the MR comes 
from, not on the destination. We can't change it.



I guess that due to previous discussion,

Could be, but It should be enough to read the documentation [1].
I am updating it again today but it was already relevant.

[1]https://yade-dev.gitlab.io/trunk/github.html?highlight=gitlab#pushing-changes-to-remote-repository 



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



___
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] Potential Blocks and Potential Particles - Documentation

[Jerome Duriez]

Is there any practical preference between .rst or latex files? 



In my opinion :

- .rst files, and being somehow part of the doc, as we see it on 
https://yade-dem.org/doc, is much more visible and much easier to 
maintain (by different people, in particular) : it's under git version 
control for instance...


On the other hand, the doc would not survive if it were inflated by new 
additions of sections each time someone proposes new stuff (which is 
otherwise obviously good)..



- .tex files and Yade Technical archives make it much more one 
person-specific (for maintenance purposes). In my view, it's like a 
publication : almost frozen for all time.


As a matter of fact we do not have any .tex files under version control 
(at the moment), and, in the way as I see things, it does not work for 
maintenance purposes to have something too deeply related with someone : 
people end up working at different institutions, or on a different 
subject, and they logically end up at some point not being able to 
maintain what they proposed earlier..




As you see, this will not tremendously help you to make a choice, but I 
wanted to take the opportunity to express some general opinions on the 
subject. Others are welcome..



Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 21/01/2019 21:31, Vasileios Angelidakis (PGR) wrote:


Hi,


Regarding the writing of a documentation for the "Potential Particles" 
and the "Potential Blocks" codes, I am happy to help
on a more consistent basis, as I currently use them. Is there any 
practical preference between .rst or latex files?


Chia, I can transcribe your introductory word file and add some 
"command-to-command" comments.



All the best,


Vasileios


*From:* Yade-dev 
 on 
behalf of Janek Kozicki 

*Sent:* 21 January 2019 20:19:04
*To:* Chia Weng Boon
*Cc:* Yade developers
*Subject:* Re: [Yade-dev] Potential Blocks and Potential Particles - 
Documentation

Hi Boon,

awesome! I'm not sure if I need to reply to your address, or only to
yade-dev, so to be safe I reply to both now.

I did follow your instructions exactly and now all four examples did
start and run. But unfortunately they appeared to work incorrectly :(

Here's the list of problems I encountered:

WedgeYADE.py

The scene is empty until I click Display->intrAllWire

I am not sure maybe the calculation is going on correctly, but since
the shape is not drawn it is very hard to tell.

Also the terminal is spammed with messages like KnKsPBLaw.cpp:34 
go:geom->penetrationDepth=0.00155115; de1->se3.position=-14.8839 
8.48539 26.8419; de2->se3.position=-17.682 -6.95829 26.8667;


And the messages are so fast that it slows down calculation very fast.


cubePBscaled.py

The same problem as above also there are extra messages:

../yade:70: DeprecationWarning: dynamic=True is deprecated, use 
fixed=False instead

  print 20*'*'+' UNEXPECTED EXCEPTION WHILE RUNNING TESTS '+20*'*'
  print 'WARNING: compiled without OpenMP, -j/--threads/--cores have 
no effect.'

  else: os.environ['OMP_NUM_THREADS']='1'

basic.py

The sphere does not collide with the box, it goes through.


cubePPscaled.py

Drawing shapes is a bit slow, so it's hard to tell if it runs
correctly. I disabled drawing of shapes, enabled intrAllWire. Ran
simulation a bit and it seemed to work.
Then I clicked to enable drawing shapes and I got SIGSEGV/SIGABRT 
handler called; gdb



Also I see that your merge request has some lines like "not used" 
which is confirmed by similar compiler warnings like this one:


BlockGen.cpp:326:22: warning: unused variable ‘linecount’ 
[-Wunused-variable]
BlockGen.cpp:2670:48: warning: unused variable ‘zlocalA’ 
[-Wunused-variable]




best regards
Janek




Chia Weng Boon said: (by the date of Mon, 21 Jan 2019 13:02:58 +0800)

> Hi all,
>
> In my DPhil thesis submitted in 2013, I previously developed 
algorithms for

> (i) block generation and contact detection between polyhedral blocks (I
> have named it as Potential Blocks in YADE), and also (ii) contact 
detection

> between general non-spherical particles (Potential Particles).
>
> http://www2.eng.ox.ac.uk/civil/publications/theses/boon
>
> It is now being updated with Coin-OR's clp library (2015) and I've 
added it

> into the config file in YADE (2016-2017).  I've written a brief
> introduction as to how to enable this feature in YADE (attached), so 
that
> it can be incorporated into YADE's Documentation (maybe 3rd 
edition?).  I
> am working in the industry currently, and can only spend time on a 
casual

> basis as a hobby (once in a few months).
>
> The algorithms for block generation and contact detection are 
already being

> used by other research groups.
>
> https://github.com/cb-geo/spark-rocks
>
> 

Re: [Yade-dev] Migrating to GitLab

[Jerome Duriez]

I actually had in mind your sentence

We (Grenoble folk) are not going to spend human and cpu time on 
website and gitlab framework, just to host an unmaintained project.
from [*], which kind of convinced me as a reason to modify our workflow 
towards a tighter control (interpreting the above "unmaintained" as = to 
"open to modifications without any real assessment").


At the same time, Rémi left 3SR and, as a first consequence, we kind of 
lost control on our wiki (even though I would not deeply miss it ;-) as 
far as I'm concerned).


Thus, I was wondering if the move towards merge requests would be 
accompanied by new human and cpu ressources (coming from UMS Gricad ??) 
? If yes, would these human and cpu ressources be additional to what we 
used to have until now (from 3SR), or "just" replace them ??



In summary (and with an inspiration from French idioms) : we will now 
face sticks (with the MR procedure), is there any carrot ? :-)



Jérôme

[*] https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg13682.html

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 17/01/2019 18:12, Bruno Chareyre wrote:



On 1/17/19 5:53 PM, Jerome Duriez wrote:
 it's maybe time to ask what does YADE development (if not "we") may 
expect as investment from Grenoble "in exchange" ?


Who is expecting something, from who, in exchange of what? You lost 
me, sorry. :)


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



___
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] Migrating to GitLab

[Jerome Duriez]

Hi Bruno,

Thank you for everything.

It was a reason for new ways of doing things (the merge requests, in 
particular), it's maybe time to ask what does YADE development (if not 
"we") may expect as investment from Grenoble "in exchange" ?
Good hopes to maintain all that we have in spite of possible changes on 
3SR side (see Rémi's departure) ? Or something more than we used to have ?



Looking forward to discuss the rules for approving the merge requests :-)


Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 17/01/2019 17:40, Bruno Chareyre wrote:

Hi there,

The repository is functional at:
https://gitlab.com/yade-dev/trunk

For using gitlab you can read the updated doc page
https://yade-dev.gitlab.io/trunk/github.html#yade-github-label

As soon as you have a gitlab account let me know your login name so I 
can add you to the project.


I just discovered a technical constraints which makes MR from personal 
repo awkward at the moment (although it could work with future gitlab 
versions maybe [1]).
The issue is that if a MR is generated from a forked repo to the 
parent yade-dev/trunk repo, then running the pipeline [3] requires 
that runners[2] be available in the forked repo. It is not possible to 
build the MR on the parent repo.
So unless you have the computational ressources and enough skills/IT 
support to configure runners locally, MR from personal repo will not 
be tested automatically. They can be handled (some MR could still make 
it that way) but it is not very convenient and it will take more time 
to be accepted.


It is pushing us toward a solution closer to what Janek suggested, 
which was based on multiple branches more than multiple repos. I.e. 
push (normal push) to different branches of yade-dev/trunk, then MR 
from that branch to master. Since both branches are under yade-dev the 
group runners will be used in this case.


Please check the doc and let me know if some information is missing.

I suggest to not conclude migration before Anton's freeze.
You can still work with github repo if you have local changes and you 
are affraid to mess up, I will merge gitub repo into gitlab if needed.

Else please consider pushing to gitlab any future revision.

There is an experimental repo at 
https://gitlab.com/yade-dev/trunk-exp. Feel free to break it.


Cheers

Bruno


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/23902
[2] hardware on which compilation and regression tests occur
[3] https://gitlab.com/yade-dev/trunk/pipelines (you can click on 
every step to visualize process like 
https://gitlab.com/yade-dev/trunk/-/jobs/147313249)


On 1/13/19 10:03 AM, Anton Gladky wrote:

Hello Bruno,

thanks for the explanation. That is more-less clear. From my side - OK.


  would like to have you in the maintainers group if you agree.

Yes, I agree. Thanks.

Best regards

Anton

Am Fr., 11. Jan. 2019 um 14:53 Uhr schrieb Bruno Chareyre
:



On Thu, 10 Jan 2019 at 21:40, Anton Gladky  
wrote:

Sorry guys, I still cannot understand, what brings:
- renaming master->develop
- having potentially broken/not-mergable experimental branch.



Oh yes, it's confused. Things will become more clear with a 
functional repo (I'm only waiting for runners to be assigned 
presently, then we can switch).


Master took the name "develop" in the course of this discussion 
because of the master-develop framework mentioned earlier (by Janek).
If we keep a single branch there is no reason to rename it. It will 
be master.


Experimental: my intention was to let people play with an 
experimental gitlab repo so they can learn a bit of gitlab CI 
without messing up yade history.
Of course they can play with git in their personal repo but the 
cycle will be incomplete if they are not assigned runners. Hence why 
I suggested a draft project, perhaps only in a transitory phase.
There is no added complexity, it's just a clone of the main repo 
with runners assigned (we will not assign runners to each other 
personal repo, I guess it goes without saying).
If kept in the long run then maybe experimental repo could help 
sharing experimental stuff through precompiled packages without 
interfering with main repo.
Say, someone finds out that pink-colored GUI is better and he wants 
others to try it. If it's in experimental others can simply apt-get 
install to inspect the achievement.


Anyway, I am not so active in the project, so feel free to make 
your own

decisions. Do not forget to keep simple things simple...


I would like to have you in the maintainers group if you agree. And 
thanks for comments, they are helpful.

Cheers

Bruno



Regards


Anton

Am Do., 10. Jan. 2019 um 20:16 Uhr schrieb Janek Kozicki 
:

OK, I think I finally understood your intentions:

merge requests go to develop (renamed from master), with several devs
approving it with www interface.

experimental branch is not used for that, but 

Re: [Yade-dev] Migrating to GitLab

[Jerome Duriez]

On 08/01/2019 17:50, Bruno Chareyre wrote:



On Tue, 8 Jan 2019 at 09:56, Jerome Duriez <mailto:jerome.dur...@irstea.fr>> wrote:


let's maybe try to avoid switching from only one branch to more than
three ?...


We have already 19 branches on github/yade/trunk, plus other branches 
under personal accounts.
Limiting the number of branches is not a realistic objective, don't 
worry about that. It will become more clear with concrete usage, and 
you will not have to handle them all anyway.


Yes, I actually meant the branches a single dev has to deal with, for 
his modifications to finally be included into the code ;-)
(it's true however experimental would not be one of those if it's just 
to make experiments..)


___
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] Migrating to GitLab

[Jerome Duriez]

[..] with master-develop
approach. [..] you really need to know, why do
you need it.

Thanks for feedback Anton, that's my point :-)

Considering that a develop->master step still needs to be clarified, 
with different opinions at the moment between Bruno (below) and Janek 
(07/01/2019 à 17:31 email) --- which is normal in a discussion phase ---

, considering a third experimental branch appears in the discussion
, plus the branchs for each dev,

let's maybe try to avoid switching from only one branch to more than 
three ?...



Thanks for your motivation !

Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 07/01/2019 20:36, Anton Gladky wrote:

Hello all,

last several years I did Yade releases and the process was
the following. Before the release was done I created the corresponding
release-branch (for example 0.60 [1]) and just tagged the new
Yade version there. It worked relatively good.

--> develop
   \\
\ \
 \Release 1 \Release 2
  \Release 1.1

I can remember only a couple of times, where the hot-fixes were
needed to be integrated into the release-branch due to some serious
stability or functionality issues.

Last years I have an experience of work with master-develop
approach. It is not bad. But you really need to know, why do
you need it.

I am fully support the feature-branch + merge request way of working.
It can really help to double check the code and implement some
additional tests.

[1] https://github.com/yade/trunk/tree/0.60

My 2cts

Regards

Anton

Am Mo., 7. Jan. 2019 um 17:39 Uhr schrieb Janek Kozicki :

Bruno Chareyre said: (by the date of Mon, 7 Jan 2019 16:59:53 +0100)


Daily builds would be based on the develop branch.

good, that answer my question from other mail.


(by the way, with a tighter control on development, would we still
need a distinction between "yade" and "yadedaily" packages ?..)

Yade is stable release, not updated very often, included in main
debian/ubuntu repos.
Yadedaily is updated  more than daily, after each change to the source
code, not included in debian/ubuntu repos.
They are very different things and I think we need both.

agreed.


Also, with "develop" and "master", I guess any proposal for code
modification would have to be closely examined and validated twice :
- once to make it into "develop"
- and once, to make it from "develop" into "master"
?...

There is no reason to check the develop->master merge if everything in
develop is already validated by regtests + human review.
Our github/master corresponds to "develop" more or less.
Merging develop into master in the new model would correspond to Anton
calling for update and releasing 2018.b. More or less.

agred.


We probably need a liberal, truly unstable repo on the top of this, at
least in a transitory phase, so that everyone can play with gitlab a bit
and break everything with no limit. For instance to compare --no-ff,
--only-ff, and other variants.

how about calling it experimental ? :-))

And yes, we definitely need something like that.
Where git reset --hard is nothing to be afraid of.

--
Janek Kozicki

___
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



___
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] [Yade-users] [Question #676841]: the definition of porosity

[Jerome Duriez]

As for me, I subscribe to Bruno's presentation: better speak in terms of 
normal component of relative displacement between centers.


Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 17/12/2018 13:43, Bruno Chareyre wrote:



On 12/17/18 12:14 PM, Jan Stránský wrote:


yes. In reality (if the particles were soft), there would be no 
overlap but the particles would deform (being in contact, but not 
overlapping).
In Yade, the particles are rigid and do overlap. Repulsive forces are 
somehow computed from this overlap.
Porosity is computed using the original particles volume. This way, 
the computation is very easy and fast.


>From existing overlaps, you can relatively easily compute actual volume
of overlaps and adjust the evaluation if needed.


I beg to disagree. :)
It would be better if we could speak the same language in answers 
(that's why I'm moving the discussion to yade-dev), let's see if we 
find a common ground.
I would suggest that Cundall/Yade DEM makes no assumption of 
rigidity/overlaps. The notion of overlap is misleading and should be 
avoided. I usually speak of normal displacement wrt. equilibrium 
state, instead.


The only rigid-body approximation is in Newton, where we take moment 
of inertia constant (it should change with deformation).
Deformation is neglected from an inertial point of view, that is true, 
but it doesn't mean no deformation anywhere.


In contact models it is admitted that the bodies are not rigid, since 
there can be relative motion between bodies in contact.
Hertz-Mindlin is a perfect example, it is directly accounting for 
internal deformation, and it is derived on the basis that solid 
surfaces  *cannot* overlap.
The other models can be seen as linearizations of HM, and along this 
line they don't introduce overlaps either.


The fact is that we never display deformed shapes of particles. We 
could in some cases (with HM at least), and then the spheres would 
appear with surface deflection instead of overlaps. It would be 
painful to implement and rendering would be much slower, but virtually 
it can be done. Hence why overlap is just a geometrical artifact. It 
is not needed in the governing equations, it only appears as a 
byproduct of graphical display.


Rejecting the notion of overlap is I think the only way to escape 
classical ill-posed questions on porosity. "Should overlapped volumes 
be removed?"
If we agree that there is no overlap there is of course no reason to 
compute overlapping volume. What is the change of volume of a 
compressed contact then? Well, HM tells you exactly the volume change 
as part of the closed form solution. If someone is using a linearized 
form, defining accurate volume change is less clear, it may have to be 
defined as part of the contact model itself. But in any case, the 
overlapping volume is irrelevant to physics.


Bruno




Also please, if the question is about porosity, next time provide the
code you use to compute porosity. There are two of them, [1] using the
computation you described, the other [2] using voxel approximation (but
for your case, computing actual overlaps is not that difficult and much
more precise).

Jan

[1] https://yade-dem.org/doc/yade.utils.html#yade._utils.porosity
[2] https://yade-dem.org/doc/yade.utils.html#yade._utils.voxelPorosity





___
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] Migrating to GitLab

[Jerome Duriez]

Hello everyone,

In terms of Gitlab vs Github


Lazyness would tend to make me think to stay on github to avoid the need 
for adaptation (at least registering a new account on gitlab I guess ?), 
but this is not a real opinion. Hence some questions.


Would we have new features using gitlab ? I got more and more used to 
github and like it for its commit comments / pull requests / issues. We 
actually barely / do not use those... ;-) but maybe this could change in 
the future. Would we have the same on gitlab ? (Yes ?)


I also see there are gtilab versions that require a fee ([1] in your 
email). Are we going to use (for the integration framework) a free 
version ? Or do we start to have funds available for Yade development 
(which would be good news ;-) ). Do we use the actual gitlab, or a 
Grenoble-dedicated gitlab ([2] in your email) ?



Branch management model
*

This a major discussion for me, that would deserve a thread on its own 
(and more than two participants hopefully), I think.



1. Regarding the possibility to update trunk from other branchs only: 
this would mean every dev should make a public branch before pushing to 
trunk/master ?



2. Regarding the more global question of pre-assessing changes:

I think a more controlled / pre-assessed way of doing things is not be 
possible with our current HR.


Typically, people can not do otherwise than looking closely at things 
when they are directly concerned (which is not always obvious to realize 
by the way). Everyone (both of us at least) have in mind our recent 
emails about https://bugs.launchpad.net/yade/+bug/1804621, the initial 
commit [*], and the ensuing email on Yade-dev [**]. In this case, the 
commit was announced beforehand on the mailing list, its exact 
consequences (in terms of modifying tuples to lists) stated [***]. And 
still an unforeseen problem did arise and many emails exchanged.


I'm taking this example to just support my point we don't have the HR 
with enough time and a fully comprehensive knowledge of Yade (if this is 
still possible) for meaningful pre-assessment reviews to happen.
I could take other examples (my past proposal for InsertionSortCollider 
-- link provided upon request, not an issue anymore --, a current pull 
request at []) to show things the other way: when changes have been 
refrained until a close review which never happened.



I'm thus 100% happy with our current way of doing things, as far as I'm 
concerned, and would not be in favor of changing things towards a 
tighter control. I think this could only freeze (collective, at least) 
development.


I understand this current way of doing things is stressful for computing 
cluster users, but I see this stress being inherent to an evolving free, 
open-source code that comes "with no warranty"...



Jérôme


[*] 
https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1

[**] https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg13652.html
[***] 
https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg13339.html

[] https://github.com/yade/trunk/pull/55

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 27/11/2018 19:54, Bruno Chareyre wrote:

Hi devs,
This is an announcement (1) and call for opinions (2).

(1)  We will be migrating the integration framework to GitLab.com 
soon. That is: the config of buildbot, doc generation, and packaging 
will be using gitlab and will be hosted on gitlab.com [1], while 
hardware ressources will be provided locally by 3SR and/or Gricad's 
Gitlab [2].

It should increase flexibility and decrease maintainance issues.
Rémi made most of the work already (thank you!). Curious about it? You 
can check [3].

The switch could happen in a couple months.

___
(2)
GitLab.com could also host the master branch in replacement of 
GitHub.com. It is not required though, and there is no problem to keep 
it on GitHub (like we kept bug tracking on launchpad after moving 
master to github), or not. This is open question to me. Migrating a 
branch is easy to do and easy to revert, so there is no technical 
constraint on us. It just needs to decide if we want to keep github or 
adopt gitlab for the source code (or both...).


If source code was migrated, same question for bug tracking and answers?

Whatever is decided for the above, the migration is also a good 
opportunity to think about the branch management model. Are we happy 
with it?
Currently we have a centralized usage of a distributed CVS. Most 
contributors push to master directly  with strictly no pre-assessement 
of the contributions. Another possible (and classical) model would be 
to only accept merge requests from other branches. Which can have 
advantages, namely: easier to review since the the requests will 
usually collect a larger number of commits 

Re: [Yade-dev] Mathr::ZERO_TOLERANCE vs Mathr::EPSILON

[Jerome Duriez]

As for history/archeology, it looks like Vaclav introduced this code [*] 
(completing the previous commit [**])


I'd thus propose to get rid of ZERO_TOLERANCE at least, replacing with 
EPSILON where it is currently used.



Thoughts ?


(As for me, tolerance would for instance be  useful to know when an 
increasing value (x, increasing from x0 < a) can be detected as entering 
an interval [a,b], accounting for a possibly blurred comparison between 
x and a. Would you consider this as very specific ? :-) )



[*] 
https://github.com/yade/trunk/commit/2172ceb5af8704bf5073f82acfdd8686c89d3c99
[**] 
https://github.com/yade/trunk/commit/6e5e0a8d1e8008855109bd28bd7098129026f2d2


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 15/11/2018 16:21, Bruno Chareyre wrote:

Hi Jérôme,
I don't know, but I guess they were introduced independently by 
different authors.
I actually don't know why we would need to define tolerance at all, 
unless in very specific cases.


For instance I judge that a line like this (ViscoelasticPM.cpp) is not 
only useless but actually wrong:

if (std::abs(cn1) <= Mathr::ZERO_TOLERANCE ) cn1=0;

If it's small let it be small. No need to make it zero. And since cn1 
is not dimensionless it implies that currently the accuracy depends on 
a specific choice of units...


Bruno




Bruno

On 11/15/18 3:54 PM, Jerome Duriez wrote:

Hello,

Out of curiosity, why do we have both Mathr::ZERO_TOLERANCE and 
Mathr::EPSILON in the code [*] ?


I would understand they're both intended to give an expected 
magnitude of rounding errors. (Note that ZERO_TOLERANCE is hardcoded 
as 1e-20, while EPSILON is ~ 2e-16 here)


Both are used throughout the code (EPSILON more often ?)


Thanks,

Jérôme



[*] 
https://github.com/yade/trunk/blob/3269232e4982c1aa527581a200a0224555b09a1e/lib/base/Math.cpp


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
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



___
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

[Yade-dev] Mathr::ZERO_TOLERANCE vs Mathr::EPSILON

[Jerome Duriez]

Hello,

Out of curiosity, why do we have both Mathr::ZERO_TOLERANCE and 
Mathr::EPSILON in the code [*] ?


I would understand they're both intended to give an expected magnitude 
of rounding errors. (Note that ZERO_TOLERANCE is hardcoded as 1e-20, 
while EPSILON is ~ 2e-16 here)


Both are used throughout the code (EPSILON more often ?)


Thanks,

Jérôme



[*] 
https://github.com/yade/trunk/blob/3269232e4982c1aa527581a200a0224555b09a1e/lib/base/Math.cpp


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
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] Buildbot failure

[Jerome Duriez]

Hi Robert,

My understanding of these failures was rather there was read/write 
permission problems on the buildbot ? [*]


As you probably know, the buildbot is in Grenoble 3SR lab, and only 
Bruno and remi.caillet...@3sr-grenoble.fr (but Rémi is no more at 3SR if 
I understood correctly ?...) could have access.



Thanks anyway for your efforts getting rid of these "buildbot failure" 
messages ! ;-)



Jérôme

PS: are you not yourself in Grenoble actually ?

[*] 
https://yade-dem.org/buildbot/builders/yade-full/builds/4844/steps/test/logs/stdio 




--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 05/11/2018 11:26, Robert Caulk wrote:

Hello Yade devs,

It seems the buildbot's tmp/ directory might be in need of cleaning or 
restructuring considering the current error (which is preventing a 
full build):


mktemp: failed to create directory via template 
'/tmp/xvfb-run.XX': Too many links


Tough to say what the problem really is without access to the 
buildbot, but I found this blog post discussing a possible long term 
fix [1]. I am happy to troubleshoot more if someone can help me access 
the buildbot :-)


https://blog.nexcess.net/2012/04/27/mkdir-too-many-links-what-it-is-and-how-to-fix/

Cheers,

Robert

___
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] Building Documentation

[Jerome Duriez]

Hi Alex,

At least, I get the same behavior as you, here.

Cheers,

Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 10/10/2018 18:05, Eulitz, Alexander wrote:


Hi,

I just tried building the documentation from source according to [1] 
(just locally for evaluating changes I’d like to make at the doc).


The build succeeded with some warnings. Anyway I cant find the 
documentation in the folder given in the manual:


/path/to/installfolder/share/doc/yade-your-version

instead I can find it here:

/path/to/buildfolder/doc/sphinx/_build/html

Is this the usual behaviour?

Cheers

Alex

[1] https://yade-dem.org/doc/installation.html#source-code


___
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] Compilation (cmake) options Doc

[Jerome Duriez]

See 
https://github.com/yade/trunk/commit/0a292779b6a474442c1cbaaf4f7cefeab6621d9a. 
Thanks


Acutally I'm now seeing things the other way, and wonder about the point 
having the options list as comments in CMakeLists.txt, in addition to 
sphinx doc...
I noticed CHOLMOD_GPU was effective in CMakeLists code, present in 
sphinx doc, but not in the comments of the file ;-) (my last parenthesis 
in my previous email.)


Just a thought

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 03/09/2018 16:45, Bruno Chareyre wrote:

Hi Jérôme,
It sounds like a good idea to provide a pointer to CMakeLists.txt in 
this paragraph(*) yet there is no reason to remove the current doc, 
better update it.
Removing doc to show people they can read source code is not a very 
good direction in general, 99% of yade users have no interest in 
discovering cmake.
Personally, I'm also frequently going back to the install page (e.g. 
to check the syntax of a particular feature) and I'm happy that the 
info is not more clicks away from the info I need.


Further, the doc is also supposed to produce a self-contained 
printable document. If some content is removed from this document it 
is clearly a regression.


Bruno

(*) e.g. "(an updated list can be retrieved _here_)"

On 09/03/2018 02:51 PM, Jerome Duriez wrote:

Hi,

In the source installation doc [*] I'm proposing to directly point 
towards https://github.com/yade/trunk/blob/master/CMakeLists.txt for 
a list of compilation options, instead of having the paragraph "The 
following options are available: [...]"


In the current state, there are at least three possible compilation 
options that are not listed in [*] but that do exist: 
ENABLE_POTENTIAL_PARTICLES, ENABLE_DEFORM and ENABLE_OAR.


By removing the "The following options are available" § from the 
sphinx doc, the risk of such a out-of-sync situation would disappear 
(and it would learn reader of the doc the existence/role of 
CMakeLists.txt)



(And there would only remain the difficulty to keep in-sync the 
beginning of CMakeLists.txt with the tasks this file actually 
performs ;-) )



Thoughts ?


[*] https://yade-dem.org/doc/installation.html#compilation

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
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



___
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] Shop::aabbExtrema() : from boost::python::tuple return type to std::vector ?

[Jerome Duriez]

See this commit. 
<https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1>


Regarding your suggestions, Bruno :

" - dereferencing body pointer without checking it"
should be corrected now [*]

"- dynamic cast"
Are you referring to the Shape cast [**] ? If yes, I understand it as a 
good thing to check whether we indeed have a sphere and did not touch it.


"- only works for spheres"
Yes, at least it is clearly stated in the doc.. I'm actually not aware 
of a more generic extrema function somewhere else...



Still open to further changes obviously, thanks,

Jérôme

[*] 
https://github.com/yade/trunk/blob/1db13fb1183b9e294dc9761da76cfa4fc2791cc1/pkg/dem/Shop_02.cpp#L879
[**] 
https://github.com/yade/trunk/blob/1db13fb1183b9e294dc9761da76cfa4fc2791cc1/pkg/dem/Shop_02.cpp#L880


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 08/08/2018 15:54, Bruno Chareyre wrote:

Hi Jérôme,
This change would be sensible, seems to me (especially regarding your 
second bullet point).

Note that pair would make more sense than a vector<>.

I would point out that the implementation of this function looks 
sloppy in various other ways:

- dereferencing body pointer without checking it
- dynamic cast
- only works for spheres

Isn't there a more generic extrema function somewhere? I'm wondering.

Bruno



On 1 August 2018 at 14:29, Jerome Duriez <mailto:jerome.dur...@irstea.fr>> wrote:


Hi again,

I would like changing in pkg/dem/Shop*pp the py::tuple
aabbExtrema() [*] to std::vectoraabbExtrema() (keeping
obviously the Python exposure).


I think this would

- make the Shop C++ files one (small) step closer from the ideal
situation discussed at
https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg13308.html
<https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg13308.html>

- thus avoiding the back and forth Python-C++ boost conversions in
all C++ uses of aabbExtrema() e.g. [**]

- help me solving easily
https://bugs.launchpad.net/yade/+bug/1764424
<https://bugs.launchpad.net/yade/+bug/1764424> ;-) (thanks Jan for
suggestion)

- change (I guess, after py/wrapper/customConverters.cpp) from the
user's side the aabbExtrema() value (after typed in YADE terminal)
from a tuple to a list...


Thoughts ?

Jérôme

[*]
https://github.com/yade/trunk/blob/master/pkg/dem/Shop.hpp#L165
<https://github.com/yade/trunk/blob/master/pkg/dem/Shop.hpp#L165>
and
https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L874
<https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L874>
[**]
https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L352
<https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L352>
and L353

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
Mailing list: https://launchpad.net/~yade-dev
<https://launchpad.net/%7Eyade-dev>
Post to     : yade-dev@lists.launchpad.net
<mailto:yade-dev@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~yade-dev
<https://launchpad.net/%7Eyade-dev>
More help   : https://help.launchpad.net/ListHelp
<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



___
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

[Yade-dev] Shop::aabbExtrema() : from boost::python::tuple return type to std::vector ?

[Jerome Duriez]

Hi again,

I would like changing in pkg/dem/Shop*pp the py::tuple aabbExtrema() [*] 
to std::vectoraabbExtrema() (keeping obviously the Python 
exposure).



I think this would

- make the Shop C++ files one (small) step closer from the ideal 
situation discussed at 
https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg13308.html


- thus avoiding the back and forth Python-C++ boost conversions in all 
C++ uses of aabbExtrema() e.g. [**]


- help me solving easily https://bugs.launchpad.net/yade/+bug/1764424 
;-) (thanks Jan for suggestion)


- change (I guess, after py/wrapper/customConverters.cpp) from the 
user's side the aabbExtrema() value (after typed in YADE terminal) from 
a tuple to a list...



Thoughts ?

Jérôme

[*] https://github.com/yade/trunk/blob/master/pkg/dem/Shop.hpp#L165 and 
https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L874
[**] https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L352 
and L353


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
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] Dynamic vs Fixed for bodies utils functions

[Jerome Duriez]

Thanks for feedback, what did you have in mind with "aliasing" ?
I do not know (nor could find) any Python aliasing thing which I could 
understand as being possibly useful here..


To enable both dynamic and fixed to be accepted, I could only imagine 
for now adding (**kwargs) to the functions signatures.
While this may not harm for _commonBodySetup() (because this function is 
quite transparent from an user's point of view), it would probably be a 
bad thing for sphere() et al. functions (for their documentations at least)




--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 27/07/2018 21:18, Bruno Chareyre wrote:
Hi Jérôme, I discover the situation with your email and I agree that 
it can be improved (looks like).
A good fix would need to clarify the meaning (or is it already clear 
that fixed == !dynamic everywhere?), then it is easy to make both 
accepted through aliasing.

Removing one of the two seems awkward based on your summary.
Cheers
B

Le jeu. 26 juil. 2018 18:07, Jerome Duriez <mailto:jerome.dur...@irstea.fr>> a écrit :


Hi,

As you may know, the Python (utils module) functions for creating
bodies
make a more or less redundant use of the two "dynamic" and "fixed"
boolean parameters.


It seems to me both are usually accepted with different behaviors:
- for sphere() and box(), both are passed to _commonBodySetup where
/dynamic/ (when given by the user) will rule without mercy over
/fixed/. [1]
- facet(), tetraPoly(), tetra(), polyhedron() also accept both but
makes
no use whatsoever of /dynamic/ ;-)

As a matter of fact, and since one commit in 2010 [2], the /dynamic/
keyword is said to be deprecated but the fact is it is still
here... It
also directly appears in the rest of the code (contrary to
/fixed/) as
Body.dynamic [3] and is commented as such in the doc [4].

On the other hand, the use of fixed seems to be more frequent in the
script examples (I did not try here to distinguish between the
working
examples and the non-working ones ;-) though..)...


In case you agree with my description, would you also agree with some
changes here ?

If yes, my personal choice would be to just keep /dynamic/. Note that
the risks for breaking backwards compatibility for old Python scripts
may be reduced by:
- keeping just the /dynamic/ attribute in _commonBodySetup() which is
never used directly by the users
- removing the fixed parameter from sphere() and box()
- modify the facet(), tetraPoly(), tetra(), polyhedron() code to just
pass /dynamic/ to _commonBodySetup(), possibly keeping the /fi//xed/
name in these functions signatures if you prefer to.
(?)


What are your opinions / use of these keywords ?


Jérôme

[1] https://github.com/yade/trunk/blob/master/py/utils.py#L131
[2]

https://github.com/yade/trunk/commit/d8e420ed569c6b4ec3569282df925a5035513d24
[3]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Body.dynamic
[4] https://yade-dem.org/doc/user.html#motion-constraints

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
Mailing list: https://launchpad.net/~yade-dev
<https://launchpad.net/%7Eyade-dev>
Post to     : yade-dev@lists.launchpad.net
<mailto:yade-dev@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~yade-dev
<https://launchpad.net/%7Eyade-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



___
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

[Yade-dev] Dynamic vs Fixed for bodies utils functions

[Jerome Duriez]

Hi,

As you may know, the Python (utils module) functions for creating bodies 
make a more or less redundant use of the two "dynamic" and "fixed" 
boolean parameters.



It seems to me both are usually accepted with different behaviors:
- for sphere() and box(), both are passed to _commonBodySetup where 
/dynamic/ (when given by the user) will rule without mercy over /fixed/. [1]
- facet(), tetraPoly(), tetra(), polyhedron() also accept both but makes 
no use whatsoever of /dynamic/ ;-)


As a matter of fact, and since one commit in 2010 [2], the /dynamic/ 
keyword is said to be deprecated but the fact is it is still here... It 
also directly appears in the rest of the code (contrary to /fixed/) as 
Body.dynamic [3] and is commented as such in the doc [4].


On the other hand, the use of fixed seems to be more frequent in the 
script examples (I did not try here to distinguish between the working 
examples and the non-working ones ;-) though..)...



In case you agree with my description, would you also agree with some 
changes here ?


If yes, my personal choice would be to just keep /dynamic/. Note that 
the risks for breaking backwards compatibility for old Python scripts 
may be reduced by:
- keeping just the /dynamic/ attribute in _commonBodySetup() which is 
never used directly by the users

- removing the fixed parameter from sphere() and box()
- modify the facet(), tetraPoly(), tetra(), polyhedron() code to just 
pass /dynamic/ to _commonBodySetup(), possibly keeping the /fi//xed/ 
name in these functions signatures if you prefer to.

(?)


What are your opinions / use of these keywords ?


Jérôme

[1] https://github.com/yade/trunk/blob/master/py/utils.py#L131
[2] 
https://github.com/yade/trunk/commit/d8e420ed569c6b4ec3569282df925a5035513d24

[3] https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Body.dynamic
[4] https://yade-dem.org/doc/user.html#motion-constraints

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
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] Why _utils.hpp and Shop.hpp ? Shop::getPorosity vs Shop__getPorosity

[Jerome Duriez]

Thanks for the 1st opinion, Jan.

To be clear, I do not want to propose any changes, it's just I'm writing 
these days C++ functions with Python exposure, and I try to understand 
the rationale (if any) behind this architecture before I reproduce it...


Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 16/07/2018 14:14, Jan Stránský wrote:

Hi Jerome,

below please find my opinion. If the approach proposed by you works 
and does not break existing code (or it is not easy to fix it), I 
would have nothing against the refactoring.



What is the reason for having (for instance) Shop__getPorosity()
in py/_utils.hpp/cpp and Shop::getPorosity() in pkg/dem/Shop.hpp /
Shop_01.cpp ?


In **my opinion**:
1) Shop functions should be C++ only, not returning or accepting 
boost::python stuff. The python stuff (like converting std::vector to 
python tuple/list or modifying input/output like [1]) is (should be) 
the reason for py/_utils existence.
2) In the same way, there should not be non-python function in 
py/_utils (should be moved to Shop).

Not 1) nor 2) is the case now..

Maybe the scene as argument is left from the past and it is safe to 
remove it?


I wanted to write that another reason could be compatibility, because 
come functions are named differently in C++and python (e.g. 
bodyStressTensor and getStressLWForEachBody), but this is irrelevant 
since you can have any name for python functions (put here for 
backward reference if anybody has the same idea :-)



having py/_utils.*pp in addition to pkg/dem/Shop* 



Both following comments are extensions of my first paragraph

There are some "python wrapping", see e.g. [1], where the inputs and 
return types are a bit modified to be more user friendly (you don't 
need to create a Material first, pass it to function and dig data from 
it, a plain dict is returned).


But more importantly, to be able to have these Shop functions in 
Python, you need some boost::python tricks, which IMO should be placed 
in a separate file, so py/_utils.*pp would stay anyway (although it 
could be cleaner).



cheers
Jan

[1] https://github.com/yade/trunk/blob/master/py/_utils.cpp#L111



2018-07-16 11:21 GMT+02:00 Jerome Duriez <mailto:jerome.dur...@irstea.fr>>:


Hi,

What is the reason for having (for instance) Shop__getPorosity()
in py/_utils.hpp/cpp and Shop::getPorosity() in pkg/dem/Shop.hpp /
Shop_01.cpp ?

I can see the latter has "scene" as an argument [1] in addition to
"volume" (contrary to the former [2]), but probably this could be
removed from the definition, always using
Omega::instance().getScene() in the implementation [3] ? So, I'm
not sure this is the reason

Is this for Python wrapping ? Could we not use Shop::getPorosity
(once we removed the scene argument) at
https://github.com/yade/trunk/blob/master/py/_utils.cpp#L463
<https://github.com/yade/trunk/blob/master/py/_utils.cpp#L463> ?


The same question goes for many other functions, I guess, and the
general philosophy behind having py/_utils.*pp in addition to
pkg/dem/Shop*

Thank you,

Jérôme


[1] https://github.com/yade/trunk/blob/master/pkg/dem/Shop.hpp#L56
<https://github.com/yade/trunk/blob/master/pkg/dem/Shop.hpp#L56>
[2] https://github.com/yade/trunk/blob/master/py/_utils.hpp#L123
<https://github.com/yade/trunk/blob/master/py/_utils.hpp#L123>
[3] just modifying
https://github.com/yade/trunk/blob/master/pkg/dem/Shop_01.cpp#L300
<https://github.com/yade/trunk/blob/master/pkg/dem/Shop_01.cpp#L300>

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
Mailing list: https://launchpad.net/~yade-dev
<https://launchpad.net/%7Eyade-dev>
Post to     : yade-dev@lists.launchpad.net
<mailto:yade-dev@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~yade-dev
<https://launchpad.net/%7Eyade-dev>
More help   : https://help.launchpad.net/ListHelp
<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



___
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

[Yade-dev] Why _utils.hpp and Shop.hpp ? Shop::getPorosity vs Shop__getPorosity

[Jerome Duriez]

Hi,

What is the reason for having (for instance) Shop__getPorosity() in 
py/_utils.hpp/cpp and Shop::getPorosity() in pkg/dem/Shop.hpp / 
Shop_01.cpp ?


I can see the latter has "scene" as an argument [1] in addition to 
"volume" (contrary to the former [2]), but probably this could be 
removed from the definition, always using Omega::instance().getScene() 
in the implementation [3] ? So, I'm not sure this is the reason


Is this for Python wrapping ? Could we not use Shop::getPorosity (once 
we removed the scene argument) at 
https://github.com/yade/trunk/blob/master/py/_utils.cpp#L463 ?



The same question goes for many other functions, I guess, and the 
general philosophy behind having py/_utils.*pp in addition to pkg/dem/Shop*


Thank you,

Jérôme


[1] https://github.com/yade/trunk/blob/master/pkg/dem/Shop.hpp#L56
[2] https://github.com/yade/trunk/blob/master/py/_utils.hpp#L123
[3] just modifying 
https://github.com/yade/trunk/blob/master/pkg/dem/Shop_01.cpp#L300


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

___
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] About pastebin and data files in launchpad questions

[Jerome Duriez]

Hi all,

I agree Bruno with your description of the annoying extra efforts that 
are required to try to help with such questions. As far as I am 
concerned, I do not try downloading things and help in these cases...


My first suggestion would be to further push users to propose (for real 
!!!) minimal working examples, but I think the only efficient way to do 
this would be not answering many of the questions and Jan is probably 
too kind for that ;-)


Anyway, I think myself it sounds realistic to ask users to avoid extra 
files in their MWE, and do not have any other suggestions..



Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 29/06/2018 12:33, Bruno Chareyre wrote:

Hi Yade devs,
When I try to save a few minutes to answer some questions I very ofen 
find myself clicking here and there to access a pastebin file which is 
needed for a given script to run. The [pastebin|whateve|...] file 
can't downloaded directly in many cases. I then have to copy - which 
can imply substantial scrooling, paste, save in the right place, go 
back to terminal, run.
And sometimes it is just to find that the script itself will not run, 
even with the proper data file.


If you want to see this cycle in action you can have a look at [1] 
where four posts more or less are just to sort out the data files, 
implying than Jan had to repeatedly reproduce the cycle mentioned 
above. Worth mentioning, post #11 introduces additional links for the 
same filenames (same content? who knows?), so it is absolutely unclear 
now what someone is supposed to download to simply test a script and 
help someone else.


I was thinking that we could go deeper in the MWE part of 
https://yade-dem.org/wiki/Howtoask, to push questionners toward 
self-contained scripts.
An issue is that even among the devs I see this tendency to manipulate 
data files.
There are a few cases where it can't be avoided, like stl mesh. But in 
most cases I think a data file is not needed MWE, specifically for 
sphere positions and clump data (which are just positions).
What do you think? Does it sound realistic to ask users to avoid extra 
files in MWEs?


We could even provide a way to make sure that no "file not found" will 
occur. For instance, every mwe.py should be compatible with:

mkdir MWE
cp mwe.py ./MWE/mweTest.py
cd MWE
/path/to/yade mweTest.py
rm -rf ../MWE

Other suggestions?

Bruno

[1] https://answers.launchpad.net/yade/+question/670501



___
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] Python 2 removal

[Jerome Duriez]

Hi Anton,

I'd consider this idea, ie I have some time and motivation, and no 
knowledge.. :-)
Moreover / instead possible personal efforts, I could also look into the 
possibility proposing a dedicated internship to some IT (with an 
emphasis on the "I") student.


Since I do not have a precise perception of the task, what is your 
opinion regarding the internship option ?
Would the migration be indeed feasible in this framework ? For which 
internship duration (1 month, 5 month, .. ?) and which education level 
(license/undergraduate, master/graduate, .. ?)


We can discuss by direct emails if appropriate,


Best,

Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 07/05/2018 20:09, Anton Gladky wrote:

Dear Yade developers,

Python 2 reaches end of life and will probably removed
soon from Debian [1] and then most probably from Ubuntu-Mint
etc archives too. It is only the question of time. I think it will unlikely
happen till the Buster release (mid 2019), but it will probably
happen at the end of 2019.

Anyway, the migration of Yade onto Python 3 of Yade is really
necessary to guarantee the further project life in modern distributions.

It would be good if somebody finds some resources (time, man
power) and start this work. It should not be too difficult, but
requires time, knowledge and motivation to do this migration.

It will be necessary to guarantee the smooth migration period not
to break the other's work.

I will not do it due to extreme lack of free time, but can do some
kind of review/advice/etc.

[1] https://lists.debian.org/debian-devel/2018/04/msg00508.html

Best regards

Anton

___
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

[Yade-dev] Use of boost::python::extract() in Engine::action()

[Jerome Duriez]

Hi,

In connection with the bug [*], I'm trying to familiarize myself with 
boost::python.
As an example, I would like to extract in the c++ world a python 
integer, something I can achieve outside YADE but not within:



When building my own c++ program (see the attached testBP.cpp) the two 
following lines of code are OK:


// * c++ lines OK outside YADE, not within: *
  boost::python::object pythonNumber(5);
  int cNumber = boost::python::extract(pythonNumber);
// *


On the other hand, when inserted e.g. in NewtonIntegrator::action(), the 
two exact same lines will induce a segmentation fault, e.g. with the 
following MWE (note the funny difference between O.step() and O.run()..)


# * MWE of YADE script that seg faults with the above c++ lines e.g. 
in NewtonIntegrator::action() : 

  O.bodies.append(sphere(Vector3(0,0,0),radius=1))
  O.run(1) #O.step() would work...
# *


Would anyone have an understanding of this behavior ?

Thanks,

Jérôme

[*] https://bugs.launchpad.net/yade/+bug/1764424


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

// a test using boost::python::object and boost::python::extract, to compile with:

// g++ -I /usr/include/python2.7/ testBP.cpp -o testBP -lboost_python-py27 -lpython2.7


#include 
#include 
#include 

int main(){

  Py_Initialize(); // not necessary in YADE source code (Py_IsInitialized() already equals 1 therein, logically..)

  boost::python::object pythonNumber(5);
  int cNumber = boost::python::extract(pythonNumber);
  
  std::cout << "Number extracted:" << cNumber <<  std::endl;
  return 0;
}

// ./testBP will output the expected message, wo any segmentation fault
___
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] Cmake !find metis and cholmod

[Jerome Duriez]

Hi Bruno,

I can compile 2018-05-22.git-f538da1 (I just "git pulled") without any 
problem.


Here are some of my cmake outputs, for info:

-- Found Cholmod in /usr/lib/x86_64-linux-gnu/libcholmod.so
-- Found OpenBlas in /usr/lib/libopenblas.so
-- Found Metis in /usr/lib/x86_64-linux-gnu/libmetis.so

-- ===
-- Yade configured with following features: Odeint VTK OpenMP GTS 
GUI-Qt5 CGAL PFVFLOW TWOPHASEFLOW LINSOLV GL2PS
-- Disabled features: CHOLMOD_GPU SPH DEFORM LIQMIGRATION LBMFLOW 
MASK_ARBITRARY PROFILING PotentialParticles PotentialBlocks



Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 22/05/2018 13:22, Bruno Chareyre wrote:

Hi there,

I see the buildbot fails to cmake/find those two libs. This is the 
main reason of current failure. Of course more #ifdef would hide the 
issue, but I would prefer to fix it. I have a question for you all.

_Anyone else got the same errors as below or it's only the buildbot?_
Thanks.
Bruno

Ref.
https://yade-dem.org/buildbot/builders/yade-full/builds/4618/steps/compile/logs/stdio
-- Could NOT find Cholmod (missing: CHOLMOD_LIBRARIES 
CHOLMOD_INCLUDE_DIR AMD_LIBRARY CAMD_LIBRARY COLAMD_LIBRARY 
CCOLAMD_LIBRARY) -- Found OpenBlas: /usr/lib/libopenblas.so -- Could 
NOT find Metis (missing: METIS_INCLUDE_DIR METIS_LIBRARY)

Leading to (that's where more consistent ifdef-ing could hide):
https://yade-dem.org/buildbot/builders/yade-full/builds/4618/steps/compile/logs/stdio/home/buildbot/yade/yade-full/src/pkg/pfv/TwoPhaseFlowEngine.hpp:159:59: 
error: 'LC' was not declared in this scope


--
___
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


Email too brief?
Here's why!http://emailcharter.org  



___
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] Ip2_FrictMat_FrictMat_FrictPhys doc

[Jerome Duriez]

Looking at 
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Ip2_FrictMat_FrictMat_FrictPhys, 
I personally:


- do not see anywhere that $E_i$ = Frictmat.young

- do not see an exact expression for the shear contact stiffness.
I only see mentions of a shear sphere stiffness, and a mixed use of "ks, 
kn" vs "k1, k2" notations : the first paragraph (about normal direction) 
uses k1, k2 for "sphere stiffness" and kn for a "contact stiffness", 
then (regarding shear) ks is about "sphere stiffness", not the contact 
one anymore, and there is no more any k1 and k2..


- think the harmonic average of k1 and k2 is 2 * k1 * k2/ (k1 + k2) and 
not just k1*k2 / (k1 + k2)


- do not see an exact listing of all three contact parameters computed 
by Ip2_FrictMat_FrictMat_FrictPhys



Even though we all here are at ease with these models, I think the 
"young questions" we still face (me, few days ago here) should 
demonstrate there is room for improvement...
Hoping to avoid another 
https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg03051.html, 
I think the proposal below has the advantages to precisely give all 
expressions for the three relevant contact parameters, which I 
personally can not see for now in 
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Ip2_FrictMat_FrictMat_FrictPhys 
(for any parameter).



From your answers, I will obviously refrain from touching the general 
doc. And I'd propose a new version of Ip2_FrictMat_FrictMat_FrictPhys 
docstring keeping the physical explanations for the contact stiffness as


YADE_CLASS_BASE_DOC_ATTRS(Ip2_FrictMat_FrictMat_FrictPhys,IPhysFunctor,"Create 
a :yref:`FrictPhys` from two :yref:`FrictMats` as per the 
following expressions: \n\n$k_n = \\frac{E_1D_1*E_2D_2}{E_1D_1+E_2D_2}$ 
where $k_n=$ :yref:`FrictPhys.kn`, the $E_i$ are :yref:`FrictMat.young` 
for each contacting body $i=1;2$, and the $D_i$ are the bodies' 
(equivalent) diameters\n\n$k_s = 
\\frac{E_1D_1P_1*E_2D_2P_2}{E_1D_1P_1+E_2D_2P_2}$ where $k_s=$ 
:yref:`FrictPhys.ks` and the $P_i$ are the bodies' 
:yref:`FrictMat.poisson`\n\n$\\mu = \\tan(min(\\phi_1,\\phi_2))$ by 
default (see :yref:`frictAngle 
attribute`), where $\\mu=$ 
:yref:`FrictPhys.tangensOfFrictionAngle` and the $\\phi_i$ are the 
bodies' :yref:`FrictMat.frictionAngle`.\n\nThe $k_n,k_s$ expressions 
correspond to an harmonic average of particles compliances being 
proportionnal to $E_iD_i$ [Smilauer2010b]_"


As for the "(equivalent)" parenthesis diameter, the problem is 
Ip2_FrictMat_FrictMat_FrictPhys applies as well to bodies with 
non-spherical shape. I can remove this parenthesis / be more specific in 
terms of "GenericSpheresContact.refRi" if you prefer.


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cézanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

A free DEM conference in April: https://2ndyadeworkshop.sciencesconf.org/

On 22/02/2018 17:04, Bruno Chareyre wrote:

Hi Jérôme,
I am not in favor of removing some documentation, thank you for asking.
In my view such patch would be a regression. I don't understand the 
motivation, see below.


On 02/21/2018 05:59 PM, Jerome Duriez wrote:
After seeing Yet Another Doubts on "young" meaning / 
Ip2_FrictMat_FrictMat_FrictPhys contact model (a PhD student in my 
institute), I'm proposing to explicitly mention the underlying 
equations in the doc, once for all.
The corresponding would-be diff appears at the end of the email, you 
may also compare the attached screenshot with 
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Ip2_FrictMat_FrictMat_FrictPhys.


The equations are _already_ in the documentation as can be seen 
following the link, and you patch is not adding any if I read 
correctly. What the diff does is that it removes the physical 
explanations of the model. I am a bit lost then. Or maybe you did not 
paste the correct diff?


From the diff, you will see I'm also proposing to remove the 
"harmonic average stiffness" comment, for instance because there 
actually is a "2" factor missing/extra between the comment and the 
actual code.
The model is really based on an harmonic average, why is it better to 
hide it?

Where is the problem with a factor 2? Something to fix somewhere?
The patch is mentioning an "equivalent" diameter, what is that? 
Diameter is just true diameter.


In the case of the above-mentioned PhD student, confusion also arose 
because of https://yade-dem.org/doc/formulation.html#stiffnesses and 
https://yade-dem.org/doc/formulation.html#normal-stiffness.
As such, I would also propose to simply remove these two sections 
from the doc.
From my point of view, they actually are too Ip2-specific to appear 
in the general doc.
What was wrong in these sections based on the student feedback? What 
can be improved?
These sections describe what happens in 

[Yade-dev] Ip2_FrictMat_FrictMat_FrictPhys doc

[Jerome Duriez]

Hi,

After seeing Yet Another Doubts on "young" meaning / 
Ip2_FrictMat_FrictMat_FrictPhys contact model (a PhD student in my 
institute), I'm proposing to explicitly mention the underlying equations 
in the doc, once for all.
The corresponding would-be diff appears at the end of the email, you may 
also compare the attached screenshot with 
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Ip2_FrictMat_FrictMat_FrictPhys.
From the diff, you will see I'm also proposing to remove the "harmonic 
average stiffness" comment, for instance because there actually is a "2" 
factor missing/extra between the comment and the actual code.



In the case of the above-mentioned PhD student, confusion also arose 
because of https://yade-dem.org/doc/formulation.html#stiffnesses and 
https://yade-dem.org/doc/formulation.html#normal-stiffness.
As such, I would also propose to simply remove these two sections from 
the doc.
From my point of view, they actually are too Ip2-specific to appear in 
the general doc.



If necessary, a reference to the (equivalent) 2.2.1 and 2.2.1.1. 
sections from Vaclav's thesis ([Smilauer2010b] reference) could be 
introduced e.g. in Ip2_CpmMat_CpmMat_CpmPhys and 
Ip2_FrictMat_FrictMat_FrictPhys docstrings, to keep track of these 
comments that could be made concerning the Ip2 equations.



This email probably is Yet Another non-critical one, but since it deals 
about (the doc of) central pieces of code, and lines probably written by 
Vaclav, I'm opening a possible discussion here before performing the 
changes.



Jérôme

PS: next step would be to move 
https://yade-dem.org/doc/formulation.html#strain-evaluation to Ig2 
docstrings but I'm not planning on it...



** Diff herein proposed for commit **

diff --git a/pkg/dem/FrictPhys.cpp b/pkg/dem/FrictPhys.cpp
index cb904da..4f8ffe8 100644
--- a/pkg/dem/FrictPhys.cpp
+++ b/pkg/dem/FrictPhys.cpp
@@ -26,9 +26,7 @@ void Ip2_FrictMat_FrictMat_FrictPhys::go( const 
shared_ptr& b1

    Real Va = mat1->poisson;
    Real Vb = mat2->poisson;

-   //harmonic average of the two stiffnesses when (2*Ri*Ei) is the 
stiffness of a contact point on sphere "i"

    Real Kn = 2*Ea*Ra*Eb*Rb/(Ea*Ra+Eb*Rb);
-   //same for shear stiffness
    Real Ks = 2*Ea*Ra*Va*Eb*Rb*Vb/(Ea*Ra*Va+Eb*Rb*Vb);

    Real frictionAngle = (!frictAngle) ? 
std::min(mat1->frictionAngle,mat2->frictionAngle) : 
(*frictAngle)(mat1->id,mat2->id,mat1->frictionAngle,mat2->frictionAngle);


diff --git a/pkg/dem/FrictPhys.hpp b/pkg/dem/FrictPhys.hpp
index eeb2ef4..12c85ee 100644
--- a/pkg/dem/FrictPhys.hpp
+++ b/pkg/dem/FrictPhys.hpp
@@ -44,7 +44,7 @@ class Ip2_FrictMat_FrictMat_FrictPhys: public 
IPhysFunctor{

    const shared_ptr& b2,
    const shared_ptr& interaction);
    FUNCTOR2D(FrictMat,FrictMat);
- 
YADE_CLASS_BASE_DOC_ATTRS(Ip2_FrictMat_FrictMat_FrictPhys,IPhysFunctor,"Create 
a :yref:`FrictPhys` from two :yref:`FrictMats`. The compliance 
of one sphere under point load is defined here as $1/(E.D)$, with $E$ 
the stiffness of the sphere and $D$ its diameter. The compliance of the 
contact itself will be the sum of compliances from each sphere, i.e. 
$1/(E_1.D_1)+1/(E_2.D_2)$ in the general case, or $2/(E.D)$ in the 
special case of equal sizes and equal stiffness. Note that summing 
compliances corresponds to an harmonic average of stiffnesss (as in e.g. 
[Scholtes2009a]_), which is how kn is actually computed in the 
:yref:`Ip2_FrictMat_FrictMat_FrictPhys` functor:\n\n $k_n = 
\\frac{E_1D_1*E_2D_2}{E_1D_1+E_2D_2}=\\frac{k_1*k_2}{k_1+k_2}$, with 
$k_i=E_iD_i$.\n\n The shear stiffness ks of one sphere is defined via 
the material parameter :yref:`ElastMat::poisson`, as ks=poisson*kn, and 
the resulting shear stiffness of the interaction will be also an 
harmonic average. In the case of a contact between a :yref:`ViscElMat` 
and a :yref:`FrictMat`, be sure to set :yref:`FrictMat::young` and 
:yref:`FrictMat::poisson`, otherwise the default value will be used.",
+ 
YADE_CLASS_BASE_DOC_ATTRS(Ip2_FrictMat_FrictMat_FrictPhys,IPhysFunctor,"Create 
a :yref:`FrictPhys` from two :yref:`FrictMats` as per the 
following expressions: \n\n$k_n = \\frac{E_1D_1*E_2D_2}{E_1D_1+E_2D_2}$ 
where $k_n=$ :yref:`FrictPhys.kn`, the $E_i$ are :yref:`FrictMat.young` 
for each contacting body $i=1;2$, and the $D_i$ are the bodies' 
(equivalent) diameters\n\n$k_s = 
\\frac{E_1D_1P_1*E_2D_2P_2}{E_1D_1P_1+E_2D_2P_2}$ where $k_s=$ 
:yref:`FrictPhys.ks` and the $P_i$ are the bodies' 
:yref:`FrictMat.poisson`\n\n$\\mu = \\tan(min(\\phi_1,\\phi_2))$ by 
default (see :yref:`frictAngle 
attribute`), where $\\mu=$ 
:yref:`FrictPhys.tangensOfFrictionAngle` and the $\\phi_i$ are the 
bodies' :yref:`FrictMat.frictionAngle`.",


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cézanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

A free DEM conference 

Re: [Yade-dev] Mathjax/imgmath for math output in doc ?

[Jerome Duriez]

Answer:

By defaut, maths expressions are rendered in the sphinx doc as png 
images, which requires having "dvipng" installed on your machine.

"sudo apt install dvipng" solved my problem.

Hope it may help someone one day, at least..

Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cézanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

A free DEM conference in April: https://2ndyadeworkshop.sciencesconf.org/

On 20/02/2018 10:56, Jerome Duriez wrote:
The equations from https://yade-dem.org/doc/ actually look more like 
images than mathjax products [*], then the exact same two questions 
(below) seem rather to be about imgmath / pngmath things (sphinx 
extensions ?) than MathJax

Sorry for spamming..

[*] 
http://www.sphinx-doc.org/en/stable/ext/math.html#module-sphinx.ext.imgmath


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cézanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

A free DEM conference in April:https://2ndyadeworkshop.sciencesconf.org/

On 20/02/2018 10:45, Jerome Duriez wrote:

Hi,

When I locally build the doc for my local YADE versions (launching 
"make doc" from the build folder, and browsing afterwards 
doc/sphinx/_build/html/ in this build folder), all maths latex 
commands do not display properly in the local html pages I get.
Typing $k_n$ (or directly :math:`k_n`) in a docstring just gives 
"k_n" as such (without any other characters) in the corresponding html.


From my (limited) understanding, the reason could be a non-working 
MathJax thing on my system.


- do you confirm MathJax is necessary for doc-building with proper 
rendering of math expressions ?
- how do you deal with / install / configure MathJax on your systems 
? (if someone ever faced this issue ? on 3SR cluster responsible for 
https://yade-dem.org/doc/ at least ?)


Thanks,

Jérôme
--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cézanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

A free DEM conference in April:https://2ndyadeworkshop.sciencesconf.org/



___
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


___
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] Mathjax/imgmath for math output in doc ?

[Jerome Duriez]

The equations from https://yade-dem.org/doc/ actually look more like 
images than mathjax products [*], then the exact same two questions 
(below) seem rather to be about imgmath / pngmath things (sphinx 
extensions ?) than MathJax

Sorry for spamming..

[*] 
http://www.sphinx-doc.org/en/stable/ext/math.html#module-sphinx.ext.imgmath


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cézanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

A free DEM conference in April: https://2ndyadeworkshop.sciencesconf.org/

On 20/02/2018 10:45, Jerome Duriez wrote:

Hi,

When I locally build the doc for my local YADE versions (launching 
"make doc" from the build folder, and browsing afterwards 
doc/sphinx/_build/html/ in this build folder), all maths latex 
commands do not display properly in the local html pages I get.
Typing $k_n$ (or directly :math:`k_n`) in a docstring just gives "k_n" 
as such (without any other characters) in the corresponding html.


From my (limited) understanding, the reason could be a non-working 
MathJax thing on my system.


- do you confirm MathJax is necessary for doc-building with proper 
rendering of math expressions ?
- how do you deal with / install / configure MathJax on your systems ? 
(if someone ever faced this issue ? on 3SR cluster responsible for 
https://yade-dem.org/doc/ at least ?)


Thanks,

Jérôme
--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cézanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

A free DEM conference in April:https://2ndyadeworkshop.sciencesconf.org/



___
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] Yade related publication?

[Jerome Duriez]

Hi Robert,

Regarding your last two specific questions, my personal answers are "no".

Regarding, the general idea of your proposal, maybe I may refer you to a 
YADE-related paper published in SoftwareX (a journal aiming to give some 
credit to code development "per se" in scientific research, that has 
been discussed once here) :

[Haustein2017] from https://yade-dem.org/doc/publications.html.
Is this what you have in mind ?

Jérôme

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cézanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

A free DEM conference in April: https://2ndyadeworkshop.sciencesconf.org/

On 02/02/2018 19:37, Robert Caulk wrote:

Hey Yade Devs,

I am wondering if we have the demand to create a Yade related white 
paper publication. The publication would document very Yade specific 
functionalities and I imagine some papers might even highlight pieces 
code. I think the format would be very flexible, some releases might 
be 3 pages with brief summary and figures, while others might be 
formatted similarly to a conference paper. In all cases, I think we 
could maintain a quality archive by incorporating CrossRef, reviewing 
the writing/work, and laying out the documents consistently.


Is it possible for us to set up a conduit for Yade users/devs to 
release Yade specific research to the public domain? If so, I'd like 
to spearhead the project. If there is some reason why we specifically 
should not and cannot do this, please let me know. Otherwise, please 
take a moment to read the following questions. If you answer "yes" to 
either of these questions, do you mind replying and letting me know? 
This is my attempt to gauge interest. If we have none, I will scrap 
the idea entirely.


  * Do you have any Yade related work that does not fit into a
scientific journal, but has great value to existing/future Yade
users? For example: maybe you have some lab notes with figures
that exhibit some Yade functionality and you'd like to be able to
reference this in another paper/appendix/supporting material.
  * Do you have a conference/journal paper related to Yade that never
ended up being published, but you'd like to reference the work?

Best regards,

Robert




___
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] 2nd YADE workshop: Aix-en-Provence (France), April 26-27, 2018

[Jerome Duriez]

Dear YADE users and developers,

A gentle reminder on the second YADE workshop: *Discrete-based modeling 
of multi-scale coupled problems* to be held in *Aix-en-Provence* (south 
of France), on *April 26-27*, 2018.


Deadline for *abstract submission* has just been extended to *February 
2*, while (free of charge) registration is already open.


Please see *https://2ndyadeworkshop.sciencesconf.org/* for all details, 
including the current list of confirmed keynote speakers at 
https://2ndyadeworkshop.sciencesconf.org/resource/page/id/4.



Looking forward to welcoming you in Aix-en-Provence,

Jérôme Duriez for the organizing commitee

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cézanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

A free DEM conference in April: https://2ndyadeworkshop.sciencesconf.org/

On 19/12/2017 14:08, 2ndyadeworks...@irstea.fr wrote:

Dear YADE users and developers,

You are all invited to participate in the second Yet Another Discrete 
Element workshop: *Discrete-based modeling of multi-scale coupled 
problems*, that will take place in *Aix-en-Provence* (France), on 
*April 26-27, 2018*: https://2ndyadeworkshop.sciencesconf.org/


This workshop will welcome a wide variety of DEM-related discussions: 
from "DEM mechanical analysis of granular materials", to "Fluid-solid 
coupling in DEM", including "continuous numerical methods coupled with 
DEM", and technical discussions regarding "High-performance computing 
in DEM".
Oral presentation of your research in this field requires submittinga 
1-2 pages abstract before January 21, 2018, following the instructions 
at https://2ndyadeworkshop.sciencesconf.org/resource/page/id/1.


Registration to the workshop will be free of charge, including lunches 
and dinner (plus accommodation in case your institution belongs to the 
GdRI GeoMech network). Please see 
https://2ndyadeworkshop.sciencesconf.org/resource/page/id/3 for more 
details and the registration procedure.

Please note that the number of participants will be limited.


Looking forward to welcoming you in Aix-en-Provence (south of France), 
next April,


Jérôme Duriez for the organizing committee


___
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

[Yade-dev] YADE builds manually caused by unknown ?

[Jerome Duriez]

Hi there,

Out of curiosity, is there actually someone who is asking the buildbot 
to perform so much builds (of old revisions ?) ?
I'm referring here to the kind of builds [1] for which we got (quite 
often) this kind of email [2]


The fact that the "Revision" and "Got Revision" fields are often 
different on the web pages such as [1] is also mysterious too me...



Actually, I would love if 2018 could see some changes in these build emails.
If it is actually necessary that builds are so often manually triggered 
by someone, would it be possible to send emails only for the "new 
revision" (= "Scheduler" ?) builds ?


Do you feel the same ?

And happy New Year !

Jérôme

[1] https://yade-dem.org/buildbot/builders/yade-full/builds/4347
[2] https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg12812.html

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cézanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

A free DEM conference in April: https://2ndyadeworkshop.sciencesconf.org/

___
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] 2nd Yade-DEM workshop

[Jerome Duriez]

Thanks Klaus and others for your inputs.

The topic looks quite specific indeed, this is to match the scientific 
themes of my new position and, hopefully, to attract more easily 
external funding (in order to keep conferences fees as low as possible).
This being said, I wish to save e.g. a half day session for other YADE 
applications.


As for the date, nothing is really locked in yet actually, except 
"Summer 2018" at its ends (it's too hot here in the middle of summer !). 
Instead of 1st half June, it could be end of August as well, thank you 
Klaus for mentioning these other conferences.


Jérôme

Le 03/10/2017 à 06:49, Klaus Thoeni a écrit :

Hi Jerome,

congrats to your new position also from my side and thank you very much for
your initiative.

I had a look at your proposal which seems to be specifically related to hydro-
mechanical modelling. Is there any particular reason? If I remember correctly,
the first workshop was not related to a particular topic. I am just wondering
because you might be approaching different people.

Is the date locked in? I just came back from the Particles conference with the
following information. The next DEM8 conference is at Uni Twente, July 22-26
2019. Another international conference people might be attending is SolMech
2018, 27-31 Aug in Warsaw.

Thanks again for organising this.

Klaus


On Fri, 29 Sep 2017 01:11:33 PM Jerome Duriez wrote:

Dear all;


Attached is a very first draft of a possible "Call" for the workshop
(not published anywhere yet). I'm sharing it here in order to have some
feedback from your side on the date/venue/topics: all of those should
ideally fit you, so that we can get together.


I probably won't be able to drastically change these date/venue/topics,
but I could try to accommodate to some extent your suggestions/needs if
any.


As a side note, and depending on the success to the call (when
launched), I could try to plan some half-day session "YADE specials"
gathering very technical presentations/discussions on YADE itself, or
YADE-based scientific presentations at the scientific margins of the
workshop.


The goal is to advertise the workshop before end of (November ?) 2017,
but your inputs would be welcome much earlier than this date.


Let me know,


Jérôme

Le 04/09/2017 à 18:21, Jerome Duriez a écrit :

Hi there,


I 'm now in my new position (notwithstanding the used email address)
in french institute Irstea. It seems my new boss is very open to the
idea of such a workshop, probably including for what concerns his wallet.


I can thus push this idea further, probably with the help of Grenoble
to remind me the number of participants at the 1st workshop and to
give me an idea about the required credit (how much did the 1st
workshop cost ?).


I guess the goal could still be next summer for now. I noticed another
DEM symposium in Glasgow (UK) June 11th - June 18th 2018 (ECCM-ECFD
Conferences 2018), which could serve as a first random idea for the
Yade workshop dates in case we try to fit with another conference
where overseas participants could also go.


As for the venue (most important), it would be in Aix en Provence, a
lovely city near the French Riviera (the Cote d'Azur, along the
Mediterranean).


Thoughts ?


Jerome



----------

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:* July 20, 2017 5:08 AM
*To:* yade-dev@lists.launchpad.net
*Subject:* Re: [Yade-dev] 2nd Yade-DEM workshop
Hello Jérôme,
It sounds like an interesting option, thank you for suggestion.
There are many yade users at IRSTEA.
Keep in mind that organizing such things needs time to secure some
funding, followed by more time to announce the event (people will
hardly change their schedule if they discover it just a couple months
in advance) and invite some speakers. Next summer could be a bit too
early already if you'll start the position in september (congrats!).
Or you'd have to be very efficient. :)
Let us know when you know more precisely what could be possible.
Cheers
Bruno

On 07/14/2017 06:07 PM, Jerome Duriez wrote:

Hi,


I should start a new position in some french institute in September,
and trying to organize next summer a 2d Yade workshop there was
actually something I had in mind.


Since this position has not officially started and I did not discuss
this idea yet with anyone from this institute (with anyone else
before this email actually..) I won't give much more specifics at the
moment, but would like to say I'm interested in the idea.


I personally had in mind the standalone version, though I agree
combining with a greater conference would economically make sense. If
the combined versi

Re: [Yade-dev] 2nd Yade-DEM workshop

[Jerome Duriez]

Dear all;


Attached is a very first draft of a possible "Call" for the workshop 
(not published anywhere yet). I'm sharing it here in order to have some 
feedback from your side on the date/venue/topics: all of those should 
ideally fit you, so that we can get together.



I probably won't be able to drastically change these date/venue/topics, 
but I could try to accommodate to some extent your suggestions/needs if 
any.



As a side note, and depending on the success to the call (when 
launched), I could try to plan some half-day session "YADE specials" 
gathering very technical presentations/discussions on YADE itself, or 
YADE-based scientific presentations at the scientific margins of the 
workshop.



The goal is to advertise the workshop before end of (November ?) 2017, 
but your inputs would be welcome much earlier than this date.



Let me know,


Jérôme


Le 04/09/2017 à 18:21, Jerome Duriez a écrit :


Hi there,


I 'm now in my new position (notwithstanding the used email address) 
in french institute Irstea. It seems my new boss is very open to the 
idea of such a workshop, probably including for what concerns his wallet.



I can thus push this idea further, probably with the help of Grenoble 
to remind me the number of participants at the 1st workshop and to 
give me an idea about the required credit (how much did the 1st 
workshop cost ?).



I guess the goal could still be next summer for now. I noticed another 
DEM symposium in Glasgow (UK) June 11th - June 18th 2018 (ECCM-ECFD 
Conferences 2018), which could serve as a first random idea for the 
Yade workshop dates in case we try to fit with another conference 
where overseas participants could also go.



As for the venue (most important), it would be in Aix en Provence, a 
lovely city near the French Riviera (the Cote d'Azur, along the 
Mediterranean).



Thoughts ?


Jerome



------

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:* July 20, 2017 5:08 AM
*To:* yade-dev@lists.launchpad.net
*Subject:* Re: [Yade-dev] 2nd Yade-DEM workshop
Hello Jérôme,
It sounds like an interesting option, thank you for suggestion.
There are many yade users at IRSTEA.
Keep in mind that organizing such things needs time to secure some 
funding, followed by more time to announce the event (people will 
hardly change their schedule if they discover it just a couple months 
in advance) and invite some speakers. Next summer could be a bit too 
early already if you'll start the position in september (congrats!). 
Or you'd have to be very efficient. :)

Let us know when you know more precisely what could be possible.
Cheers
Bruno



On 07/14/2017 06:07 PM, Jerome Duriez wrote:


Hi,


I should start a new position in some french institute in September, 
and trying to organize next summer a 2d Yade workshop there was 
actually something I had in mind.



Since this position has not officially started and I did not discuss 
this idea yet with anyone from this institute (with anyone else 
before this email actually..) I won't give much more specifics at the 
moment, but would like to say I'm interested in the idea.



I personally had in mind the standalone version, though I agree 
combining with a greater conference would economically make sense. If 
the combined version should materialize, I'd propose to keep some 
strong YADE connection in the title (even though users from other 
codes may still be welcome), because that's what we are and I think 
there is already way enough micromechanics symposia...



Just to start the discussion...


Jerome



------

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...@3sr-grenoble.fr>

*Sent:* July 13, 2017 10:13 AM
*To:* Yade developers
*Subject:* [Yade-dev] 2nd Yade-DEM workshop
Hello,
No, I'm not announcing the next yade workshop. :-/
Following the 1st workshop in Grenoble, we have been considering the
possibility of having a second workshop in Freiberg (Anton's place).
With Anton flying to a different sky this will not happen.

I am writing this message as a call for proposals. If some of you have
good ideas on how to make another yade meeting happen please tell!
It could be a standalone event like the first workshop, but it could
also be a parallel event or some sort of special session
before/during/after a relevant conference. Having it included in a
conf. lik

Re: [Yade-dev] 2nd Yade-DEM workshop

[Jerome Duriez]

Hi there,


I 'm now in my new position (notwithstanding the used email address) in french 
institute Irstea. It seems my new boss is very open to the idea of such a 
workshop, probably including for what concerns his wallet.


I can thus push this idea further, probably with the help of Grenoble to remind 
me the number of participants at the 1st workshop and to give me an idea about 
the required credit (how much did the 1st workshop cost ?).


I guess the goal could still be next summer for now. I noticed another DEM 
symposium in Glasgow (UK) June 11th - June 18th 2018 (ECCM-ECFD Conferences 
2018), which could serve as a first random idea for the Yade workshop dates in 
case we try to fit with another conference where overseas participants could 
also go.


As for the venue (most important), it would be in Aix en Provence, a lovely 
city near the French Riviera (the Cote d'Azur, along the Mediterranean).


Thoughts ?


Jerome



--

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: July 20, 2017 5:08 AM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] 2nd Yade-DEM workshop

Hello Jérôme,
It sounds like an interesting option, thank you for suggestion.
There are many yade users at IRSTEA.
Keep in mind that organizing such things needs time to secure some funding, 
followed by more time to announce the event (people will hardly change their 
schedule if they discover it just a couple months in advance) and invite some 
speakers. Next summer could be a bit too early already if you'll start the 
position in september (congrats!). Or you'd have to be very efficient. :)
Let us know when you know more precisely what could be possible.
Cheers
Bruno



On 07/14/2017 06:07 PM, Jerome Duriez wrote:

Hi,


I should start a new position in some french institute in September, and trying 
to organize next summer a 2d Yade workshop there was actually something I had 
in mind.


Since this position has not officially started and I did not discuss this idea 
yet with anyone from this institute (with anyone else before this email 
actually..) I won't give much more specifics at the moment, but would like to 
say I'm interested in the idea.


I personally had in mind the standalone version, though I agree combining with 
a greater conference would economically make sense. If the combined version 
should materialize, I'd propose to keep some strong YADE connection in the 
title (even though users from other codes may still be welcome), because that's 
what we are and I think there is already way enough micromechanics symposia...


Just to start the discussion...


Jerome



------

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><mailto:yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net>
 on behalf of Bruno Chareyre 
<bruno.chare...@3sr-grenoble.fr><mailto:bruno.chare...@3sr-grenoble.fr>
Sent: July 13, 2017 10:13 AM
To: Yade developers
Subject: [Yade-dev] 2nd Yade-DEM workshop

Hello,
No, I'm not announcing the next yade workshop. :-/
Following the 1st workshop in Grenoble, we have been considering the
possibility of having a second workshop in Freiberg (Anton's place).
With Anton flying to a different sky this will not happen.

I am writing this message as a call for proposals. If some of you have
good ideas on how to make another yade meeting happen please tell!
It could be a standalone event like the first workshop, but it could
also be a parallel event or some sort of special session
before/during/after a relevant conference. Having it included in a
conf. like Particles/DEM/P probably needs action well before the
event (maybe 2-3 years at least) and to avoid the name "yade workshop"
(better "open source DEM" or something, and why not gathering other
DEM codes anyway?).

The idea of combining with another event is mainly to optimize travel
costs since, wherever it is,  some participants will have to travel a
long way.

The topic is now open to discussion. :)

Bruno


___
Mailing list: https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
Post to : yade-dev@lists.launchpad.net<mailto:yade-dev@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net<m

Re: [Yade-dev] 2nd Yade-DEM workshop

[Jerome Duriez]

Hi,


I should start a new position in some french institute in September, and trying 
to organize next summer a 2d Yade workshop there was actually something I had 
in mind.


Since this position has not officially started and I did not discuss this idea 
yet with anyone from this institute (with anyone else before this email 
actually..) I won't give much more specifics at the moment, but would like to 
say I'm interested in the idea.


I personally had in mind the standalone version, though I agree combining with 
a greater conference would economically make sense. If the combined version 
should materialize, I'd propose to keep some strong YADE connection in the 
title (even though users from other codes may still be welcome), because that's 
what we are and I think there is already way enough micromechanics symposia...


Just to start the discussion...


Jerome



--

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...@3sr-grenoble.fr>
Sent: July 13, 2017 10:13 AM
To: Yade developers
Subject: [Yade-dev] 2nd Yade-DEM workshop

Hello,
No, I'm not announcing the next yade workshop. :-/
Following the 1st workshop in Grenoble, we have been considering the
possibility of having a second workshop in Freiberg (Anton's place).
With Anton flying to a different sky this will not happen.

I am writing this message as a call for proposals. If some of you have
good ideas on how to make another yade meeting happen please tell!
It could be a standalone event like the first workshop, but it could
also be a parallel event or some sort of special session
before/during/after a relevant conference. Having it included in a
conf. like Particles/DEM/P probably needs action well before the
event (maybe 2-3 years at least) and to avoid the name "yade workshop"
(better "open source DEM" or something, and why not gathering other
DEM codes anyway?).

The idea of combining with another event is mainly to optimize travel
costs since, wherever it is,  some participants will have to travel a
long way.

The topic is now open to discussion. :)

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
___
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] Removing one check (regression) test

[Jerome Duriez]

I was actually wondering whether there might be something else in the sources 
that would define the list of the regression scripts.. Now, it's clear this 
list is just not perfectly updated (if already existing) at compilation time.


The rest is clear to me, thanks (to Klaus as well) !


Jerome



--

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 28, 2017 1:53 AM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] Removing one check (regression) test

Hello Jérôme,
What is in the Git trunk and what is/not in your build folders are independant 
things.
As soon as the file is removed from trunk nobody will check it out, then of 
course nobody will have to remove it from a fresh build.
The behavior you got is that of cmake, independently of git.
"git -rm file" is the right command, you need to "git commit file" after that, 
then "git push".

Thank you for cleaning!

Bruno


On 06/27/2017 07:25 PM, Jerome Duriez wrote:

Hi,


I'm in the process of removing 
Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity from trunk (I was 
probably the only one to ever use it). For the moment, I'd just like to remove 
one regression check test which is associated to this contact law 
(scripts/checks-and-tests/checks/checkTestNormalInelasticity.py), and I have a 
question.


After having 'git -rm' -ed this checkTestNormalInelasticity.py script, launched 
a 'cmake' command and a new compilation, yade --check still launches this 
regression script...

I could finally get rid of it only after cleaning install/lib folder (and a new 
make install): then, yade --check would not consider this .py script anymore.


However, I'm wondering if this is 'normal', or if I should do something else 
(than git -rm scripts/checks-and-tests/checks/checkTestNormalInelasticity.py) 
in the source before I push this regression script removal ?


Thanks,


Jerome


----------

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


Yade developers in Launchpad<https://launchpad.net/~yade-dev>
launchpad.net
yade-dev@lists.launchpad.net Policy: You must be a team member to subscribe to 
the team mailing list. View public archive View subscribers


___
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

[Yade-dev] Meaning/Doc of ViscoFrictPhys in connection with Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity

[Jerome Duriez]

Hi,


As said elsewhere, I'm removing 
Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity from trunk. The latter 
is mentionned in the doc of ViscoFrictPhys [*], with a formulation that even 
suggests that ViscoFrictPhys was necessary because of 
Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity.

However, I could not find in the code or in the archive any explanation how 
these two classes would be related..


Is there actually anything to take care of in ViscoFrictPhys when removing 
Law2_*_NormalInelasticity (outside removing the mention to 
Law2_*_NormalInelasticity in the docstring) ?


Jerome


[*] https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.ViscoFrictPhys


--

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

[Yade-dev] Removing one check (regression) test

[Jerome Duriez]

Hi,


I'm in the process of removing 
Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity from trunk (I was 
probably the only one to ever use it). For the moment, I'd just like to remove 
one regression check test which is associated to this contact law 
(scripts/checks-and-tests/checks/checkTestNormalInelasticity.py), and I have a 
question.


After having 'git -rm' -ed this checkTestNormalInelasticity.py script, launched 
a 'cmake' command and a new compilation, yade --check still launches this 
regression script...

I could finally get rid of it only after cleaning install/lib folder (and a new 
make install): then, yade --check would not consider this .py script anymore.


However, I'm wondering if this is 'normal', or if I should do something else 
(than git -rm scripts/checks-and-tests/checks/checkTestNormalInelasticity.py) 
in the source before I push this regression script removal ?


Thanks,


Jerome


--

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

[Yade-dev] No more commit emails ? (no more gitHub/trunk import into Launchpad)

[Jerome Duriez]

Hello,


It seems there is some issues with some Launchpad -- GitHub link, see the 
"Failed" for Import Details at 
https://code.launchpad.net/~yade-pkg/yade/git-trunk


I guess this is the reason why the yade-dev email address is no more notified 
about new gitHub "commits".

See the last email notification at [*] about revno 4044 (May 15th), 
corresponding to the last revision included in this Launchpad page.

There has been a bunch of other revisions, since


Since my understanding of the issue stops here, any explanations / solutions ?

(these email commit notifications were useful from my point of view)


Jerome


[*] http://www.mail-archive.com/yade-dev@lists.launchpad.net/msg12405.html



------

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] Frequency of documentation update

[Jerome Duriez]

Hi guys,


It seems to me the documentation update frequency is definitely an issue, now.

>From my PC, the website [*] has been out of sync with trunk for 2 months now, 
>and is still stuck in 2016. No activity on the buildbot since last November..


What happens ?


Jerome


[*] https://yade-dem.org/doc/

--

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 Jerome Duriez <jerome.dur...@ucalgary.ca>
Sent: November 16, 2016 11:51 AM
To: Yade dev
Subject: Re: [Yade-dev] Frequency of documentation update


Sorry guys, but the answers made me more confused...


I had in mind that the buildbot [*] (i.e. 3SR cluster I guess) updates the doc 
at https://yade-dem.org/doc/ each time it performs a "build". Which is supposed 
to happen in my mind very often (once a day and after each commit ?)


Has there been / is there / will there be changes on that side ?

(Looking at the build log, I'm just seeing the last build was indeed November 
1st, several commits ago)


[*] https://yade-dem.org/buildbot/

<https://yade-dem.org/buildbot/>

----------

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 Anton Gladky <gladky.an...@gmail.com>
Sent: November 16, 2016 11:35 AM
To: Yade developers
Subject: Re: [Yade-dev] Frequency of documentation update

2016-11-16 17:58 GMT+01:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>:
> We are actually changing this at the moment. If I'm not wrong (still
> possible because it is a bit intricate): previously the builds were
> triggered manually, by Anton, then the doc uploaded and yadedaily released.

Buildbot built and uploaded the documentation. Yadedaily builds only
offline documentation for packages.

Anton

___
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] FlowEngine.ipp.in: return values of volumeCell*()

[Jerome Duriez]

Ok, I indeed figured out since, that my crashes are (obviously ?) not related 
with this difference. Thanks for the information though,


Jerome



--

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: November 29, 2016 10:47 AM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] FlowEngine.ipp.in: return values of volumeCell*()



On 11/25/2016 06:46 PM, Jerome Duriez wrote:

Hi,


In pkg/pfg/FlowEngine.ipp.in, why do volumeCell() return directly a "volume" 
value [1], whereas other volumeCell*Fictious() functions return the std::abs() 
of "volume" [2] ?

Volume [1] is a signed volume and theoreticaly - at least - the sign can change 
over time (if one vertex go across a facet). For volume[2] the author (Ema or 
me I don't remember) apparently speculated that those ones would not change 
sign in a normal situation, which is maybe true but it doesn't have to be 
assumed, it could be a signed volume as well with a mechanism to keep the sign 
in memory (what [1] does).

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

[Yade-dev] FlowEngine.ipp.in: return values of volumeCell*()

[Jerome Duriez]

Hi,


In pkg/pfg/FlowEngine.ipp.in, why do volumeCell() return directly a "volume" 
value [1], whereas other volumeCell*Fictious() functions return the std::abs() 
of "volume" [2] ?


(I'm trying to play with this code, and I get a segmentation fault calling 
volumeCellSingleFictious() in [3], but not when calling volumeCell() in [4] )



Thank you,


Jerome


[1] https://github.com/yade/trunk/blob/master/pkg/pfv/FlowEngine.ipp.in#L591

[2] https://github.com/yade/trunk/blob/master/pkg/pfv/FlowEngine.ipp.in#L514

[3] https://github.com/yade/trunk/blob/master/pkg/pfv/FlowEngine.ipp.in#L413

[4] https://github.com/yade/trunk/blob/master/pkg/pfv/FlowEngine.ipp.in#L412



------

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] Frequency of documentation update

[Jerome Duriez]

Last build was November 3rd (with many build requests pending since), sorry for 
the typo...


From: Yade-dev <yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net> 
on behalf of Jerome Duriez <jerome.dur...@ucalgary.ca>
Sent: November 16, 2016 11:51 AM
To: Yade dev
Subject: Re: [Yade-dev] Frequency of documentation update


Sorry guys, but the answers made me more confused...


I had in mind that the buildbot [*] (i.e. 3SR cluster I guess) updates the doc 
at https://yade-dem.org/doc/ each time it performs a "build". Which is supposed 
to happen in my mind very often (once a day and after each commit ?)


Has there been / is there / will there be changes on that side ?

(Looking at the build log, I'm just seeing the last build was indeed November 
1st, several commits ago)


[*] https://yade-dem.org/buildbot/

<https://yade-dem.org/buildbot/>

------

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 Anton Gladky <gladky.an...@gmail.com>
Sent: November 16, 2016 11:35 AM
To: Yade developers
Subject: Re: [Yade-dev] Frequency of documentation update

2016-11-16 17:58 GMT+01:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>:
> We are actually changing this at the moment. If I'm not wrong (still
> possible because it is a bit intricate): previously the builds were
> triggered manually, by Anton, then the doc uploaded and yadedaily released.

Buildbot built and uploaded the documentation. Yadedaily builds only
offline documentation for packages.

Anton

___
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] Frequency of documentation update

[Jerome Duriez]

Sorry guys, but the answers made me more confused...


I had in mind that the buildbot [*] (i.e. 3SR cluster I guess) updates the doc 
at https://yade-dem.org/doc/ each time it performs a "build". Which is supposed 
to happen in my mind very often (once a day and after each commit ?)


Has there been / is there / will there be changes on that side ?

(Looking at the build log, I'm just seeing the last build was indeed November 
1st, several commits ago)


[*] https://yade-dem.org/buildbot/

<https://yade-dem.org/buildbot/>

------

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 Anton Gladky <gladky.an...@gmail.com>
Sent: November 16, 2016 11:35 AM
To: Yade developers
Subject: Re: [Yade-dev] Frequency of documentation update

2016-11-16 17:58 GMT+01:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>:
> We are actually changing this at the moment. If I'm not wrong (still
> possible because it is a bit intricate): previously the builds were
> triggered manually, by Anton, then the doc uploaded and yadedaily released.

Buildbot built and uploaded the documentation. Yadedaily builds only
offline documentation for packages.

Anton

___
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 3953: Introduce Network::surfaceSolidThroatInPore() for partial solid surfaces per half-throat

[Jerome Duriez]

Hi Bruno,


It seems there is still one "surfaceSolidPore" left in the code after this 
commit, see [*]. Do you confirm it is by mistake ? Should it be replaced with 
surfaceSolidThroat ?


I'm getting a related compilation error with this recent trunk (after having 
manually enabled the TWOPHASEFLOW compilation)

"error: 'class 
CGT::FlowBoundingSphere<CGT::_Tesselation<CGT::TriangulationTypes<FlowVertexInfo_FlowEngineT,
 FlowCellInfo_FlowEngineT> > >' has no member named 'surfaceSolidPore'"

Thanks,

Jerome



[*] 
https://github.com/yade/trunk/blob/master/lib/triangulation/FlowBoundingSphere.ipp#L750



----------

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 nore...@launchpad.net <nore...@launchpad.net>
Sent: October 24, 2016 10:57 AM
To: Yade developers
Subject: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3953: Introduce 
Network::surfaceSolidThroatInPore() for partial solid surfaces per half-throat


revno: 3953
committer: Bruno Chareyre <bruno.chare...@grenoble-inp.fr>
timestamp: Mon 2016-10-24 13:17:04 +0200
message:
  Introduce Network::surfaceSolidThroatInPore() for partial solid surfaces per 
half-throat

  - Introduce Network::surfaceSolidThroatInPore() for partial solid
  surfaces per half-throat
  - consistent triangulation of clumps vs. clump members depending on
  Flow::convertClumps
  - consistent use of mask for selective triangulation of bodies
  - conditional summation of forces to skip boundaries when introduced as
  additional bodies (grep maxBodyId)
  - make consistent use of idOffset for those cases
  - introduce wall normals
modified:
  lib/triangulation/FlowBoundingSphere.hpp
  lib/triangulation/Network.hpp
  lib/triangulation/Network.ipp
  pkg/pfv/FlowEngine.hpp.in
  pkg/pfv/FlowEngine.ipp.in


--
lp:yade
https://code.launchpad.net/~yade-pkg/yade/git-trunk

Your team Yade developers is subscribed to branch lp:yade.
To unsubscribe from this branch go to 
https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription
___
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 3937: Update citing_yade.bib

[Jerome Duriez]

To conclude, I think reverting was not appropriate here, could you please 
re-revert ?

Thanks !


Jerome



--

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 nore...@launchpad.net <nore...@launchpad.net>
Sent: September-23-16 8:28 AM
To: Yade developers
Subject: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3937: Update 
citing_yade.bib


revno: 3937
author: Bruno Chareyre <bruno.chare...@grenoble-inp.fr>
committer: GitHub <nore...@github.com>
timestamp: Fri 2016-09-23 15:23:31 +0200
message:
  Update citing_yade.bib

  revert f1401423
modified:
  doc/citing_yade.bib


--
lp:yade
https://code.launchpad.net/~yade-pkg/yade/git-trunk

Your team Yade developers is subscribed to branch lp:yade.
To unsubscribe from this branch go to 
https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription
___
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 3932: Friendlier BibTex entries for 2015 doc. To avoid Smilauer and et al in manuscripts

[Jerome Duriez]

Yes, in Yade doc, or with a classical \documentclass{article} together with 
\bibliographystyle{unsrt}, it just outputs "et al.". Again, "and others" is 
just a normal BibTeX command.

Did you actually test it and observe any "joke" ?


Jerome



----------

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: September-26-16 4:12 AM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3932: Friendlier 
BibTex entries for 2015 doc. To avoid Smilauer and et al in manuscripts

Thank you very much for explanation. Sorry if I've been reverting too hastly.
Did you test this "and others" within yade doc and if a few variant bibtex 
style?
Just to be sure it will not produce further jokes.
B


On 09/23/2016 05:29 PM, Jerome Duriez wrote:

Hi Bruno,


It is about paper manuscripts with "authoryear" references style (in text):

\documentclass[authoryear]{elsarticle} together with \usepackage{natbib} 
typically.


In such case, the older reference displays *in the main text* "and et al." :

"\cite{yade:doc2} made a great code" would give "Smilauer and et al. made a 
great code" as you got it

However, the references list, such as the one in 
https://www.yade-dem.org/doc/publications.html would still be fine.


Using "and others" in the BibTeX entry allows to solve the first behavior (the 
main text) without modifying what appears in the reference list. It will still 
be "Smilauer et al." in the reference list


"and others" is indeed normally recognized by BibTeX, see 
http://tex.stackexchange.com/questions/123600/latex-doesnt-recognize-et-al-in-the-bibliography
 (the answers at least)





___
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 3932: Friendlier BibTex entries for 2015 doc. To avoid Smilauer and et al in manuscripts

[Jerome Duriez]

Hi Bruno,


It is about paper manuscripts with "authoryear" references style (in text):

\documentclass[authoryear]{elsarticle} together with \usepackage{natbib} 
typically.


In such case, the older reference displays *in the main text* "and et al." :

"\cite{yade:doc2} made a great code" would give "Smilauer and et al. made a 
great code" as you got it

However, the references list, such as the one in 
https://www.yade-dem.org/doc/publications.html would still be fine.


Using "and others" in the BibTeX entry allows to solve the first behavior (the 
main text) without modifying what appears in the reference list. It will still 
be "Smilauer et al." in the reference list


"and others" is indeed normally recognized by BibTeX, see 
http://tex.stackexchange.com/questions/123600/latex-doesnt-recognize-et-al-in-the-bibliography
 (the answers at least)

[http://cdn.sstatic.net/Sites/tex/img/apple-touch-i...@2.png?v=eaf26b461720]<http://tex.stackexchange.com/questions/123600/latex-doesnt-recognize-et-al-in-the-bibliography>

bibtex - LaTeX doesn't recognize "et al." in the 
...<http://tex.stackexchange.com/questions/123600/latex-doesnt-recognize-et-al-in-the-bibliography>
tex.stackexchange.com
I'm using Jabref to manage my Bibliography. Sometimes, I put directly: First 
Author et al. when adding the article author's name in Jabref. When compiling 
my .tex ...





Publications on Yade — Yade 2016-08-24.git-0557faf 
...<https://www.yade-dem.org/doc/publications.html>
www.yade-dem.org
Publications on Yade¶ This page should be a relatively complete list of 
publications on Yade itself or done with Yade. If you publish something, do not 
hesitate to ...





--

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: September-23-16 6:41 AM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3932: Friendlier 
BibTex entries for 2015 doc. To avoid Smilauer and et al in manuscripts

I can't reproduce the problem Jérôme.
The references diplayed in [1] do not have "and et al." although they are 
generated by bibtex.
I also had these references included in standard latex toolchains and it never 
gave "and et al.".
The problem is to fix on your side it seems. How are you compiling? Which 
bibtex style?
Bruno

[1] https://www.yade-dem.org/doc/publications.html
Publications on Yade — Yade 2016-08-24.git-0557faf 
...<https://www.yade-dem.org/doc/publications.html>
www.yade-dem.org
Publications on Yade¶ This page should be a relatively complete list of 
publications on Yade itself or done with Yade. If you publish something, do not 
hesitate to ...




On 09/23/2016 01:24 PM, Bruno Chareyre wrote:
Dumb me! I should read twice.
Now I understand the problem Smilauer and et al.
Still the solution is not right. We must really display "Smilauer et al.".
Bibtex experts around?
B

On 09/23/2016 12:56 PM, Bruno Chareyre wrote:
Hi Jérôme,
I don't understand this commit. Why do you want to avoid "et al."?? It is a 
very well accepted convention.
Anyway, it is too late to change it, the document has been online for months.
It appears with "et al." using the DOI 
(https://dx.doi.org/10.5281/zenodo.34045), for instance.
Could you please revert?
Bruno

On 09/20/2016 09:04 PM, nore...@launchpad.net<mailto:nore...@launchpad.net> 
wrote:


revno: 3932
committer: jduriez <jerome.dur...@ucalgary.ca><mailto:jerome.dur...@ucalgary.ca>
timestamp: Tue 2016-09-20 12:19:53 -0600
message:
  Friendlier BibTex entries for 2015 doc. To avoid Smilauer and et al in 
manuscripts
modified:
  doc/citing_yade.bib


--
lp:yade
https://code.launchpad.net/~yade-pkg/yade/git-trunk<https://code.launchpad.net/%7Eyade-pkg/yade/git-trunk>

Your team Yade developers is subscribed to branch lp:yade.
To unsubscribe from this branch go to 
https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription<https://code.launchpad.net/%7Eyade-pkg/yade/git-trunk/+edit-subscription>




___
Mailing list: https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
Post to : yade-dev@lists.launchpad.net<mailto:yade-dev@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
More help   : https://help.launchpad.net/ListHelp





___
Mailing list: https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyad

Re: [Yade-dev] Capillary scripts

[Jerome Duriez]

See (for reference) 
https://github.com/yade/trunk/commit/e23a181f023956bd195be89d44632748403f1ddb 
and previous commit, thanks !


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

Capillary scripts commit (http://www.mail-archive.com/yade-dev@lists · 
yade/trunk@e23a181<https://github.com/yade/trunk/commit/e23a181f023956bd195be89d44632748403f1ddb>
github.com
...launchpad.net/msg12103.html). Located in a new 
examples/capillaryLaplaceYoung folder intended to illustrates capillary Law2. 
With one new simulation script example and another old one, moved here





------

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 Jerome Duriez <jerome.dur...@ucalgary.ca>
Sent: September-08-16 6:02 PM
To: Yade dev
Subject: [Yade-dev] Capillary scripts


Hi there,


Attached are three .m scripts aimed at generating capillary files for use with 
Law2_ScGeom_CapillaryPhys_Capillarity. Obviously, the idea, discussed 
previously here and there on the mailing lists, is to make this part of YADE 
more "open-source". Also, there is two major differences with previous (L. 
Scholtes') work:


* these scripts may generate capillary files accommodating any contact angle 
value, instead of 0 previously


* they provide new output as an "orientation tensor" defined from the 
fluid-fluid interface of capillary bridges. These data would constitute new 
attributes of CapillaryPhys, see "nn11" and "nn33" in the attached version of 
CapillaryPhys.hpp. (Note that these nn11 and nn33 can be used to get the bridge 
fluid-fluid interface S as S = 2*nn11 + nn33). This is about post-processing 
only.


The attached README.txt details the role of the .m files and how to use them: 
interested users in the end just need to give a look to, and launch, 
writesCapFile.m.



The core of the work, as usual, is solving the Laplace-Young equation for a 
capillary bridge configuration. The corresponding, quite classical, equations 
appear in solveLiqBridge file/function. There will be a dedicated journal paper 
on this topic, currently under "Minor Revision" review.



These files are ready to be pushed to trunk, together with updated 
CapillaryPhys (see attached), and Law2_ScGeom_CapillaryPhys_Capillarity, in 
order to read the new data (nn11 and nn33) from generated capillary files.


This email is for possible discussion before I perform the commit.


Cheers,


Jerome


PS: Vaclav, I took the liberty cc-ing you since I had once the feeling you 
would be interested in such scripts. (Woo does not include any capillary 
interactions at the moment, though ?)



--

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] Capillary scripts

[Jerome Duriez]

Yes, they were coded by myself, indeed.



--

Jerome Duriez, Research Associate

University of Calgary, Dpt of Civil Engineering

+1 403 220 7367



From: Anton Gladky <gladky.an...@gmail.com>
Sent: September-14-16 1:14 PM
To: Jerome Duriez
Cc: Yade dev
Subject: Re: [Yade-dev] Capillary scripts

Hi Jerome,

from my point of view, it is not a problem to push those scripts to
the trunk as they are just scripts and you think they can be
useful to other user too.

Of course, they need to get a description in documentation or
(and) have a good example, how to use them. Yes, they can
be pushed to the scripts/ or to examples/corresponding_subfolder.

The most important question is the license. Are those scripts created
by you?

Best regards,

Anton


2016-09-14 3:19 GMT+02:00 Jerome Duriez <jerome.dur...@ucalgary.ca>:
> Hello,
>
>
> After a couple of private emails with Bruno, I can confirm that these
> scripts work with GNU Octave as well (in addition to the less open-source
> friendly MATLAB )
>
>
> We mentionned with Bruno the possibility uploading these .m scripts on the
> wiki, however I would greatly prefer they are in trunk, in order to enjoy
> the revision tracking tools.
>
> As these scripts are not bound, from my point of view, to any non
> open-source tool, I think it should be fine. Any opinion ? (Bruno ? others
> ?)
>
>
> Another question is what would be the best trunk subfolder for these files ?
> trunk/scripts ?
___
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] Capillary scripts

[Jerome Duriez]

Hi Klaus,


You're right about Python, the reason why I used Matlab/Octave instead is quite 
stupid: I'm much more at ease with these softwares...


I will give a close look to what's inside "examples" to figure out which folder 
to use, thanks for suggestion !


Jerome



------

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 Klaus Thoeni <klaus.tho...@gmail.com>
Sent: September-13-16 8:58 PM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] Capillary scripts

Hi Jerome,

great addition and thanks for sharing the scripts.

One question, why did you use Matlab/Octave and not python? Python scripts
would "fit" better into the trunk ;-)

I terms of where to upload the scripts. I would suggest a folder in
"examples" with an example, your scripts and instructions. I think some people
already used this approach. But anyway, this is just a suggestion.

Cheers
Klaus

On Wed, 14 Sep 2016 01:19:16 AM Jerome Duriez wrote:
> Hello,
>
>
> After a couple of private emails with Bruno, I can confirm that these
> scripts work with GNU Octave as well (in addition to the less open-source
> friendly MATLAB )
>
>
> We mentionned with Bruno the possibility uploading these .m scripts on the
> wiki, however I would greatly prefer they are in trunk, in order to enjoy
> the revision tracking tools.
>
> As these scripts are not bound, from my point of view, to any non
> open-source tool, I think it should be fine. Any opinion ? (Bruno ? others
> ?)
>
>
> Another question is what would be the best trunk subfolder for these files ?
> trunk/scripts ?
>
>
>
> --
>
> 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 Jerome Duriez <jerome.dur...@ucalgary.ca> Sent: September-08-16 6:02 PM
> To: Yade dev
> Subject: [Yade-dev] Capillary scripts
>
>
> Hi there,
>
>
> Attached are three .m scripts aimed at generating capillary files for use
> with Law2_ScGeom_CapillaryPhys_Capillarity. Obviously, the idea, discussed
> previously here and there on the mailing lists, is to make this part of
> YADE more "open-source". Also, there is two major differences with previous
> (L. Scholtes') work:
>
>
> * these scripts may generate capillary files accommodating any contact angle
> value, instead of 0 previously
>
>
> * they provide new output as an "orientation tensor" defined from the
> fluid-fluid interface of capillary bridges. These data would constitute new
> attributes of CapillaryPhys, see "nn11" and "nn33" in the attached version
> of CapillaryPhys.hpp. (Note that these nn11 and nn33 can be used to get the
> bridge fluid-fluid interface S as S = 2*nn11 + nn33). This is about
> post-processing only.
>
>
> The attached README.txt details the role of the .m files and how to use
> them: interested users in the end just need to give a look to, and launch,
> writesCapFile.m.
>
>
>
> The core of the work, as usual, is solving the Laplace-Young equation for a
> capillary bridge configuration. The corresponding, quite classical,
> equations appear in solveLiqBridge file/function. There will be a dedicated
> journal paper on this topic, currently under "Minor Revision" review.
>
>
>
> These files are ready to be pushed to trunk, together with updated
> CapillaryPhys (see attached), and Law2_ScGeom_CapillaryPhys_Capillarity, in
> order to read the new data (nn11 and nn33) from generated capillary files.
>
>
> This email is for possible discussion before I perform the commit.
>
>
> Cheers,
>
>
> Jerome
>
>
> PS: Vaclav, I took the liberty cc-ing you since I had once the feeling you
> would be interested in such scripts. (Woo does not include any capillary
> interactions at the moment, though ?)
>
>
>
> --
>
> Jerome Duriez, Research Associate
>
> University of Calgary, Dpt of Civil Engineering
>
> +1 403 220 7367


___
Mailing list: https://launchpad.net/~yade-dev
Yade developers in Launchpad<https://launchpad.net/~yade-dev>
launchpad.net
yade-dev@lists.launchpad.net Policy: You must be a team member to subscribe to 
the team mailing list. View public archive View subscribers


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] Capillary scripts

[Jerome Duriez]

Hello,


After a couple of private emails with Bruno, I can confirm that these scripts 
work with GNU Octave as well (in addition to the less open-source friendly 
MATLAB )


We mentionned with Bruno the possibility uploading these .m scripts on the 
wiki, however I would greatly prefer they are in trunk, in order to enjoy the 
revision tracking tools.

As these scripts are not bound, from my point of view, to any non open-source 
tool, I think it should be fine. Any opinion ? (Bruno ? others ?)


Another question is what would be the best trunk subfolder for these files ? 
trunk/scripts ?



--

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 Jerome Duriez <jerome.dur...@ucalgary.ca>
Sent: September-08-16 6:02 PM
To: Yade dev
Subject: [Yade-dev] Capillary scripts


Hi there,


Attached are three .m scripts aimed at generating capillary files for use with 
Law2_ScGeom_CapillaryPhys_Capillarity. Obviously, the idea, discussed 
previously here and there on the mailing lists, is to make this part of YADE 
more "open-source". Also, there is two major differences with previous (L. 
Scholtes') work:


* these scripts may generate capillary files accommodating any contact angle 
value, instead of 0 previously


* they provide new output as an "orientation tensor" defined from the 
fluid-fluid interface of capillary bridges. These data would constitute new 
attributes of CapillaryPhys, see "nn11" and "nn33" in the attached version of 
CapillaryPhys.hpp. (Note that these nn11 and nn33 can be used to get the bridge 
fluid-fluid interface S as S = 2*nn11 + nn33). This is about post-processing 
only.


The attached README.txt details the role of the .m files and how to use them: 
interested users in the end just need to give a look to, and launch, 
writesCapFile.m.



The core of the work, as usual, is solving the Laplace-Young equation for a 
capillary bridge configuration. The corresponding, quite classical, equations 
appear in solveLiqBridge file/function. There will be a dedicated journal paper 
on this topic, currently under "Minor Revision" review.



These files are ready to be pushed to trunk, together with updated 
CapillaryPhys (see attached), and Law2_ScGeom_CapillaryPhys_Capillarity, in 
order to read the new data (nn11 and nn33) from generated capillary files.


This email is for possible discussion before I perform the commit.


Cheers,


Jerome


PS: Vaclav, I took the liberty cc-ing you since I had once the feeling you 
would be interested in such scripts. (Woo does not include any capillary 
interactions at the moment, though ?)



------

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

[Yade-dev] Capillary scripts

[Jerome Duriez]

Hi there,


Attached are three .m scripts aimed at generating capillary files for use with 
Law2_ScGeom_CapillaryPhys_Capillarity. Obviously, the idea, discussed 
previously here and there on the mailing lists, is to make this part of YADE 
more "open-source". Also, there is two major differences with previous (L. 
Scholtes') work:


* these scripts may generate capillary files accommodating any contact angle 
value, instead of 0 previously


* they provide new output as an "orientation tensor" defined from the 
fluid-fluid interface of capillary bridges. These data would constitute new 
attributes of CapillaryPhys, see "nn11" and "nn33" in the attached version of 
CapillaryPhys.hpp. (Note that these nn11 and nn33 can be used to get the bridge 
fluid-fluid interface S as S = 2*nn11 + nn33). This is about post-processing 
only.


The attached README.txt details the role of the .m files and how to use them: 
interested users in the end just need to give a look to, and launch, 
writesCapFile.m.



The core of the work, as usual, is solving the Laplace-Young equation for a 
capillary bridge configuration. The corresponding, quite classical, equations 
appear in solveLiqBridge file/function. There will be a dedicated journal paper 
on this topic, currently under "Minor Revision" review.



These files are ready to be pushed to trunk, together with updated 
CapillaryPhys (see attached), and Law2_ScGeom_CapillaryPhys_Capillarity, in 
order to read the new data (nn11 and nn33) from generated capillary files.


This email is for possible discussion before I perform the commit.


Cheers,


Jerome


PS: Vaclav, I took the liberty cc-ing you since I had once the feeling you 
would be interested in such scripts. (Woo does not include any capillary 
interactions at the moment, though ?)



----------

Jerome Duriez, Research Associate

University of Calgary, Dpt of Civil Engineering

+1 403 220 7367
/*
*  Copyright (C) 2006 by luc Scholtes*
*  luc.schol...@hmg.inpg.fr  *
**
*  This program is free software; it is licensed under the terms of the  *
*  GNU General Public License v2 or later. See file LICENSE for details. *
*/
#pragma once
#include
#include
#include

class CapillaryPhys : public FrictPhys
{
	public :
		int currentIndexes [4]; // used for faster interpolation (stores previous positions in tables)
		
		virtual ~CapillaryPhys() {};

	YADE_CLASS_BASE_DOC_ATTRS_INIT_CTOR_PY(CapillaryPhys,FrictPhys,"Physics (of interaction) for :yref:`Law2_ScGeom_CapillaryPhys_Capillarity`.",
 ((bool,meniscus,false,Attr::readonly,"True when a meniscus with a non-zero liquid volume (:yref:`vMeniscus`) has been computed for this interaction"))
 ((bool,isBroken,false,,"Might be set to true by the user to make liquid bridge inactive (capillary force is zero)"))
 ((Real,capillaryPressure,0.,,"Value of the capillary pressure Uc. Defined as Ugas-Uliquid, obtained from :yref:`corresponding Law2 parameter`"))
 ((Real,vMeniscus,0.,,"Volume of the meniscus"))
 ((Real,Delta1,0.,,"Defines the surface area wetted by the meniscus on the smallest grains of radius R1 (R1<R2)"))
 ((Real,Delta2,0.,,"Defines the surface area wetted by the meniscus on the biggest grains of radius R2 (R1<R2)"))
 ((Vector3r,fCap,Vector3r::Zero(),,"Capillary force produced by the presence of the meniscus. This is the force acting on particle #2"))
 ((short int,fusionNumber,0.,,"Indicates the number of meniscii that overlap with this one"))
 ((Real,nn11,0.,,":math:`\\iint_A n_1 n_1 \\, dS = \\iint_A n_2 n_2 \\, dS`, $A$ being the liquid-gas surface of the meniscus, $\\vec n$ the associated normal, and $(1,2,3)$ a local basis with $3$ the meniscus orientation (:yref:`ScGeom.normal`). NB: $A$ = 2 :yref:`nn11` + :yref:`nn33`."))
 ((Real,nn33,0.,,":math:`\\iint_A n_3 n_3 \\, dS`, $A$ being the liquid-gas surface of the meniscus, $\\vec n$ the associated normal, and $(1,2,3)$ a local basis with $3$ the meniscus orientation (:yref:`ScGeom.normal`). NB: $A$ = 2 :yref:`nn11` + :yref:`nn33`."))
 ,,
 createIndex();currentIndexes[0]=currentIndexes[1]=currentIndexes[2]=currentIndexes[3]=0;
 ,
 );
	REGISTER_CLASS_INDEX(CapillaryPhys,FrictPhys);
};
REGISTER_SERIALIZABLE(CapillaryPhys);


class Ip2_FrictMat_FrictMat_CapillaryPhys : public IPhysFunctor
{
	public :
		virtual void go(	const shared_ptr& b1,
	const shared_ptr& b2,
	const shared_ptr& interaction);

	FUNCTOR2D(FrictMat,FrictMat);
	YADE_CLASS_BASE_DOC_ATT

Re: [Yade-dev] TriaxialStressController.externalWork sign

[Jerome Duriez]

I hoped the "actually" would convey the "positive energy" meaning (like I would 
speak of a "true" acceleration for an increasing speed), but it seems it's not 
the case...


I still prefer "my" proposal but I would not oppose any further changes !



------

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: July-28-16 11:06 AM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] TriaxialStressController.externalWork sign

XLatexIt! run report...

*** Found expression $u$
*** Found expression $T$
*** Found expression $ \int_{\partial \Omega} \boldmath T \cdot  \bm u ds$
Image was already generated



I don't think it makes much sense to speak of whether it is negative or 
positive.


"negativ when the boundaries actually provide energy to the sample", you mean 
when the boundaries actually provide a positive energy to the sample?

Since if it provides a negative energy then the function will return a positive 
value. ;)

I would suggest plain mathematical definition:

"Mechanical work associated to the boundary conditions, i.e. [$   
\int_{\partial \Omega} \boldmath T \cdot  \bm u ds$]  with [$T$]  the surface 
traction and [$u$]  the displacement at the boundary."


There is no strong argument to multiply such a straight definition by -1 in my 
view.


Bruno



On 07/28/2016 06:33 PM, Jerome Duriez wrote:

Ok, I just proposed something:

https://github.com/yade/trunk/commit/6a9b6178ebade3c6d5ea6cbcdf439a9f20073648

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

Doc clarification for TriaxialStressController.externalWork (http://w… · 
yade/trunk@6a9b617<https://github.com/yade/trunk/commit/6a9b6178ebade3c6d5ea6cbcdf439a9f20073648>
github.com
…ww.mail-archive.com/yade-dev@lists.launchpad.net/msg12083.html<mailto:ww.mail-archive.com/yade-dev@lists.launchpad.net/msg12083.html>)




Thanks,


Jerome



--

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><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: July-28-16 10:06 AM
To: yade-dev@lists.launchpad.net<mailto:yade-dev@lists.launchpad.net>
Subject: Re: [Yade-dev] TriaxialStressController.externalWork sign


Hi Jérôme,

Strictly speaking the doc is right: "Energy provided by boundaries" does not 
tell if the boundaries provide energy to the sample or to the outside.

I agree that it is probably more common to define "external work input" as an 
input to the sample, yet overall it remains a matter of taste.

I'm not for discussing/changing such sign conventions unless they are obviously 
wrong. There are probably tons of user scripts which would have to be adapted 
after such change (including mines), not a good thing. Instead, I would clarify 
the documentation without changing the code.

Bruno

On 07/27/2016 07:26 PM, Jerome Duriez wrote:

Hello,


I'm proposing to change the sign convention of 
TriaxialStressController.externalWork.


I would like it corresponds to the "Energy provided by boundaries" as the doc 
says, however it seems to me it's currently rather the energy provided to the 
boundaries (by the sample). Since we use the Force acting on the boundaries 
together with the boundaries velocities.


Agree to revert this sign ?


Jerome



--

Jerome Duriez, Research Associate

University of Calgary, Dpt of Civil Engineering

+1 403 220 7367



___
Mailing list: https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
Post to : yade-dev@lists.launchpad.net<mailto:yade-dev@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
More help   : https://help.launchpad.net/ListHelp


Yade developers in Launchpad<https://launchpad.net/%7Eyade-dev>
launchpad.net
yade-dev@lists.launchpad.net<mailto:yade-dev@lists.launchpad.net> Policy: You 
must be a team member to subscribe to the team mailing list. View public 
archive View subscribers





___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net<mailto:yade-dev@lists.launchpad.net

Re: [Yade-dev] TriaxialStressController.externalWork sign

[Jerome Duriez]

Ok, I just proposed something:

https://github.com/yade/trunk/commit/6a9b6178ebade3c6d5ea6cbcdf439a9f20073648

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

Doc clarification for TriaxialStressController.externalWork (http://w... · 
yade/trunk@6a9b617<https://github.com/yade/trunk/commit/6a9b6178ebade3c6d5ea6cbcdf439a9f20073648>
github.com
...ww.mail-archive.com/yade-dev@lists.launchpad.net/msg12083.html)




Thanks,


Jerome



------

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: July-28-16 10:06 AM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] TriaxialStressController.externalWork sign


Hi Jérôme,

Strictly speaking the doc is right: "Energy provided by boundaries" does not 
tell if the boundaries provide energy to the sample or to the outside.

I agree that it is probably more common to define "external work input" as an 
input to the sample, yet overall it remains a matter of taste.

I'm not for discussing/changing such sign conventions unless they are obviously 
wrong. There are probably tons of user scripts which would have to be adapted 
after such change (including mines), not a good thing. Instead, I would clarify 
the documentation without changing the code.

Bruno

On 07/27/2016 07:26 PM, Jerome Duriez wrote:

Hello,


I'm proposing to change the sign convention of 
TriaxialStressController.externalWork.


I would like it corresponds to the "Energy provided by boundaries" as the doc 
says, however it seems to me it's currently rather the energy provided to the 
boundaries (by the sample). Since we use the Force acting on the boundaries 
together with the boundaries velocities.


Agree to revert this sign ?


Jerome



------

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


Yade developers in Launchpad<https://launchpad.net/~yade-dev>
launchpad.net
yade-dev@lists.launchpad.net Policy: You must be a team member to subscribe to 
the team mailing list. View public archive View subscribers


___
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

[Yade-dev] TriaxialStressController.externalWork sign

[Jerome Duriez]

Hello,


I'm proposing to change the sign convention of 
TriaxialStressController.externalWork.


I would like it corresponds to the "Energy provided by boundaries" as the doc 
says, however it seems to me it's currently rather the energy provided to the 
boundaries (by the sample). Since we use the Force acting on the boundaries 
together with the boundaries velocities.


Agree to revert this sign ?


Jerome



------

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

[Yade-dev] Law2_ScGeom_CapillaryPhys_Capillarity code workflow for erased interactions

[Jerome Duriez]

Hello,


Currently Law2_ScGeom_CapillaryPhys_Capillarity may erase some interactions 
when the liquid volume vanishes, at the line 156 [1]

However, subsequent operations on the interaction are still coded after that, 
like storing the filling angle [2]


I've just faced segmentation fault because of that: the l. 164 in [2] wants to 
access a physics data that does not exist anymore.. I'm surprised I'm facing 
such situation only now but, anyway, do we agree there is something to correct 
here ? (just moving the Delta lines up)


Jerome


PS: this also applies to Law2_ScGeom_CapillaryPhys_Capillarity1 []


[1]: 
https://github.com/yade/trunk/blob/master/pkg/dem/Law2_ScGeom_CapillaryPhys_Capillarity.cpp#L156

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




--

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] [Yade-users] Yade 2016.06a released

[Jerome Duriez]

Thank you very much Anton !


As a small remark for the next announcement (that hopefully will exist), I'd 
suggest you consider to briefly explain in such emails what kind of "Yade" such 
stable release is related to.

Since we have now 3 ways installing Yade (source code, yade-daily and stable 
prepackaged softwares in Debian distributions, I hope I do not miss 
anything...) , I thought it might be confusing for some users to get whether / 
how they are affected by such release. I had myself to go to 
https://yade-dem.org/doc/installation.html to figure out it is about the stable 
prepackaged softwares (I guess...)...


Just a thought,


Jerome


Installation — Yade 2016-06-02.git-d691ff0 
documentation<https://yade-dem.org/doc/installation.html>
yade-dem.org
Installation¶ Yade can be installed from packages (pre-compiled binaries) or 
source code. The choice depends on what you need: if you don’t plan to modify 
Yade ...




------

Jerome Duriez, Research Associate

University of Calgary, Dpt of Civil Engineering

+1 403 220 7367



From: Yade-users 
<yade-users-bounces+jerome.duriez=ucalgary...@lists.launchpad.net> on behalf of 
Anton Gladky <gladky.an...@gmail.com>
Sent: June-14-16 12:59 PM
To: yade-us...@lists.launchpad.net
Cc: yade-dev
Subject: [Yade-users] Yade 2016.06a released

Dear Yade users and developers,

After almost 8 months of development I am glad to announce
the next Yade version 2016.06a. The complete changelog
you will find as always at the end of this message.

The versioning of releases is changed and now is in the
form .MMx. Where x is the letter, which can be
changed by minor updates in the stable releases.

Thanks all for contributions!

Anton

==
yade-2016.06a
Tue, Jun 14 20:30:53 2016 +0200

Anton Gladky (88):
  Remove release.
  Clean some unused macroses (old wm3-stuff)
  Remove some global headers
  Raise minimal boost version to 1.47
  Add -DNDEBUG if compiling in release mode
  Tiny code refactoring
  Clean some warnings and old stuff.
  Return removed header back.
  Fix warning in newer matplotlib.
  Drop old commented stuff in python-scrips.
  Remove flags and preSteps from scene
  Remove deprecated findBoundDispatcherInEnginesIfNoFunctorsAndWarn
  Remove PISC_DEBUG.
  Fix typo in installation sections of doce. Thanks to Jan.
  Export normal and viscous part of the visco-elastic contact
  Remove confusing part in installation part of documentation regarding Qt5.
  Fix typo in CMakeLists
  Tiny updates of examples of LudingPM.
  Fix compilation warnings.
  Update formatting in SpherePack
  Fix an order of calculation of c in SpherePack
  Fix some compilation warnings.
  Fix cappitalization typo in Lapack (case-sensitive in this case).
  Respect VTK6 in PotentialParticles.
  Add .travis.yml for CI.
  Remove version restriction on sphinx.
  Use trusty as build-env.
  Add -y parameter to apt-get install.
  Fix numpy import on travis.
  Fix segfault during save/load of CapViscModels
  Add one more check-script (capillary models)
  Fix typo in check-script.
  Fix crash in Ig2_Facet_Polyhedra_PolyhedraGeom
  vtkExporter: increase number of leading zeros to 8
  Move implementation of methods of ForceContainer in cpp.
  Split implementation of ForceContainer in parallel and serial.
  Add zero-forces to the youngest body after simulation load.
Closes LP:1560171
  Drop parallel execution in replaceByClumps. Closes LP:1559098
  Add import of polyhedras from the file.
  Add an opportunity to shift, scale and rotate imported polyhedrons
  Minor fixes in Polyhedra_splitter.
  Fix division by zero crash in Polyhedra
  Add CGAL_DISABLE_ROUNDING_MATH_CHECK, -frounding-math when CGAL
is enabled.
  Fix some formatting issues.
  Non-invasive fixes in polyhedra_splitter.
  Get max-min coefs in polyhedra_splitter simpler.
  Use tuple as a parameter for SplitPolyhedraDouble
  Add check script for polyhedra crash.
  Use explicitly -DNDEBUG instead of CMAKE_CXX_FLAGS_RELEASE
  Check isnan in some coordinates before calling CGAL.
  Minor formatting fixes in Polyhedra.
  Add check-script for save/load of clumps.
  Disable checkPolyhedraCrush. It is unstable now.
  Fix checkPolyhedraCrush
  Remove polyhedra_utils import from "ymport"
  Add prefix std:: to isnan and isinf.
  Update checkPolyhedraCrush
  Update files for ppa-infrastructure.
  Undef NDEBUG in all polyhedra files.
  Add pause for checkSaveLoadClumps to escape race condition.
  Use variadic arguments in DynLibDispatcher.
  Fix crash in polyhedra, if maxFs=0.
  Fix checkPolyhedraCrush (remove qt)
  Remove unused func

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

[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

[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

[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/562d4c952f4b7f67a88ed954caa20b68a041e207> 
https://github.com/yade/trunk/commit/e063ea12479a56f85ca456aef8f52be19cbed84d

[https://avatars1.githubusercontent.com/u/5427081?v=3=200]<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://avatars1.githubusercontent.com/u/5427081?v=3=200]<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.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Dynamic bodies and getSpheresVolume()

[Jerome Duriez]

See 
https://github.com/yade/trunk/commit/c1a5e87a84423686780299b2fc09acfb2606a67b, 
thanks !

Jerome



From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net] 
on behalf of Bruno Chareyre [bruno.chare...@grenoble-inp.fr]
Sent: May-26-16 7:05 AM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] Dynamic bodies and getSpheresVolume()

It makes sense indeed.
The dynamic check was probably a loose evaluation of shape, now redundant.
Bruno

On 05/20/2016 11:30 PM, Jerome Duriez wrote:
Hi,

getSpheresVolume() currently skips all dynamic bodies before even considering 
whether they are spheres or not [*]. I think it would you make sense to just 
consider the shape, and to remove this "dynamic" condition.

It would for instance allow to use consistently porosity() function for a fixed 
packing of sphere. (Now, porosity() then always returns 1 in such case)

What do you think ?


Jerome


[*] 
https://github.com/yade/trunk/blob/6d4a0d1689c6bad2dbdd6e27d1653418f7fc6498/pkg/dem/Shop_01.cpp#L308


PS: the same applies for other functions, such as getSpheresMass(), but this 
has not been an issue for me...



___
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

[Yade-dev] Dynamic bodies and getSpheresVolume()

[Jerome Duriez]

Hi,

getSpheresVolume() currently skips all dynamic bodies before even considering 
whether they are spheres or not [*]. I think it would you make sense to just 
consider the shape, and to remove this "dynamic" condition.

It would for instance allow to use consistently porosity() function for a fixed 
packing of sphere. (Now, porosity() then always returns 1 in such case)

What do you think ?


Jerome


[*] 
https://github.com/yade/trunk/blob/6d4a0d1689c6bad2dbdd6e27d1653418f7fc6498/pkg/dem/Shop_01.cpp#L308


PS: the same applies for other functions, such as getSpheresMass(), but this 
has not been an issue for me...
___
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] Yade release, new versioning?

[Jerome Duriez]

This new kind of versioning would definitively sound more meaningful (to me at 
least).

As for the 2 or 4 year digits, assuming Yade will last one century is a far 
reach ! ;-)


Jerome


From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net] 
on behalf of Anton Gladky [gladky.an...@gmail.com]
Sent: April-19-16 2:13 PM
To: yade-dev
Subject: [Yade-dev] Yade release, new versioning?

Dear all,

I am planning to release new Yade version soon, because
the 1.20.0 was released about 6 months ago and we have
over 120 commits now.

Some projects now are using the following versioning for
releases: .MM (i.e. 2016.04). Do we want to adopt
such a system?

I think this versioning is better in comparison to our numbering,
because it includes the information about release time.

Looking forward for your comments.

Best regards

Anton
___
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] moderation of "Michal Nitka"

[Jerome Duriez]

Hi Bruno,

I dealt with two of "Michal"s messages yesterday (including the notification 
you show us, it seems), but discarded them. (I would be surprised I messed 
Discard with Accept...)

Why do you think those messages have been approved ?

It's true I got this morning (in my spam box though) two other messages from 
Michal's account, but those were sent through the Launchpad question interface, 
which we can not moderate (see our previous discussion).
For me it is clear these are distinct messages than the ones previously 
moderated.

Jerome

From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net] 
on behalf of Bruno Chareyre [bruno.chare...@3sr-grenoble.fr]
Sent: March 29, 2016 2:52 AM
To: Yade Development Group
Subject: [Yade-dev] moderation of "Michal Nitka"

Hi,
If I understand correctly someone with admin rights approved two messages from 
"Michal Nitka" recently (based on a notification as below).
Whoever it is, please don't approve any other message from this account without 
really checking it.
This account has been corrupted and is sending spams [1], I banned it from our 
lists and I sent a personal email to Michal to explain.
Bruno

[1] https://answers.launchpad.net/yade/+question/269691


 Forwarded Message 
Subject:New mailing list message requiring approval for Yade developers
Date:   Mon, 28 Mar 2016 17:16:44 -
From:   Yade developers 
Reply-To:   Yade developers 

To:




Hello Bruno Chareyre,

Yade developers has a new message requiring your approval.

Subject: Fw: new message
Author name: Michal Nitka
Author url: https://launchpad.net/~michal-n
Date: 2016-03-28 17:14:07+00:00
Message-ID: 
<3281ba4e$2c23c13e$4af56c88$@poczta.onet.pl>

A message has been posted to the mailing list for your team, but this
message requires your approval before it will be sent to the list
members.  After reviewing the message, you may approve, discard or
reject it.

To review all messages pending approval, visit:

https://launchpad.net/~yade-dev/+mailinglist-moderate

Regards,
The Launchpad team




___
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

[Yade-dev] fabricTensor() in aperiodic conditions ?

[Jerome Duriez]

Hello,

What's the reason for fabricTensor() utils function to be designed only for 
periodic simulations (according to the doc and the error raised in aperiodic 
conditions:
https://github.com/yade/trunk/blob/c5330ac6a612db52275b10f87691b5630ab8c24a/pkg/dem/Shop_02.cpp#L262)
 ?

I could not find any and was thinking to remove this condition (keeping a test 
to disregard contact with boundaries ?), but preferred to ask first.

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] Spam on the mailing list

[Jerome Duriez]

In this case, I thought that the guy has anyway to be a member of "yade-users" 
to get the answers to his question (in his emails like me). In fact, I just 
realized that it is certainly possible just browsing the Launchpad interface 
web pages...

I can see the point now, thanks.


From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net] 
on behalf of Jan Stránský [honzik.stran...@gmail.com]
Sent: February-16-16 9:50 AM
To: yade-dev
Subject: Re: [Yade-dev] Spam on the mailing list

Hi Jerome,

imagine you are a new Yade user, testing it and deciding if you will use it or 
not, and want to ask just some basic question, and for it you have to register 
somewhere, waiting (possibly a few days) for approval and only after that you 
can ask.. It would annoy me :-) every while there is a question from people I 
have never heard before and I think it would be pitty to make it hard just 
because of one spammer..

If you mark a question as a spam, it is not displayed in any list by default. 
If you get yade-users emails, containing all the questions, a few spams is no 
problem from my point of view, as large amount of questions is completely out 
of my interest, ability to answer, knowledge of code, knowledge of physics etc 
etc..

Of course, we should have the possibility to ban a user if that account send 
spams (like "thomas" recently)

cheers
Jan


2016-02-16 17:36 GMT+01:00 Jerome Duriez 
<jerome.dur...@ucalgary.ca<mailto:jerome.dur...@ucalgary.ca>>:
Hi,

What kind of issues do you have in mind if we restrict to yade-users members 
the possibility of asking questions ?

Jerome


From: Yade-dev 
[yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net<mailto:ucalgary...@lists.launchpad.net>]
 on behalf of Eulitz, Alexander 
[alexander.eul...@iwf.tu-berlin.de<mailto:alexander.eul...@iwf.tu-berlin.de>]
Sent: February-15-16 12:29 AM
To: Bruno Chareyre
Cc: yade-dev
Subject: Re: [Yade-dev] Spam on the mailing list

Hi there,
I totally agree with Bruno. Moving to github is not a good idea in my opinion 
for the same reason Anton gave, at least if we can manage this in an other way.
Unfortunately I dont have a constructive idea how to handle it.
greets Alex

Von: Yade-dev 
[mailto:yade-dev-bounces+alexander.eulitz<mailto:yade-dev-bounces%2Balexander.eulitz>=iwf.tu-berlin...@lists.launchpad.net<mailto:iwf.tu-berlin...@lists.launchpad.net>]
 Im Auftrag von Bruno Chareyre
Gesendet: Samstag, 13. Februar 2016 20:41
Cc: yade-dev
Betreff: Re: [Yade-dev] Spam on the mailing list

I don't know how launchpad handles spammers, can we ban some accounts on the 
mailing lists we are managing?
I don't think restricting posting rights of everyone but team members is the 
right way to solve the problem. It has to remain open access IMO.
Bruno

On 13 February 2016 at 13:25, Anton Gladky 
<gladky.an...@gmail.com<mailto:gladky.an...@gmail.com>> wrote:
Hi Jerome,

thanks for raising this question. For both groups we
have several administrators, including me, Bruno, Jan and
I have added you also as admin. If there are also some
more proposals, let`s implement them.

If Launchpad will be too painful, we can move most of stuff
to GitHub. I would like to escape it, because we have thousands
of messages on LP, but if it will work too bad... Let`s see.

Best regards

Anton


2016-02-12 19:42 GMT+01:00 Jerome Duriez 
<jerome.dur...@ucalgary.ca<mailto:jerome.dur...@ucalgary.ca>>:
> Hello,
>
> I personally consider the spams we're getting these days on the mailing list
> as a problem, and not a good sign of vitality for the project when they're
> more frequent than actual questions.
>
> Up to now, we had spams coming from:
> 1. a Launchpad account which is not member of any yade Launchpad teams
> 2. an actual member of yade Launchpad team(s)
>
> In the case of "2", I do not have so much idea.. (in the case we had
> recently, I just got in touch with the member who since changed his email
> account password)
>
> However, restricting to team members the possibility to ask answers would
> solve 1. And make more meaningful the control we put on yade Launchapd
> teams...
> This might be possible according to what I read at the bottom of
> https://help.launchpad.net/ListHelp. It seems it is the administrator of the
> yade-users team who could do it ? Anton ? (even though I approve new
> members, it does not seem to me I can perform the procedure described on
> https://help.launchpad.net/ListHelp ?)
>
> Jerome
___
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


_

Re: [Yade-dev] Spam on the mailing list

[Jerome Duriez]

Hi,

What kind of issues do you have in mind if we restrict to yade-users members 
the possibility of asking questions ?

Jerome


From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net] 
on behalf of Eulitz, Alexander [alexander.eul...@iwf.tu-berlin.de]
Sent: February-15-16 12:29 AM
To: Bruno Chareyre
Cc: yade-dev
Subject: Re: [Yade-dev] Spam on the mailing list

Hi there,
I totally agree with Bruno. Moving to github is not a good idea in my opinion 
for the same reason Anton gave, at least if we can manage this in an other way.
Unfortunately I dont have a constructive idea how to handle it.
greets Alex

Von: Yade-dev 
[mailto:yade-dev-bounces+alexander.eulitz=iwf.tu-berlin...@lists.launchpad.net] 
Im Auftrag von Bruno Chareyre
Gesendet: Samstag, 13. Februar 2016 20:41
Cc: yade-dev
Betreff: Re: [Yade-dev] Spam on the mailing list

I don't know how launchpad handles spammers, can we ban some accounts on the 
mailing lists we are managing?
I don't think restricting posting rights of everyone but team members is the 
right way to solve the problem. It has to remain open access IMO.
Bruno

On 13 February 2016 at 13:25, Anton Gladky 
<gladky.an...@gmail.com<mailto:gladky.an...@gmail.com>> wrote:
Hi Jerome,

thanks for raising this question. For both groups we
have several administrators, including me, Bruno, Jan and
I have added you also as admin. If there are also some
more proposals, let`s implement them.

If Launchpad will be too painful, we can move most of stuff
to GitHub. I would like to escape it, because we have thousands
of messages on LP, but if it will work too bad... Let`s see.

Best regards

Anton


2016-02-12 19:42 GMT+01:00 Jerome Duriez 
<jerome.dur...@ucalgary.ca<mailto:jerome.dur...@ucalgary.ca>>:
> Hello,
>
> I personally consider the spams we're getting these days on the mailing list
> as a problem, and not a good sign of vitality for the project when they're
> more frequent than actual questions.
>
> Up to now, we had spams coming from:
> 1. a Launchpad account which is not member of any yade Launchpad teams
> 2. an actual member of yade Launchpad team(s)
>
> In the case of "2", I do not have so much idea.. (in the case we had
> recently, I just got in touch with the member who since changed his email
> account password)
>
> However, restricting to team members the possibility to ask answers would
> solve 1. And make more meaningful the control we put on yade Launchapd
> teams...
> This might be possible according to what I read at the bottom of
> https://help.launchpad.net/ListHelp. It seems it is the administrator of the
> yade-users team who could do it ? Anton ? (even though I approve new
> members, it does not seem to me I can perform the procedure described on
> https://help.launchpad.net/ListHelp ?)
>
> Jerome
___
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

[Yade-dev] Spam on the mailing list

[Jerome Duriez]

Hello,

I personally consider the spams we're getting these days on the mailing list as 
a problem, and not a good sign of vitality for the project when they're more 
frequent than actual questions.

Up to now, we had spams coming from:
1. a Launchpad account which is not member of any yade Launchpad teams
2. an actual member of yade Launchpad team(s)

In the case of "2", I do not have so much idea.. (in the case we had recently, 
I just got in touch with the member who since changed his email account 
password)

However, restricting to team members the possibility to ask answers would solve 
1. And make more meaningful the control we put on yade Launchapd teams...
This might be possible according to what I read at the bottom of 
https://help.launchpad.net/ListHelp. It seems it is the administrator of the 
yade-users team who could do it ? Anton ? (even though I approve new members, 
it does not seem to me I can perform the procedure described on 
https://help.launchpad.net/ListHelp ?)

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] SoftwareX

[Jerome Duriez]

Ah, I see now, thanks ! Indeed, it's satisfying to see that numerous scientists 
are interested into such questions..


From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net] 
on behalf of Bruno Chareyre [bruno.chare...@3sr-grenoble.fr]
Sent: October 5, 2015 8:50 AM
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] SoftwareX

See also "where should I publish my software?":
http://www.software.ac.uk/resources/guides/which-journals-should-i-publish-my-software


On 04/10/15 18:33, Bruno Chareyre wrote:


On 4 October 2015 at 18:26, Bruno Chareyre 
> wrote:
http://carver.cs.ua.edu/Papers/Journal/2015/SLR-Science_preprint.pdf
http://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.1001745
http://software.ac.uk/so-exactly-what-software-did-you-use


Or this (typical):
http://beyond-impact.org/?p=175



___
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




--
___
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] SoftwareX

[Jerome Duriez]

Hello,

With some delay, and out of curiosity, what link do you draw between this 
software-carpentry (I understood as an 
association helping researchers to deal with their computing tools) and the 
journal softwarex (where YADE could be presented ?)

I could not get it..

Jerome


From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net] 
on behalf of Bruno Chareyre [bruno.chare...@3sr-grenoble.fr]
Sent: September 22, 2015 4:20 PM
To: Yade developers
Subject: Re: [Yade-dev] SoftwareX

I must mention that Jan's note is closely linked, in my brain, to a discussion 
I had with a developper of Plaxis, who suggested [1] as a relevant link.
B

[1] https://software-carpentry.org/

On 22 September 2015 at 17:37, Bruno Chareyre 
> wrote:
Very interesting initiative.
As it turns out I've been reviewer for a paper in MethodsX[1] recently, a 
journal based on a very similar idea.
MethodsX is supposed to be oriented toward experimental methods, but it appears 
that they also publish programming things.
Ultimately, I guess SoftwareX aims at attracting the computational papers which 
currently go to MethodsX.
Looking at [2] I see quite unusual content compared to classical journal 
papers. Something to keep in mind. Thanks Jan.
Bruno


[1] http://www.journals.elsevier.com/methodsx
[2] http://www.sciencedirect.com/science/article/pii/S235271101535

On 17/09/15 14:35, Jan Stránský wrote:
Hello all,
recently I have found links bellow, might be useful for the discussion how to 
cite Yade in future and for newer versions. Mainly sent not to forget 
completely :-)
cheers
Jan

[1] https://www.youtube.com/watch?v=l1cWoHKCBak
[2] http://www.journals.elsevier.com/softwarex



___
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




--
___
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


___
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