Re: [Yade-dev] Disabling/redirecting questions on launchpad?

[Bruno Chareyre]

Hi,

I switched the "Answers" configuration from "Launchpad" to "External". 
The old questions are still accessible.

Now the answers tab in browser is empty [1].
Unfortunately it does not point to gitlab, it just says "Launchpad does 
not know where Yade tracks support requests" and it redirects to ubuntu 
package for yade...


I inserted the link to gitlab in the overview. [2]

https://answers.launchpad.net/yade
https://launchpad.net/yade

Cheers

Bruno

On 13/12/2023 10:51, Jan Stránský wrote:

Hello,
there are regularly new questions on launchpad.
Would it be possible to disable new questions?
Or better, somehow automatically redirect to GitLab?
Cheers
Jan

___
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

Grenoble INP - UGA
Institut d'ingénierie et de management / Graduate Schools of engineering and 
management
46 av. Félix-Viallet - 38301 Grenoble
www.grenoble-inp.fr

3SR Lab
1270, rue de la piscine - 38400 Saint Martin d’Hères
www.3sr.univ-grenoble-alpes.fr

Email too short? Here is why: https://www.emailcharter.info/


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

[Bruno Chareyre]

Dear Marius,

Congrats and thank you for letting us know. Maybe Luc will take care of 
listing it in our publication page.

Otherwise, please, provide a bibtex entry.

Best Regards

Bruno

On 07/12/2023 14:43, Marius Huber wrote:

Hello,

I would like to draw your attention to our recent publication using 
Yade. You may want to add its reference to your online publication list.
https://www-sciencedirect-com.bases-doc.univ-lorraine.fr/science/article/pii/S0169555X23003665 



/Huber, M., Scholtès, L., & Lavé, J. (2024). Stability and failure 
modes of slopes with anisotropic strength: Insights from discrete 
element models. Geomorphology, 444, 108946./


Or the DOI:
https://doi.org/10.1016/j.geomorph.2023.108946 
<https://doi-org.bases-doc.univ-lorraine.fr/10.1016/j.geomorph.2023.108946> 



Have a good day.

Kind regards,

Marius Huber
/_/
/Marius L. HUBER/
/Doctorant - Tectonique, Erosion & Evolution du relief,/
/Centre de Recherches Pétrographiques et Géochimiques/
/(CRPG), CNRS, et GeoRessources, Université de Lorraine/
/15 rue Notre Dame des Pauvres BP 20/
/54500 Vandœuvre les Nancy, France/
/Tél. +33 (0)644 381231 | Skype: marius.huber21/





___
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

Grenoble INP - UGA
Institut d'ingénierie et de management / Graduate Schools of engineering and 
management
46 av. Félix-Viallet - 38301 Grenoble
www.grenoble-inp.fr

3SR Lab
1270, rue de la piscine - 38400 Saint Martin d’Hères
www.3sr.univ-grenoble-alpes.fr

Email too short? Here is why:https://www.emailcharter.info/
___
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] Deprecate Debian Stretch, Ubuntu 16.04, 18.04

[Bruno Chareyre]

Hi Klaus,

Removing from pipeline just means that we don't rebuild on 18.04 again 
and again in gitlab.
The 18.04 release will still be available, so there is no special issue 
wrt openFoam in my view.


Bruno

On 20/11/2023 22:07, Klaus Thoeni wrote:

HI guys,

regarding 18.04. In the paper it is stated that OpenFOAM coupling is 
only working in 18.04. Would it make sense to keep it?


Klaus

On Tue, Nov 21, 2023 at 7:42 AM Bruno Chareyre 
 wrote:


Yes, that's perfect.

B

On 20/11/2023 21:39, Anton Gladky wrote:

Hi Bruno,

we can freeze the daily versions and drop deprecated distros
from all CI pipelines.

Regards

Anton

Am Mo., 20. Nov. 2023 um 21:01 Uhr schrieb Bruno Chareyre
  <mailto:bruno.chare...@3sr-grenoble.fr>:

Hi Anton,

I agree to stop building them. To be sure: are you thinking about removing them from 
"daily" package repository as well, or just to freeze the versions there?

Cheers

Bruno


On 20/11/2023 20:52, Anton Gladky wrote:

Dear all,

We are adding more and more releases to be supported.|
Debian Trixie is being added in the near future, and later
next year, Ubuntu 24.04 LTS will also be included.

My proposal is to deprecate at least Debian Stretch, Ubuntu 16.04,
and Ubuntu 18.04. We need to free up some resources, and
having always older distributions in pipelines is unlikely to bring
any benefit.

What are your thoughts? How many users are really using those
distributions?

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

    --

    Bruno Chareyre
Associate Professor

Grenoble INP - UGA
Institut d'ingénierie et de management / Graduate Schools of engineering 
and management
46 av. Félix-Viallet - 38301 Grenoble
www.grenoble-inp.fr  <http://www.grenoble-inp.fr>

3SR Lab
Soils, Solids, Structures, Risks
1270, rue de la piscine - 38400 Saint Martin d’Hères
www.3sr.univ-grenoble-alpes.fr  <http://www.3sr.univ-grenoble-alpes.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
    -- 


*Bruno Chareyre*
/Associate Professor
/

/*Grenoble INP - UGA**
*Institut d'ingénierie et de management / Graduate Schools of
engineering and management**
46 av. Félix-Viallet - 38301 Grenoble
www.grenoble-inp.fr <http://www.grenoble-inp.fr>
/

/*3SR Lab**
*Soils, Solids, Structures, Risks**
1270, rue de la piscine - 38400 Saint Martin d’Hères
www.3sr.univ-grenoble-alpes.fr <https://3sr.univ-grenoble-alpes.fr/en>
/

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

/*Grenoble INP - UGA**
*Institut d'ingénierie et de management / Graduate Schools of 
engineering and management**

46 av. Félix-Viallet - 38301 Grenoble
www.grenoble-inp.fr <http://www.grenoble-inp.fr>
/

/*3SR Lab**
*Soils, Solids, Structures, Risks**
1270, rue de la piscine - 38400 Saint Martin d’Hères
www.3sr.univ-grenoble-alpes.fr <https://3sr.univ-grenoble-alpes.fr/en>
/

//___
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] Deprecate Debian Stretch, Ubuntu 16.04, 18.04

[Bruno Chareyre]

Yes, that's perfect.

B

On 20/11/2023 21:39, Anton Gladky wrote:

Hi Bruno,

we can freeze the daily versions and drop deprecated distros
from all CI pipelines.

Regards

Anton

Am Mo., 20. Nov. 2023 um 21:01 Uhr schrieb Bruno Chareyre
:

Hi Anton,

I agree to stop building them. To be sure: are you thinking about removing them from 
"daily" package repository as well, or just to freeze the versions there?

Cheers

Bruno


On 20/11/2023 20:52, Anton Gladky wrote:

Dear all,

We are adding more and more releases to be supported.|
Debian Trixie is being added in the near future, and later
next year, Ubuntu 24.04 LTS will also be included.

My proposal is to deprecate at least Debian Stretch, Ubuntu 16.04,
and Ubuntu 18.04. We need to free up some resources, and
having always older distributions in pipelines is unlikely to bring
any benefit.

What are your thoughts? How many users are really using those
distributions?

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

--

Bruno Chareyre
Associate Professor

Grenoble INP - UGA
Institut d'ingénierie et de management / Graduate Schools of engineering and 
management
46 av. Félix-Viallet - 38301 Grenoble
www.grenoble-inp.fr

3SR Lab
Soils, Solids, Structures, Risks
1270, rue de la piscine - 38400 Saint Martin d’Hères
www.3sr.univ-grenoble-alpes.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

--

*Bruno Chareyre*
/Associate Professor
/

/*Grenoble INP - UGA**
*Institut d'ingénierie et de management / Graduate Schools of 
engineering and management**

46 av. Félix-Viallet - 38301 Grenoble
www.grenoble-inp.fr <http://www.grenoble-inp.fr>
/

/*3SR Lab**
*Soils, Solids, Structures, Risks**
1270, rue de la piscine - 38400 Saint Martin d’Hères
www.3sr.univ-grenoble-alpes.fr <https://3sr.univ-grenoble-alpes.fr/en>
/

//___
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] Deprecate Debian Stretch, Ubuntu 16.04, 18.04

[Bruno Chareyre]

Hi Anton,

I agree to stop building them. To be sure: are you thinking about 
removing them from "daily" package repository as well, or just to freeze 
the versions there?


Cheers

Bruno


On 20/11/2023 20:52, Anton Gladky wrote:

Dear all,

We are adding more and more releases to be supported.|
Debian Trixie is being added in the near future, and later
next year, Ubuntu 24.04 LTS will also be included.

My proposal is to deprecate at least Debian Stretch, Ubuntu 16.04,
and Ubuntu 18.04. We need to free up some resources, and
having always older distributions in pipelines is unlikely to bring
any benefit.

What are your thoughts? How many users are really using those
distributions?

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

--

*Bruno Chareyre*
/Associate Professor
/

/*Grenoble INP - UGA**
*Institut d'ingénierie et de management / Graduate Schools of 
engineering and management**

46 av. Félix-Viallet - 38301 Grenoble
www.grenoble-inp.fr <http://www.grenoble-inp.fr>
/

/*3SR Lab**
*Soils, Solids, Structures, Risks**
1270, rue de la piscine - 38400 Saint Martin d’Hères
www.3sr.univ-grenoble-alpes.fr <https://3sr.univ-grenoble-alpes.fr/en>
/

//___
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] A new dev member

[Bruno Chareyre]

Dear all,

I have been in contact with Ruidong (Kyle) LI lately. Since he was 
planning to suggest changes to the source code (I don't know much more 
yet) I invited him to yade-trunk.

Welcome Ruidong!

Bruno

--
Bruno Chareyre
Associate Professor

Grenoble INP - UGA
Institut d'ingénierie et de management / Graduate Schools of engineering and 
management
46 av. Félix-Viallet - 38301 Grenoble
www.grenoble-inp.fr

3SR Lab
1270, rue de la piscine - 38400 Saint Martin d’Hères
www.3sr.univ-grenoble-alpes.fr

Email too short? Here is why: https://www.emailcharter.info/


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

[Bruno Chareyre]

I see your test in my mailbox.
Maybe we will have to host a "yade-dev" list somewhere else if we drop 
launchpad?


B

On 29/08/2023 19:36, Janek Kozicki (yade) wrote:

I am testing yade-dev mailing list. I can see latest Bruno's email in
the mailing list archive:

https://lists.launchpad.net/yade-dev/date.html

but I didn't receive it as email.

I wonder what's going on.

Janek

--
Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
Gdansk University of Technology (Gdansk Tech)
Faculty of Applied Physics and Mathematics
Institute of Physics and Applied Computer Science
Division of Theoretical Physics and Quantum Information
--
http://yade-dem.org/
http://pg.edu.pl/p/jan-kozicki-19725
http://mostwiedzy.pl/en/jan-kozicki,19725-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

--

*Bruno Chareyre*
/Associate Professor
/

/*Grenoble INP - UGA**
*Institut d'ingénierie et de management / Graduate Schools of 
engineering and management**

46 av. Félix-Viallet - 38301 Grenoble
www.grenoble-inp.fr <http://www.grenoble-inp.fr>
/

/*3SR Lab**
*Soils, Solids, Structures, Risks**
1270, rue de la piscine - 38400 Saint Martin d’Hères
www.3sr.univ-grenoble-alpes.fr <https://3sr.univ-grenoble-alpes.fr/en>
/

//___
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] Fwd: [Yade-users] [Question #160514]: launching yade

[Bruno Chareyre]

Conclusion: the mailing lists still work. We can communicate through 
yade-dev too.


Feedback on the "Yade guide":

1- it seems to work, it is impressive
2- it's probably better to crawl the archives of recent years only 
(mentionning scons in relation with compiling issue is very confusing)
3- in the end, the first paragraph could be shortened, something like 
"possibly related issues:"


B




 Forwarded Message 
Subject:Re: [Yade-users] [Question #160514]: launching yade
Date:   Mon, 28 Aug 2023 07:10:37 -
From:   Yade Guide 
Reply-To:   question160...@answers.launchpad.net
To: yade-us...@lists.launchpad.net



Question #160514 on Yade changed:
https://answers.launchpad.net/yade/+question/160514

Yade Guide posted a new comment:
Hey there! As an automated bot, I've gone through your question and
found a few relevant threads that might interest you. Feel free to
explore these topics further by clicking on the links provided below.

Title: "compilation failed on debian wheezy"
The user faced issues with YADE, which were resolved by deleting 
'build-unknown'. Despite using the latest git version (7b3752a), they 
still encountered 'yade-unknown' on Wheezy. The issue should be fixed 
when python-git 0.3.2~RC1-1 migrates to Wheezy, and the user needs to 
clean their scons.profile from any 'garbage'.

https://answers.launchpad.net/yade/+question/193815


Title: "Problem while launching YADE"
Benoit encounters issues with YADE launch due to missing libraries 
despite successful compilation, Jerome and Anton provide assistance. 
Suggestions include using '/home/benoit/YADE/install' as the 
DINSTALL_PREFIX and checking if 'DINSTALL_PREFIX=$HOME/YADE/install' 
works. Starting from rev 6d9fdab6 it does not matter any more, what path 
to use: relative or absolute.

https://answers.launchpad.net/yade/+question/204120

--
You received this question notification because your team yade-users is
an answer contact for Yade.

___
Mailing list:https://launchpad.net/~yade-users
Post to :yade-us...@lists.launchpad.net
Unsubscribe :https://launchpad.net/~yade-users
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 2023.02a released

[Bruno Chareyre]

h all Ig2 
functors,... (!893)

  ensure randomColor() uses utils func (!909)
  Removing unused chain attribute from facet() Python  signature (!913)
  fabricTensor for non-spherical particles through extrema  argument 
(!916)

  Update Hertz-Mindlin model and docs (!919)

Fluid & thermal & particle saturation ( 7 MRs)
  ymport.py: Check FoamFile header and handle comments.  (!813)
  Generalize link between ThermalEngine and derived  FlowEngines (!844)
  Make thermal state working version (!846)
  avoid a potential infinite recursion in the lubricated  contact 
model (!847)

  compile and improve  Law2_ScGeom_CapillaryPhys_Capillarity1.cpp (!868)
  Adding a readme file for capillary files, with data  description (!904)
  Fix CapillaryEngine (case of no input files) + exemple  script (!902)

High precision RealHP ComplexHP ( 7 MRs)
  Build ubuntu 22.04 & bookworm packages for long double,  float128 
and mpfr150 (!814)
  Fix REAL_HP on other architectures. Add bookworm arm64 to  CI 
pipeline. (!817)

  Fix long double on other architectures: arm64, s390x,  ppc64el (!820)
  Fix #247 by removing the confusing name REAL_HP (!859)
  Needs a fix: Debian package high precision build problem  (!884)
  Make sure cpp_bin_float 150 passes the tests: larger tolerance 62 → 
150 decimal places. (!887)

  A bit more in docs about "Using higher precisions in C++" (!918)

PotentialParticles / Blocks           ( 5 MRs)
  PotentialParticle minor changes (documentation,  unnecessary 
prerequisites and contact between fixed bodies) (!835)
  Correct normalForce when allowViscousAttraction=False for  PP and PB 
(!838)

  Pbc doc figures improvements (!862)
  Allow contacts between fixed potential blocks (!910)
  Adding potential_utils module and additional examples for  the 
PotentialBlocks (!907)


Examples                              ( 4 MRs)
  Law2_ScGeom_CapillaryPhys_Capillarity maintenance:  updates in doc 
and examples README, in independence of the wiki (!896)
  Partial fix bug #228, use yapf3 python code formatting on  some of 
examples (not all of them yet) (!715)
  A capillary example: A better location of GSTS before NI  (thanks 
Guo Chang) (!878)

  fixed outdated mill.py example (!899)

Tests & checks & CI                   ( 4 MRs)
  increase ccache size to 500G for nova runners (!845)
  reduce peak demand on MPI workers to release pressure on  gitlab 
runners (from 10 to 4) (!848)

  enable shared ccache and make -j4 the default (not 5)  (!849)
  Fix test_bookworm: it now uses the same screenshots as  test_22_04 
(!856)


Polyhedra / Facets                    ( 3 MRs)
  Further clarification of Facet code (!826)
  ymport: polyMesh support. (!821)
  Modifying code comments in ScGeom, now that it may apply  to sthg 
else than Sphere and Facet shapes (!880)


Clumps                                ( 3 MRs)
  Implement clump breakage algorithm (!857)
  Fix clump stress (!891)
  use Shop::getStress in PeriTriaxController to handle  clumps 
gracefuly (!892)


Packaging improvements & building     ( 2 MRs)
  CMake: Skip libvtk version 7. (!819)
  CMake: Add DISABLE_PKGS option. (!816)

Alpha shapes                          ( 2 MRs)
  Display alphaShapes in QGLViewer (!901)
  Bound alpha shapes (!906)

clang-format & reorganize             ( 7 MRs)
  Move pfv (!851)
  Fix #228, small final reformat (!929)
  Fix #228, add to the CI pipeline a verification that all python 
scripts are formatted (now it's ready) (!926)

  small clang C++ reformat (!922)
  Partial fix bug #228, yapf3 python reformat in ./examples/ (!925)
  Partial fix bug #228, small yapf3 python reformat in ./py/ ./gui/ 
and ./doc/ (!924)

  Partial fix bug #228, small yapf3 python reformat in ./scripts/ (!923)

___
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
Grenoble INP - 3SR Lab.


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

[Bruno Chareyre]

Dear Yade devs,

I wish you all a happy new year.
Some good news to start with: I got latest yade documentation accepted 
in arXiv [1].


Since arXiv is now indexed by Scopus, there is a chance Yade will be 
there too at some point.


The tex sources couldn't be included because arXiv doesn't support 
xetex, unfortunately. It went through as a pdf only.


Cheers

Bruno

[1] http://arxiv.org/abs/2301.00611

--
Bruno Chareyre
Grenoble INP - 3SR Lab.


___
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] Please enable runners for some projects in the group

[Bruno Chareyre]

Hi,

The nova runners are a bit limited in disk space, especially nova2.
If this will need additional docker images (docker-prod probably 
would?), it's maybe wiser to not use them here. What do you think?


And yes, let's remove yade-runner1, but... where do you see it?
I would like to find the machine name in order to also locate it physically.

Bruno


On 15/10/2022 15:55, Janek Kozicki (yade) wrote:

Great, let me know in case of problems :-))

Janek

Anton Gladky said: (by the date of Sat, 15 Oct 2022 14:48:28 +0200)


Thanks, Janek! It really works!

Anton


Am Sa., 15. Okt. 2022 um 14:19 Uhr schrieb Janek Kozicki (yade) <
jkozicki-y...@pg.edu.pl>:


Hi,

I have created a single group runner, called loop1-group-runner, in:

https://gitlab.com/groups/yade-dev/-/runners?runner_type[]=GROUP_TYPE

now it appears in every of our projects. Also there is a
yade-runner-01, last time I checked it ran out of disc space and
couldn't do any jobs. Maybe it is time to recheck yade-runner-01 and
maybe erase it, Bruno?

I suppose, that once group runners are enabled in all projects that
you linked below, it should work? I only checked in docker-prod and
it seems to work:

https://gitlab.com/yade-dev/docker-prod/-/jobs/3178115457

best regards
Janek

Anton Gladky said: (by the date of Sat, 15 Oct 2022 11:46:18 +0200)


Hi.

as you probably know, gitlab is changing its business modell.
Right now we are affected by this change through the usage
of shared runners for some projects.

@Janek, @Bruno or maybe somebody else, could you please
your runner-instances for the following projects:

- Docker-Prod: https://gitlab.com/yade-dev/docker-prod/-/settings/ci_cd
- Singularity-Prod:
https://gitlab.com/yade-dev/singularity-prod/-/settings/ci_cd
- Answers (no CI, but would be good to have):
https://gitlab.com/yade-dev/answers/-/settings/ci_cd
- Yade-Website (reserved for the future):
https://gitlab.com/yade-dev/yade-website/-/settings/ci_cd
- Yade-data (no CI, but would be good to have)
https://gitlab.com/yade-dev/yade-data/-/settings/ci_cd

Thanks

Anton


--
--
Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
Gdansk University of Technology (Gdansk Tech)
Faculty of Applied Physics and Mathematics
Institute of Physics and Applied Computer Science
Division of Theoretical Physics and Quantum Information
--
http://yade-dem.org/
http://pg.edu.pl/jkozicki (click English flag on top right)





___
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] Website down?

[Bruno Chareyre]

The hardware is fixed and website is back.

B

On 30/05/2022 08:28, bruno.chareyre wrote:
Local hardware failure, independent of the yade server. Our intranet 
is down basically. Should be fixed soon.

Cheers

B

---
Bruno Chareyre
Grenoble INP - 3SR
---


Local hardware failure, independent of the yade server. Our intranet is down 
basically. Should be fixed soon.CheersB---Bruno ChareyreGrenoble INP - 3SR---


 Message d'origine 
De : Jan Stránský 
Date : 26/05/2022 16:59 (GMT+01:00)
À : Robert Caulk 
Cc : Yade developers 
Objet : Re: [Yade-dev] Website down?

no..
Jan


čt 26. 5. 2022 v 16:55 odesílatel Robert Caulk  
napsal:


Anyone else able to reach yade-dem.org <http://yade-dem.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


 Message d'origine De : Jan Stránský  Date : 
26/05/2022  16:59  (GMT+01:00) À : Robert Caulk  Cc : Yade 
developers  Objet : Re: [Yade-dev] Website down? no..Jančt 26. 5. 
2022 v 16:55 odesílatel Robert Caulk  napsal:Anyone else able to reach 
yade-dem.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] Wiki is down

[Bruno Chareyre]

On 09/05/2022 05:39, Jan Stránský wrote:


I cannot link to https://www.yade-dem.org/wiki/Howtoask :-D


I had exactly the same problem last week, hehe.
It's reported, I'm waiting.
Thanks for mentioning.
That's actually pushing for continuing migration to documentation and 
closing the wiki.


Cheers

Bruno




___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

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

[Bruno Chareyre]

Hi,

Thanks for supporting the idea. Please check [1], which contains a 
temptative paragraph and an updated logo.
I'm a html dummy so the aspect is rather basic. Feel free to improve it 
in any way.


I would propose to link to an english version of the letter by russian 
scientists, which I find brilliant [2]. Didn't find the best target yet 
for an english version.


Bruno

[1] https://gitlab.com/yade-dev/trunk/-/merge_requests/833

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


On 04/03/2022 14:27, Janek Kozicki (yade) wrote:


Yes, good idea. Let's do this. It is so sad and crazy.

Janek

Bruno Chareyre said: (by the date of Thu, 3 Mar 2022 18:16:48 +0100)


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

[Yade-dev] Yade vs. war in Ukraine

[Bruno Chareyre]

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

Re: [Yade-dev] Submitting Yade to an "Open Software" prize (FYI)

[Bruno Chareyre]

Hi,

Yade did not receive a prize unfortunately. Another time maybe.
There where rather big fishes in the competition, including python's 
"Scikit-learn" ("Community" prize).
No feedback was sent to me directly. I had to check the conference 
website to know. You can also check the nominees at [1].


The full program of the conference with corresponding talks are 
available [2].


Cheers

Bruno

[1] 
https://www.ouvrirlascience.fr/open-science-free-software-award-ceremony/


[2] https://osec2022.eu/program/


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

[Bruno Chareyre]

Hi there,
The application has been submitted. I did not circulate the final version since there was not enough time left for review, but I think the 
discussion in our last meeting was enough. Now let's see what happens.

The decision shouldn't take too long since the prizes will be given on February 4th at 
"Paris Open Science European Conference".
Cheers
Bruno

[1] https://www.ouvrirlascience.fr/paris-open-science-european-conference-osec/

On 10/25/21 12:27 PM, 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


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

[Bruno Chareyre]

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] members yade-dev gitlab

[Bruno Chareyre]

Hi Raphaël,

Please check your emails, I just invited you (again? or maybe if I 
failed something last time, sorry).


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

[Yade-dev] Dev meeting next week

[Bruno Chareyre]

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] would a HarmonicForceEngine be of any interest?

[Bruno Chareyre]

Hi Daniel, it makes sense. You are welcome to show this in a merge 
request (do you know how?).


Bruno

On 12/05/2021 14:25, Daniel Kiracofe wrote:
For my own purposes, I have written a HarmonicForceEngine, which is 
exactly what it sounds like.  Identical to HarmonicMotionEngine, but 
applies proscribed forces instead of proscribed motion. Would this be 
of interest to anyone else? If so I can submit a merge request.


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
___
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] Docker/Singularity images for production (and possibly development)

[Bruno Chareyre]

ml#L17


Yes, that's my fault 
<https://gitlab.com/yade-dev/docker-yade/-/commit/c0674c4aacdd3207bb156d2f385704ac5bf5d763>. 
:)


But I was speaking of pushing from trunk pipeline. Anyway, the 
incremental compilation part is a secondary point.


Main point is we can easily provide some docker/singularity images that 
people could directly use to run yade (on HPC especially). Currently we 
don't. Depending on storage limits they can be under yade-dev or 
bchareyre, I don't mind. Either way we can point to them in the doc.


Cheers

Bruno







best regards
Janek

Bruno Chareyre said: (by the date of Fri, 5 Mar 2021 10:37:59 +0100)


Hi there,

I'm planning to build new docker images in yade's gitlab for production,
and possibly for development (see second part of this message, some
background comes first).  This is open to suggestions.

* Background:

I recently started playing with "Singularity" images since I found our
HPC department made it available on the clusters. There was also a user
mentioning that on launchpad recently. From end-user POV, singularity
images work like docker images, but a very practical difference is that
it is allowed on our (and others') HPC. Docker isn't, for security reason.

It made running yade so easy. The above command worked immediately, and
should work just the same on every system with singularity installed:
/ssh myHPC//
//singularity exec
docker://registry.gitlab.com/bchareyre/docker-yade:ubuntu20.04-daily
yadedaily --check/

or equivalently: /
///export YADE=//'singularity exec
docker://registry.gitlab.com/bchareyre/docker-yade:ubuntu20.04-daily
yadedaily'
$YADE --check
$YADE myScript.py
$ etc.
//

Key points:
1- singularity accepts docker images in input.
2- the above command is using some custom docker with yadedaily
pre-installed (which then needs to be downloadable from somewhere where
docker is permitted)
3- it is compatible with MPI(!). The host system's MPI is able to
communicate with the image system's MPI in a scenario like this, as if
it was just yade running natively on the host:
/mpirun -np 500 $YADE someParrallelStuff.py
/4- a condition for this MPI magic to work is that the mpi library is in
the same version for the host and for the executed image
5- performance: no measurable difference compared to a yade compiled on
the host (be it running -j1, -jN or mpiexec).

For the moment the custom dockers are built in [1]
<https://gitlab.com/bchareyre/docker-yade>.
I'm also building a Singularity images with [2]
<https://gitlab.com/bchareyre/yade-singularity/-/blob/master/.gitlab-ci.yml>
but I didn't really use it since I can build it from docker directly on
the cluster (building the singularity image is implicit in /singularity
exec docker://.../). Building on-site may not be allowed everywhere,
though, and in that case [2] could be useful.

* What can be done:

I will move [1,2] or something similar to gitlab/yade-dev and advertise
it in the install page. Also build more versions for people to use them.
More versions because of the MPI point above (4): depending on the host
system someone may want OMPI v1 (unbuntu16), or v2 (ubuntu18), etc.

For production images it would make sense to just use canonical
debian/ubuntu with yade and/or yadedaily preinstalled. But, it is not
exactly what I did for the moment. Instead I used docker images from our
registry. Which implies the images have yade, and also what it needs to
compile yade (I didn't test compilation yet but it should work).

I was thinking of splitting that into two types of images; minimal
images for production and "dev" images with all compilation
pre-requisites. Then I realized that the best "dev" image would be - by
far - one reflecting the state of the system at the end of our current
pipeline, i.e. one with a full /build folder and possibly ccache info
(if not too large).

If such dev images were pushed to yade registry then anyone could grab
latest build and recompile incrementally. It could save a lot of
(compilation) time for us when trying to debug something on multiple
distros.

And what about that?: compiling with a ubuntu20 docker image on a
ubuntu20 host should make it possible to use the pipeline's ccache while
still running yade on the native system (provided that the install path
is in the host filesystem).

Maybe pushing to registry could be done directly as part of current
pipeline, not sure yet. I am still thinking about some aspects but I
think you get the general idea. Suggestions and advices are welcome. :)

Chers

Bruno

[1] https://gitlab.com/bchareyre/docker-yade

[2]
https://gitlab.com/bchareyre/yade-singularity/-/blob/master/.gitlab-ci.yml


___
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] Docker/Singularity images for production (and possibly development)

[Bruno Chareyre]

Hi there,

I'm planning to build new docker images in yade's gitlab for production, 
and possibly for development (see second part of this message, some 
background comes first).  This is open to suggestions.


* Background:

I recently started playing with "Singularity" images since I found our 
HPC department made it available on the clusters. There was also a user 
mentioning that on launchpad recently. From end-user POV, singularity 
images work like docker images, but a very practical difference is that 
it is allowed on our (and others') HPC. Docker isn't, for security reason.


It made running yade so easy. The above command worked immediately, and 
should work just the same on every system with singularity installed:

/ssh myHPC//
//singularity exec 
docker://registry.gitlab.com/bchareyre/docker-yade:ubuntu20.04-daily 
yadedaily --check/


or equivalently: /
///export YADE=//'singularity exec 
docker://registry.gitlab.com/bchareyre/docker-yade:ubuntu20.04-daily 
yadedaily'

$YADE --check
$YADE myScript.py
$ etc.
//

Key points:
1- singularity accepts docker images in input.
2- the above command is using some custom docker with yadedaily 
pre-installed (which then needs to be downloadable from somewhere where 
docker is permitted)
3- it is compatible with MPI(!). The host system's MPI is able to 
communicate with the image system's MPI in a scenario like this, as if 
it was just yade running natively on the host:

/mpirun -np 500 $YADE someParrallelStuff.py
/4- a condition for this MPI magic to work is that the mpi library is in 
the same version for the host and for the executed image
5- performance: no measurable difference compared to a yade compiled on 
the host (be it running -j1, -jN or mpiexec).


For the moment the custom dockers are built in [1] 
.
I'm also building a Singularity images with [2] 
 
but I didn't really use it since I can build it from docker directly on 
the cluster (building the singularity image is implicit in /singularity 
exec docker://.../). Building on-site may not be allowed everywhere, 
though, and in that case [2] could be useful.


* What can be done:

I will move [1,2] or something similar to gitlab/yade-dev and advertise 
it in the install page. Also build more versions for people to use them. 
More versions because of the MPI point above (4): depending on the host 
system someone may want OMPI v1 (unbuntu16), or v2 (ubuntu18), etc.


For production images it would make sense to just use canonical 
debian/ubuntu with yade and/or yadedaily preinstalled. But, it is not 
exactly what I did for the moment. Instead I used docker images from our 
registry. Which implies the images have yade, and also what it needs to 
compile yade (I didn't test compilation yet but it should work).


I was thinking of splitting that into two types of images; minimal 
images for production and "dev" images with all compilation 
pre-requisites. Then I realized that the best "dev" image would be - by 
far - one reflecting the state of the system at the end of our current 
pipeline, i.e. one with a full /build folder and possibly ccache info 
(if not too large).


If such dev images were pushed to yade registry then anyone could grab 
latest build and recompile incrementally. It could save a lot of 
(compilation) time for us when trying to debug something on multiple 
distros.


And what about that?: compiling with a ubuntu20 docker image on a 
ubuntu20 host should make it possible to use the pipeline's ccache while 
still running yade on the native system (provided that the install path 
is in the host filesystem).


Maybe pushing to registry could be done directly as part of current 
pipeline, not sure yet. I am still thinking about some aspects but I 
think you get the general idea. Suggestions and advices are welcome. :)


Chers

Bruno

[1] https://gitlab.com/bchareyre/docker-yade

[2] 
https://gitlab.com/bchareyre/yade-singularity/-/blob/master/.gitlab-ci.yml


/
/

/
/

/
/

/
/




___
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] A suggestion/contribution regarding bug of Yade-users #694548

[Bruno Chareyre]

Hi Gaël,

On 03/03/2021 00:49, Janek Kozicki (yade) wrote:

For example if you
have your commits in master,


In case you have no idea if the commits are in master, let's step back a 
bit (else Janek's instructions are already enough):


- your modified source code is in a folder "trunk", go to that path in 
terminal

- try "git status", then "git diff". Do you see the changes?
- if so "git commit -a -m 'short description of what is commited' "
- go back to Janek's email :)

Bruno




___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] boost::mpi and python bindings for it.

[Bruno Chareyre]

Hi,

Very interesting indeed. I didn't notice.
I wouldn't claim that, by definition, it is more safe than mpi4py (just 
another wrapper) but it would remove that dependency.


I wonder if a simple replacement of mpi4py.comm by boost.mpi.comm would 
do the trick. If they followed same naming conventions it could.


Cheers

Bruno


On 03/03/2021 23:56, Janek Kozicki (yade) wrote:

Hi Bruno,

There is a boost::mpi library built on top of OpenMPI, MPICH2, IntelMPI [0].
In the introduction [1] they say it's just a wrapper for OpenMPI,
MPICH2 and IntelMPI. By using boost you could have some extra safety.

Example [2]:

int main(int argc, char* argv[])
{
   mpi::environment env(argc, argv);
   mpi::communicator world;
   std::cout << "I am process " << world.rank() << " of " << world.size()
 << "." << std::endl;
   return 0;
}

Python example [3]:

   import boost.mpi as mpi
   print "I am process %d of %d." % (mpi.rank, mpi.size)

Have a look :)
Janek

[0] https://www.boost.org/doc/libs/1_75_0/doc/html/mpi.html
[1] https://www.boost.org/doc/libs/1_75_0/doc/html/mpi/getting_started.html
[2] https://www.boost.org/doc/libs/1_75_0/doc/html/mpi/tutorial.html
[3] https://www.boost.org/doc/libs/1_75_0/doc/html/mpi/python.html






___
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] A suggestion/contribution regarding bug of Yade-users #694548

[Bruno Chareyre]

Hi Gaël,

Thank you for your email. And no you are not colliding with my work 
since I have it in mind but didn't start anything yet.


I would suggest you create a gitlab account if you don't have one so we 
can add you as yade contributor.


You can then push your change to a branch. Something like (assuming you 
modified the sources directly in local master branch):


/git push origin master:PFacetFix /


I'm eager to understand which problem you found. :)


Bruno


On 23/02/2021 21:59, Gael Lorieul wrote:

Hi ️

It has been a long time…

I have come accross thread #694548 on the "Yade-users" mailing list 
(from January 2021), which concerned unphysical collisions between 
PFacets (the dynamics of the rebound does not correspond to what one's 
physical/common sense would expect).


I wanted to share that I encountered a very similar issue but with 
gridConnection objects (I work with cylinders), and that I found a 
solution. The latter should be easily extendible both to PFacet/PFacet 
and PFacet/gridConnection collisions (although I only tested 
gridConnection/gridConnection collisions). I am not sure how elegant 
or computationally efficient it is, but it has given me good results 
on the (very few) simulations I have tested it on.


I initially wanted to test my solution on full-scale simulations 
before submiting it to the Yade code base, so as to present a code 
that is robust and mature. But as it has been almost a full year since 
then (the company I work for gave me assignments other than DEM), I 
feel that perhaps I should reach out for other ways to share this 
information…


This implies that although I am quite confident of my fix, I am not 
100% certain either…


Perhaps a first step would be for me to present what I have found, and 
how my fix works? I am not sure as to where to present it: This 
mailing list? Thread #694548? You tell me ️


Gaël


PS: I have started to re-implement my solution in yade e07e530 (26 Nov 
2020) (my previous implementation was based on yade 1b4ae97 (8 Feb 
2020)). Hopefully the work I do on e07e530 will not be difficult to 
port to the latest yade versions… (It seems the yade project started 
using clang-format (or similar tool) sometime between e07e530 and 
1b4ae97 so `diff` outputs half the file: not very helpful… ️)


PS2: Could thread #695558 be also concerned by this same uncorrect 
physical behavior?


PS3: I hope that I am not colliding with Bruno's work on the subject 
(according to Bruno's e-mail of Tue, 12 Jan 2021 07:50:51)



___
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] New Yade version, beginning of January 2021 - Release notes.

[Bruno Chareyre]

Hi all,

It has been a busy year for yade-dev. With both fresh and vetran blood 
flowing in.


I trust 2021 will be also quite busy, and that's great.

Thanks very much to Anton and Janek for putting stuff together for next 
release.


And Happy New Year to all of you!

Bruno

p.s. we might also want to release a new numbered version of doc 
sometimes soon. 2nd edition is from 2015.




On 31/12/2020 22:27, Anton Gladky wrote:

Hi Janek,

thanks for preparing release notes based on MR! Very appreciated!
I will start to prepare a newer Yade release soon.

Best regards

Anton

Am Fr., 25. Dez. 2020 um 00:26 Uhr schrieb Janek Kozicki (yade)
:

Hi Anton,

the website https://pad.systemli.org/p/yade-2021-release-notes
has reset its content. I pasted there the merge requests from this year.
But also I paste them here. Of course please rearrange as you see fit :)

I might have misplaced some merge request titles. Then please edit this list.
Especially I thought that we had more MPI related stufff happening.


Short summary of 2021.01a release:
short title (Merge Request count)

Documentation (41 MRs)
Bug fixes (36 MRs)
High precision RealHP  (31 MRs)
Small improvements(22 MRs)
Fluid & thermal & particle saturation (14 MRs)
Tests & checks(12 MRs)
OpenMPI calculations  ( 8 MRs)
clang-format in the pipeline  ( 7 MRs)
Packaging improvements( 6 MRs)
GUI   ( 3 MRs)


Documentation (41 MRs):
   Update installation.rst (asan builds + stuff)
   Add recent publications
   point youtube's 'related videos' to the same channel
   Update front page link to videos: tutorial-more-examples.html more up to 
date.
   Fix bug and documentation FlowEngine invVoidVolume wrapper
   Fix recent build failures on master with latest docker bullseye image.
   Small docs fix
   Doc typo: missing norm in trial shear force
   Doc Body.groupMask
   User doc
   Update high precision documentation
   Miscellanea doc
   Add example script for opengeomechanics paper
   clarify thermalengine doc
   Documentation makeCloud and makeClumpCloud
   ViscoelasticPM doc update
   Prog doc typo
   ProgDocTypos
   Formulation doc typo
   improve cellDist doc
   small addition to the doc to mention verletDist explicitely
   Doc prog.rst update
   FlowEngine.getCell doc
   Doc update of VTKRecorder.fileName
   ymport.textPolyhedra-doc
   Prog doc typos and minor changes
   Doc Law2_Polyhedra*
   residualFrictionAngle in radians in JCFpmMat docstring
   Sphinx doc broken link in Prog doc
   O.forces.f doc
   Two Docstrings
   BaselineTypo
   adding open geomechanics reference to doc and pubs
   Add --stdperformance, --quickperformance explanation to documentation.
   Polyhedra Ip2 doc
   MaterialContainer doc typo
   timing.runtimeDoc
   Added Hicham Benniou PhD reference
   Add references to article describing lubrication law
   update publications
   !463 alternative : Added article February 2020 Computational Particle 
Mechanics

Bug fixes (36 MRs):
   fix #145 seed in makeCloud FIX makeCloud doesn't use "seed"
   Fix pygts module import in python3.9
   Fix PyRunner. Now it can propagate errors upwards.
   Fix #110 FIX Graph yade.plot.live matplotlib numpy update exception
   Fix compilation with python3.9
   fix #157 FIX O.stopAtTime does not do anything useful
   Fix #140 FIX ForceContainerParallel::sync() can count permanent forces twice 
or more
   Fix https://gitlab.com/yade-dev/docker-yade/issues/1 FIX yade-ci crashes
   export.text2vtk - fixed a bug + refactoring
   Fix #146 FIX "to-Python converter already registered" RuntimeWarning
   Fix even more warnings, print only 'maybe-uninitialized' and '#warning' 
(!270), faster compilation. (!273)   18 of 18 tasks completed
   fix clang formating mistake, change remaining doubles to Real
   fix tutorial script https://answers.launchpad.net/yade/+question/689537
   Fix printing Vectors by LOG macros.
   Fix GCC-10 compilation #958006
   Fix_PBs_orientations
   #153 fix FIX O.energy['nonViscDamp'] misses gravity forces
   Skip url ping-pong for "getting help" page
   fix yade crash, when closing 3D view via "X" window frame button, in Ubuntu 
20.04, fixes #164 FIX yade crash when closing the 3D view.
   Fix close view crash
   small mailmap fix and test cleanup
   Little bit of work on #97 : lib/base/Math.hpp should be math only
   Fix compilation against newer QT5.
   Some small fixes for Sacha : Fix compilation with boost 1.65 and g++ 9.3 
combination
   Fix denser grid in GLViewer.
   clumpId type should be Body::id_t, not int. Add fixme note in Math.hpp about 
issue #97
   Fix #162 - fix building master pipeline due to recent VTK upgrade in 
OpenSuse 15.
   Fix build on latest bullseye
   Fix doc generation for newer sphinx. #955097
   Workaround MPFR boost bug on ubuntu focal
   

Re: [Yade-dev] GitLab repo archives

[Bruno Chareyre]

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] Need little help (no laughing please) + some update

[Bruno Chareyre]

Hi there,

I've had a number of independent issues lately, I hope my unavailability 
did not impact daily yade-devs workflow too much (hopefully the bus 
factor was factored in well enough).


I'm now trying to be back, with merging MPI branch as top priority.

The issue is my gitlab account is blocked because of a bug in the google 
sign-in button... I reported the problem, apparently a common one. I'll 
try to get back control of that account. In the meantime it would be 
great if someone could invite user bchareyre1 and grant some admin 
rights to him (at least Anton and Janek can do that).


Commit via ssh should still be ok for me as "bchareyre" but merging, for 
instance, needs to sign in and click. Not possible a.t.m.


I hope you are all doing well.

Laters

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>







-- ___ Bruno Chareyre Associate Professor Lab. 3SR, ENSE³, 
Grenoble INP Tél : +33 4 56 52 86 21  Email too brief? 
Here's why: email charter
___
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

[Bruno Chareyre]

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

[Bruno Chareyre]

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  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
> 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] Do we have "quick" pipeline on gitlab?

[Bruno Chareyre]

On Mon, 18 May 2020 at 19:16, Janek Kozicki (yade) 
wrote:

>  They are listed in the pipeline and marked as
> success, but inside you only have "Skipping this test, because it's a
> WIP merge request."
>
>
Oh! That's why it looks as long as usual but it's faster!
I'm sorry, obviously I lost track at some point. :)

Maybe think about upgrading your pc to 20.04 :)
>

Man... You can't imagine. If I install it by myself it will be ok but I
will not have access to univ intranet.
I thus rely on IT service, but IT is not yet ready to migrate from 16 to 18
(I asked many times). They have issues with multiple things.
That's ok. I can live with schroot/docker and friends, I will have to.
I know I have a long email somewhere with all your instructions to do so. :)

B
___
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] Do we have "quick" pipeline on gitlab?

[Bruno Chareyre]

I meant fast like this ;)
https://gitlab.com/yade-dev/trunk/pipelines/147230965
B

On Mon, 18 May 2020 at 17:17, Bruno Chareyre 
wrote:

> The speed record is because I'm still that idiot trying to debug via
> gitlab instead of just playing a 18.04 image locally...
>
> I see that even for WIP we are compiling a long list. Four different
> high-precision formats, for instance.
> In my case I'm interested in reaching step2 build-doc as fast as possible.
> 95% of the pipeline is a waste.
> Ok, maybe that's too specific and I should just trick gitlab.ci... but
> still, compiling with 5 number formats in the minimal build is a bit
> overkill maybe.
> B
>
>
>
> On Mon, 18 May 2020 at 15:25, Janek Kozicki (yade) <
> jkozicki-y...@pg.edu.pl> wrote:
>
>> Yeah, it looks like you are breaking some speed record here ;)
>> A build below 16 minutes. Almost 10, if you don't look at unnecessary
>> stuff :)
>>
>> Yes, debug is building doc. It is because we had a rare bug caught
>> only by ASAN or debug during doc building and nowhere else. So we decided
>> to
>> keep testing it that way.
>>
>> cheers!
>> Janek
>>
>> Bruno Chareyre said: (by the date of Mon, 18 May 2020 15:08:20 +0200)
>>
>> > Thanks. I know the WIP one indeed but I thought 1/ it was not *that*
>> > faster, and 2/ it was not building doc.
>> > I was wrong on both it seems. :)
>> > Also, it seems debug build includes building doc now, do you confirm?
>> > Things change fast! (for good :)
>> > B
>> >
>> > On Mon, 18 May 2020 at 14:35, Janek Kozicki (yade) <
>> jkozicki-y...@pg.edu.pl>
>> > wrote:
>> >
>> > > Yes, we have a quick pipeline. Add the "WIP: " in front of the title.
>> > > It is being checked by the build system (searach for WIP in
>> > > gitlab-ci.yml file :), and some builds are cancelled if they start
>> > > with WIP:
>> > >
>> > >
>> > > cheers
>> > > Janek
>> > >
>> > > Bruno Chareyre said: (by the date of Mon, 18 May 2020 12:51:33
>> +0200)
>> > >
>> > > > Hi Janek,
>> > > > As I was pushing at high frequency recently I kept cancelling
>> gitlab jobs
>> > > > since they were way too long.
>> > > > Is there a trick I miss? Would it make sense to have a special tag
>> we can
>> > > > set for building some branches with lightweight series of
>> builds/test/doc
>> > > > on them (say, ubuntu + debian)?
>> > > > We can actually trick the gitlab.ci but that's ugly and there's
>> always a
>> > > > risk to push it.
>> > > > Cheers
>> > > > Bruno
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > --
>> > > > ___
>> > > > 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
>> > > >
>> > >
>> > >
>> > > --
>> > > --
>> > > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
>> > > Gdańsk University of Technology
>> > > Faculty of Applied Physics and Mathematics
>> > > Department of Theoretical Physics and Quantum Information
>> > > --
>> > > http://yade-dem.org/
>> > > http://pg.edu.pl/jkozicki (click English flag on top right)
>> > >
>> > >
>> > >
>> >
>> > --
>> > --
>> > ___
>> > 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>
>>
>>
>> --
>> --
>> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
>> Gdańsk University of Technology
>> Faculty of Applied Physics and Mathematics
>> Department of Theoretical Physics and Quantum Information
>> --
>> http://yade-dem.org/
>> http://pg.edu.pl/jkozicki (click English flag on top right)
>>
>>
>>
>
> --
> --
> ___
> 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>
>


-- 
-- 
___
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] Do we have "quick" pipeline on gitlab?

[Bruno Chareyre]

The speed record is because I'm still that idiot trying to debug via gitlab
instead of just playing a 18.04 image locally...

I see that even for WIP we are compiling a long list. Four different
high-precision formats, for instance.
In my case I'm interested in reaching step2 build-doc as fast as possible.
95% of the pipeline is a waste.
Ok, maybe that's too specific and I should just trick gitlab.ci... but
still, compiling with 5 number formats in the minimal build is a bit
overkill maybe.
B



On Mon, 18 May 2020 at 15:25, Janek Kozicki (yade) 
wrote:

> Yeah, it looks like you are breaking some speed record here ;)
> A build below 16 minutes. Almost 10, if you don't look at unnecessary
> stuff :)
>
> Yes, debug is building doc. It is because we had a rare bug caught
> only by ASAN or debug during doc building and nowhere else. So we decided
> to
> keep testing it that way.
>
> cheers!
> Janek
>
> Bruno Chareyre said: (by the date of Mon, 18 May 2020 15:08:20 +0200)
>
> > Thanks. I know the WIP one indeed but I thought 1/ it was not *that*
> > faster, and 2/ it was not building doc.
> > I was wrong on both it seems. :)
> > Also, it seems debug build includes building doc now, do you confirm?
> > Things change fast! (for good :)
> > B
> >
> > On Mon, 18 May 2020 at 14:35, Janek Kozicki (yade) <
> jkozicki-y...@pg.edu.pl>
> > wrote:
> >
> > > Yes, we have a quick pipeline. Add the "WIP: " in front of the title.
> > > It is being checked by the build system (searach for WIP in
> > > gitlab-ci.yml file :), and some builds are cancelled if they start
> > > with WIP:
> > >
> > >
> > > cheers
> > > Janek
> > >
> > > Bruno Chareyre said: (by the date of Mon, 18 May 2020 12:51:33
> +0200)
> > >
> > > > Hi Janek,
> > > > As I was pushing at high frequency recently I kept cancelling gitlab
> jobs
> > > > since they were way too long.
> > > > Is there a trick I miss? Would it make sense to have a special tag
> we can
> > > > set for building some branches with lightweight series of
> builds/test/doc
> > > > on them (say, ubuntu + debian)?
> > > > We can actually trick the gitlab.ci but that's ugly and there's
> always a
> > > > risk to push it.
> > > > Cheers
> > > > Bruno
> > > >
> > > >
> > > >
> > > > --
> > > > --
> > > > ___
> > > > 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
> > > >
> > >
> > >
> > > --
> > > --
> > > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > > Gdańsk University of Technology
> > > Faculty of Applied Physics and Mathematics
> > > Department of Theoretical Physics and Quantum Information
> > > --
> > > http://yade-dem.org/
> > > http://pg.edu.pl/jkozicki (click English flag on top right)
> > >
> > >
> > >
> >
> > --
> > --
> > ___
> > 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
> >
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
>
>

-- 
-- 
___
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] Do we have "quick" pipeline on gitlab?

[Bruno Chareyre]

Thanks. I know the WIP one indeed but I thought 1/ it was not *that*
faster, and 2/ it was not building doc.
I was wrong on both it seems. :)
Also, it seems debug build includes building doc now, do you confirm?
Things change fast! (for good :)
B

On Mon, 18 May 2020 at 14:35, Janek Kozicki (yade) 
wrote:

> Yes, we have a quick pipeline. Add the "WIP: " in front of the title.
> It is being checked by the build system (searach for WIP in
> gitlab-ci.yml file :), and some builds are cancelled if they start
> with WIP:
>
>
> cheers
> Janek
>
> Bruno Chareyre said: (by the date of Mon, 18 May 2020 12:51:33 +0200)
>
> > Hi Janek,
> > As I was pushing at high frequency recently I kept cancelling gitlab jobs
> > since they were way too long.
> > Is there a trick I miss? Would it make sense to have a special tag we can
> > set for building some branches with lightweight series of builds/test/doc
> > on them (say, ubuntu + debian)?
> > We can actually trick the gitlab.ci but that's ugly and there's always a
> > risk to push it.
> > Cheers
> > Bruno
> >
> >
> >
> > --
> > --
> > ___
> > 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
> >
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
>
>

-- 
-- 
___
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] Do we have "quick" pipeline on gitlab?

[Bruno Chareyre]

Hi Janek,
As I was pushing at high frequency recently I kept cancelling gitlab jobs
since they were way too long.
Is there a trick I miss? Would it make sense to have a special tag we can
set for building some branches with lightweight series of builds/test/doc
on them (say, ubuntu + debian)?
We can actually trick the gitlab.ci but that's ugly and there's always a
risk to push it.
Cheers
Bruno



-- 
-- 
___
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] Joining yade-dev team

[Bruno Chareyre]

On Fri, 15 May 2020 at 18:04, Sacha Duverger 
wrote:

> Hello,
>
> Thanks for adding me on Gitlab, I have a few questions though :
>
> 1)
> I cloned the trunk from gitlab on my machine and made the changes on
> domaindecomposition.py (I was using yade2020.01a before).
> How should I proceed now to request the merge ?
>
> I was thinking of simply doing:
> - commit the changes locally on my machine
> - push the commit with “git push origin master"
>

Nobody can push to master. Instead:
git checkout -b newBranchWithAFeature
git commit
git push origin newBranchWithAFeature:nameOfThatBranchOnGitlab

Then you need to request a merge on gitlab for
nameOfThatBranchOnGitlab->master.
That way you can't break anything in master unless someone else approve the
breakage. :)

2)
>
> There are two changes I made to domaindecomposition.py. The first one is
> easily spottable and should change the returned value of a method. The
> second one doesn’t change the returned value because the variable on which
> the supposed mistake is isn’t used. However, I merged the loop in which the
> supposed mistake is with another similar one, and I took off a “if” that
> didn’t seem necessary.
> Should I commit only the corrections or the improvements as well ? And
> should I commit all those changes at once or make several commits ?
>
> I have no clue. Push first, then we can discuss it.



> 3)
> I had to compile YADE again since I started from the trunk on Gitlab. I
> tried to compile it using 10 cores but it failed. When I tried to compile
> it again using only one core it worked.
> Should I detail this problem as a question on the launchpad or is there a
> more appropriate place for this kind of problems ?
>
>
Your hardware failure (RAM), not a yade failure. Launchpad would be the
right place anyway.
Cheers
Bruno
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Joining yade-dev team

[Bruno Chareyre]

Hi Sacha,
Thank you for reaching us. It is good that someone will try that
independently.
Please note that the documentation is still lacking but it more up to date
in a temporary branch [1].
I'm curious to see the problems you found.
Regards
Bruno

[1] https://gitlab.com/yade-dev/trunk/-/blob/MPIdoc/doc/sphinx/mpy.rst

On Fri, 15 May 2020 at 13:52, Janek Kozicki (yade) 
wrote:

> Looks like Bruno is a bit busy :-) So I have added you o our project.
>
> We are looking forward to your merge requests! :)
>
> best regards
> Janek
>
> Robert Caulk said: (by the date of Thu, 14 May 2020 19:22:48 +0200)
>
> > bisectionDecomposition.py is objectively better than
> > domaindecomposition.py. However, there is still utility in being able to
> > manually control the subdomains with domaindecomposition.py. And
> therefore
> > your corrections are very welcome :-)
> >
> > On Thu, May 14, 2020 at 6:52 PM Sacha Duverger  >
> > wrote:
> >
> > > Thank you for welcoming me,
> > >
> > > I use domaindecomposition.py because the exemple I tried ([1]) used it.
> > > It wasn’t up to date with the current version of YADE. Now that you
> > > mention bisectionDecomposition.py, I’m beginning to think that I should
> > > have used [2] instead.
> > >
> > > [1] :
> > >
> https://gitlab.com/yade-dev/trunk/-/blob/master/examples/mpi/testMPI_3D.py
> > > [2] :
> > >
> https://gitlab.com/yade-dev/trunk/-/blob/master/examples/mpi/testMPI_3D_bisection.py
> > >
> > >
> > > On 14 May 2020, at 15:43, Robert Caulk  wrote:
> > >
> > > Out of curiosity, why are you using domaindecomposition.py instead of
> > > bisectionDecomposition.py?
> > >
> > > On Thu, May 14, 2020 at 2:39 PM Janek Kozicki (yade) <
> > > jkozicki-y...@pg.edu.pl> wrote:
> > >
> > >> Hi, welcome here! :)
> > >>
> > >> Bruno is leading the MPI programming effort, I will let him do the
> honors
> > >> ;)
> > >> BTW, he is in the middle of finishing the docs :)
> > >>
> > >> best regards
> > >> Janek
> > >>
> > >>
> > >> Sacha Duverger said: (by the date of Thu, 14 May 2020 13:39:37
> +0200)
> > >>
> > >> > Hello,
> > >> >
> > >> > I’ve been using YADE since over a year now. I recently tried to use
> the
> > >> MPI parallelisation and I believe I found a couple of errors in the
> > >> py/domaindecomposition.py script.
> > >> >
> > >> > Could I join the yade-dev team so I can suggest my corrections? My
> > >> username on gitlab is @schd .
> > >> >
> > >> >
> > >> > Thank you,
> > >> >
> > >> > Sacha Duverger
> > >> > ___
> > >> > 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
> > >>
> > >>
> > >> --
> > >> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > >> Gdańsk University of Technology
> > >> Faculty of Applied Physics and Mathematics
> > >> Department of Theoretical Physics and Quantum Information
> > >> --
> > >> http://yade-dem.org/
> > >> http://pg.edu.pl/jkozicki (click English flag on top right)
> > >>
> > >> ___
> > >> 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
> > >>
> > >
> > >
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
>
>

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

[Bruno Chareyre]

It's all fine provided that you keep it backward-compatible. Else it's
worst than the initial pb in my view.
Cheers
Bruno


Le mer. 29 avr. 2020 09:37, Jerome Duriez  a écrit :

> 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://l

Re: [Yade-dev] Sign convention or name O.energy['gravWork']

[Bruno Chareyre]

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

[Bruno Chareyre]

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  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
> 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] gitlab is installed at Gdańsk University of Technology

[Bruno Chareyre]

Hi Janek,
Thanks for mentioning. We do have gitlab hosted in Grenoble as well (
https://gricad-gitlab.univ-grenoble-alpes.fr/) and we considered it when
moving from github.
Yade is on *.com mainly because the gitlab version at Gricad tends to stay
behind *.com while, as you know it is a fast-evolving system.
Cheers
Bruno

p.s. I'm like you facing remote teaching troubles, with kids at home. I may
not be very responsive.

Le sam. 21 mars. 2020 23:05, Janek Kozicki (yade) 
a écrit :

> This might become useful someday, if gitlab.com will start having some
> problems:
>
> https://git.pg.edu.pl/explore
>
> plus the university's  IT team is pretty responsive.
>
> I didn't create yade-dev group there or anything (yet).
>
>
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
> ___
> 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] should we drop qt4 support?

[Bruno Chareyre]

Wow, thanks a ton for clarifying. Recently I was wondering why dragging
with mouse did not work like before... I'll check.
Thanks
Bruno

Le mar. 10 mars. 2020 20:28, Janek Kozicki (yade) 
a écrit :

> Bruno Chareyre said: (by the date of Tue, 10 Mar 2020 13:10:24 +0100)
> > That's what puzzled me in the first place. So deeply that I didn't dare
> > replying to the question. :)
>
> Ah sorry, here's exactly what I meant:
>
> qt5/GLViewer.cpp, function postSelection() was written by Anton in
> 2015-06-26
>
> qt4/GLViewer.cpp, function postSelection() was changed by Bruno in
> 2017-05-24
>
> hm,hm.. Bruno, did you fix something in 2017 in postSelection? Something
> about
>
> Omega::instance().getScene()->selectedBody = -1;
>
> And maybe at that time you were using qt4? And you were playing with
> moving bodies around?
>
> If so, then maybe the "correct" version of this function is rather in qt4
> directory?
>
> > Yes I think we can drop Qt4.
> > Back to Ubuntu16 Qt5 is available.
>
> OK, great. That (first clang-format) merge request about QT does just
> that. It reformats the directory and removes qt4 directory.
>
> However currently in tha MR there is postSelection() from qt5 version
> by Anton from 2015-06-26. We can change that if you want :)
>
> best regards
> Janek
>
>
> PS: here's the full (clang-formatted) snippet:
>
> qt5, Anton, year 2015:
>
> if (selection < 0) {
> if (last >= 0) {
> Body::byId(Body::id_t(last))->state->blockedDOFs =
> initBlocked;
> last =
> -1;
> Omega::instance().getScene()->selectedBody   =
> -1;
> }
> if (isMoving) {
> displayMessage("Moving finished");
> mouseMovesCamera();
> isMoving   = false;
> Omega::instance().getScene()->selectedBody = -1;
> }
> return;
> }
>
> and qt4, Bruno, year 2017:
>
> if (selection < 0) {
> Omega::instance().getScene()->selectedBody = -1;
> if (last >= 0) {
> Body::byId(Body::id_t(last))->state->blockedDOFs =
> initBlocked;
> last =
> -1;
> }
> if (isMoving) {
> displayMessage("Moving finished");
> mouseMovesCamera();
> isMoving = false;
> }
> return;
> }
>
> Bruno's code is shorter by one line and the only difference is that
> selectedBody = -1; is done alaways, not just inside if(…).
>
> Sorry about writing so much about single line. I simply compared the two
> dirs,
> and saw just this one difference between the two :)
>
>
>
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
>
>
___
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] should we drop qt4 support? + clang-format ?

[Bruno Chareyre]

On Mon, 9 Mar 2020 at 23:28, Janek Kozicki (yade) 
wrote:

>
> Since I have finished all the large modifications in master I thought
> about clang-formatting it.
> But maybe somebody else has some ongoing large changes and prefers to wait
> with this?
>
Hi,
Do you mean to reformat the whole repository?
Hopefully someone will raise hands in such case. Vasileios maybe?
B
___
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] should we drop qt4 support?

[Bruno Chareyre]

Hi there,

On Mon, 9 Mar 2020 at 21:53, Anton Gladky  wrote:

>
> > If we decided to remove qt4, then we need to decide which version of
> > GLViewer::postSelection(…)
>
> If we drop qt4 directory completely, then we will have only qt5-version
> of this method, right?
>

That's what puzzled me in the first place. So deeply that I didn't dare
replying to the question. :)
Yes I think we can drop Qt4.
Back to Ubuntu16 Qt5 is available.
Cheers
Bruno




>
> Am So., 8. März 2020 um 23:07 Uhr schrieb Janek Kozicki (yade)
> :
> >
> > If we decided to remove qt4, then we need to decide which version of
> > GLViewer::postSelection(…) to use, because `meld gui/qt4 gui/qt5`
> > shows that this function is the only one that differs between the two
> > directories.
> >
> >
> >
> > Janek Kozicki (yade) said: (by the date of Sun, 8 Mar 2020 22:54:07
> +0100)
> >
> > > These last two merge requests have duplicate changes in both
> directories.
> > > The changes are identical, because I did
> > >
> > >   git diff --staged > /tmp/z.patch
> > >   # edit file, replace qt5 with qt5
> > >   patch -p1 < /tmp/z.patch
> > >
> > > but having two copies of same stuff isn't healthy. Does anyone still
> use qt4?
> > >
> > > best regards
> > > Janek
> > >
> > >
> > >
> > > --
> > > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > > Gdańsk University of Technology
> > > Faculty of Applied Physics and Mathematics
> > > Department of Theoretical Physics and Quantum Information
> > > --
> > > http://yade-dem.org/
> > > http://pg.edu.pl/jkozicki (click English flag on top right)
> > >
> > > ___
> > > 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
> >
> >
> > --
> > --
> > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > Gdańsk University of Technology
> > Faculty of Applied Physics and Mathematics
> > Department of Theoretical Physics and Quantum Information
> > --
> > http://yade-dem.org/
> > http://pg.edu.pl/jkozicki (click English flag on top right)
> >
> > ___
> > 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
>


-- 
-- 
___
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] Request for sudoDEM+third party source code

[Bruno Chareyre]

Dear Shiwei,
Congrats, it is an important step. I'm forwarding the news to yade-dev. :)
Best Regards
Bruno

On Sun, 1 Mar 2020 at 17:26, Shiwei Zhao  wrote:

> I already pushed the source codes into a GitHub repository (
> https://github.com/SudoDEM/SudoDEM). Hope to collaborate with you soon.
> Thank you.
>
>
___
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] Do we want low precision float in the gitlab CI pipeline?

[Bruno Chareyre]

(sorry for previous empty message)
Hi,
I don't think DEM can realistically work with floats. If 100 particles in a
row are elongated by 0.01%, the relative displacement between the 99th and
100th particles is 1e-6 times the positions. With single precision it would
already produce substantial numerical noise in terms of contact force.
I mentioned single precision in relation with solving linear systems with
cholmod, and that part does not support HP.
I think we can skip the float pipeline. :)
Cheers
Bruno



On Sun, 1 Mar 2020 at 16:24, Janek Kozicki (yade) 
wrote:

> Hi,
>
> The high precision tests are now running in the gitlab pipeline. And
> we can be sure that `double` are not getting by accident into master.
> (except for the modules which are not supported by HP right now [1],
> in there some `double` could sneak in)
>
> This work also makes low-precision possible. I didn't add this to the
> pipeline, thinking it's not of much use. In some comment Bruno
> mentioned that some people want to use float in the GPUs to get the
> results faster. (Whether these results are correct is a topic for a
> different discussion :)
>
> I could prepare a merge request that adds float to the pipeline,
> because it is compiling (so it works) but it is not passing the tests.
>
> The disadvantage is that in many test scripts an exception will have
> to be written using following distinction:
>if (yade.config.highPrecisionDecimalPlaces < 7):
>
> That's because some of the tests produce different results when float
> is used, which is not a surprise ;)
>
> Currently yade --check has following failures on float:
>
> 7  checks are failed
>   checkColliderConstantness.py
>   checkViscElEng.py
>   checkPotentialParticles.py
>   checkColliderCorrectness.py
>   checkJCFpm.py
>   checkWirePM.py
>   checkCapillaryModels.py
>
> And yade --test also has similar errors due to only 6 available
> decimal places. The log is longer, so I attach it.
>
> And most of these failures are because the results are compared with
> 1e-8 precision, while float maximally can offer 6 decimal places.
>
> best regards
> Janek
>
>
> [1]
> https://yade-dev.gitlab.io/-/trunk/-/jobs/455155443/artifacts/install/share/doc/yade-ci/html/HighPrecisionReal.html#supported-modules
>
>
>
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
> ___
> 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


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] Do we want low precision float in the gitlab CI pipeline?

[Bruno Chareyre]

Hi,
I don't think DEM can in gener

On Sun, 1 Mar 2020 at 16:24, Janek Kozicki (yade) 
wrote:

> Hi,
>
> The high precision tests are now running in the gitlab pipeline. And
> we can be sure that `double` are not getting by accident into master.
> (except for the modules which are not supported by HP right now [1],
> in there some `double` could sneak in)
>
> This work also makes low-precision possible. I didn't add this to the
> pipeline, thinking it's not of much use. In some comment Bruno
> mentioned that some people want to use float in the GPUs to get the
> results faster. (Whether these results are correct is a topic for a
> different discussion :)
>
> I could prepare a merge request that adds float to the pipeline,
> because it is compiling (so it works) but it is not passing the tests.
>
> The disadvantage is that in many test scripts an exception will have
> to be written using following distinction:
>if (yade.config.highPrecisionDecimalPlaces < 7):
>
> That's because some of the tests produce different results when float
> is used, which is not a surprise ;)
>
> Currently yade --check has following failures on float:
>
> 7  checks are failed
>   checkColliderConstantness.py
>   checkViscElEng.py
>   checkPotentialParticles.py
>   checkColliderCorrectness.py
>   checkJCFpm.py
>   checkWirePM.py
>   checkCapillaryModels.py
>
> And yade --test also has similar errors due to only 6 available
> decimal places. The log is longer, so I attach it.
>
> And most of these failures are because the results are compared with
> 1e-8 precision, while float maximally can offer 6 decimal places.
>
> best regards
> Janek
>
>
> [1]
> https://yade-dev.gitlab.io/-/trunk/-/jobs/455155443/artifacts/install/share/doc/yade-ci/html/HighPrecisionReal.html#supported-modules
>
>
>
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
> ___
> 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


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] Request for sudoDEM+third party source code

[Bruno Chareyre]

On Thu, 27 Feb 2020 at 16:59, Janek Kozicki (yade) 
wrote:

> We have met Jidong Zhao, the sudoDEM co-author, at the last yade
> workshop. Perhaps we should ask him directly?
>

Shiewei is the maintainer and distributor of sudoDEM [1].
I think I met him at DEM8 too. The sources of sudoDEM were available at
that time IIRC, it changed since then.
The license issues are easy to fix and (hopefully) the source code will be
easy to get.
We can ping Jidong otherwise.
B
[1] https://www.swayzhao.tk/sudodem/
___
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] Request for sudoDEM+third party source code

[Bruno Chareyre]

Dear Shiewei,
I was trying to use and to check something in the source code of sudoDEM3D
today.
However, I found that the program was distributed only in the form of
binary code. Did I miss something?
If not, could you please send me (or provide a link to download same
versions of) the source codes that were used to generate the binary objects
available as tarballs for sudoDEM3D at [1]
<https://www.researchgate.net/profile/Shiwei_Zhao3/project/SudoDEM-a-discrete-element-code-for-non-spherical-particles/attachment/5d37fd89cfe4a7968db8a305/AS:784079259701258@1563950471928/download/SudoDEM3D-1.3.6.rc1.tar.xz?context=ProjectUpdatesLog>
and for the third party libraries at [2]
<https://zenodo.org/record/2683766#.XlfQl-F7nRZ>?

I believe sudoDEM is a great achievement and I'm glad that yade was helpful
for that work.
I also think it is very important to comply to the terms and conditions of
yade's license (GPL2), and I feel annoyed that sudoDEM apparently doesn't.
In fact, it certainly also breaks the terms and conditions of some third
party libraries.

I'm reproducing below relevant subsets of yade's license (GPL2), they speak
for themselves I think. Please note that mentioning GPL3 on your website is
irrelevant since the GPL3 applies to a source code only, not to a binary
code.
Licensing questions are not always easy, if you are unsure what is
permitted please contact yade-dev@lists.launchpad.net, we will do our best
to advise.
If you are "in the process of" making sources available, then maybe just
don't distribute binaries meanwhile. In any case, make sure you can always
provide the exact same sources you use for generating each *.so you
distribute.
The easiest (though not mandatory) way to do so, by far, is to
systematically give links to both binaries and sources for each version. In
any case, you must provide license in full, and a written notice on how to
get source codes if you don't provide a link to it.

Best Regards

Bruno Chareyre

___

Yade's license says:






















*  0.  "work based on the Program" means either the Program or any
derivative work  1. You may copy and distribute [...] provided that
youconspicuously and appropriately publish on each copy an
appropriatecopyright notice   2. You may modify your copy [...] and
distribute such modificationsunder the terms of Section 1 above, provided
that you also meet all of these conditions:a) You must cause the
modified files to carry prominent noticesstating that you changed the
files and the date of any change.b) You must cause any work that you
distribute [...] to be licensed [...] under the terms of this License.  3.
You may copy and distribute the Program (or a work based on it,under
Section 2) in object code or executable form under the terms ofSections 1
and 2 above provided that you also do one of the following:a) Accompany
it with the complete corresponding machine-readablesource code [...]
b) Accompany it with a written offer, valid for at least threeyears, to
give any third party [...] the corresponding source code  4. You may not
[...] distribute the Programexcept as expressly provided under this
License. Any attemptotherwise [...] will automatically terminate your
rights  10. If [your] distribution conditions are different, write to the
authorto ask for permission.*

- -

[1]
https://www.researchgate.net/profile/Shiwei_Zhao3/project/SudoDEM-a-discrete-element-code-for-non-spherical-particles/attachment/5d37fd89cfe4a7968db8a305/AS:784079259701258@1563950471928/download/SudoDEM3D-1.3.6.rc1.tar.xz?context=ProjectUpdatesLog

[2] https://zenodo.org/record/2683766#.XlfQl-F7nRZ


-- 
-- 
___
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] High precision Real and minieigen

[Bruno Chareyre]

Hi Janek, thanks for pybind feedback. It is intriguing. It was definitely
after me mentionning compile times with boost for c++ / python, at a
workshop, that someone reached me and advised about pybind.
Rumor?

Bruno



Le dim. 23 févr. 2020 16:03, Janek Kozicki (yade) 
a écrit :

> > Another note: I just realized that the compilation benchmarks might
> > have not been fair, because I think that I added few more
> > registrations (like Vector2c, or sth. like that) while doing pybind
> > migration. I will compare again without these extra registrations.
>
> OK, I have compared with the exact same registrations. And it seems
> that pybind has many advantages, but not the one that it is compiling
> faster. See:
>
> pybind without debug info; call `ccache --clear` between every invocation.
> -O3 -j 1   -O3 -j 10
> wall clock time: 2:41.14   wall clock time: 0:40.67
> wall clock time: 2:46.56   wall clock time: 0:41.28
> wall clock time: 2:47.42   wall clock time: 0:42.54
> wall clock time: 2:43.79   wall clock time: 0:44.70
>
> -O1 -j 1   -O1 -j 10
> wall clock time: 2:09.88   wall clock time: 0:35.00
> wall clock time: 2:10.78   wall clock time: 0:33.46
> wall clock time: 2:08.19   wall clock time: 0:32.62
> wall clock time: 2:10.10   wall clock time: 0:32.73
>
>
> 
> boost::python without debug info; call `ccache --clear` between every
> invocation.
> -O3 -j 1   -O3 -j 10
> wall clock time: 2:16.83   wall clock time: 0:33.88
> wall clock time: 2:15.96   wall clock time: 0:32.84
> wall clock time: 2:16.00   wall clock time: 0:34.85
> wall clock time: 2:16.52   wall clock time: 0:32.32
>
> -O1 -j 1   -O1 -j 10
> wall clock time: 2:01.48   wall clock time: 0:28.56
> wall clock time: 2:00.70   wall clock time: 0:29.15
> wall clock time: 2:01.29   wall clock time: 0:28.05
> wall clock time: 2:00.56   wall clock time: 0:28.35
>
> The main pybind disadvantage is unstable API. I don't like writing
> extra code to support older linux distributions.
>
>
> Also I think that if while copying minieigen into yade we did some
> extra rebalancing between the .cpp files, so that in each file there's
> about the same amount of registrations performed, then we could
> reduce (parallel) compilation time to maybe 25 or 20 seconds.
>
>
> If you wanted to compile and try yourself, the comparison was between
> branches master and tryPybind. To see how to compile see .gitlab-ci.yml,
> I'm sorry that it's a bit messy. I was never good at using build
> systems ;) I just wanted parallel build quickly. That's why I wrote
> such strange makefile.
>
> best regards
> Janek
>
>
>
> > Another comparison note:
> >
> > 8. boost::python is much more picky about the order of registered
> >functions, and sometimes does not work if the order is "wrong".
> >pybind always resolves the function overloads correctly.
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
> ___
> 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] High precision Real and minieigen

[Bruno Chareyre]

g crazy from
> the
> > > number of "defines" there.
> > >
> > > Anton
> > >
> > > Am Fr., 21. Feb. 2020 um 17:04 Uhr schrieb Janek Kozicki (yade)
> > > :
> > > >
> > > > Uh Anton, I'm sorry to be so boring:
> > > >
> > > > I have checked with sid in /etc/apt/sources.list:
> > > >
> > > >   deb-src http://ftp.pl.debian.org/debian/ sid  main non-free
> contrib
> > > >
> > > > and built the python3-minieigen_0.50.3+dfsg1-12_amd64.deb package.
> > > >
> > > > There is no /usr/include/minieigen/*pp files inside :(
> > > >
> > > > For high precision to work, they are necessary. Maybe the proper way
> > > > to do this is to introduce python3-minieigen-dev package? I'm not
> > > > sure. These sources are needed because of these include [1]
> statements.
> > > >
> > > > I am attaching once again the file python3-minieigen.install which
> > > > installs *pp files. Even the *.cpp files are used. If you feel
> > > > that *.cpp files are too much, we could duplicate the .cpp files in
> > > > yade (they are rather short) and only include the *.hpp files (these
> > > > are quite long). But all *pp files in /usr/include/minieigen/ would
> > > > be perfect.
> > > >
> > > > Best regards
> > > > Janek
> >
> >
> > --
> > --
> > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > Gdańsk University of Technology
> > Faculty of Applied Physics and Mathematics
> > Department of Theoretical Physics and Quantum Information
> > --
> > http://yade-dem.org/
> > http://pg.edu.pl/jkozicki (click English flag on top right)
> >
> > ___
> > 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
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
> ___
> 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


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] High precision Real and minieigen

[Bruno Chareyre]

Hi, this is great. Thanks a lot Anton.
I removed yade-daily from yade-dev project on Gitlab, btw.
Bruno

p.s. As a side note, Vaçlav dropped minieigen support because of pybind
<https://pybind11.readthedocs.io/en/stable/> move mainly. That package
seems to reduce compilation times significantly compared to boost - it was
suggested to me for this reason at least.





On Thu, 20 Feb 2020 at 21:57, Janek Kozicki (yade) 
wrote:

> Thank you Anton, this is very considerate of you.
>
> best regards
> Janek
>
> Anton Gladky said: (by the date of Thu, 20 Feb 2020 20:17:25 +0100)
>
> > Hi Janek,
> >
> > I have backported both of your patches [1], [2] into the
> > existing in Debian minieigen-package and uploaded into
> > the Debian.
> >
> > The newer minieigen can now be polished, new version released and
> > uploaded with no rush.
> >
> > [1] https://github.com/eudoxos/minieigen/pull/24
> > [2] https://github.com/eudoxos/minieigen/pull/25
> >
> > Best regards
> >
> > Anton
> >
> > Am Mi., 19. Feb. 2020 um 22:37 Uhr schrieb Janek Kozicki (yade)
> > :
> > >
> > > I have asked Vaclav to transfer maintenance of miniEigen to us:
> > >
> > > https://github.com/eudoxos/minieigen/pull/26
> > >
> > > cheers
> > > Janek
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
>
>

-- 
-- 
___
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] New yade release is planned for Jan 2020

[Bruno Chareyre]

Thanks Anton, I think the timing is good. It actually will be a major
release considering py3 and mpi support. Minimal doc for mpi should be
complete by that time.

I was also planning to name a 3rd edition of the doc with additional
authors.

Cheers

Bruno

Le lun. 9 déc. 2019 21:56, Anton Gladky  a écrit :

> Dear Yade developers,
>
> at the beginning of January 2020 I am planning to tag
> newer Yade version. After that it will be uploaded into
> the Debian and automatically synced into the next
> Ubuntu LTS 20.04.
>
> If you are planning some more changes to be pushed into
> this version, please prepare merge requests till the end of this
> year. Plan some time for review/pipelines etc.
>
> Also it would be good to fo through the list of known issues
> and fix/close as much as possible.
>
> If you have some good reasons to delay the release - please
> let me know.
>
> Thanks and 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] Doc building problem

[Bruno Chareyre]

Hi Anton,
A recent change coming to mind is [1] (and I'm not super-familiar with
commenting a line in sphinx), it's easily reverted if you want to check.
Nothing else comes to mind.
B

[1]
https://gitlab.com/yade-dev/trunk/commit/33601df81df0a74f5d4618bc8dbf4e54159f6352

On Mon, 2 Dec 2019 at 22:02, Anton Gladky  wrote:

> Hmm,
>
> it looks like the problem is in debian:sid, in debian:bullseye everything
> is
> working as expected.
>
> Anton
>
> Am Mo., 2. Dez. 2019 um 20:02 Uhr schrieb Anton Gladky <
> gladky.an...@gmail.com>:
> >
> > Hello all,
> >
> > I am preparing the newer Yade for the Debian and upcoming Ubuntu LTS.
> > It will be python3-only build. A couple of weeks ago the build worked
> fine.
> > But now, the compilation stucks on building docs:
> >
> > ==
> > building [mo]: all of 0 po files
> > building [html]: all source files
> > updating environment: 53 added, 0 changed, 0 removed
> > reading sources... [  1%] FEMxDEM
> > reading sources... [  3%] FoamCoupling
> > reading sources... [  5%] GPUacceleration
> > reading sources... [  7%] HydroForceEngine
> > reading sources... [  9%] acousticemissions
> > reading sources... [ 11%] amazonEC2
> > reading sources... [ 13%] citing
> > reading sources... [ 15%] consulting
> > reading sources... [ 16%] formulation
> > reading sources... [ 18%] formulation-link
> > reading sources... [ 20%] github
> > reading sources... [ 22%] gitrepo
> > reading sources... [ 24%] index-toctree
> > reading sources... [ 26%] index-toctree-book
> > reading sources... [ 28%] index-toctree-manuals
> > reading sources... [ 30%] index-toctree-reference
> > reading sources... [ 32%] index-toctree-theory
> > reading sources... [ 33%] index-toctree_manuals
> > reading sources... [ 35%] installation
> > reading sources... [ 37%] introduction
> > ==
> >
> > And nothing more. Has anybody ideas, why it happens?
> >
> > 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
>
>
>

-- 
-- 
___
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] gitlab artifacts missing

[Bruno Chareyre]

On Wed, 13 Nov 2019 at 20:33, Anton Gladky  wrote:

>
> could you please send me a script, which is doing the download/upload?
>
>
Please forgive in advance my naive bash crap and see below.

*cd /tmp*
*touch etag_last*






*wget --server-response --spider
https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages
<https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages>
2>&1 | grep ETag > etag_remoteif ! cmp -s etag_remote etag_last; then
wget
https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages
<https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages>
  unzip download?job=pagesrm -rf /var/www/doc/*mv /tmp/public
/var/www/docrm download?job=pages*
*mv etag_remote etag_last*
*fi*



> Actually, when I do
>
> "wget
> https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages
> "
>
> I get right now the error code 8.
>

As I type this email that target works again (log at the end of this
email), yet for some reason (it occured at least twice in the last months,
probably only for a couple hours the first time).



> Actually, if you use the symbol &&, it will not execute the next step,
> if the previous one failed.
>
> Something like:
>
> wget
> https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages
> &&
> <https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages&;>
> rm -rf /var/www/yade-dem.org && cp * /var/www/yade-dem.org



Sounds like the good fix, thanks for mentioning the syntax.
I think we will try that.
The question of why this happens remains but that's perfectly fine to
workaround it.
Cheers
Bruno




$ wget
https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages
--2019-11-13 17:55:13--
https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages
Resolving gitlab.com (gitlab.com)... 35.231.145.151
Connecting to gitlab.com (gitlab.com)|35.231.145.151|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-11-13 17:55:14 ERROR 404: Not Found.

$ wget
https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages
--2019-11-14 17:09:32--
https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages
Resolving gitlab.com (gitlab.com)... 35.231.145.151
Connecting to gitlab.com (gitlab.com)|35.231.145.151|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location:
https://gitlab.com/yade-dev/trunk/-/jobs/349059349/artifacts/download
[following]
--2019-11-14 17:09:34--
https://gitlab.com/yade-dev/trunk/-/jobs/349059349/artifacts/download
Reusing existing connection to gitlab.com:443.
HTTP request sent, awaiting response... 302 Found
Location:
https://storage.googleapis.com/gitlab-gprd-artifacts/5c/74/5c748985bd13444e59322d1dd55fa2a5091e45a49c1db75d94366184ad2a7fe9/2019_11_13/349059349/361212541/artifacts.zip?response-content-disposition=attachment%3B%20filename%3D%22artifacts.zip%22%3B%20filename%2A%3DUTF-8%27%27artifacts.zip=application%2Fzip=gitlab-object-storage-...@gitlab-production.iam.gserviceaccount.com=JpHFPisbZHmwBGSHy%2Bu%2BDN0Qyi8TQN%2F2J5DbGjSJiuKKO8T8XzyrxjfbEncC%0AgNSHmubYDcLB%2FScSvvS8m%2BJt%2F%2BHkerujryO%2B4FQMAzcnxg2ptUTE2hqR3F43%0AuJk6zo5OsJ8IFvzzfH43VRvhPXEiC2NwbC0FB7jIqvw%2FNevlghADoRxvG7BK%0A0m9yaeoywDilR%2FDu%2BB6qUegllIyp8gvc5XrjyDortOuSUM7wegpRGQ5vMBS1%0Arxn%2F1AvTyeUDaSkbyMeLmx9XxHBJsFdlBAPHdQ1nVgh1GmGU7uoIku7895nd%0AhxoDIfe4ANq5Qdj6O7LgKhr%2FHugAgkyPJ2B8VDf5ZQ%3D%3D=1573748375
[following]
--2019-11-14 17:09:35--
https://storage.googleapis.com/gitlab-gprd-artifacts/5c/74/5c748985bd13444e59322d1dd55fa2a5091e45a49c1db75d94366184ad2a7fe9/2019_11_13/349059349/361212541/artifacts.zip?response-content-disposition=attachment%3B%20filename%3D%22artifacts.zip%22%3B%20filename%2A%3DUTF-8%27%27artifacts.zip=application%2Fzip=gitlab-object-storage-...@gitlab-production.iam.gserviceaccount.com=JpHFPisbZHmwBGSHy%2Bu%2BDN0Qyi8TQN%2F2J5DbGjSJiuKKO8T8XzyrxjfbEncC%0AgNSHmubYDcLB%2FScSvvS8m%2BJt%2F%2BHkerujryO%2B4FQMAzcnxg2ptUTE2hqR3F43%0AuJk6zo5OsJ8IFvzzfH43VRvhPXEiC2NwbC0FB7jIqvw%2FNevlghADoRxvG7BK%0A0m9yaeoywDilR%2FDu%2BB6qUegllIyp8gvc5XrjyDortOuSUM7wegpRGQ5vMBS1%0Arxn%2F1AvTyeUDaSkbyMeLmx9XxHBJsFdlBAPHdQ1nVgh1GmGU7uoIku7895nd%0AhxoDIfe4ANq5Qdj6O7LgKhr%2FHugAgkyPJ2B8VDf5ZQ%3D%3D=1573748375
Resolving storage.googleapis.com (storage.googleapis.com)...
216.58.206.240, 2a00:1450:4007:817::2010
Connecting to storage.googleapis.com
(storage.googleapis.com)|216.58.206.240|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 18604798 (18M) [application/zip]
Saving to: ‘download?job=pages’

download?job=pages
100%[=>]  17.74M  23.0MB/s
 in 0.8s

>
> Am Mi., 13. Nov. 2019 um 18:05 Uhr schrieb Bruno Chareyre
> :
>
> >
> > 

[Yade-dev] gitlab artifacts missing

[Bruno Chareyre]

Hi there,
yade-dem.org is currently down while yade-dev.gitlab.io/trunk/ is not.

The reason is that yade server is downloading the gitlab artifacts like
this:
*wget
https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages
<https://gitlab.com/yade-dev/trunk/-/jobs/artifacts/master/download?job=pages>,*
but at the moment that url returns nothing. Hence empty website.

Obviously our script should test the output of wget, to not replace the
content by nothing. We can fix this. Even so, I would like to understand
why the artifacts are not there. They usually are. Is it because they
expired on gitlab? Is it because of a failed pipeline?
Maybe we should form another url to try and get the content of
yade-dev.gitlab.io/trunk/ (if possibe) instead of checking out an artifact.
I don't have time to check more right now so in case someone has
inspiration, let me know:
- if you know how to make wget conditional
- if you know a better target url

Cheers

Bruno

-- 
-- 
___
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] clang-format (Was: Re: Removing trailing white space, yay or nay?)

[Bruno Chareyre]

Thanks Anton, it makes sense to me.

On Mon, 21 Oct 2019 at 21:02, Anton Gladky  wrote:

> If we do a one-shot-reformatting - it is also OK. But I would then prefer
> to set the author of this commit, something to "clang-formatter",
> Just to identify, that this particular change was done by this action.
>

Now I'm unsure myself. Maybe for stable files which we rarely touch the
"cons" of reformatting are more than the "pros".
A special commiter is a very good point. And even if it's done per-file it
would be better to have a commit by that clang-formatter on the top of
actual commit rather than altogether - so the changes don't get hiden.


>
> For example, my IDE shows at each line, who was the last author
> of the particular line  (git blame basically). Sometimes it is useful to
> contact
> the author of the line/code personally.
>

Yep, "git blame" will be meaningless. Fortunately that's not the only way
to browse history, but yeah, that's the main downside.


> But again, it is up to the majority to decide, whether to use this tool or
> not.
> But the code is getting more readable, more uniform and professional
>

It would be an improvement in my view.
Cheers

Bruno
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] clang-format (Was: Re: Removing trailing white space, yay or nay?)

[Bruno Chareyre]

Thanks for clarification Janek,
Yes, apparently kate and kedevelop5 [1] both have clang plugins.
Might be a bit more involved to get it working on 16.04 (there's kdevelop4)
but it should be doable.
Bruno
[1] https://www.kdevelop.org/news/first-beta-release-kdevelop-500-available


On Mon, 21 Oct 2019 at 14:53, Janek Kozicki (yade) 
wrote:

> Bruno Chareyre said: (by the date of Mon, 21 Oct 2019 11:57:28 +0200)
>
> > Hi Anton,
> > It's not yet all clear to me how it will work.
> > What would be the workflow in general for, let's say, a kdevelop/kate
> user?
> > Edit, then "git-clang-format" before commit?
>
> I pushed the script `scripts/clang-formatter.sh` which you can call on
> file or a directory and it will do the formatting. The script checks
> beforehand if there are any uncommitted changes, so that you do not
> mix substantial changes with formatting changes. Mixing them in
> single commit might cause problems with reading history, I suppose.
>
> > I'm particularly curious about your statement in the giltab thread [1]:
> > "Reformatting everything is not the best idea. It will change everything
> > and can hurt the history. I would propose to do it step by step, only by
> > changing the files."
> >
> > Do you suggest that each time a file will be modified it should be also
> > re-formatted, but no systematic reformatting would be done beyond that?
> > Isn't it maximizing the risk of mixing real changes with formatting? I
> > would think reformatting everything in one single commit would make the
> > history much more clear.
>
> Honestly I don't know. I think that at least for start we should just
> try to get comfortable with the new system. If we agree that it works for
> everyone then maybe we can reformat everything.
>
> clang-format appears to be a quite popular tool. I figured out how to
> invoke it from inside vim on the selected text [1]. I am pretty sure you
> can do the same from kdevelop/kate.
>
>
> > Last thing I'm thinking about: how will we avoid that different
> > authors with (even slightly) different editing tools and
> > auto-formating settings end up in committing conflicting
> > auto-formats?
>
> The basic assumption is that once we have a .clang-format file, the
> script `scripts/clang-formatter.sh` produces the same results for everyone.
>
> So even if you mix the formatting somehow, this script will reset it
> to what is in the repository.
>
> However I didn't yet check if the results on ubuntu 16.04 are the
> same as on debian bullseye. We better check that before a
> full-rollout.
>
> Janek
>
> [1] https://gitlab.com/yade-dev/trunk/merge_requests/298#note_232967339
>
> ___
> 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


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

[Bruno Chareyre]

Le jeu. 10 oct. 2019 11:13, William Chèvremont <
william.chevrem...@univ-grenoble-alpes.fr> a écrit :

>
> I'll update the doc about subclassing c++ in python, as this is mandatory
> for all python code called from C++ while running O.run().
>

The doc should probably mention "pyRunString
", which
is currently used to run python commands from yade's c++.
It indeed includes a gilLock.
Bruno
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Python inheritance

[Bruno Chareyre]

Hi William,
I don't know precisely but in case it can help I would raise that the main
difference between step() and run() is Py_BEGIN_ALLOW_THREADS, at least if
O.run(...,wait=True).
Do you have the same problem with and without "wait"?

Simply passing to c++ a python expression (just a string with python
commands) or a python function returning a value - instead of a derived
class object - could be a simple workaround maybe.

Bruno








On Tue, 8 Oct 2019 at 10:56, William Chèvremont <
william.chevrem...@univ-grenoble-alpes.fr> wrote:

> Hi,
>
> @Janek
>
> Yes, I'm aware of the doc about subclassing types in python. There are
> no problem about that, since it works when calling O.step() instead of
> O.run().
>
> @Anton
>
> The complete backtrace is attached to this mail. Functions of interests
> are around line 400.
>
> Best Regards,
>
> William
>
>
> On 07/10/2019 18:19, Janek Kozicki (yade) wrote:
> > Only a quick question to make sure - you have read
> https://yade-dem.org/doc/prog.html#subclassing-c-types-in-python in
> documentation?
> >
> >
> > best regards
> > Janek
> >
> > ___
> > 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
>


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

[Bruno Chareyre]

Hi Anton,

On Tue, 6 Aug 2019 at 20:54, Anton Gladky  wrote:

>
> - *Debian 11 Bullseye*:
> This package is needed for the users of the current Debian Testing.
> Also it is used to test the new packages, coming into the Debian and
> later into the Ubuntu.
>


> Next year we will prepare packages for Ubuntu 20.04.
>

This is an incredible asset for yade that other things are tested against
it. The freeglut3 seems to be a good example.
Recently at DEM8 conference we were contrasting the no-dependencies
approach of Mercury-DPM with the depend-on-everything approach of Yade.
While our approach enables very advanced stuff it would not be viable
without a good integration.
You rock! :)

Bruno
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Call for testing, updated yadedaily packages

[Bruno Chareyre]

Hi Jérôme,

On Fri, 5 Jul 2019 at 17:03, Jerome Duriez  wrote:

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

It is indeed a relevant source of information and it can be mentioned.
However keep in mind that the dockerfiles contain more than what we need to
compile on a desktop (ccache, devscripts, git-buildpackage,... the list may
grow arbitrarily with time depending on what we find usefull to run the
pipelines). Therefore, we need to maintain also a minimal list of
prerequisites in the installation page anyway, with a single dependencies
line which can be copy-pasted to a terminal for the sake of convenience.
It seems to me that the current compilation instructions are relatively
clear whatever the OS, aren't they?
Cheers
Bruno
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Call for testing, updated yadedaily packages

[Bruno Chareyre]

On Sat, 13 Jul 2019 at 01:28,  wrote:

> in practice any computer can have a gitlab-runner installed. You could
> place the private key on a PC that you control with gitlab-runner
> installed. Use the tag to mark it as the one used only for building
> packages and nothing else to save your resources. By this way your private
> key would be securely connected to the gitlab framework
>

Fair point.


> The "only" problem is that this solution requires that you have a trusted
> PC that runs almost all the time.
>

What about using yade-runner for this (it would make sense to have both the
credentials and the repository in Grenoble)?

Bruno
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Call for testing, updated yadedaily packages

[Bruno Chareyre]

Hi Anton,

On Fri, 12 Jul 2019 at 19:03, Anton Gladky  wrote:

> Comments, critic are
> very welcome.
>

This is great! Thank you very much.
Was there specific difficulties with ubuntu16.04 (even if it's getting old
I'm sure there would be users of it)?
If yes, then let it be. If it just needs to add a name in [1] then it's
maybe worth it.
[1]
https://gitlab.com/yade-dev/trunk/merge_requests/185/diffs#9e4f27c17b0dc74b4dff4de88036f97a4daf0f00_0_7


> > p.s. just curious about the amazonaws hosting, issues with gitlab.com?
> If it helps local server yade-dem.org can be used to. Nothing against
>
> Now it is done on my laptop and I am just using the Amazon S3 for testing
> purposes.
> We can surely use it further, but I would also prefer to move to
> yade-dem.org.
> But we need to coordinate that.
>

Ok. There are two questions then:
- Where to host: yade-dem.org is available like before (it's on a brand new
hardware and it should stay for years), we need to give you access to it I
guess.
- Who/how to sign the packages: I don't see it very convenient if you have
to do anything manually, we are updating master many times a day at the
moment. Or maybe a few of us need to learn how to do it to.



> Theoretically, we could use the gitlab infrastructure to build the
> repository as well.
> But the problem is that it should be signed by the private yade-GPG key.
> And I would escape to upload this private key into the gitlab servers due
> to security concerns. Maybe I am missing something.
>

I know exactly what you mean. That's why currently yade-dem.org does wget
the documentation from gitlab (checking every 10 minutes or so) instead of
gitlab pushing actively. We did not like giving credentials to gitlab.
I don't think you missed anything, there is no escape on this aspect.

Regards

Bruno
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Call for testing, updated yadedaily packages

[Bruno Chareyre]

@Gael
That inconsistent mpi detection is a known weirdness as the message
suggests. We have it in gitlab-ci pipeline as well.
Hopefully we will understand it, but it should be fine anyway.
Bruno


On Mon, 1 Jul 2019 at 16:18, Gael Lorieul 
wrote:

> Hello,
>
> On 27-06-19 15:15, Anton Gladky wrote:
>  > yadedaily packages are being under renovation at the moment. And now
>  > they need to be tested.
>
> Installed on Ubuntu 18.04
> Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
> Intel Corporation Skylake GT2 [HD Graphics 520]
>
> I have one warning with `yade --test`:
> "mpi version reported by by cmake is  [(3, 1, 0), '3.1']  and by C++ is
> [(2, 1, 1), 'ompi:2.1.1']
> Warning: mpi versions are different. Can you help with file
> py/libVersions.py.in?"
>
> The `py/libVersions.py.in` file contains the comment: "The mpi version
> detected by cmake sometimes is different than version detected by C++,
> this needs further investigation."
>
> cmake 3.10.2-1ubuntu2, installed from official Ubuntu repositories
> g++ 4:7.4.0-1ubuntu2.3, installed from official Ubuntu repositories
> openmpi-bin 2.1.1-8, installed from official Ubuntu repositories
>
> Note: I have never installed manually OpenMpi packages, or built it
> manually from the sources on this computer. I have not held back any
> package either. I cannot find trace of an OpenMpi 3.1.0 on my computer,
> only of OpenMpi 2.1.1. Eventually yadedaily picks the "correct" OpenMpi
> i.e. 2.1.1 (indicated by `yadedaily --test`).
>
> Otherwise everything works as expected:  `yadedaily --test` and
> `yadedaily --check` both run successfully with all tests passed.
>
> Cheers,
>
> Gaël
>
> ___
> 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


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

[Bruno Chareyre]

Hi Anton,
Thank you very much!
I confirm installation on ubuntu 18.04.
Cheers
Bruno

p.s. just curious about the amazonaws hosting, issues with gitlab.com? If
it helps local server yade-dem.org can be used to. Nothing against

On Thu, 27 Jun 2019 at 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
>


-- 
-- 
___
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] [Question #681091]: installation problem

[Bruno Chareyre]

On Tue, 28 May 2019 at 16:51, Janek Kozicki  wrote:

> but I am afraid that it is only deferring problems to the later stage -
> yade
> will compile, but something won't work.
>

If you mean "won't work" in the sense of "will be disabled" that's fine.
If someone wants to compile with support for a specific module he will
usually pay attention to the prerequisites (especially if cmake output
makes it clearly and if the feature is missing after first compilation).
The problem here is that compilation fails completely for someone who,
potentially, has no interest in metis or in mpi, that's more annoying.
Still, I'm curious to know what the problem is in that case.
Bruno
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] [Yade-users] [Question #681091]: installation problem

[Bruno Chareyre]

Hi Janek,
Not sure I understand correctly this problem but, it seems we are not
switching off features automatically when a package is optional? That was
usual behavior and it would probably raise less questions.
Do I miss something?
Bruno

Le lun. 27 mai 2019 16:03, Janek Kozicki <
question681...@answers.launchpad.net> a écrit :

> Question #681091 on Yade changed:
> https://answers.launchpad.net/yade/+question/681091
>
> Status: Open => Answered
>
> Janek Kozicki proposed the following answer:
> Please have  a look at this one:
> https://answers.launchpad.net/yade/+question/680867
>
> --
> You received this question notification because your team yade-users is
> an answer contact for Yade.
>
> ___
> Mailing list: https://launchpad.net/~yade-users
> Post to : yade-us...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-users
> 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-dem.org is back

[Bruno Chareyre]

Instead of pushing from gitlab we pull latest artifacts from yade-dem.org.
Bruno

Le dim. 26 mai 2019 13:02, Janek Kozicki  a écrit :

> Bruno Chareyre said: (by the date of Fri, 24 May 2019 12:33:31 +0200)
>
> > Everything is in the title. We are no longer switching to the gitlab.io
> > pages for the doc (they are actually mirrored, so they can serve as a
> > backup if yade-dem. org is down).
>
> I see that merge request
> https://gitlab.com/yade-dev/trunk/merge_requests/147
> is still open. How did you do this without it?
>
> 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

[Yade-dev] yade-dem.org is back

[Bruno Chareyre]

Hi there,
Everything is in the title. We are no longer switching to the gitlab.io
pages for the doc (they are actually mirrored, so they can serve as a
backup if yade-dem. org is down).
Let me know if you spot problem on the website.
Cheers
Bruno

-- 
-- 
___
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] Yade migrated to Python3

[Bruno Chareyre]

Dear Yade users,
After a few weeks of intense hacking by François Kneib, Yade now supports
python3.
That change was necessary since Python 2.7 will be a dead langage very soon.
The installation instructions
<https://yade-dem.org/doc/installation.html?highlight=PYTHON_VERSION#compilation>
[1] have been updated accordingly for those compiling Yade.

This change only affects the source code for the moment, it will affect the
binary packages soon.

It is still possible to compile with python 2.7 as usual, however the
"print" command in users script will have to use brackets even in that case
(more about this and other things explained in [2]
<https://yade-dem.org/doc/tutorial-advanced.html?highlight=print#convert-python2-to3>
).
We hope the transition will be as smooth as possible for everyone.
Best regards

For the yade-dev group.
Bruno Chareyre

[1]
https://yade-dem.org/doc/installation.html?highlight=PYTHON_VERSION#compilation
[2]
https://yade-dem.org/doc/tutorial-advanced.html?highlight=print#convert-python2-to3
___
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] Updating Launchpad (Code) page

[Bruno Chareyre]

Hi Jérôme,
Thanks for raising this. I'll try and redirect to gitlab repo.
In fact the mentions of bzr are not wrong, since that's how to checkout the
launchpad repository. But it's probably better to homogenize.
Bruno

On Wed, 10 Apr 2019 at 08:53, Jerome Duriez  wrote:

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


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

Re: [Yade-dev] New member Katia Boschi

[Bruno Chareyre]

Hi Katia,
Welcome and congrats for your first merge request, a very good one.
The check test succeeded [1]. Now lets improve performance!
Bruno
[1] https://gitlab.com/yade-dev/trunk/-/jobs/191365870

On Fri, 5 Apr 2019 at 11:56, Katia Boschi  wrote:

> Hi everyone,
>
> I am starting a PhD project with Prof. Claudio Giulio di Prisco at
> Politecnico di Milano on numerical and analytical modelling of grout
> injection in granular materials, as part of a larger research project in
> Milano with industrial partner BASF. Indeed, grouting and jet-grouting are
> geotechnical consolidation techniques commonly employed to improve the
> mechanical behaviour of soils. Although these techniques are common, the
> micro-mechanical processes taking place at the local level are not yet
> quantitatively and qualitatively understood and hence rightly modelled.
> I have been visiting the geomechanics group of Laboratoire 3SR for two
> months. This stay in Grenoble aims at setting up preliminary models with
> hydromechanical coupling DEM-PFV available in Yade-DEM, under the guidance
> of Bruno Chareyre.
>
> Regards,
> Katia Boschi
> ___
> 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


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

Re: [Yade-dev] Make ccache working

[Bruno Chareyre]

You cmake logs says:
> qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such
file or directory
> -- Found unsuitable Qt version "" from NOTFOUND

I discovered that yesterday to. I'm really not sure it is related to the
ccache problem but it is strange. Try "sudo apt install qt5-default"? It
fixes the problem partly on 16.04.

I noticed the -DCMAKE_CXX_COMPILER_LAUNCHER indeed, but to me that's just
another way, not the unique way, since ccache is supposed to be used even
without cmake. It is suprising that "ccache g++" can't find g++ while g++
is available system-wide, but... yes maybe a 18.04 feature...
Cheers
Bruno




On Thu, 28 Mar 2019 at 07:48, François  wrote:

> Here attached is the full cmake output when I did:
>
>> rm -r *
>> export CC="ccache /usr/bin/gcc"
>> export CXX="ccache /usr/bin/g++"
>> cmake -DCMAKE_INSTALL_PREFIX=../install ../trunk
>>
>
>
> Le jeu. 28 mars 2019 à 06:48, Bruno Chareyre <
> bruno.chare...@3sr-grenoble.fr> a écrit :
>
>> Tu peux ajouter la sortie de cmake a ton message? Pas dispo ce matin.
>> B
>>
>> Le jeu. 28 mars. 2019 00:58, François  a
>> écrit :
>>
>>> Thanks for your help. I'm on kubuntu 18.04 (cmake 3.10.2), and maybe our
>>> versions mismatch is at the origin of the issue (I finally found a
>>> solution, see the bottom of this message).
>>> By "installing" ccache I meant in fact "enable/use" ccache, I also
>>> installed it with "apt install ccache". Of course, I always start from an
>>> empty build dir.
>>>
>>> Now I restarted everything with a clean $PATH, reverting my changes.
>>> Using export CC and CXX doesn't work:
>>>
>>>> export CC="ccache gcc"
>>>> export CXX="ccache g++"
>>>> cmake -DCMAKE_INSTALL_PREFIX=../install ../trunk
>>>> [...]
>>>> *ccache: error: Could not find compiler "g++" in PATH*
>>>>
>>> Somebody had the same issue here:
>>> https://github.com/bazelbuild/bazel/issues/3642 so I tried
>>> unsuccessfully :
>>>
>>>> rm -r *
>>>> export CC="ccache /usr/bin/gcc"
>>>> export CXX="ccache /usr/bin/g++"
>>>> cmake -DCMAKE_INSTALL_PREFIX=../install ../trunk
>>>> [...]
>>>> */usr/bin/ccache: invalid option -- 'd'*
>>>>
>>> I didn't found exactly why, but somewhere the "-d" option is passed
>>> directly to ccache (instead of gcc/g++ I assume), but not in your 16.04
>>> system.
>>>
>>> So I tried two methods to use $PATH instead of $CXX and $CC:
>>> - the one in ccache documentation, with symlinks :
>>> https://ccache.samba.org/manual/latest.html#_run_modes
>>> - the one we can find everywhere with export PATH="/usr/lib/ccache:$PATH"
>>> But the result is finally the same as above.
>>>
>>> *OUTCOME*:
>>> I feel a bit confused as I spent some time to make it work to finally
>>> see that cmake handles ccache since version 3.4:
>>> https://cmake.org/cmake/help/v3.6/release/3.4.html#variables
>>> Without environment variables nor symlinks, the solution basically is to
>>> run cmake with "*-DCMAKE_CXX_COMPILER_LAUNCHER=ccache
>>> -DCMAKE_C_COMPILER_LAUNCHER=ccache*"
>>> Now ccache is activated, after a successful build I have 720.9 MB in
>>> cache, yade full build in 30s yeepee :-D
>>> This solution should also work for ubuntu 16.04 as it carries cmake 3.5,
>>> but not for ubuntu 14.04.
>>>
>>> NB: Interestingly, compiling [yade with python 3] for the first time
>>> with the full ccache of [yade with python 2.7] took about 5 mins against
>>> about 30min for a full uncached build.
>>>
>>> Cheers,
>>> François
>>>
>>>
>>>
>>>
>>> Le mer. 27 mars 2019 à 20:40, Bruno Chareyre <
>>> bruno.chare...@3sr-grenoble.fr> a écrit :
>>>
>>>> I checked your ubuntu 12.04 page again. That's actually about hiding
>>>> ccache behind normal gcc invocation, and I kind-of dislike the idea.
>>>> Explicit call to «ccache g++» sounds cleaner to me and it is compatible
>>>> with mpicxx (for ubuntu 16.04 at least).
>>>> Better undo what you have done until now in terms of ccache hacks and
>>>> stick to yade doc's method if you are unsure.
>>>>
>>>> «ccache -s» also reports unsupported options on my ubuntu 16.04 but a
>&

Re: [Yade-dev] Make ccache working

[Bruno Chareyre]

Tu peux ajouter la sortie de cmake a ton message? Pas dispo ce matin.
B

Le jeu. 28 mars. 2019 00:58, François  a écrit :

> Thanks for your help. I'm on kubuntu 18.04 (cmake 3.10.2), and maybe our
> versions mismatch is at the origin of the issue (I finally found a
> solution, see the bottom of this message).
> By "installing" ccache I meant in fact "enable/use" ccache, I also
> installed it with "apt install ccache". Of course, I always start from an
> empty build dir.
>
> Now I restarted everything with a clean $PATH, reverting my changes. Using
> export CC and CXX doesn't work:
>
>> export CC="ccache gcc"
>> export CXX="ccache g++"
>> cmake -DCMAKE_INSTALL_PREFIX=../install ../trunk
>> [...]
>> *ccache: error: Could not find compiler "g++" in PATH*
>>
> Somebody had the same issue here:
> https://github.com/bazelbuild/bazel/issues/3642 so I tried unsuccessfully
> :
>
>> rm -r *
>> export CC="ccache /usr/bin/gcc"
>> export CXX="ccache /usr/bin/g++"
>> cmake -DCMAKE_INSTALL_PREFIX=../install ../trunk
>> [...]
>> */usr/bin/ccache: invalid option -- 'd'*
>>
> I didn't found exactly why, but somewhere the "-d" option is passed
> directly to ccache (instead of gcc/g++ I assume), but not in your 16.04
> system.
>
> So I tried two methods to use $PATH instead of $CXX and $CC:
> - the one in ccache documentation, with symlinks :
> https://ccache.samba.org/manual/latest.html#_run_modes
> - the one we can find everywhere with export PATH="/usr/lib/ccache:$PATH"
> But the result is finally the same as above.
>
> *OUTCOME*:
> I feel a bit confused as I spent some time to make it work to finally see
> that cmake handles ccache since version 3.4:
> https://cmake.org/cmake/help/v3.6/release/3.4.html#variables
> Without environment variables nor symlinks, the solution basically is to
> run cmake with "*-DCMAKE_CXX_COMPILER_LAUNCHER=ccache
> -DCMAKE_C_COMPILER_LAUNCHER=ccache*"
> Now ccache is activated, after a successful build I have 720.9 MB in
> cache, yade full build in 30s yeepee :-D
> This solution should also work for ubuntu 16.04 as it carries cmake 3.5,
> but not for ubuntu 14.04.
>
> NB: Interestingly, compiling [yade with python 3] for the first time with
> the full ccache of [yade with python 2.7] took about 5 mins against about
> 30min for a full uncached build.
>
> Cheers,
> François
>
>
>
>
> Le mer. 27 mars 2019 à 20:40, Bruno Chareyre <
> bruno.chare...@3sr-grenoble.fr> a écrit :
>
>> I checked your ubuntu 12.04 page again. That's actually about hiding
>> ccache behind normal gcc invocation, and I kind-of dislike the idea.
>> Explicit call to «ccache g++» sounds cleaner to me and it is compatible
>> with mpicxx (for ubuntu 16.04 at least).
>> Better undo what you have done until now in terms of ccache hacks and
>> stick to yade doc's method if you are unsure.
>>
>> «ccache -s» also reports unsupported options on my ubuntu 16.04 but a
>> full rebuild takes 40sec regardless.
>>
>> Bruno
>>
>> Le mer. 27 mars. 2019 19:46, Bruno Chareyre <
>> bruno.chare...@3sr-grenoble.fr> a écrit :
>>
>>> Also, did you start from fresh build after exporting CXX?
>>> I mean:
>>> rm -rf ./*
>>> export ...
>>> cmake [options]
>>> make -jN
>>>
>>> Bruno
>>>
>>> Le mer. 27 mars. 2019 18:33, Bruno Chareyre <
>>> bruno.chare...@3sr-grenoble.fr> a écrit :
>>>
>>>> Hi François,
>>>>
>>>> Please remember to give your linux version.
>>>>
>>>> On Wed, 27 Mar 2019 at 17:44, François 
>>>> wrote:
>>>>
>>>>> export CXX=ccache g++
>>>>>
>>>>>> bash: export: « g++ » : identifiant non valable
>>>>>>
>>>>> Using
>>>>>
>>>>>> export CXX='ccache g++'
>>>>>
>>>>> works
>>>>>
>>>>
>>>> Thanks for pointing that out. I forgot the " indeed, I'll fix it.
>>>> It would be useful to turn your bash to english for pasting errors here
>>>> (also much more efficient when searching online solutions).
>>>>
>>>>
>>>>
>>>>> but it will result in cmake fail while checking cc compiler.
>>>>> Finally, I "installed" ccache thanks to the first answer here:
>>>>> https://askubuntu.com/questions/470545/how-do-i-set-up-ccache and it

Re: [Yade-dev] Make ccache working

[Bruno Chareyre]

I checked your ubuntu 12.04 page again. That's actually about hiding ccache
behind normal gcc invocation, and I kind-of dislike the idea. Explicit call
to «ccache g++» sounds cleaner to me and it is compatible with mpicxx (for
ubuntu 16.04 at least).
Better undo what you have done until now in terms of ccache hacks and stick
to yade doc's method if you are unsure.

«ccache -s» also reports unsupported options on my ubuntu 16.04 but a full
rebuild takes 40sec regardless.

Bruno

Le mer. 27 mars. 2019 19:46, Bruno Chareyre 
a écrit :

> Also, did you start from fresh build after exporting CXX?
> I mean:
> rm -rf ./*
> export ...
> cmake [options]
> make -jN
>
> Bruno
>
> Le mer. 27 mars. 2019 18:33, Bruno Chareyre <
> bruno.chare...@3sr-grenoble.fr> a écrit :
>
>> Hi François,
>>
>> Please remember to give your linux version.
>>
>> On Wed, 27 Mar 2019 at 17:44, François  wrote:
>>
>>> export CXX=ccache g++
>>>
>>>> bash: export: « g++ » : identifiant non valable
>>>>
>>> Using
>>>
>>>> export CXX='ccache g++'
>>>
>>> works
>>>
>>
>> Thanks for pointing that out. I forgot the " indeed, I'll fix it.
>> It would be useful to turn your bash to english for pasting errors here
>> (also much more efficient when searching online solutions).
>>
>>
>>
>>> but it will result in cmake fail while checking cc compiler.
>>> Finally, I "installed" ccache thanks to the first answer here:
>>> https://askubuntu.com/questions/470545/how-do-i-set-up-ccache and it
>>> *kinda* works.
>>>
>>
>> Arguably, using ccache is assuming that it is installed. ;)
>> Not sure why you needed that ubuntu 12.04 forum, as far as I remember I
>> only had to "apt-get install ccache".
>>
>>
>>>
>>>- the second one, once the install is ok and cmake uses ccache, is
>>>that I only get "unsupported compiler option" when I try *ccache -s*
>>>after a full yade compilation. It results in a almost-empty cache:
>>>
>>>
>> Does compilation work?
>> Could you send cmake output, and some sample of "make VERBOSE=1"?
>>
>> I have this:
>>
>> *[ 39%] Building CXX object
>> CMakeFiles/yade.dir/pkg/dem/Ig2_Box_Sphere_ScGeom.cpp.o/usr/bin/ccache
>> g++  -DBOOST_MATH_DISABLE_FLOAT128=1 -DNDE...*
>>
>> Cheers
>>
>> Bruno
>>
>>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Make ccache working

[Bruno Chareyre]

Also, did you start from fresh build after exporting CXX?
I mean:
rm -rf ./*
export ...
cmake [options]
make -jN

Bruno

Le mer. 27 mars. 2019 18:33, Bruno Chareyre 
a écrit :

> Hi François,
>
> Please remember to give your linux version.
>
> On Wed, 27 Mar 2019 at 17:44, François  wrote:
>
>> export CXX=ccache g++
>>
>>> bash: export: « g++ » : identifiant non valable
>>>
>> Using
>>
>>> export CXX='ccache g++'
>>
>> works
>>
>
> Thanks for pointing that out. I forgot the " indeed, I'll fix it.
> It would be useful to turn your bash to english for pasting errors here
> (also much more efficient when searching online solutions).
>
>
>
>> but it will result in cmake fail while checking cc compiler.
>> Finally, I "installed" ccache thanks to the first answer here:
>> https://askubuntu.com/questions/470545/how-do-i-set-up-ccache and it
>> *kinda* works.
>>
>
> Arguably, using ccache is assuming that it is installed. ;)
> Not sure why you needed that ubuntu 12.04 forum, as far as I remember I
> only had to "apt-get install ccache".
>
>
>>
>>- the second one, once the install is ok and cmake uses ccache, is
>>that I only get "unsupported compiler option" when I try *ccache -s*
>>after a full yade compilation. It results in a almost-empty cache:
>>
>>
> Does compilation work?
> Could you send cmake output, and some sample of "make VERBOSE=1"?
>
> I have this:
>
> *[ 39%] Building CXX object
> CMakeFiles/yade.dir/pkg/dem/Ig2_Box_Sphere_ScGeom.cpp.o/usr/bin/ccache
> g++  -DBOOST_MATH_DISABLE_FLOAT128=1 -DNDE...*
>
> Cheers
>
> Bruno
>
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Make ccache working

[Bruno Chareyre]

Hi François,

Please remember to give your linux version.

On Wed, 27 Mar 2019 at 17:44, François  wrote:

> export CXX=ccache g++
>
>> bash: export: « g++ » : identifiant non valable
>>
> Using
>
>> export CXX='ccache g++'
>
> works
>

Thanks for pointing that out. I forgot the " indeed, I'll fix it.
It would be useful to turn your bash to english for pasting errors here
(also much more efficient when searching online solutions).



> but it will result in cmake fail while checking cc compiler.
> Finally, I "installed" ccache thanks to the first answer here:
> https://askubuntu.com/questions/470545/how-do-i-set-up-ccache and it
> *kinda* works.
>

Arguably, using ccache is assuming that it is installed. ;)
Not sure why you needed that ubuntu 12.04 forum, as far as I remember I
only had to "apt-get install ccache".


>
>- the second one, once the install is ok and cmake uses ccache, is
>that I only get "unsupported compiler option" when I try *ccache -s*
>after a full yade compilation. It results in a almost-empty cache:
>
>
Does compilation work?
Could you send cmake output, and some sample of "make VERBOSE=1"?

I have this:

*[ 39%] Building CXX object
CMakeFiles/yade.dir/pkg/dem/Ig2_Box_Sphere_ScGeom.cpp.o/usr/bin/ccache
g++  -DBOOST_MATH_DISABLE_FLOAT128=1 -DNDE...*

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

[Yade-dev] Some update on futur steps

[Bruno Chareyre]

Hi there,
This is a quick update on multiple things.

1. François Kneib just initiated a "python-3" branch and he will be working
on python3 migration, as the name suggests.

2. I just migrated the yade-mpi repository to a new gitlab branch ("mpi").
This is still work in progress, but hopefully it will reach a more final
stage in a few months (also with the help of François). We have a
nearly-working framework (it's actually working in a sense but some
interactions data is still missing in the data exchanges and one particular
step is inefficient and must be removed). We got encouraging results from
benchmarks on Gricad's HPC farm, and even an award in a national "HPC
Hackaton" [1].

3. the server in 3SR hosting yade-dem.org (doc, wiki, packages and
publications), will be migrated to a new hardware. It should resolve the
frequent wiki-downs, which were simply due to a full partition after
excessive accumulation of logs by the buildbot. Buildbot has been turned
off, by the way, so even in the short term wiki should be safer than
before.

Cheers

Bruno

[1] check first news here: http://geomec.net/newsletter/?p=432




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

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

[Bruno Chareyre]

That's just because that branch still uses the older config. It should not
happen for newly created branches.
Bruno

On Wed, 20 Mar 2019 at 09:52, Jerome Duriez  wrote:

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


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

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

[Bruno Chareyre]

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

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

[Bruno Chareyre]

Hi Jérôme,
It is a bit strange but it is reminiscent of a recent fix of the "search"
box we discussed with Rémi.
I would suggest to sync trunk-exp vs. trunk, it will probably fix the issue.
Bruno

On Mon, 18 Mar 2019 at 13:46, Jerome Duriez  wrote:

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


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

Re: [Yade-dev] [Yade-users] [Question #678982]: about TriaxialStressController

[Bruno Chareyre]

Hi Jérôme,
Both orderings are used. Nothing wrong in little endian, and it's simpler
in the case of bitmasks since it doesn't imply reordering.
https://en.m.wikipedia.org/wiki/Endianness

Bruno

Le jeu. 7 mars. 2019 12:56, Jerome Duriez  a
écrit :

> 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
>
___
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_REQUIRE_FEATURE and Linking.

[Bruno Chareyre]

Hi Janek,

On 2/15/19 7:06 PM, Janek Kozicki wrote:

   ./scripts/linkdeps.py:  
m=re.match('^YADE_REQUIRE_FEATURE\((.*)\).*',l)

which means that the only mention of YADE_REQUIRE_FEATURE is in
documentation, and that Chia Weng Boon tried to use it in
PotentialBlocks code, but it is commented out.

So should we remove this section? But why is it present in 
./scripts/linkdeps.py ?


It could be that the mechanism is functional but not effectively used. 
Not sure. Worth a try before removing.


You should get an idea of the the mechanism effectively used at the 
moment just reading CMakeLists.txt.
On this basis cmake will define c++ preprocessor macros which can be 
used for #ifdef's.



The next section about Linking is also incorrect, because when I do this command

   find -name "*.so" -exec basename {} \; | sort | uniq

in the build tree, I obtain:

_GLViewer.so
_customConverters.so
_packObb.so
_packPredicates.so
_packSpheres.so
_polyhedra_utils.so
_utils.so
boot.so
libyade.so
wrapper.so

which is different from what is described in 
https://yade-dev.gitlab.io/trunk/prog.html#linking
The above libs correspond to python modules which can be imported in 
python scripts, they are not loaded at runtime (well, utils is loaded at 
runtime but that's because the startup script has some "import utils" 
inside).
We oscillated between monolithic build and independent plugins a couple 
time if I remember well. We are more on the monolithic side at the moment.
Why the split is as it is now is not something I can justify fully, I 
would have to check case by case.
I suspect in some cases - e.g. polyhedra - it's just because the 
developper liked it this way.
I know utils is high demanding in terms of RAM so utils+libyade in one 
single lib would probably increase the memory requirement for compiling 
yade.



What should we do with this?
I think developer manual could assume monolithic build and so there is 
no real need for a "linking" section.
The possibility of adding independent python modules with boost::python 
could be mentioned, with an example selected in the above.



PS: I am not sure where I should post these concerns:

* https://gitlab.com/yade-dev/trunk/merge_requests/69
* https://gitlab.com/yade-dev/trunk/issues
* here, on yade-dev


Too many communication channels are not good. One has too monitor them all.


For me it doesn't make a real difference since I'm receiving them all, 
but I'm "owner" of the gitlab group, I don't know what happens for others.


Cheers

Bruno









___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] [Bug 1810283] Re: Wiki homepage broken

[Bruno Chareyre]

On 2/22/19 4:14 PM, Jan Stránský wrote:
just a note concerning wiki, I know (but have no experience with them) 
that gitlab offers wiki pages. Maybe it would be worth moving also 
wiki within the gitlab migration..


Yes, it was mentioned in earlier messages and it is an option.
If someone wants to try and migrate current content to gitlab.com that's 
fine.


However if we keep running a dedicated server in 3SR anyway (because 
there is not just the wiki to host) there is less need for such a migration.
Gitlab migration reduces the dependency on 3SR hardware significantly, 
keeping just that server with wiki and other things on it is doable.


Cheers

Bruno



___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] [Bug 1810283] Re: Wiki homepage broken

[Bruno Chareyre]

Hi,
The wiki is back. No space on disk was the issue.

The same physical machine has publications [1], daily packages [2] - and
previously the html documentation which is now on gitlab.
I discussed a migration of that server to another physical machine with our
one-man IT support (Jérôme Branon) since it is an old machine.
It can be done it seems.
In this event I'm considering getting the html doc back to its previous
place, it would avoid the hacky "gitlab.io" url substitution. More
precisely, yade-dem.org/doc would mirror yade-dev.gitlab.io/trunk/.

Cheers

Bruno

[1] https://yade-dem.org/publi/
[2] http://packages.yade-dem.org/

On Mon, 7 Jan 2019 at 17:36, Janek Kozicki  wrote:

> Bruno Chareyre said: (by the date of Mon, 07 Jan 2019 15:23:11 -)
>
> > To be honest that wiki hosted on some 3SR server will get less and less
> support with Rémi gone.
> > I don't even know which computer exactly is hosting this.
> >
> > Finding a replacement would be a good thing. Gitlab is hosting wiki
> pages indeed (even Github actually) but I don't if it is possible to just
> dump everything and upload it elsewhere...
> > If the bug appear randomly I suspect an issue on the host computer, like
> full HD or exhausted RAM.
>
> I propose to not edit wiki until the migration process to gitlab is
> finished. Maybe Rémi could find the hosting computer and send us the
> compressed directory with it?
>
> Then we would investigate possible ways to import it into gitlab?
>
> --
> 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

Re: [Yade-dev] PotentialBlocks & Particles documentation on website?

[Bruno Chareyre]

On 2/11/19 6:19 PM, Janek Kozicki wrote:

Bruno Chareyre said: (by the date of Mon, 11 Feb 2019 17:59:57 +0100)



And this is standard in debian?

I'm not sure how to interpret your question :)


The question was: can I "sudo apt-get install python-escript"?


Missing recommended packages do not break yade package.

python-escript is not necessary for any other part of yade to work.
Only if you actually want to start a FEMxDEM .py script you get
errors without this package.

Also if python-escript is missing for some reason in the linux
distribution, then yade packaage would NOT be broken, because it does
not depend on it (it only recommends it).


Oh, yes, good point. Since its only used via python there is no runtime 
error at startup if not present.



And in fact that is the case with new stable debian release, I don't
know why but python-escript is not there.

Yeah, that was my point. :(


  Maybe it will be added
there later. So if we configure yade.deb to recommend python-escript,
then it would be a hint, that it's nice to install it, but it is not
entirely necessary.

Ok.


That's what I think we could do to enable FEMxDEM. Plus a bit of
stuff in documentation about how to run those example FEMxDEM
scripts. Which I still want to write ;)

Wait we diverged from PB to FEMxDEM.
IIRC PB needs not just python packages, it needs something at compile 
time and that's where we have an issue isn't it?


Sorry if I'm a bit lost...

Bruno


___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] how about bringing MyTetrahedron example back to documentation?

[Bruno Chareyre]

Hi Janek,
I would go for the code block in rst.
Bruno



On 2/8/19 9:34 PM, Janek Kozicki wrote:

Back in the day I wrote this simple example for Vaclav about how to
write new geometry, collision detection and constitutive laws.
I think that Anton also studied this example. You can see it here:

   git co -b old-tetra f2ddab567

   find -name "*MyTetrahedron*"

So I was going through documentation and I saw this empty section,

https://yade-dev.gitlab.io/trunk/tutorial-advanced.html#new-law

and I suppose that it would be a nice place to put it there.

I am not sure if I should just write .. code-block: inside .rst with
explanations of this code. And no files in the directory tree, or
maybe put it in /examples/ directory?

But /examples/ contain only *.py code, and that would be a C++ code
example. So to have it working actually I would need to put it
in /pkg/example maybe?

what do you think?


PS: yeah I still want to make those videos from some of those new 215
examples that I checked last week, but I prefer to go from one
chapter to next one, without skipping :)




___
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] PotentialBlocks & Particles documentation on website?

[Bruno Chareyre]

On 2/8/19 7:37 PM, Janek Kozicki wrote:
Enabling FEMxDEM means only adding python-escript to recommended 
packages. 

And this is standard in debian?

B



___
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] PotentialBlocks & Particles documentation on website?

[Bruno Chareyre]

On 2/6/19 2:30 PM, Janek Kozicki wrote:


Of course when Vasileios will write a chapter of documentation
in .rst it will be available, but then clicking the references to
relevant classes will not work.

Question is: how do we solve that?
It just needs to turn on that feature either explicitely in pipeline 
config (cmake  PB_enabled=ON) or implicitely by changing the default 
in CmakeLists.txt.



A separate concern, for another discussion is including them into a
debian pacakage release, because it will bring some dependencies with
it. Which might be difficult to deal with, especially given our bad
experience with CGAL. Personally I would prefer that we split yade
into more debian packages, based on their dependencies, like:

yade-cgal-dep, - parts of yade that depend on CGAL
yade-coinor-dep,   - parts of yade that depend on coinor i.e. PotentialBlocks
yade-escript-dep,  - parts of yade that depend on python-escript, i.e. FEMxDEM
yade-fft-dep   - (future) parts of yade that depend on libfftw (quantum 
mechanics)
I see no real interest in splitting since the problems we will face are 
exactly the same.
If we know how to package yade-cgal-dep properly then we know how 
package yadedaily (or any yade-stable) with CGAL. There is no difference.
If we don't know how to package yade-cgal-dep, then we must turn the 
feature off in yade as well.
More deb packages would help if there were conflicts such that, e.g., 
coinor and escript couldn't be installed together. I don't think it is 
the case here.
So the only advantage would be to minimize disk usage for installing the 
basic yade version, not a real issue.
The price would be more maintainance and branch management, thus I'm not 
a big fan.


In order to build documentation without implying package dependency a 
solution could be use "#ifdef YADE_POTENTIAL_BLOCKS" more selectively, 
i.e. make it guard only the parts of implementation which really depends 
on external dependencies. Then the interface would be compiled 
regardless of feature activation.


Bruno



___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] all bugs moved from launchpad to gitlab issues

[Bruno Chareyre]

Hi, that was a good move.
And you are crazy. :)
Yes, it seems some bugs are irrelevant.
B

On 2/5/19 10:27 PM, Janek Kozicki wrote:

Hi,

I thought we should better migrate because hopping back and forth
between gitlab and launchpad while fixing LaTeX pngmath stuff was
very inconvenient.

I have found this tool:

https://github.com/dmi-try/lpgrabber

git clone https://github.com/dmi-try/lpgrabber.git

It automatically downloaded all bugs into a CSV file from launchpad.
gitlab can import CSV files, but without newlines in bug description.
So I spent 30minutes copying them back and forth. But still it was a
lot faster thanks to automatic import of bug titles.

now we should close some issues that were fixed, some of them looong time ago ;)

best regards
Janek

___
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] [Bug 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Bruno Chareyre]

I think we can merge the branch now (without deleting it) since it fixes
a number of problem online already. Right?

We can keep working on the same branch for further improvement. That's
where the rebase question surfaces again maybe? ;)

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1814286

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

___
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] [Bug 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Bruno Chareyre]

[1] replaces \vec by \boldsymbol using Robert's trick in layout's preamble.
To me it sounds like a dirty trick to define latex conventions in the layout of 
web pages but there seem to be no other option. 

We could not see a problem with \rm, if there is one we can replace it
with \text or something, or simply remove.

\ensuremath was removed.

For \sortlines I suggested to upload the images from previous builds to the doc 
and use them as-is.
 
Problems solved, it seems(?). Thanks guys. 

Bruno


[1] https://gitlab.com/yade-dev/trunk/commit/bdbb374c

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1814286

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

___
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] [Bug 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Bruno Chareyre]

Ok, let us know Robert.

@Anton, do you mean that on some recent version at least the equations
compile correctly?

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1814286

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

___
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] [Bug 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Bruno Chareyre]

It sounds like the pragmatic move is to replace the macros by what they mean. 
Search & replace should work, and I think there are very few pages where those 
macros are used (if not just one page).
Bruno

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1814286

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

___
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] Migration to gitlan - moving bugs to issues on gitlab?

[Bruno Chareyre]

Yeah, i'm still wondering how it was possible to receice bug-related posts
more than once. But I there are other valid arguments for gitlab issue
tracking anyway. :)
Bruno

Le ven. 1 févr. 2019 23:21, Robert Caulk  a écrit :

> Am I missing a subscription? I’m only receiving these messages once.
>
> Le ven. 1 févr. 2019 à 23:08, Janek Kozicki  a écrit :
>
>> > A mixed option could be to move bugs to gitlab and keep Q on LP,
>> hence
>> > separating them even more.
>>
>> Now I lean towards thinking that this might make some sense.
>>
>> In last conversation about pngmath and LaTeX symbols each message I
>> received twice, and my last one I received four times :(
>>
>> issues would integrate neatly with the rest of gitlab, would allow to
>> mark fixed bugs, etc.
>>
>> best regards
>> Janek
>>
>>
>>
>> Bruno Chareyre said: (by the date of Fri, 14 Dec 2018 15:59:14 +0100)
>>
>> > Thanks for investigations Robert. That's convincing.
>> > Mixing bugs and questions does not seem to be a good idea.
>> > A mixed option could be to move bugs to gitlab and keep Q on LP,
>> hence
>> > separating them even more.
>> > Not sure there is any real advantage in doing that, though.
>> >
>> > Bruno
>>
>>
>>
>> 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

[Yade-dev] [Bug 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Bruno Chareyre]

Maybe http://docs.mathjax.org/en/latest/misc/faq.html#does-mathjax-
support-tex-macros

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1814286

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

___
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] [Bug 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Bruno Chareyre]

Before 34fb5ffef all equations in the html were retrieved from png files.
With "mathjax instead of pngmath" they are replaced by inline code, which 
actually works for some of them, but not all of them.
You probably found why (#1).

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1814286

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

___
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] [Bug 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Bruno Chareyre]

The problem appeared in [1].
Maybe it fixed the new sphinx while breaking the older one?
B

[11] https://gitlab.com/yade-dev/trunk/commit/34fb5ffef

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1814286

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions

___
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