Re: [Yade-dev] Test
Hi Bruno, I did not receive your email. I copied it from list archive website. I am not sure how is it possible that you received it and I didn't. Maybe something is wrong with my filters? No idea. But when did they break - I didn't change anything in my configuration for years. Did anyone else receive this mailing list post? Yeah, moving to another mailing list server for yade-dev seems reasonable. best regards Janek @ email copied from https://lists.launchpad.net/yade-dev/msg15150.html @ @ I see your test in my mailbox. @ Maybe we will have to host a "yade-dev" list somewhere else if we @ drop launchpad? @ B Janek Kozicki (yade) said: (by the date of Tue, 29 Aug 2023 19:36:56 +0200) > 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
[Yade-dev] Test
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
Re: [Yade-dev] Upcoming Yade Release 2023.01
Hi, I created update Changelog MR for this: https://gitlab.com/yade-dev/trunk/-/merge_requests/917/diffs best regards Janek Anton Gladky said: (by the date of Mon, 16 Jan 2023 21:16:59 +0100) > Dear all, > > as always at the beginning of the year we are preparing > the stable Yade Release. > > Please, push your changes through merge requests till this Friday, > 20.01.2023 and think about adding some more notes into the > Changelog [1]. > > [1] https://pad.systemli.org/p/yade-2023-changelog > > Thank you > > 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 -- -- 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
Re: [Yade-dev] Please enable runners for some projects in the group
I see yade-runner1 in: https://gitlab.com/groups/yade-dev/-/runners?runner_type[]=GROUP_TYPE best regards Janek Bruno Chareyre said: (by the date of Sun, 16 Oct 2022 18:21:15 +0200) > 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 -- -- 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] Please enable runners for some projects in the group
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) > > -- -- 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] Please enable runners for some projects in the group
One special note, when Bruno you will be adding nova1 or nova2 to group runners. To get the docker-prod to work I needed a special entry in /etc/config.toml: volumes = ["/cache", "/storage/ccache:/root/.ccache:rw", "/var/run/docker.sock:/var/run/docker.sock"] with the emphasis on the last entry: "/var/run/docker.sock:/var/run/docker.sock" it was necessary to make the docker work in docker-prod. The first two entries are the typical ccache stuff, which we use regularly. best regards Janek Janek Kozicki (yade) said: (by the date of Sat, 15 Oct 2022 14:19:30 +0200) > 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) -- -- 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] Please enable runners for some projects in the group
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
[Yade-dev] testing yade on ubuntu 22.04
Bruno, when you will be testing on ubuntu 2022.04, you should be also able to launch the high precision ones: yade-longdouble yade-float128 yade-mpfr150 please give them a try. best regards Janek -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) 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] Yade vs. war in Ukraine
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 -- -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) 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] [Yade-users] TODO-List for Yade
Thank you Anton for creating this list. I have just added a few more items there, including some ideas which I had in mind for a long time. Some of them are difficult, but doable. https://gitlab.com/yade-dev/trunk/-/issues/251 This is the TODO list at which my students will start looking at on March 1st (in only three days). And they have to decide which item to pick on March 15th. A bit unlucky timing, because that's just a day before our yade-dev meeting. They will be working in groups of 3 to 5 and they have 10 months to complete the task. They are not forced to pick items from this list - they can have some other unrelated ideas to work on. But we can provide them with nice ideas, hoping that they will pick something from this list. If you want to add something NOW is the time. I recall that Klaus mentioned, that you needed some students who finished a full C++ course? That's these students. So now you can add items to this list :) best regards Janek Anton Gladky said: (by the date of Sun, 20 Feb 2022 14:47:45 +0100) > Dear all, > > As discussed during the last meeting of yade-devs, I have prepared > a list of TODO-tasks [1] for Yade, which can be completed during the student > works, Google summer of code and other similar contests and springs. > > Feel free to add new ideas (even crazy ones!) into this list. If somebody > will work on the particular task, it will be separated into the extra-task to > be > tracked. > > [1] https://gitlab.com/yade-dev/trunk/-/issues/251 > > Thanks and best regards > > Anton > > ___ > 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 -- -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) 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
[Yade-dev] New Yade version, beginning of January 2022 - Release notes.
HP doc Examples ( 7 MRs) Add example scripts for alpha shapes Add placeholder for high precision triple-pendulum example Add the triple pendulum script examples for our paper More alpha shape examples Conical Damage Model with pressure dependent inter-particle friction coefficient - implementation and examples of a new contact law HydroForceEngine examples: update and add new examples LevelSet example has been extended LevelSet ( 4 MRs) ISC is forced to be serial with 0 verletDist, avoiding the LOG_ERROR in that case LevelSet shape 0/N : beginning of several merge requests for giving a new LevelSet shape Level set 1/N: example and VTK visualization stuff - New Python functions or files, and modifications to VTKRecorder for visualization purposes. Level set (N-1)/N - LevelSet shaped bodies can now interact (without touching InteractionLoop as discussed at some point in the past). Add example & check. OpenMPI calculations ( 4 MRs) Dem8 benchmarks final update DEM8_Benchmarks: Silo Flow and the Penetration Test scripts using SI units (m-N-Pa-kg). revert !596 - see what happens with more testing: checkMPISilo.py Add mpi-default-bin to depends of yadedaily. Fixes #216 (some docker images didn't have mpirun command) GUI ( 3 MRs) Fix rendering of labels in Potential* Gl1 functors for wire=True Fix #27 - fix problem with wrong ETA estimation, by removing it. GUI serialization shows more info if there is an unhandled type. Polyhedra ( 1 MRs) Polyhedra warning about vertices number Alpha shapes ( 1 MRs) Add alpha shapes support & example -- -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) 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
[Yade-dev] Next yade dev meeting, March 16th.
Hello everyone, We are holding dev meetings on zoom once every two months. 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, March 16th at 11:00 CEST time. Please reply in this thread if you plan to join so we can send you the zoom link. cheers Janek -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) 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] R: yade-dev team tomorrow's zoom meeting reminder
Hi Deepak and Katia, you can obtain the invite links from Klaus and from discord as mentioned by Robert :-) On discord there is a link to our agenda too. Please feel free to edit the agenda, to add discussion points which you would like to discuss. You are very welcome :-)) thank you very much for your interest! best regards Janek Katia Boschi said: (by the date of Wed, 10 Nov 2021 09:00:34 +) > Dear Janek, > > I would be interested too. > Thank you, > > Katia > > —— > Katia Boschi > > PhD Candidate in Structural, Seismic and Geotechnical Engineering > Department of Civil and Environmental Engineering (DICA) > Politecnico di Milano > Piazza Leonardo da Vinci, 32 - 20133 Milan (IT) > Skype: boschikatia > > > Da: Yade-dev > per conto di Deepak Kn > Data: martedì, 9 novembre 2021 20:00 > A: Janek Kozicki (yade) > Cc: yade-dev@lists.launchpad.net > Oggetto: Re: [Yade-dev] yade-dev team tomorrow's zoom meeting reminder > Hello Janek, > > Just a question, how often do these meetings take place ? > > Thanks and best regards, > Deepak > > On Tue, Nov 2, 2021 at 3:40 PM Janek Kozicki (yade) > mailto:jkozicki-y...@pg.edu.pl>> wrote: > BTW, Klaus, here in Europe just three days ago we have switched to > winter time. That's one hour shift. > > > > Janek Kozicki (yade) said: (by the date of Tue, 2 Nov 2021 15:32:27 +0100) > > > Hello everyone, > > > > Just a reminder that tomorrow we have a developer zoom meeting at 11:00 CET. > > > > If someone yet uninvited wants to join I hope there's still time to > > reply to this message to get the zoom link from Klaus. > > > > best regards > > Janek > > > > -- > > -- > > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. > > Gdansk University of Technology (Gdansk Tech) > > 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) > > > -- > -- > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. > Gdansk University of Technology (Gdansk Tech) > 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<mailto: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. Gdansk University of Technology (Gdansk Tech) 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] yade-dev team tomorrow's zoom meeting reminder
BTW, Klaus, here in Europe just three days ago we have switched to winter time. That's one hour shift. Janek Kozicki (yade) said: (by the date of Tue, 2 Nov 2021 15:32:27 +0100) > Hello everyone, > > Just a reminder that tomorrow we have a developer zoom meeting at 11:00 CET. > > If someone yet uninvited wants to join I hope there's still time to > reply to this message to get the zoom link from Klaus. > > best regards > Janek > > -- > -- > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. > Gdansk University of Technology (Gdansk Tech) > 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) -- -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) 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
[Yade-dev] yade-dev team tomorrow's zoom meeting reminder
Hello everyone, Just a reminder that tomorrow we have a developer zoom meeting at 11:00 CET. If someone yet uninvited wants to join I hope there's still time to reply to this message to get the zoom link from Klaus. best regards Janek -- -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) 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] members yade-dev gitlab
Ouch sorry I didn't notice you gave the name! :-) But I see that Bruno already added you: https://gitlab.com/yade-dev/trunk/-/project_members welcome! Janek Raphaël Maurin said: (by the date of Mon, 30 Aug 2021 16:57:24 +0200) > Hi all, Hi Janek, > > There should have been a problem, I checked and I cannot find the email > you talk about. Sorry for the unconvenience, as said in the last email, > my gitlab account name: raphm1. > > Best regards, > > Raphaël > > Le 30/08/2021 à 16:03, Janek Kozicki (yade) a écrit : > > Hi, I recall that month ago Bruno has sent you an email asking about > > your gitlab account name. > > > > best regards > > Janek > > > > Raphaël Maurin said: (by the date of Mon, 30 Aug 2021 15:08:35 +0200) > > > >> Dear all, > >> > >> Following the question I asked some times ago on the users launchpad > >> [1], can someone add me (raphm1) to the yade-dev member list on gitlab > >> to do some commits ? I need to upload changes (mainly on > >> HydroForceEngine), validations and examples I have been doing these last > >> years (I adapted the changes from the latest version of the code). > >> > >> Thanks, > >> > >> Raphaël > >> > >> [1] https://answers.launchpad.net/yade/+question/697927 > >> > >> > >> ___ > >> Mailing list: https://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. Gdansk University of Technology (Gdansk Tech) 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] members yade-dev gitlab
Hi, I recall that month ago Bruno has sent you an email asking about your gitlab account name. best regards Janek Raphaël Maurin said: (by the date of Mon, 30 Aug 2021 15:08:35 +0200) > Dear all, > > Following the question I asked some times ago on the users launchpad > [1], can someone add me (raphm1) to the yade-dev member list on gitlab > to do some commits ? I need to upload changes (mainly on > HydroForceEngine), validations and examples I have been doing these last > years (I adapted the changes from the latest version of the code). > > Thanks, > > Raphaël > > [1] https://answers.launchpad.net/yade/+question/697927 > > > ___ > Mailing list: https://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. Gdansk University of Technology (Gdansk Tech) 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] would a HarmonicForceEngine be of any interest?
You can create a fork on your own profile, then create a merge request from your profile to yade-dev. Then it will go though our pipeline, like for example this MR: https://gitlab.com/yade-dev/trunk/-/merge_requests/511 I guess we need to update docs about this. best regards Janek Daniel Kiracofe said: (by the date of Thu, 13 May 2021 10:17:03 -0400) > Thank you Bruno. I think I know how although I have not done it > before. I followed the instructions at > https://yade-dem.org/doc/gitrepo.html?highlight=merge%20request and > tried method 1, but I got an error message "You are not allowed to > push code to this project.". I don't think I can do method 2 as I do > not have GitLab Runners installed. Do you need to add permission for > me to push a branch? My gitlab username is daniel.kiracofe > > >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 -- -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) 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] Introducing Yade discord beta
Cool! I am this guy: https://xkcd.com/1782/ I found some irssi-discord bridge plugins, will try them :-) best regards Janek Robert Caulk said: (by the date of Thu, 6 May 2021 19:55:23 +0200) > Hey Yade devs, > > A few of us were discussing the *idea of encouraging more collaboration* > among Yade devs and the idea came up to create a central server for > chatting about various topics and exchanging ideas. > > Discord seems to be a good candidate for this since we can organize the > server into various topics (i.e. resources, polyhedra, fluid-couplings, > geomechanics etc.) Also, we don't need to install any software to join and > chat (there is a browser-based version) > > *The goal of this discord* server is to bring yade devs and users together > in one place to chat freely and openly. If we are lucky, some > collaborations will pop up, if we are unlucky it may just become a landing > spot for new users. > > Before we open it to the public, I'd like to invite you yade devs to the > "beta" server. Come on over and say hey, start testing it out, and provide > feedback. If you have any suggestions for the layout/organization, please > let me know, and I will make sure to incorporate your recommendations. > > So, see you over at the yade discord server: > > https://discord.gg/kkZ4c3nQtV > > Cheers, > > Robert -- -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) 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] Docker/Singularity images for production (and possibly development)
Yeah, let's do that. Friday for me is the best option, sometime after 12:00. Anton Gladky said: (by the date of Sat, 6 Mar 2021 19:46:54 +0100) > Hi Bruno, > > this is very interesting! I have never heard about singularity yet. Thanks > for information. > > From my point of view, it is not a problem at all to build docker-images > with yadedaily > inside, if it is helpful for you and anybody. I have some concerns about > large dev-images, > but I am also opened to it. > > I would propose to organize a short zoom/bbb/jitsi video-meeting and to > discuss it by voice. > We are practicing it already with Janek and Klaus for some other (paper) > stuff and it works > perfectly and just faster as writing long emails. > > Best regards > > Anton > > > Am Sa., 6. März 2021 um 19:18 Uhr schrieb Bruno Chareyre < > bruno.chare...@3sr-grenoble.fr>: > > > > > On 06/03/2021 17:06, Janek Kozicki (yade) wrote: > > > > I am not exactly sure what you want to discuss, > > > > I don't know either LOL. That's more an announcement in advance so someone > > can raise issues, ask features, etc. > > > > Do you want to create some sort of packages with yade installed inside? > > > > You can call it package, but that's more like some docker images in a > > different format (from a very macroscopic point of view). Main thing is > > that it is allowed on HPC (where compiling yade can be big pain) and it > > seems to become more popular. > > > > Hence people will look for a yade-docker target (one with yade inside) in > > order to build their singularity images, and it is fairly easy to offer > > some. > > > > Mind that before using Singularity I have never been able to get all > > checkTests to pass on our HPC cluster. I was able to run what I needed most > > of the time, but never to pass all tests. There was always an issue with > > something. > > > > I am not sure if yade-dev registry will be able to hold big > > docker images. > > > > Good point, though the images have no reason to be much bigger than our > > current docker images. The problem would be more images, not larger images. > > I will check registry limit. If it is a problem I can keep pushing to > > gitlab.com/bchareyre registry, not an issue. See: > > https://gitlab.com/bchareyre/docker-yade/container_registry/1672064 > > > > As you see the images are from 1.1GB to 1.7GB, not a big increment. > > > > We may run out of space if we don't start paying > > gitlab for hosting. > > > > Not an issue. What I described is what I'm already doing under my account > > (without paying). If migrating one thing from gitlab/bchareyre to > > gitlab/yade-dev is the cause of running out of space, then I'll just not > > migrate. It is not an problem to provide the images to the users under my > > registry. > > > > Perhaps these singularity_docker packages should also be on yade-dem.org ? > > > > Excessively complex. We would have to setup a registry on our local server > > while gitlab does that very well. > > > > > > The interesting stuff for me would be if we could use these HPC > > singularity servers in our gitlab continuous integration pipeline :) > > > > If you mean accessing more hardware ressources, no, it will not work in > > Grenoble. > > The HPC clusters are dedicated to scientific computing. They have special > > job submission systems, it will absolutely not integrate in a CI framework. > > > > The yade-runner-01 quickly runs out of space whenever try to I enable > > it ;-) > > > > Yeah, but this is a completely different type of ressources, even if they > > are provided by the same people overall. > > Maybe it is a good time to check again how I could get gitlab runners for > > yade. They improved a number of things and offered new services in the > > recent years. There might be docker farms more easily accessible than when > > Rémi configured yade-runner-01, now. Rémi was basically ahead of things. > > > > > > Maybe it is only a matter of single line in > > file /etc/gitlab-runner/config.toml , change: > > > > executor = "docker" > > > > to > > > > executor = "singularity" > > > > I think this is quite likely. > > > > > > Very likely but there is no point doing that, I think. > > Why would you generate a singularity image from a docker image to achieve > > something the docker image does just as well? > > In the context of using gitlabCI/docker
Re: [Yade-dev] Docker/Singularity images for production (and possibly development)
agic 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 -- -- 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
[Yade-dev] boost::mpi and python bindings for it.
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
--
--
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] A suggestion/contribution regarding bug of Yade-users #694548
it it personnaly to the git repository so that I learn how > it is done. I would need a bit of guidance for that though ️. I also > think I might need the confirmation that the fix I propose indeed is > relevant and safe to be implemented. > > Gaël > > [1] http://dl.free.fr/mbGj9Moc0 > ___ > Mailing list: https://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
Re: [Yade-dev] A suggestion/contribution regarding bug of Yade-users #694548
> (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… ️) Hi, reformat with the same .clang-format file your old branch (*). Then you will be back to meaningful diffs. I used this trick more than once when fighting old bugs which appeared long before clang-format and comparing with newer versions: this eliminates all formatting differences and only meaningful code changes remain. best regards Janek (*) you can use: `scripts/clang-formatter.sh ./` (copied to old branch, along with .clang-format config file) Gael Lorieul said: (by the date of Tue, 23 Feb 2021 20:59:33 +) > 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) > -- -- 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] Yade 2021.01a is released
This is an awesome team effort. Congratulations everyone. This year was great, let's make the next one even better :) cheers Janek Anton Gladky said: (by the date of Thu, 28 Jan 2021 19:58:35 +0100) > Dear Yade users and developers, > > As always at the beginning of the year we are releasing > the newer Yade version. A couple of days ago Yade 2021.01a > was released [1]! Thanks all for contributions! > > Special thanks to Janek for his contribution and preparing the > release notes! French team thanks for pushing MPI version of the > Yade and other features and fixes! > > [1] https://gitlab.com/yade-dev/trunk/-/releases/2021.01a > > Best regards > > Anton -- -- 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] New Yade version, beginning of January 2021 - Release notes.
Draw grid label coordinates, allow custom change of grid density. remove unaligned margins in GUI inspect. Add enum support for GUI dropdown menus. === Are the extra debian packages yade-long-double or yade-float128, maybe even yade-mpfr150 even possible? best regards Janek Janek Kozicki (yade) said: (by the date of Sun, 6 Dec 2020 00:26:03 +0100) > Hi Anton, > > Do you think that you could also prepare yade-long-double or > yade-float128, maybe even yade-mpfr150 packages? > > Better if all of them used ENABLE_MPFR, to avoid slow boost::cpp_bin_float. > > It would work great to protect (via dpkg tests caused by changes in > other packages) our achievement of having working high precision in > yade. We don't want this functionality to break at some later time. > > best regards > Janek > > > Anton Gladky said: (by the date of Mon, 16 Nov 2020 20:13:06 +0100) > > > Hello Jérôme, > > > > our goal is to get the newer Yade into the Debian Bullseye, because > > it will be the default version for the next two years (till 2023). > > > > It would be good to upload Yade into the repository in January (till soft > > freeze > > on 2021-02-12). After that date any upload into the repository should be > > coordinated with the Release team and is actually not for the new software > > versions. > > > > If you are able to push your changes till the end of December and all tests > > are passing, I think it would be possible to accept it for the new release. > > > > I am not a fan of a last-minute commit (especially on Friday afternoon > > :) ) because it can break the stuff with a very limited time to fix it. > > > > Anyway, if you are not able to do it on time - there is still an > > opportunity to release a minor version later. > > > > Please take time and test your code (including --test and --check scripts) > > to prevent breakages and to provide Yade with new and reliable features. > > > > Best regards > > > > > > Anton > > > > Am Fr., 13. Nov. 2020 um 11:23 Uhr schrieb Jerome Duriez > > : > > > > > > > > Dear all, > > > > > > Sorry for the inconvenience but is there any flexibility in that schedule > > > ? > > > > > > I have been working on a new Shape child and I may get closer to the > > > endpoint of my work in the form of a merge request. > > > > > > It now represents "32 files changed, 2193 insertions(+), 178 > > > deletions(-)" since 2020.01(a ?) = commit 9964f5. > > > > > > > > > In case there is some flexibility in the schedule and if I'm not the > > > only one interested in that flexibility (MPI maybe ?..), maybe we could > > > discuss inclusion of that Shape child in the new release ? > > > > > > If not, let it be, I would totally understand to miss that train. > > > > > > > > > Jérôme > > > > > > -- > > > Chargé de Recherche / Research Associate > > > INRAE, RECOVER > > > 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE > > > +33 (0)4 42 66 99 21 > > > https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez > > > > > > On 12/11/2020 22:18, Anton Gladky wrote: > > > > Dear Yade users and developers, > > > > > > > > As always at the beginning of January I am planning to prepare > > > > a release of a new Yade version. > > > > > > > > Please try to push your changes inyo the code at least till the mid > > > > of December, so we will have enough time to test it on different > > > > platforms during the Christmas period and release it on time. > > > > Also please try not to push too much breaking changes at that > > > > period.. > > > > > > > > The new Debian Bullseye release is scheduled already [1]. So we > > > > should not be too late to prepare a new Yade for the next stable > > > > Debian version. > > > > > > > > Also it would be good to prepare short but meaningful release notes. > > > > Current git-workflow has too many small log-messages, so it is > > > > difficult to get meaningful information from there. Please use this > > > > link to add some notes [2]. > > > > > > > > [1] https://wiki.debian.org/DebianBullseye > > > > [2] https://pad.systemli.org/p/yade-2021-release-notes > > > > > > > > Thank you > > > > > > > > Anton Gladky -- 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] New Yade version, beginning of January 2021
Hi Anton, Do you think that you could also prepare yade-long-double or yade-float128, maybe even yade-mpfr150 packages? Better if all of them used ENABLE_MPFR, to avoid slow boost::cpp_bin_float. It would work great to protect (via dpkg tests caused by changes in other packages) our achievement of having working high precision in yade. We don't want this functionality to break at some later time. best regards Janek Anton Gladky said: (by the date of Mon, 16 Nov 2020 20:13:06 +0100) > Hello Jérôme, > > our goal is to get the newer Yade into the Debian Bullseye, because > it will be the default version for the next two years (till 2023). > > It would be good to upload Yade into the repository in January (till soft > freeze > on 2021-02-12). After that date any upload into the repository should be > coordinated with the Release team and is actually not for the new software > versions. > > If you are able to push your changes till the end of December and all tests > are passing, I think it would be possible to accept it for the new release. > > I am not a fan of a last-minute commit (especially on Friday afternoon > :) ) because it can break the stuff with a very limited time to fix it. > > Anyway, if you are not able to do it on time - there is still an > opportunity to release a minor version later. > > Please take time and test your code (including --test and --check scripts) > to prevent breakages and to provide Yade with new and reliable features. > > Best regards > > > Anton > > Am Fr., 13. Nov. 2020 um 11:23 Uhr schrieb Jerome Duriez > : > > > > > Dear all, > > > > Sorry for the inconvenience but is there any flexibility in that schedule ? > > > > I have been working on a new Shape child and I may get closer to the > > endpoint of my work in the form of a merge request. > > > > It now represents "32 files changed, 2193 insertions(+), 178 > > deletions(-)" since 2020.01(a ?) = commit 9964f5. > > > > > > In case there is some flexibility in the schedule and if I'm not the > > only one interested in that flexibility (MPI maybe ?..), maybe we could > > discuss inclusion of that Shape child in the new release ? > > > > If not, let it be, I would totally understand to miss that train. > > > > > > Jérôme > > > > -- > > Chargé de Recherche / Research Associate > > INRAE, RECOVER > > 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE > > +33 (0)4 42 66 99 21 > > https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez > > > > On 12/11/2020 22:18, Anton Gladky wrote: > > > Dear Yade users and developers, > > > > > > As always at the beginning of January I am planning to prepare > > > a release of a new Yade version. > > > > > > Please try to push your changes inyo the code at least till the mid > > > of December, so we will have enough time to test it on different > > > platforms during the Christmas period and release it on time. > > > Also please try not to push too much breaking changes at that > > > period.. > > > > > > The new Debian Bullseye release is scheduled already [1]. So we > > > should not be too late to prepare a new Yade for the next stable > > > Debian version. > > > > > > Also it would be good to prepare short but meaningful release notes. > > > Current git-workflow has too many small log-messages, so it is > > > difficult to get meaningful information from there. Please use this > > > link to add some notes [2]. > > > > > > [1] https://wiki.debian.org/DebianBullseye > > > [2] https://pad.systemli.org/p/yade-2021-release-notes > > > > > > Thank you > > > > > > Anton Gladky > > > > > > ___ > > > Mailing list: https://launchpad.net/~yade-dev > > > Post to : yade-dev@lists.launchpad.net > > > Unsubscribe : https://launchpad.net/~yade-dev > > > More help : https://help.launchpad.net/ListHelp > > > > > > > ___ > > Mailing list: https://launchpad.net/~yade-dev > > Post to : yade-dev@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~yade-dev > > More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://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
Re: [Yade-dev] New Yade version, beginning of January 2021
Hi, it is great that you move forward with packaging a new yade release. I will take some time to write a bit in the release notes link which you provided. best regards Janek Anton Gladky said: (by the date of Thu, 12 Nov 2020 22:18:55 +0100) > Dear Yade users and developers, > > As always at the beginning of January I am planning to prepare > a release of a new Yade version. > > Please try to push your changes inyo the code at least till the mid > of December, so we will have enough time to test it on different > platforms during the Christmas period and release it on time. > Also please try not to push too much breaking changes at that > period.. > > The new Debian Bullseye release is scheduled already [1]. So we > should not be too late to prepare a new Yade for the next stable > Debian version. > > Also it would be good to prepare short but meaningful release notes. > Current git-workflow has too many small log-messages, so it is > difficult to get meaningful information from there. Please use this > link to add some notes [2]. > > [1] https://wiki.debian.org/DebianBullseye > [2] https://pad.systemli.org/p/yade-2021-release-notes > > Thank you > > Anton Gladky > > ___ > Mailing list: https://launchpad.net/~yade-dev > Post to : yade-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp -- -- 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] Need little help (no laughing please) + some update
I confirmed in person. Issue resolved. Good luck! We did plenty of work during the summer holidays, you will see in the latest MRs and commits :) cheers Janek Bruno Chareyre said: (by the date of Wed, 7 Oct 2020 11:57:33 +0200) > 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 -- -- 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] Fwd: Re: [Question #691593]: avoid this message : "The constructor with a shareWidget is deprecated, use the regular contructor instead."
Hi Luc, your patch does not pass the pipeline: https://gitlab.com/yade-dev/trunk/-/merge_requests/512/pipelines feel free to correct it and open another merge request. It is now possible to run pipelines for forked projects [1][2] so it is much easier now for you to submit a merge request. best regards Janek [1] https://gitlab.com/gitlab-org/gitlab/-/issues/217451 [2] https://gitlab.com/yade-dev/trunk/-/merge_requests/511#note_385917497 Luc Oger said: (by the date of Sat, 4 Jul 2020 12:50:18 +0200) > Dear all, > > as requested, here the three changes made to avoid the warning about > sharewidget coming from libqglViewer from 2.7.1 and Qt higher than 5.3 > > Sinceelry yours > > Luc OGER > > Ps hint on https://www.qt.io/blog/2014/09/10/qt-weekly-19-qopenglwidget > given from libqglviewer group > > Message transféré > Sujet : Re: [Question #691593]: avoid this message : "The constructor > with a shareWidget is deprecated, use the regular contructor instead." > Date :Fri, 03 Jul 2020 12:11:00 - > De : Jérôme Duriez > Répondre à : question691...@answers.launchpad.net > Pour :luc.o...@univ-rennes1.fr > > > > Your question #691593 on Yade changed: > https://answers.launchpad.net/yade/+question/691593 > > Jérôme Duriez posted a new comment: > Thanks for sharing Luc, maybe it would help for possible future > integration of this to (one choice to pick, increasing complexity) > > - send the output of a (git) diff to yade-dev@lists.launchpad.net > > - join YADE development on GitLab, see https://yade- > dem.org/doc/gitrepo.html to start with (you probably also need to send > an email asking to join the yade-dev gitlab team with your gitlab > account) > > -- > You received this question notification because you asked the question. > > > -- > Luc OGER > Directeur de Recherche CNRS > > univ-rennes1 <https://www.univ-rennes1.fr/> > > > *Institut de Physique de Rennes <https://www.ipr.univ-rennes1.fr/>* > (UMR U.Rennes1-CNRS 6251) > Département Milieux Divisés > > Page perso <https://perso.univ-rennes1.fr/luc.oger>** > > > Bâtiment 11A, Campus de Beaulieu > CS 74205, 263 Ave. du Général Leclerc > 35042 Rennes CEDEX > > > > +33 (0)2 23 23 56 58 > > > <https://twitter.com/UnivRennes1> <https://fr-fr.facebook.com/UnivRennes1> > www.univ-rennes1.fr <https://www.univ-rennes1.fr> > > -- -- 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] Do we have "quick" pipeline on gitlab?
Bruno Chareyre said: (by the date of Mon, 18 May 2020 21:22:41 +0200) > 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. :) yeah. Also - these build servers are sometimes used by other people to calculate some stuff, and sometimes some of them are slower or faster than usual. If you see that a build is taking more than 2 minutes (when ccache is expected to be fully applicable), it can be faster to click "cancel" then "retry" (hoping that it will retry on another build server from the available ones), because this particular build server is under high load right now. Micromanaging them on my side (adding/removing them manually to gitlab runner config) depending on what stuff is running on each of them does not make sense. They all work nice. Just randomly some of them are slower for a couple of hours. I type this, because right now y6pak is slow, and 15 minutes is spent on ccached compilation that normally takes 2 minutes. > > 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. ouch. That's not good. Tell them to go directly to 20.04 :) They wasted 2 years ;) > 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. :) -- -- 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] Do we have "quick" pipeline on gitlab?
Bruno Chareyre said: (by the date of Mon, 18 May 2020 17:17:08 +0200) > still, compiling with 5 number formats in the minimal build is a bit > overkill maybe. One number format (long double) is compiled in WIP, all the others are all disabled. 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." Or did I miss something? yeah. You can make gitlab-ci even shorter. And revert that when you are finished with this ;) Maybe think about upgrading your pc to 20.04 :) cheers Janek > 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 > > >
Re: [Yade-dev] Do we have "quick" pipeline on gitlab?
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) > 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) ___ Mailing list: https://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?
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) ___ Mailing list: https://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
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) ___ Mailing list: https://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
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
[Yade-dev] gitlab is installed at Gdańsk University of Technology
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
Re: [Yade-dev] Vector outputs in LOG macros vs cout
OK, I think it is fixed in latest MR https://gitlab.com/yade-dev/trunk/-/merge_requests/446 please try it. Janek Kozicki (yade) said: (by the date of Fri, 20 Mar 2020 22:36:36 +0100) > Hi Jerome, > > it is not on purpose. I find it annoying too. I will have a look :) > I guess it has got something with operator<< somewhere. > > My university shifted to online courses, this takes more time than I > would like. I hope that soon I will manage to do some work with yade. > > best regards > Janek > > > Jerome Duriez said: (by the date of Fri, 20 Mar 2020 14:59:19 +0100) > > > Hi (Janek ?) > > > > Is it on purpose (or imposed by Boost ?) that e.g. > > > > LOG_DEBUG(someVector3r_Or3i_Or...) > > > > will output the vector items in "column", while > > > > cout << someVector3r_Or3i_Or... > > > > would output them in the same row ? > > > > > > Hoping that current boring lockdown times will give some interest to > > that question ! ;-) > > > > Jérôme > > > > -- > > Chargé de Recherche / Research Associate > > Inrae, RECOVER > > 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE > > +33 (0)4 42 66 99 21 > > https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez > > > > > > ___ > > Mailing list: https://launchpad.net/~yade-dev > > Post to : yade-dev@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~yade-dev > > More help : https://help.launchpad.net/ListHelp > > > -- > -- > 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
Re: [Yade-dev] Vector outputs in LOG macros vs cout
Hi Jerome, it is not on purpose. I find it annoying too. I will have a look :) I guess it has got something with operator<< somewhere. My university shifted to online courses, this takes more time than I would like. I hope that soon I will manage to do some work with yade. best regards Janek Jerome Duriez said: (by the date of Fri, 20 Mar 2020 14:59:19 +0100) > Hi (Janek ?) > > Is it on purpose (or imposed by Boost ?) that e.g. > > LOG_DEBUG(someVector3r_Or3i_Or...) > > will output the vector items in "column", while > > cout << someVector3r_Or3i_Or... > > would output them in the same row ? > > > Hoping that current boring lockdown times will give some interest to > that question ! ;-) > > Jérôme > > -- > Chargé de Recherche / Research Associate > Inrae, RECOVER > 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE > +33 (0)4 42 66 99 21 > https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez > > > ___ > Mailing list: https://launchpad.net/~yade-dev > Post to : yade-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp -- -- 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?
Bruno Chareyre said: (by the date of Tue, 10 Mar 2020 20:42:08 +0100)
> Wow, thanks a ton for clarifying. Recently I was wondering why dragging
> with mouse did not work like before... I'll check.
OK, great! Please push the fix to
https://gitlab.com/yade-dev/trunk/-/merge_requests/438
:-))
> 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)
> >
> >
> >
--
--
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 said: (by the date of Tue, 10 Mar 2020 13:13:47 +0100) > Do you mean to reformat the whole repository? yes, exactly. Sorry for so many merge requests (again). This time I was thinking that maybe someone was working in ./core and not in ./lib directory. Maybe I should have done just one huge MR?. I usually exaggerate stuff to stay on the safe side ;) But these MRs are separate dirs, they cannot be in conflict with each other. And I am thinking that maybe we can do this reformatting now, because I finished the high precision stuff. While doing the HP coding I had crazy amount of interleaving branches. Reformatting at that time wasn't possible. And I had to make so many different merge requests, and still they were quite large (even though I did split them into as many smaller parts for easier checking as I could). But now HP is finished, so we could do that (from my perspective). Provided that it is not colliding with your local code. :) It's not a problem to close these MRs, reopen later when needed and `git push --force` the up-to-date reformatted code. Meaning: we can do this later if it hurts anybody now. Vasileios Angelidakis (PGR) said: (by the date of Tue, 10 Mar 2020 13:45:59 +) > I don’t have any objections if you clang-format the whole repository. Can do > the same with my local WIP repository to avoid conflicts. Great, thanks! Let's see what others can say about this? :) 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
Re: [Yade-dev] should we drop qt4 support?
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 ?
Anton Gladky said: (by the date of Mon, 9 Mar 2020 21:54:04 +0100) > If we drop qt4 directory completely, then we will have only qt5-version > of this method, right? Oh, right. And it was used for a long time, so it must be good :) I have just updated that merge request and removed qt4 directory. Fortunately we have GUI tests in the pipeline, so it should detect any abnormalities :) (there shouldn't be any, I guess). 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? If changes are small, then you could run: scripts/clang-formatter.sh $YOUR_FILE and copy it onto the reformatted file. Then the only changes in the diff will be the modified lines. best regards Janek > > Regards > > Anton > > 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
Re: [Yade-dev] should we drop qt4 support?
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
[Yade-dev] should we drop qt4 support?
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
Re: [Yade-dev] Do we want low precision float in the gitlab CI pipeline?
OK, thanks :) And thanks for the link to sudoDEM :) Bruno Chareyre said: (by the date of Sun, 1 Mar 2020 21:48:19 +0100) > (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> -- -- 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
[Yade-dev] Do we want low precision float in the gitlab CI pipeline?
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) yade --test == ERROR: testMatchMakerCollisions (yade.TestMatchMaker) -- Traceback (most recent call last): File "/tmp/15-YADE/23-yade-install-bin/yade/trunk/lib/x86_64-linux-gnu/yade-2020-02-27.git-614be29/py/yade/tests/core.py", line 260, in testMatchMakerCollisions self.assertTrue((atan(O.interactions[id11,id12].phys.tangensOfFrictionAngle)-0.1)==0) AttributeError: 'NoneType' object has no attribute 'tangensOfFrictionAngle' == FAIL: testMatrix3 (yade.TestEigenWrapper) Math: Matrix3 operations -- Traceback (most recent call last): File "/tmp/15-YADE/23-yade-install-bin/yade/trunk/lib/x86_64-linux-gnu/yade-2020-02-27.git-614be29/py/yade/tests/wrapper.py", line 143, in testMatrix3 self.assertSeqAlmostEqual(m1*Vector3().UnitX,Vector3().UnitY) File "/tmp/15-YADE/23-yade-install-bin/yade/trunk/lib/x86_64-linux-gnu/yade-2020-02-27.git-614be29/py/yade/tests/wrapper.py", line 103, in assertSeqAlmostEqual for i in range(len(v1)): self.assertAlmostEqual(v1[i],v2[i],msg='Component '+str(i)+' of '+str(v1)+' and '+str(v2)) AssertionError: -1.1920928955078125e-07 != 0.0 within 7 places (1.1920928955078125e-07 difference) : Component 0 of Vector3(-1.192093e-07,1,0) and Vector3(0,1,0) == FAIL: testQuaternion (yade.TestEigenWrapper) Math: Quaternion operations -- Traceback (most recent call last): File "/tmp/15-YADE/23-yade-install-bin/yade/trunk/lib/x86_64-linux-gnu/yade-2020-02-27.git-614be29/py/yade/tests/wrapper.py", line 129, in testQuaternion self.assertSeqAlmostEqual(q1*x,y) File "/tmp/15-YADE/23-yade-install-bin/yade/trunk/lib/x86_64-linux-gnu/yade-2020-02-27.git-614be29/py/yade/tests/wrapper.py", line 103, in assertSeqAlmostEqual for i in range(len(v1)): self.assertAlmostEqual(v1[i],v2[i],msg='Component '+str(i)+' of '+str(v1)+' and '+str(v2)) AssertionError: -1.1920928955078125e-07 != 0.0 within 7 places (1.1920928955078125e-07 difference) : Component 0 of Vector3(-1.192093e-07,1,0) and Vector3(0,1,0) == FAIL: testKineticEnergy (yade.TestPBC) PBC: utils.kineticEnergy considers only fluctuation velocity, not the velocity gradient -- Traceback (most recent call last): File "/tmp/15-YADE/23-yade-install-bin/yade/trunk/lib/x86_64-linux-gnu/yade-2020-02-27.git-614be29/py/yade/tests/pbc.py", line 86, in testKineticEnergy self.assertAlmostEqual(Ek,utils.kineticEnergy()) AssertionError: 6544.984436035156 != 6544.984375 within 7 places (6.103515625e-05 difference) ==
Re: [Yade-dev] Request for sudoDEM+third party source code
We have met Jidong Zhao, the sudoDEM co-author, at the last yade workshop. Perhaps we should ask him directly? Bruno Chareyre said: (by the date of Thu, 27 Feb 2020 15:52:08 +0100) > 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: > > 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 you > conspicuously and appropriately publish on each copy an appropriate > copyright notice > 2. You may modify your copy [...] and distribute such modifications > under 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 notices > stating 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 of > Sections 1 and 2 above provided that you also do one of the following: > a) Accompany it with the complete corresponding machine-readable > source code [...] > b) Accompany it with a written offer, valid for at least three > years, to give any third party [...] the corresponding source code > > 4. You may not [...] distribute the Program > except as expressly provided under this License. Any attempt > otherwise [...] will automatically terminate your rights > > 10. If [your] distribution conditions are different, write to the author > to 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> -- -- 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] High precision Real and minieigen
Yes, I think that we can stay with boost::python. But we need to put minieigen sources back into yade. best regards Janek Anton Gladky said: (by the date of Sun, 23 Feb 2020 22:08:47 +0100) > Hi Janek, > > thanks a lot for this quick tests and results! Really impressive! > > As far as I see, there is not benefit for us to replace boost::python, > at least right now? > > Regards > > Anton > > Am So., 23. Feb. 2020 um 16:02 Uhr schrieb Janek Kozicki (yade) > : > > > > > 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) -- -- 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] High precision Real and minieigen
> 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
Re: [Yade-dev] High precision Real and minieigen
Hi Anton > sorry for delays, "real" life is taking much more time when we get older :) please don't worry. I really appreciate all your hard work. I got a little carried away, I'm sorry. > > * I would rather avoid pybind11 switch in a rush, better give it a few > > months > Maybe I was not clear, pybind11 is just a possible option. If we > really decide to switch to it, we need to evaluate, whether it is > suitable for us, whether it really helps to improve compilation times > and what it costs for us (time). exactly. The quick migration which I have done yesterday passes the tests, and seems to work at first glance, but there were some tricky sections of the code. Which I converted but I didn't test. I feel more comfortable with old and well tested boost::python version. Also I see that Vaclav has done this already [1] > > * I would prefer minieigen-src package (no extra compilation time for > > people who use `double`) > > * minieigen-src in ubuntu 20.04 will let more people to test & use high > > precision. > Unfortunately, it is almost impossible for the time being […] this is clear. > We should probably consider alternative ways to help you to integrate > high-precision stuff. Thank you! :)) 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. 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. best regards Janek [1] https://github.com/woodem/woo/blob/master/lib/eigen/pybind11/visitors.hpp ___ Mailing list: https://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
Hi All :) I did an experimental switch to pybind, see this pipeline: https://gitlab.com/cosurgi/minieigen-real/pipelines/120246349 My observations about pybind11+minieigen: 1. pybind11 seems better organized and easier to use than boost::python 2. pybind11 has unstable API, what compiles on bullseye, does not compile on debian stretch: https://gitlab.com/cosurgi/minieigen-real/-/jobs/446852240 (I only created debian-bullseye-pybind & debian-stretch-pybind images, failures on other linux distributions are because there is no pybind docker image) 3. compilation time without ccache (on my computer) base invocation: /usr/bin/time -f "\n\n\twall clock time: %E\n\n" make test_ci_mne_64 -j 1 CXXFLAGS="-D EIGEN_DONT_ALIGN -D EIGEN_DONT_VECTORIZE -D EIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT" -O1 boost::python make -j 10: 31 seconds pybind -j 10: 30 seconds boost::python make -j 1 : 120 seconds pybind -j 1 : 90 seconds -O3 boost::python make -j 10: 32 seconds pybind -j 10: 40 seconds boost::python make -j 1 : 140 seconds pybind -j 1 : 150 seconds note: that's compilation time of minieigen only. Not yade ;) It is strange to observe that boost::python is easier to be optimized by compiler. Please try yourself. I only did two measurements without calculating standard deviation ;) 4. pybind does not segfault with Eigen vectorization enabled on older compiler. boost::python segfaults with Eigen vectorization on older compilers (We only very recently have added make_SSE to the pipeline, and it is with the newer compiler version). For someone who really wants SSE that's important. But in my opinion struggling for SSE serves no purpose without AlignedVector3, which isn't supported (yet). 5. both of them assume that minieigen sources are inside yade sources. The only difference is that the content of visitor.hpp is a little different e.g. replace py::extract with py::cast, and so on. 6. I don't know how many changes have to be done in entire yade code to switch to pybind. 7. pybind is more strict about mapping types C++ ↔ python, for pybind float is really float. For boost::python all three: float, double, long double were (partially without consistency) treated as double. for pybind a duplicate registration of an already registered type is a fatal error. I understand that minieigen-src has no chance of getting into 20.04. I conclude that we should put minieigen inside yade. If that will be a boost::python version or a pybind version is yet to be decided. best regards Janek Anton Gladky said: (by the date of Sat, 22 Feb 2020 20:29:01 +0100) > Hello Janek, > > sorry for delays, "real" life is taking much more time when we get older :) > > > * I would rather avoid pybind11 switch in a rush, better give it a few > > months > > Maybe I was not clear, pybind11 is just a possible option. If we > really decide to switch to it, we need to evaluate, whether it is > suitable for us, whether it really helps to improve compilation times > and what it costs for us (time). > > > * I would prefer minieigen-src package (no extra compilation time for > > people who use `double`) > > * minieigen-src in ubuntu 20.04 will let more people to test & use high > > precision. > > Unfortunately, it is almost impossible for the time being. If I add a > new "minieigen-src" binary package, the package should go through > "NEW"-queue [1], which has almost 300 packages, waiting for review > from Debian FTP-masters. It can delay upload for months. > > We should probably consider alternative ways to help you to integrate > high-precision stuff. > > [1] https://ftp-master.debian.org/new.html > > Best regards > > Anton > > Am Fr., 21. Feb. 2020 um 22:30 Uhr schrieb Janek Kozicki (yade) > > : > > > > Hi Anton, > > > > Yes, the number of defines in Serialization.hpp is crazy. > > Changing/removing them to use pybind11 would take a lot of work. > > I'm sure it is possible, but not quickly. > > > > We can open an issue about pybind11 switch. Discuss pros and cons, > > find a good strategy to deal with crazy defines and complete it later. > > > > Doing this switch right now is unrealistic. Working on another moving > > target (pybind11) on top of an already moving target (minieigen HP > > not fully integrated) is irresponsible. If possible I would prefer: > > > > * minieigen-src package (slower compilation only for non-double) > > * or integrate minieigen with yade sources for now (rather undesirable > > due to compilation time). &g
Re: [Yade-dev] High precision Real and minieigen
OK, I will experiment a bit and see what it takes to switch to pybind11. Janek Janek Kozicki (yade) said: (by the date of Fri, 21 Feb 2020 22:30:04 +0100) > Hi Anton, > > Yes, the number of defines in Serialization.hpp is crazy. > Changing/removing them to use pybind11 would take a lot of work. > I'm sure it is possible, but not quickly. > > We can open an issue about pybind11 switch. Discuss pros and cons, > find a good strategy to deal with crazy defines and complete it later. > > Doing this switch right now is unrealistic. Working on another moving > target (pybind11) on top of an already moving target (minieigen HP > not fully integrated) is irresponsible. If possible I would prefer: > > * minieigen-src package (slower compilation only for non-double) > * or integrate minieigen with yade sources for now (rather undesirable > due to compilation time). > > Whatever we do I would prefer to integrate HP, because doubles will > appear very quickly in the code. > > Ah, if we talked about pybind11 switch three months ago it would be > perfect timing for me :( In fact I was thinking about it that time, > but I didn't want to push into something that wasn't guaranteed to be > working [*]. Figuring out the correct way to convert high precision > to/from python with boost was difficult, for a while I prefer to not > repeat this task with pybind11. But surely we can get back to this > later. > > The extra time for compilation happens only when non-double type is used. > If minieigen-src package gets to 20.04 it will be possible later for > people to compile high precision yade from gitlab sources without big hassle. > > The build_focal_simple [1] is 5 minutes because it's not parallelized. > The problem is that pybuild is not accepting -j argument. > With make -j 6 it is faster [2][3]. > > Also a fast quad_double (62 decimal places, package libqd-dev) > integration is in the works with boost::multiprecision developers [4]. > > To summarize: > > * I would rather avoid pybind11 switch in a rush, better give it a few months > * I would prefer minieigen-src package (no extra compilation time for people > who use `double`) > * minieigen-src in ubuntu 20.04 will let more people to test & use high > precision. > > I understand that this solution is temporary until we figure a > proper way to deal with pybind11. The 4 year LTS is more than enough > to solve pybind11 + Serialization.hpp problem. > > It is better to finish HP integration to not lose what is already > working. > > best regards > Janek > > > [*] pybind11 is a new dependency and a new package, boost is well > integrated with itself, it was guaranteed to work. > > [1] https://gitlab.com/yade-dev/minieigen/-/jobs/444927466 > > [2] https://gitlab.com/cosurgi/minieigen-real/pipelines/118211208 - I used > this to test HP > > [3] In the pipeline with ccache it's usually not a problem. On > debian build servers: it won't be a problem until we decide to > make yade-float128 package. But if we made an accompanying > minieigen-float128 this problem would disappear. But pybind11 > alternative is good also, just unrealistic right now. > > [4] https://github.com/boostorg/multiprecision/issues/184 > > > Anton Gladky said: (by the date of Fri, 21 Feb 2020 20:09:07 +0100) > > > Hi Janek, > > > > we have misunderstanding here. python3-minieigen is the __binary__ > > package and it is a bad idea to ship the source code with the package. > > > > Adding minieigen-src binary package is possible, but it looks like very > > undesired way. > > > > As I see, only Yade is using minieigen in the Debian. So, theoretically we > > can merge it again with Yade. Not sure, whether it is a good way though > > Yade compiles too slow. Minieigen adds definitely 4-5 compilation minutes > > and Gigabytes of used RAM. > > > > We should really have a look at pybind11 alternative, if it accelerates the > > compilation. But when I see Serialization.hpp, I am getting 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 h
Re: [Yade-dev] High precision Real and minieigen
Hi Anton, Yes, the number of defines in Serialization.hpp is crazy. Changing/removing them to use pybind11 would take a lot of work. I'm sure it is possible, but not quickly. We can open an issue about pybind11 switch. Discuss pros and cons, find a good strategy to deal with crazy defines and complete it later. Doing this switch right now is unrealistic. Working on another moving target (pybind11) on top of an already moving target (minieigen HP not fully integrated) is irresponsible. If possible I would prefer: * minieigen-src package (slower compilation only for non-double) * or integrate minieigen with yade sources for now (rather undesirable due to compilation time). Whatever we do I would prefer to integrate HP, because doubles will appear very quickly in the code. Ah, if we talked about pybind11 switch three months ago it would be perfect timing for me :( In fact I was thinking about it that time, but I didn't want to push into something that wasn't guaranteed to be working [*]. Figuring out the correct way to convert high precision to/from python with boost was difficult, for a while I prefer to not repeat this task with pybind11. But surely we can get back to this later. The extra time for compilation happens only when non-double type is used. If minieigen-src package gets to 20.04 it will be possible later for people to compile high precision yade from gitlab sources without big hassle. The build_focal_simple [1] is 5 minutes because it's not parallelized. The problem is that pybuild is not accepting -j argument. With make -j 6 it is faster [2][3]. Also a fast quad_double (62 decimal places, package libqd-dev) integration is in the works with boost::multiprecision developers [4]. To summarize: * I would rather avoid pybind11 switch in a rush, better give it a few months * I would prefer minieigen-src package (no extra compilation time for people who use `double`) * minieigen-src in ubuntu 20.04 will let more people to test & use high precision. I understand that this solution is temporary until we figure a proper way to deal with pybind11. The 4 year LTS is more than enough to solve pybind11 + Serialization.hpp problem. It is better to finish HP integration to not lose what is already working. best regards Janek [*] pybind11 is a new dependency and a new package, boost is well integrated with itself, it was guaranteed to work. [1] https://gitlab.com/yade-dev/minieigen/-/jobs/444927466 [2] https://gitlab.com/cosurgi/minieigen-real/pipelines/118211208 - I used this to test HP [3] In the pipeline with ccache it's usually not a problem. On debian build servers: it won't be a problem until we decide to make yade-float128 package. But if we made an accompanying minieigen-float128 this problem would disappear. But pybind11 alternative is good also, just unrealistic right now. [4] https://github.com/boostorg/multiprecision/issues/184 Anton Gladky said: (by the date of Fri, 21 Feb 2020 20:09:07 +0100) > Hi Janek, > > we have misunderstanding here. python3-minieigen is the __binary__ > package and it is a bad idea to ship the source code with the package. > > Adding minieigen-src binary package is possible, but it looks like very > undesired way. > > As I see, only Yade is using minieigen in the Debian. So, theoretically we > can merge it again with Yade. Not sure, whether it is a good way though > Yade compiles too slow. Minieigen adds definitely 4-5 compilation minutes > and Gigabytes of used RAM. > > We should really have a look at pybind11 alternative, if it accelerates the > compilation. But when I see Serialization.hpp, I am getting 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 Kozick
Re: [Yade-dev] High precision Real and minieigen
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 [1] https://gitlab.com/yade-dev/trunk/-/blob/master/py/high-precision/_ExposeMatrices.cpp Anton Gladky said: (by the date of Thu, 20 Feb 2020 20:17:25 +0100) > Hi Janek, > > I habe 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) src/*pp usr/include/minieigen/ ___ Mailing list: https://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
Anton did you remember about `./debian/python3-minieigen.install` file with content: src/*pp usr/include/minieigen/ ? It is not a part of upstream repository. I guess It's part of packaging process. At least that's how I understand it. Without sources in /usr/include/minieigen/ yade high precision is not going to compile. best regards Janek Janek Kozicki (yade) said: (by the date of Thu, 20 Feb 2020 21:57:54 +0100) > 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 (yade) said: (by the date of Mon, 17 Feb 2020 13:18:42 +0100) > Hi, > > Vaclav has accepted my pull request to minieigen. The macro name is > now `_HIGH_PRECISION_SUPPORT`, instead of `MINIEIGEN_OVERRIDE`. > I will update the code. > > Anton, what are the perspectives of updating debian/ubuntu package? > > Please remember about `python3-minieigen.install` file with content: > >src/*pp usr/include/minieigen/ > > it is not part of [2], but belongs to packaging process. > > Vaclav suggests that we make minieigen a part of yade build. > Personally I like the fact that it is a separate pacakge. However > maybe we need to think about forking it into gitlab [3] as a fourth > repository (we have yadedaily, docker-yade, trunk). And change the > upstream for minieigen package. > > I don't expect more changes in minieigen. It all works now. However > some code from py/wrapper/customConverters.cpp could be safely moved > there. So moving minieigen to yade-dev would allow some more cleanup. > > best regards > Janek > > [1] https://github.com/eudoxos/minieigen/pull/24 > [2] https://github.com/eudoxos/minieigen > [3] https://gitlab.com/yade-dev -- -- 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] High precision Real and minieigen
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) ___ Mailing list: https://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
I have asked Vaclav to transfer maintenance of miniEigen to us: https://github.com/eudoxos/minieigen/pull/26 cheers Janek Anton Gladky said: (by the date of Tue, 18 Feb 2020 20:22:31 +0100) > Hi Janek, > > if Vaclav is not against it, I agree to move the miniegen back to > Yade community, create yade/minieigen, release new version and > upload it to Debian. > > If we want to get a newer version in Ubuntu 20.04, it should be done > as soon as possible. > Automatic merge window is closing on 27.02. > > PS Also yade/yadedaily can be removed. I have no enough permissions to do it. > > Regards > > Anton > > Am Mo., 17. Feb. 2020 um 13:18 Uhr schrieb Janek Kozicki (yade) > : > > > > Hi, > > > > Vaclav has accepted my pull request to minieigen. The macro name is > > now `_HIGH_PRECISION_SUPPORT`, instead of `MINIEIGEN_OVERRIDE`. > > I will update the code. > > > > Anton, what are the perspectives of updating debian/ubuntu package? > > > > Please remember about `python3-minieigen.install` file with content: > > > >src/*pp usr/include/minieigen/ > > > > it is not part of [2], but belongs to packaging process. > > > > Vaclav suggests that we make minieigen a part of yade build. > > Personally I like the fact that it is a separate pacakge. However > > maybe we need to think about forking it into gitlab [3] as a fourth > > repository (we have yadedaily, docker-yade, trunk). And change the > > upstream for minieigen package. > > > > I don't expect more changes in minieigen. It all works now. However > > some code from py/wrapper/customConverters.cpp could be safely moved > > there. So moving minieigen to yade-dev would allow some more cleanup. > > > > best regards > > Janek > > > > [1] https://github.com/eudoxos/minieigen/pull/24 > > [2] https://github.com/eudoxos/minieigen > > [3] https://gitlab.com/yade-dev > > > > Janek Kozicki (yade) said: (by the date of Mon, 3 Feb 2020 15:48:19 > > +0100) > > > > > In the attachment are the minimal minieigen patches: > > > > > > These are the super-minimal necessary patches: > > > > > > 1. 50_fix_minieigen_agnostic_to_Real.patch > > > 2. 52_fix_convertible_Scalar_types.patch > > > 3. python3-minieigen.install > > > > > > This one is not strictly necessary. It's just a bugfix. The Vector4r > > > was broken, because 4th argument to the constructor was missing: > > > > > > 4. 51_fix_Vector4r.patch > > > > > > Sorry for the mixed numbering of patches, I preferred to keep the > > > original (old) patch numbers. > > > > > > > > > I am nicely surprised that these patches turned out to be so small. > > > I just learned that when compiling with #included external library > > > files the 'unused variable' warning is muted by g++. And so the > > > largest patch is not necessary. Other patches which I had here > > > initially were concerning the fixes of AlignedVector3. But for now we > > > don't use it. We have make_SSE vectorization in [4] without it. > > > > > > > > > I am really sorry for the delay. I wanted to be 100% sure that all > > > pipelines pass. (there were some problems with the build servers). > > > > > > Anton, can you apply these patches to the minieigen package? > > > > > > > > > In a couple of days I should also submit a merge request to minieigen > > > upstream. > > > > > > The latest pipeline [1] passes with a super-minimal set of patches [2][3]. > > > > > > The MR 383 [1] can be merged after all the others are merged. It will > > > then have only couple of commits. Also then I will rearrange the > > > pipeline a bit, so that there are fewer asan tests, but they will be > > > rotating. > > > Currently they use [5] 'debian-bullseye-SMALLEST-PATCH-minieigen' build > > > image. > > > > > > best regards > > > Janek > > > > > > > > > [1] https://gitlab.com/yade-dev/trunk/-/merge_requests/383/pipelines > > > [2] > > > https://gitlab.com/yade-dev/docker-yade/commit/a3accab668a4896bff4e5ec1fdf0df6b741d638c > > > [3] > > > https://gitlab.com/yade-dev/trunk/-/merge_requests/383/diffs?commit_id=fff0dc8fda163d57f8816e61201660cd3b6a0a38 > > > [4] https://gitlab.com/yade-dev/trunk/-/merge_requests/362 > > > [5] https://gitlab.com/yade-dev/docker-yade/container_registry > > > > > > Janek Koz
Re: [Yade-dev] High precision Real and minieigen
Hi, Vaclav has accepted my pull request to minieigen. The macro name is now `_HIGH_PRECISION_SUPPORT`, instead of `MINIEIGEN_OVERRIDE`. I will update the code. Anton, what are the perspectives of updating debian/ubuntu package? Please remember about `python3-minieigen.install` file with content: src/*pp usr/include/minieigen/ it is not part of [2], but belongs to packaging process. Vaclav suggests that we make minieigen a part of yade build. Personally I like the fact that it is a separate pacakge. However maybe we need to think about forking it into gitlab [3] as a fourth repository (we have yadedaily, docker-yade, trunk). And change the upstream for minieigen package. I don't expect more changes in minieigen. It all works now. However some code from py/wrapper/customConverters.cpp could be safely moved there. So moving minieigen to yade-dev would allow some more cleanup. best regards Janek [1] https://github.com/eudoxos/minieigen/pull/24 [2] https://github.com/eudoxos/minieigen [3] https://gitlab.com/yade-dev Janek Kozicki (yade) said: (by the date of Mon, 3 Feb 2020 15:48:19 +0100) > In the attachment are the minimal minieigen patches: > > These are the super-minimal necessary patches: > > 1. 50_fix_minieigen_agnostic_to_Real.patch > 2. 52_fix_convertible_Scalar_types.patch > 3. python3-minieigen.install > > This one is not strictly necessary. It's just a bugfix. The Vector4r > was broken, because 4th argument to the constructor was missing: > > 4. 51_fix_Vector4r.patch > > Sorry for the mixed numbering of patches, I preferred to keep the > original (old) patch numbers. > > > I am nicely surprised that these patches turned out to be so small. > I just learned that when compiling with #included external library > files the 'unused variable' warning is muted by g++. And so the > largest patch is not necessary. Other patches which I had here > initially were concerning the fixes of AlignedVector3. But for now we > don't use it. We have make_SSE vectorization in [4] without it. > > > I am really sorry for the delay. I wanted to be 100% sure that all > pipelines pass. (there were some problems with the build servers). > > Anton, can you apply these patches to the minieigen package? > > > In a couple of days I should also submit a merge request to minieigen > upstream. > > The latest pipeline [1] passes with a super-minimal set of patches [2][3]. > > The MR 383 [1] can be merged after all the others are merged. It will > then have only couple of commits. Also then I will rearrange the > pipeline a bit, so that there are fewer asan tests, but they will be rotating. > Currently they use [5] 'debian-bullseye-SMALLEST-PATCH-minieigen' build image. > > best regards > Janek > > > [1] https://gitlab.com/yade-dev/trunk/-/merge_requests/383/pipelines > [2] > https://gitlab.com/yade-dev/docker-yade/commit/a3accab668a4896bff4e5ec1fdf0df6b741d638c > [3] > https://gitlab.com/yade-dev/trunk/-/merge_requests/383/diffs?commit_id=fff0dc8fda163d57f8816e61201660cd3b6a0a38 > [4] https://gitlab.com/yade-dev/trunk/-/merge_requests/362 > [5] https://gitlab.com/yade-dev/docker-yade/container_registry > > Janek Kozicki (yade) said: (by the date of Mon, 27 Jan 2020 21:38:09 > +0100) > > > Hi Anton, > > > > > Can we avoid it somehow? minieigen sources were in Yade tree many years > > > ago and we managed to drop them, introducing minieigen packages. > > > It would not be the best variant to put them in the source again. > > > > Another solution is that you will include these patches [1] in the debian > > and ubuntu package until Vaclav accepts my merge request (which I > > will prepare in two or three days). > > > > I will review these patches again to see if they can be made smaller > > than they currently are. And I will let you know by Wednesday evening. > > (tomorrow I have lectures and a meeting). > > > > Please note that file [2] installs the source files > > in /usr/include/minieigen, they are needed. And also that's why [3] > > is necessary. To partially avoid this we could work on preparing > > `long double` and `float128` versions of minieigen package. > > But for MPFR and boost::multiprecision::cpp_bin_float these sources are > > still necessary because the precision is specified during compilation. > > > > best regards > > Janek > > > > BTW: you have write access to [4] > > > > [1] https://gitlab.com/cosurgi/minieigen-real/tree/master/patches > > [2] > > https://gitlab.com/cosurgi/minieigen-real/blob/master/patches/python3-minieigen.install > > [3] > > https://gitlab.com/cosurgi/minieigen-real/blob/master/patches/
Re: [Yade-dev] [Bug 1862943] [NEW] failing autopkgtests with new boost1.71
Hi, we have moved to gitlab. The launchpad bugracker is not used. I have moved
this issue to: https://gitlab.com/yade-dev/trunk/issues/143
I tried to reproduce the error, and I have a lockup during doctests stage in
yade --test:
SpherePack_toSimulation (yade.pack)
Doctest: yade.pack.SpherePack_toSimulation ... ok
addAutoData (yade.plot)
Doctest: yade.plot.addAutoData ... ok
addData (yade.plot)
Doctest: yade.plot.addData ... ok
plot (yade.plot)
Doctest: yade.plot.plot ...
/usr/lib/python3/dist-packages/matplotlib/axes/_axes.py:4268:
MatplotlibDeprecationWarning:
The 'verts' kwarg was deprecated in Matplotlib 3.0 and will be removed in 3.2.
Use 'marker' instead.
cbook.warn_deprecated("3.0", name="'verts'", obj_type="kwarg",
Is the problem the same for you?
Dimitri John Ledkov said: (by the date of Wed, 12 Feb 2020 13:25:30 -)
> Public bug reported:
>
> failing autopkgtests with new boost1.71
>
> python3-defaults currently needs ceph to become a candidate which needs
> boost1.71 to become a candidate
>
> boost1.71 is blocked on:
>
> gyoto ppc64el
> hilive arm64
> yade arm64
>
> I am opening this bug report to triange / fix these, however meanwhile
> I'd like to request release team to mark these as badtest, such that
> migration of doom can happen.
>
> Also uploaded nochange rebuilds, in case they were missbuilt with broken
> binutils/toolchain we had for a bit in focal
>
> ** Affects: boost1.71 (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Affects: gyoto (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Affects: hilive (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Affects: yade (Ubuntu)
> Importance: Undecided
> Status: New
>
>
> ** Tags: update-excuse
>
> ** Also affects: yade (Ubuntu)
>Importance: Undecided
>Status: New
>
> ** Also affects: hilive (Ubuntu)
>Importance: Undecided
>Status: New
>
> ** Also affects: gyoto (Ubuntu)
>Importance: Undecided
>Status: New
>
> --
> You received this bug notification because you are a member of Yade
> developers, which is subscribed to yade in Ubuntu.
> https://bugs.launchpad.net/bugs/1862943
>
> Title:
> failing autopkgtests with new boost1.71
>
> Status in boost1.71 package in Ubuntu:
> New
> Status in gyoto package in Ubuntu:
> New
> Status in hilive package in Ubuntu:
> New
> Status in yade package in Ubuntu:
> New
>
> Bug description:
> failing autopkgtests with new boost1.71
>
> python3-defaults currently needs ceph to become a candidate which
> needs boost1.71 to become a candidate
>
> boost1.71 is blocked on:
>
> gyoto ppc64el
> hilive arm64
> yade arm64
>
> I am opening this bug report to triange / fix these, however meanwhile
> I'd like to request release team to mark these as badtest, such that
> migration of doom can happen.
>
> Also uploaded nochange rebuilds, in case they were missbuilt with
> broken binutils/toolchain we had for a bit in focal
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/boost1.71/+bug/1862943/+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
--
--
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] High precision Real. (minieigen patches)
In the attachment are the minimal minieigen patches: These are the super-minimal necessary patches: 1. 50_fix_minieigen_agnostic_to_Real.patch 2. 52_fix_convertible_Scalar_types.patch 3. python3-minieigen.install This one is not strictly necessary. It's just a bugfix. The Vector4r was broken, because 4th argument to the constructor was missing: 4. 51_fix_Vector4r.patch Sorry for the mixed numbering of patches, I preferred to keep the original (old) patch numbers. I am nicely surprised that these patches turned out to be so small. I just learned that when compiling with #included external library files the 'unused variable' warning is muted by g++. And so the largest patch is not necessary. Other patches which I had here initially were concerning the fixes of AlignedVector3. But for now we don't use it. We have make_SSE vectorization in [4] without it. I am really sorry for the delay. I wanted to be 100% sure that all pipelines pass. (there were some problems with the build servers). Anton, can you apply these patches to the minieigen package? In a couple of days I should also submit a merge request to minieigen upstream. The latest pipeline [1] passes with a super-minimal set of patches [2][3]. The MR 383 [1] can be merged after all the others are merged. It will then have only couple of commits. Also then I will rearrange the pipeline a bit, so that there are fewer asan tests, but they will be rotating. Currently they use [5] 'debian-bullseye-SMALLEST-PATCH-minieigen' build image. best regards Janek [1] https://gitlab.com/yade-dev/trunk/-/merge_requests/383/pipelines [2] https://gitlab.com/yade-dev/docker-yade/commit/a3accab668a4896bff4e5ec1fdf0df6b741d638c [3] https://gitlab.com/yade-dev/trunk/-/merge_requests/383/diffs?commit_id=fff0dc8fda163d57f8816e61201660cd3b6a0a38 [4] https://gitlab.com/yade-dev/trunk/-/merge_requests/362 [5] https://gitlab.com/yade-dev/docker-yade/container_registry Janek Kozicki (yade) said: (by the date of Mon, 27 Jan 2020 21:38:09 +0100) > Hi Anton, > > > Can we avoid it somehow? minieigen sources were in Yade tree many years > > ago and we managed to drop them, introducing minieigen packages. > > It would not be the best variant to put them in the source again. > > Another solution is that you will include these patches [1] in the debian > and ubuntu package until Vaclav accepts my merge request (which I > will prepare in two or three days). > > I will review these patches again to see if they can be made smaller > than they currently are. And I will let you know by Wednesday evening. > (tomorrow I have lectures and a meeting). > > Please note that file [2] installs the source files > in /usr/include/minieigen, they are needed. And also that's why [3] > is necessary. To partially avoid this we could work on preparing > `long double` and `float128` versions of minieigen package. > But for MPFR and boost::multiprecision::cpp_bin_float these sources are > still necessary because the precision is specified during compilation. > > best regards > Janek > > BTW: you have write access to [4] > > [1] https://gitlab.com/cosurgi/minieigen-real/tree/master/patches > [2] > https://gitlab.com/cosurgi/minieigen-real/blob/master/patches/python3-minieigen.install > [3] > https://gitlab.com/cosurgi/minieigen-real/blob/master/patches/54_fix_compilation_warnings.patch > [4] https://gitlab.com/cosurgi/minieigen-real > > > > > Anton Gladky said: (by the date of Mon, 27 Jan 2020 21:07:15 +0100) > > > Hi Janek, > > > > > BTW, Anton did you notice that building debian package fails on > > > master due to missing python-gts? > > > https://gitlab.com/yade-dev/trunk/issues/139 > > > > please review this MR [1]. It fixes build-dependency problem and also > > --help regression introduced with "--stdperformance" option. > > > > > And in meantime I will include minieigen sources in yade tree, just > > > like we did with python-gts. By this way it will work for everyone > > > without dependency hell, until the changes are in official minieigen > > > repository. > > > > Can we avoid it somehow? minieigen sources were in Yade tree many years > > ago and we managed to drop them, introducing minieigen packages. > > It would not be the best variant to put them in the source again. > > > > [1] https://gitlab.com/yade-dev/trunk/-/merge_requests/396 > > > > Regards > > > > Anton > > > > Am Mo., 27. Jan. 2020 um 16:26 Uhr schrieb Janek Kozicki (yade) > > : > > > > > > Anton Gladky said: (by the date of Thu, 23 Jan 2020 06:44:02) > > > > > > > I do really appreciate this kind of work! > > > > But how can we
Re: [Yade-dev] High precision Real.
Hi Anton, > Can we avoid it somehow? minieigen sources were in Yade tree many years > ago and we managed to drop them, introducing minieigen packages. > It would not be the best variant to put them in the source again. Another solution is that you will include these patches [1] in the debian and ubuntu package until Vaclav accepts my merge request (which I will prepare in two or three days). I will review these patches again to see if they can be made smaller than they currently are. And I will let you know by Wednesday evening. (tomorrow I have lectures and a meeting). Please note that file [2] installs the source files in /usr/include/minieigen, they are needed. And also that's why [3] is necessary. To partially avoid this we could work on preparing `long double` and `float128` versions of minieigen package. But for MPFR and boost::multiprecision::cpp_bin_float these sources are still necessary because the precision is specified during compilation. best regards Janek BTW: you have write access to [4] [1] https://gitlab.com/cosurgi/minieigen-real/tree/master/patches [2] https://gitlab.com/cosurgi/minieigen-real/blob/master/patches/python3-minieigen.install [3] https://gitlab.com/cosurgi/minieigen-real/blob/master/patches/54_fix_compilation_warnings.patch [4] https://gitlab.com/cosurgi/minieigen-real Anton Gladky said: (by the date of Mon, 27 Jan 2020 21:07:15 +0100) > Hi Janek, > > > BTW, Anton did you notice that building debian package fails on > > master due to missing python-gts? > > https://gitlab.com/yade-dev/trunk/issues/139 > > please review this MR [1]. It fixes build-dependency problem and also > --help regression introduced with "--stdperformance" option. > > > And in meantime I will include minieigen sources in yade tree, just > > like we did with python-gts. By this way it will work for everyone > > without dependency hell, until the changes are in official minieigen > > repository. > > Can we avoid it somehow? minieigen sources were in Yade tree many years > ago and we managed to drop them, introducing minieigen packages. > It would not be the best variant to put them in the source again. > > [1] https://gitlab.com/yade-dev/trunk/-/merge_requests/396 > > Regards > > Anton > > Am Mo., 27. Jan. 2020 um 16:26 Uhr schrieb Janek Kozicki (yade) > : > > > > Anton Gladky said: (by the date of Thu, 23 Jan 2020 06:44:02) > > > > > I do really appreciate this kind of work! > > > But how can we rely on custom builds of the third party software? > > > Sorry, but this restriction will get Yade into the dependency hell. > > > > Yes, I completely agree with this premise. I will prepare merge > > request for Vaclav in https://github.com/eudoxos/minieigen > > > > And in meantime I will include minieigen sources in yade tree, just > > like we did with python-gts. By this way it will work for everyone > > without dependency hell, until the changes are in official minieigen > > repository. > > > > thanks a lot for your work. > > > > best regards > > Janek > > > > BTW, Anton did you notice that building debian package fails on > > master due to missing python-gts? > > https://gitlab.com/yade-dev/trunk/issues/139 > > > > > > Janek Kozicki (yade) said: (by the date of Mon, 13 Jan 2020 22:34:25 > > +0100) > > > > > Hi, the code for high precision is complete and passes all the tests. > > > > > > I am writing documentation for this now, I will mention there: > > > - about VTK ↔ double compatibility > > > - about GLViewer ↔ double compatibility > > > - how to build and run high precision code > > > > > > I have separated most of this work in to several "topic" merge > > > requests, so that you can check each of them separately. The general > > > idea is that "if you don't use high-precision then the old behavior > > > remains". Meaning that I avoid modifying existing code, only add some > > > sort of redirection and conversion layer that vanishes (is optimized > > > away) completely when HP is not used. > > > > > > There are some changes still not extracted into separate merge > > > requests from !366. I will continue working on this and writing > > > documentation. > > > > > > These are ready for you to review: > > > > > > * The last remaining double to Real changes. > > > https://gitlab.com/yade-dev/trunk/merge_requests/376 > > > > > > * Print time spent on each of the --checks > > > https://gitlab.com/yade-dev/trunk/merge_requests/37
Re: [Yade-dev] High precision Real.
Anton Gladky said: (by the date of Thu, 23 Jan 2020 06:44:02) > I do really appreciate this kind of work! > But how can we rely on custom builds of the third party software? > Sorry, but this restriction will get Yade into the dependency hell. Yes, I completely agree with this premise. I will prepare merge request for Vaclav in https://github.com/eudoxos/minieigen And in meantime I will include minieigen sources in yade tree, just like we did with python-gts. By this way it will work for everyone without dependency hell, until the changes are in official minieigen repository. thanks a lot for your work. best regards Janek BTW, Anton did you notice that building debian package fails on master due to missing python-gts? https://gitlab.com/yade-dev/trunk/issues/139 Janek Kozicki (yade) said: (by the date of Mon, 13 Jan 2020 22:34:25 +0100) > Hi, the code for high precision is complete and passes all the tests. > > I am writing documentation for this now, I will mention there: > - about VTK ↔ double compatibility > - about GLViewer ↔ double compatibility > - how to build and run high precision code > > I have separated most of this work in to several "topic" merge > requests, so that you can check each of them separately. The general > idea is that "if you don't use high-precision then the old behavior > remains". Meaning that I avoid modifying existing code, only add some > sort of redirection and conversion layer that vanishes (is optimized > away) completely when HP is not used. > > There are some changes still not extracted into separate merge > requests from !366. I will continue working on this and writing documentation. > > These are ready for you to review: > > * The last remaining double to Real changes. > https://gitlab.com/yade-dev/trunk/merge_requests/376 > > * Print time spent on each of the --checks > https://gitlab.com/yade-dev/trunk/merge_requests/375 > (a very short one, that's because I needed to make Lubrication tests faster > in !366) > > * Ensure that VTK is compatibile with Real. > https://gitlab.com/yade-dev/trunk/merge_requests/377 > > * OpenGL Real compatibility > https://gitlab.com/yade-dev/trunk/merge_requests/378 > > * Another step towards enabling high precision Real > https://gitlab.com/yade-dev/trunk/merge_requests/362 > > * Enable vectorization > https://gitlab.com/yade-dev/trunk/merge_requests/365 > > They can be merged to master in any order. If any rebase conflicts > arise I will solve them quickly. Maybe !362 and !365 should be merged last, > because I tested rebasing it on each of the previous ones. > > > please tell me what you think. > > 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
[Yade-dev] High precision Real.
Hi, the code for high precision is complete and passes all the tests. I am writing documentation for this now, I will mention there: - about VTK ↔ double compatibility - about GLViewer ↔ double compatibility - how to build and run high precision code I have separated most of this work in to several "topic" merge requests, so that you can check each of them separately. The general idea is that "if you don't use high-precision then the old behavior remains". Meaning that I avoid modifying existing code, only add some sort of redirection and conversion layer that vanishes (is optimized away) completely when HP is not used. There are some changes still not extracted into separate merge requests from !366. I will continue working on this and writing documentation. These are ready for you to review: * The last remaining double to Real changes. https://gitlab.com/yade-dev/trunk/merge_requests/376 * Print time spent on each of the --checks https://gitlab.com/yade-dev/trunk/merge_requests/375 (a very short one, that's because I needed to make Lubrication tests faster in !366) * Ensure that VTK is compatibile with Real. https://gitlab.com/yade-dev/trunk/merge_requests/377 * OpenGL Real compatibility https://gitlab.com/yade-dev/trunk/merge_requests/378 * Another step towards enabling high precision Real https://gitlab.com/yade-dev/trunk/merge_requests/362 * Enable vectorization https://gitlab.com/yade-dev/trunk/merge_requests/365 They can be merged to master in any order. If any rebase conflicts arise I will solve them quickly. Maybe !362 and !365 should be merged last, because I tested rebasing it on each of the previous ones. please tell me what you think. 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
Re: [Yade-dev] New yade release is planned for Jan 2020
If you encounter some build problems after submitting a package please let us know. Anton Gladky said: (by the date of Wed, 8 Jan 2020 06:47:27 +0100) > Hello, > > would you be able to finish till the end of this week? > > Yade is currently not in Debian testing, so we are in risk not to get it > to the Ubuntu 20.04. > > Regards > > Anton > > > > > On Tue, Jan 7, 2020, 21:30 Deepak Kn wrote: > > > Hello, > > Thank you very much, I have modified some of the parts in the openfoam > > coupling and I'm currently validating it and updating the documentation. > > Can we fix a date, say : 13th Jan (coming monday ? ) > > > > On Tue, Jan 7, 2020 at 12:53 PM Janek Kozicki (yade) < > > jkozicki-y...@pg.edu.pl> wrote: > > > >> This is great. Thank you very much for your hard work! > >> > >> > >> Anton Gladky said: (by the date of Mon, 6 Jan 2020 21:04:35 +0100) > >> > >> > Dear Yade developers, > >> > > >> > I am starting to tag the new release. It happens within the next few > >> days. > >> > > >> > Regards > >> > > >> > Anton > >> > > >> > Am Di., 10. Dez. 2019 um 12:55 Uhr schrieb 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 > >> > > >> > _______ > >> > Mailing list: https://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 > > -- -- 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] New yade release is planned for Jan 2020
This is great. Thank you very much for your hard work! Anton Gladky said: (by the date of Mon, 6 Jan 2020 21:04:35 +0100) > Dear Yade developers, > > I am starting to tag the new release. It happens within the next few days. > > Regards > > Anton > > Am Di., 10. Dez. 2019 um 12:55 Uhr schrieb 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 > > ___ > Mailing list: https://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
Re: [Yade-dev] Regarding the YADE current website
Dear Pranjal, we are currently having some problems with this server. Before it is fixed you can use documentation locally, by installing yade-doc package. Or by browsing an online backup on gitlab: https://yade-dev.gitlab.io/-/trunk/-/jobs/394371575/artifacts/public/index.html best regards Janek pranjal mandhaniya said: (by the date of Mon, 6 Jan 2020 03:49:58 +0530) > Respected sir, > I am trying to get to work in YADE for DEM but the website > <https://yade-dem.org/doc/Yade.pdf> is not working. > Please help me and tell me if you have also shifted the webserver. > Please update the description in Gitlab page if so. -- -- 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] new bullseye image - problems building master, CGAL disabled.
I started https://gitlab.com/yade-dev/trunk/merge_requests/368 to try to fix this problem with CGAL. Janek Kozicki (yade) said: (by the date of Thu, 2 Jan 2020 21:45:29 +0100) > Thanks for fixing this. Now I see another problem: > > CGAL is disabled on bullseye. > > see: https://gitlab.com/yade-dev/trunk/-/jobs/392544413 > > also, building deb_bullseye package is not working. But I'm sure you have > noticed that: > > https://gitlab.com/yade-dev/trunk/-/jobs/39258 > > > > > Anton Gladky said: (by the date of Wed, 1 Jan 2020 19:55:33 +0100) > > > We can temporarily try to switch to debian:sid, where this > > problem is probably fixed a couple of days ago. > > > > Anton > > > > Am Di., 31. Dez. 2019 um 23:38 Uhr schrieb Janek Kozicki (yade) > > : > > > > > > Maybe I should patch our bullseye image with your patch? > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=946481;filename=python3.8.patch;msg=5 > > > > > > > > > > > > Anton Gladky said: (by the date of Tue, 31 Dec 2019 15:35:16 +0100) > > > > > > > This is ipython problem. > > > > > > > > On Tue, Dec 31, 2019, 13:46 Janek Kozicki (yade) > > > > > > > > wrote: > > > > > > > > > It seems that now we have the same doc building problem as before: > > > > > > > > > > https://gitlab.com/yade-dev/trunk/-/jobs/391247986 > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 > > > > > 14:28:17 > > > > > +0100) > > > > > > > > > > > Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 > > > > > > 14:00:50 > > > > > +0100) > > > > > > > > > > > > > Regarding the version numbers I made an MR which workarounds the > > > > > problem: > > > > > > > > > > > > > > https://gitlab.com/yade-dev/trunk/merge_requests/367 > > > > > > > > > > > > > > I am not sure if that's the correct way to go. Isn't there > > > > > > > something > > > > > > > wrong with bullseye python versions right now? > > > > > > > > > > > > > > > > > > If the rest is working, then perhaps that test was a bit too > > > > > > restrictive before. > > > > > > > > > > > > > > > > > > > > > > > > > > This is the history of the pipelines for last commit in master: > > > > > > > > > > > > > > > > > > > https://gitlab.com/yade-dev/trunk/commit/0b6b10845892801b0893be211e011bdc1707f8cd/pipelines?ref=master > > > > > > > > > > > > > > We can see when it stopped working. > > > > > > > > > > > > > > Interestingly the libCGAL problem seems to disappear for now? > > > > > > > > > > > > > > best regards > > > > > > > Janek > > > > > > > > > > > > > > > > > > > > > > > > > > > > Janek Kozicki (yade) said: (by the date of Sun, 29 Dec 2019 > > > > > 20:41:59 +0100) > > > > > > > > > > > > > > > I just noticed following problems after new bullseye image has > > > > > > > > been > > > > > built: > > > > > > > > > > > > > > > > ImportError: libCGAL.so.13: cannot open shared object file: No > > > > > > > > such > > > > > > > > file or directory > > > > >
Re: [Yade-dev] new bullseye image - problems building master, CGAL disabled.
Thanks for fixing this. Now I see another problem: CGAL is disabled on bullseye. see: https://gitlab.com/yade-dev/trunk/-/jobs/392544413 also, building deb_bullseye package is not working. But I'm sure you have noticed that: https://gitlab.com/yade-dev/trunk/-/jobs/39258 Anton Gladky said: (by the date of Wed, 1 Jan 2020 19:55:33 +0100) > We can temporarily try to switch to debian:sid, where this > problem is probably fixed a couple of days ago. > > Anton > > Am Di., 31. Dez. 2019 um 23:38 Uhr schrieb Janek Kozicki (yade) > : > > > > Maybe I should patch our bullseye image with your patch? > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=946481;filename=python3.8.patch;msg=5 > > > > > > > > Anton Gladky said: (by the date of Tue, 31 Dec 2019 15:35:16 +0100) > > > > > This is ipython problem. > > > > > > On Tue, Dec 31, 2019, 13:46 Janek Kozicki (yade) > > > wrote: > > > > > > > It seems that now we have the same doc building problem as before: > > > > > > > > https://gitlab.com/yade-dev/trunk/-/jobs/391247986 > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 14:28:17 > > > > +0100) > > > > > > > > > Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 > > > > > 14:00:50 > > > > +0100) > > > > > > > > > > > Regarding the version numbers I made an MR which workarounds the > > > > problem: > > > > > > > > > > > > https://gitlab.com/yade-dev/trunk/merge_requests/367 > > > > > > > > > > > > I am not sure if that's the correct way to go. Isn't there something > > > > > > wrong with bullseye python versions right now? > > > > > > > > > > > > > > > If the rest is working, then perhaps that test was a bit too > > > > > restrictive before. > > > > > > > > > > > > > > > > > > > > > > This is the history of the pipelines for last commit in master: > > > > > > > > > > > > > > > > https://gitlab.com/yade-dev/trunk/commit/0b6b10845892801b0893be211e011bdc1707f8cd/pipelines?ref=master > > > > > > > > > > > > We can see when it stopped working. > > > > > > > > > > > > Interestingly the libCGAL problem seems to disappear for now? > > > > > > > > > > > > best regards > > > > > > Janek > > > > > > > > > > > > > > > > > > > > > > > > Janek Kozicki (yade) said: (by the date of Sun, 29 Dec 2019 > > > > 20:41:59 +0100) > > > > > > > > > > > > > I just noticed following problems after new bullseye image has > > > > > > > been > > > > built: > > > > > > > > > > > > > > ImportError: libCGAL.so.13: cannot open shared object file: No > > > > > > > such > > > > > > > file or directory > > > > > > > > > > > > > > > > > > > > > > > > > > > > Image was built 14h ago: > > > > > > > container registry: > > > > https://gitlab.com/yade-dev/docker-yade/container_registry > > > > > > > > > > > > > > > > > > > > > Also in the pipeline in one of my MRs I found: > > > > > > > > > > > > > > python version reported by by cmake is [(3, 8, 0), '3.8'] and by > > > > > > > C++ is [(3, 7, 5), '3.7.5'] > > > > > > > > > > > > > > We can workaround this one, but is this intended behavior? > > > >
Re: [Yade-dev] new bullseye image - problems building master, again Doc building problem.
Maybe I should patch our bullseye image with your patch? https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=946481;filename=python3.8.patch;msg=5 Anton Gladky said: (by the date of Tue, 31 Dec 2019 15:35:16 +0100) > This is ipython problem. > > On Tue, Dec 31, 2019, 13:46 Janek Kozicki (yade) > wrote: > > > It seems that now we have the same doc building problem as before: > > > > https://gitlab.com/yade-dev/trunk/-/jobs/391247986 > > > > 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 > > > > > > > > > > > > > > > > > > Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 14:28:17 > > +0100) > > > > > Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 14:00:50 > > +0100) > > > > > > > Regarding the version numbers I made an MR which workarounds the > > problem: > > > > > > > > https://gitlab.com/yade-dev/trunk/merge_requests/367 > > > > > > > > I am not sure if that's the correct way to go. Isn't there something > > > > wrong with bullseye python versions right now? > > > > > > > > > If the rest is working, then perhaps that test was a bit too > > > restrictive before. > > > > > > > > > > > > > > This is the history of the pipelines for last commit in master: > > > > > > > > > > https://gitlab.com/yade-dev/trunk/commit/0b6b10845892801b0893be211e011bdc1707f8cd/pipelines?ref=master > > > > > > > > We can see when it stopped working. > > > > > > > > Interestingly the libCGAL problem seems to disappear for now? > > > > > > > > best regards > > > > Janek > > > > > > > > > > > > > > > > Janek Kozicki (yade) said: (by the date of Sun, 29 Dec 2019 > > 20:41:59 +0100) > > > > > > > > > I just noticed following problems after new bullseye image has been > > built: > > > > > > > > > > ImportError: libCGAL.so.13: cannot open shared object file: No such > > > > > file or directory > > > > > > > > > > > > > > > > > > > > Image was built 14h ago: > > > > > container registry: > > https://gitlab.com/yade-dev/docker-yade/container_registry > > > > > > > > > > > > > > > Also in the pipeline in one of my MRs I found: > > > > > > > > > > python version reported by by cmake is [(3, 8, 0), '3.8'] and by > > > > > C++ is [(3, 7, 5), '3.7.5'] > > > > > > > > > > We can workaround this one, but is this intended behavior? > > > > > > > > > > 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) > > > > > > > > __
Re: [Yade-dev] new bullseye image - problems building master, again Doc building problem.
It seems that now we have the same doc building problem as before: https://gitlab.com/yade-dev/trunk/-/jobs/391247986 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 Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 14:28:17 +0100) > Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 14:00:50 > +0100) > > > Regarding the version numbers I made an MR which workarounds the problem: > > > > https://gitlab.com/yade-dev/trunk/merge_requests/367 > > > > I am not sure if that's the correct way to go. Isn't there something > > wrong with bullseye python versions right now? > > > If the rest is working, then perhaps that test was a bit too > restrictive before. > > > > > > This is the history of the pipelines for last commit in master: > > > > https://gitlab.com/yade-dev/trunk/commit/0b6b10845892801b0893be211e011bdc1707f8cd/pipelines?ref=master > > > > We can see when it stopped working. > > > > Interestingly the libCGAL problem seems to disappear for now? > > > > best regards > > Janek > > > > > > > > Janek Kozicki (yade) said: (by the date of Sun, 29 Dec 2019 20:41:59 > > +0100) > > > > > I just noticed following problems after new bullseye image has been built: > > > > > > ImportError: libCGAL.so.13: cannot open shared object file: No such > > > file or directory > > > > > > > > > > > > Image was built 14h ago: > > > container registry: > > > https://gitlab.com/yade-dev/docker-yade/container_registry > > > > > > > > > Also in the pipeline in one of my MRs I found: > > > > > > python version reported by by cmake is [(3, 8, 0), '3.8'] and by > > > C++ is [(3, 7, 5), '3.7.5'] > > > > > > We can workaround this one, but is this intended behavior? > > > > > > 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 > > > -- > -- > 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
Re: [Yade-dev] new bullseye image - problems building master
Janek Kozicki (yade) said: (by the date of Mon, 30 Dec 2019 14:00:50 +0100) > Regarding the version numbers I made an MR which workarounds the problem: > > https://gitlab.com/yade-dev/trunk/merge_requests/367 > > I am not sure if that's the correct way to go. Isn't there something > wrong with bullseye python versions right now? If the rest is working, then perhaps that test was a bit too restrictive before. > > This is the history of the pipelines for last commit in master: > > https://gitlab.com/yade-dev/trunk/commit/0b6b10845892801b0893be211e011bdc1707f8cd/pipelines?ref=master > > We can see when it stopped working. > > Interestingly the libCGAL problem seems to disappear for now? > > best regards > Janek > > > > Janek Kozicki (yade) said: (by the date of Sun, 29 Dec 2019 20:41:59 > +0100) > > > I just noticed following problems after new bullseye image has been built: > > > > ImportError: libCGAL.so.13: cannot open shared object file: No such > > file or directory > > > > > > > > Image was built 14h ago: > > container registry: > > https://gitlab.com/yade-dev/docker-yade/container_registry > > > > > > Also in the pipeline in one of my MRs I found: > > > > python version reported by by cmake is [(3, 8, 0), '3.8'] and by > > C++ is [(3, 7, 5), '3.7.5'] > > > > We can workaround this one, but is this intended behavior? > > > > 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 -- -- 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] new bullseye image - problems building master
Regarding the version numbers I made an MR which workarounds the problem: https://gitlab.com/yade-dev/trunk/merge_requests/367 I am not sure if that's the correct way to go. Isn't there something wrong with bullseye python versions right now? This is the history of the pipelines for last commit in master: https://gitlab.com/yade-dev/trunk/commit/0b6b10845892801b0893be211e011bdc1707f8cd/pipelines?ref=master We can see when it stopped working. Interestingly the libCGAL problem seems to disappear for now? best regards Janek Janek Kozicki (yade) said: (by the date of Sun, 29 Dec 2019 20:41:59 +0100) > I just noticed following problems after new bullseye image has been built: > > ImportError: libCGAL.so.13: cannot open shared object file: No such > file or directory > > > > Image was built 14h ago: > container registry: https://gitlab.com/yade-dev/docker-yade/container_registry > > > Also in the pipeline in one of my MRs I found: > > python version reported by by cmake is [(3, 8, 0), '3.8'] and by > C++ is [(3, 7, 5), '3.7.5'] > > We can workaround this one, but is this intended behavior? > > 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
[Yade-dev] new bullseye image - problems building master
I just noticed following problems after new bullseye image has been built: ImportError: libCGAL.so.13: cannot open shared object file: No such file or directory Image was built 14h ago: container registry: https://gitlab.com/yade-dev/docker-yade/container_registry Also in the pipeline in one of my MRs I found: python version reported by by cmake is [(3, 8, 0), '3.8'] and by C++ is [(3, 7, 5), '3.7.5'] We can workaround this one, but is this intended behavior? 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
Re: [Yade-dev] Doc building problem
Great that you found out. Sorry for not helping you with this, I was too focused on high precision support. Anton Gladky said: (by the date of Mon, 9 Dec 2019 21:48:47 +0100) > The problem was really in python3.8 and ipython in Debian Sid. > > See: > > https://bugs.debian.org/946481 > > Anton > > Am Di., 3. Dez. 2019 um 21:58 Uhr schrieb Anton Gladky > : > > > > Hi Bruno, > > > > thanks for the hint. It looks like the problem is due to > > ongoing Python3.7->Python3.8 transition. We'll see. > > > > Regards > > > > Anton > > > > Am Di., 3. Dez. 2019 um 16:27 Uhr schrieb 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 > > >> : > > >> > > > >> > 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 > > > ___ > > > Mailing list: https://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 -- -- 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] gitlab artifacts missing
A very simple explanation of how && works: do this command: ls && ls /wrongdir && ls Then do this command: ls && ls && ls You will see that in the first case the failure of 'ls /wrongdir' prevented execution of last 'ls'. That's how && works. The next command is executed only if the previous one was a success. cheers Janek Anton Gladky said: (by the date of Wed, 13 Nov 2019 20:33:14 +0100) > Hallo Bruno, > > could you please send me a script, which is doing the download/upload? > > 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. > > 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 > && rm -rf /var/www/yade-dem.org && cp * /var/www/yade-dem.org > > should solve the problem. If wget fails, like in this case - rm and cp > will not be executed. And we get old documentation, > but in any case - not the empty pages. > > I hope, my writings can be understood :) > > Regards > > Anton > > Am Mi., 13. Nov. 2019 um 18:05 Uhr schrieb 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, > > 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 > > ___ > > Mailing list: https://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 -- -- 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] clang-format (Was: Re: Removing trailing white space, yay or nay?)
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
Re: [Yade-dev] Removing trailing white space, yay or nay?
It’s a great idea. And I’m surprised how personal it is for me :) Code readability is top priority for me. I’m sure we will find the clang-format settings which suits us. Automatic checks if the recently touched files (e.g files from the current MR) were reformatted will definitely help us. At first this will add some unreadable diffs. But later it will be a refreshing breeze :) -- Janek Kozicki On 17 Oct 2019, 18:59 +0200, Anton Gladky , wrote: > Hi, > > I propose to use the clang-format [1], which automatically formats > the code according to the pre-defined rules. It has a nice support > by most of IDEs and can also be used through command line. > > There are some pre-defined styles (LLVM, Google, Chromium, Mozilla, WebKit), > and i think we just need to choose. Fine-tuning is also possible, but > it is not necessary. > > Running this tool recursively all over the code is possible, but can produce > a large, not reviewable diff. But formatting the files, touched during > development process can step-by-step fix most parts of the code and be > consistent in the future. > > I have prepared a WIP-merge request [2], where the .clang-format file is added > and the Scene.cpp was reformatted using this tool. So you can check, > whether it will work for us. Style format can be changed, but it looks like > LLVM-style will produce the minimal changes. > > Pipelines can also check, whether the committer formatted the code > with clang-format. At the end we will forget the formatting problem in Yade. > > Generally, I have a good experience with this tool and I hope it can > work for this project as well. Comments are welcome. > > [1] https://clang.llvm.org/docs/ClangFormat.html > [2] https://gitlab.com/yade-dev/trunk/merge_requests/298 > > 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] Removing trailing white space, yay or nay?
I remove trailing whitespace at the end of the line, provided that I am changing this line for some *other* purpose. I prefer to avoid changing lines only for the sake of formatting, because that will eventually cause unwanted and unnecessary merge conflicts later. Also I tend to add a newline at the end of file if such newline is missing. That’s only because ’git diff’ shows warnings about the lack of these. In fact ‘git diff’ also complains about trailing whitespaces by printing them in red. It makes it simpler to remove them ;) -- Janek Kozicki On 17 Oct 2019, 11:05 +0200, Robert Caulk , wrote: > Hey yade devs, > > Lately I’ve been letting my editor automatically remove trailing white space > in the files I’m working on. The benefit to doing this can be disputed, but > it seems most people agree that trailing white space is undesirable because > it can create unwanted commit noise and interfere with other developers quick > keys [1]. A Couple other benign reasons highlighted in that thread: > > • It takes more storage space than necessary > • The parser will have to skip an extra character for no good reason when > compiling > • Some editors might add an extra blank line when WordWrap is on and the > trailing space doesn't fit > • It feels like the cursor is hanging in thin air at the end of a line, every > step to the right may cause it to either drop or to hover further to an > unknown extent, it just feels unsteady (like those invisible or disappearing > blocks that Super Mario used to jump on). > > > But clearly the first commit on a file where existing trailing white space is > removed is also going to look excessive and polluted [2]... > > I will follow the majority opinion in our community on keeping or > progressively doing away with trailing white space. Thoughts? > > Cheers, > > Robert > > [1]https://softwareengineering.stackexchange.com/questions/121555/why-is-trailing-whitespace-a-big-deal > [2]https://gitlab.com/yade-dev/trunk/merge_requests/296/diffs?diff_id=59111225_sha=bfa40d9617c0c3f03c5d8eaddfd52d4c075f2781#65534ad2321a960558c286a3a64b1c38fb17f52c > ___ > Mailing list: https://launchpad.net/~yade-dev > Post to : yade-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Building docker images
In case of problems, I mean :) Janek Kozicki (yade) said: (by the date of Fri, 11 Oct 2019 15:47:27 +0200) > BTW, I have also configured bullseye to use 7pak. Feel free to set others to > use 7pak too. > > > Janek Kozicki (yade) said: (by the date of Fri, 4 Oct 2019 16:30:18 +0200) > > > The schedule to build images seems to have some problems: > > > > https://gitlab.com/yade-dev/docker-yade/pipeline_schedules > > > > however I have succesfully configures 7pak to be able to build these > > images. I didn't test all of them, only the most "difficult" one: > > > > https://gitlab.com/yade-dev/docker-yade/pipelines/86378015 > > > > if the problems with building images on gitlab servers persist I > > think we can fix them by adding "tags: special" like I did in the > > ubuntu18.04_foam branch. > > > > 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
Re: [Yade-dev] Building docker images
BTW, I have also configured bullseye to use 7pak. Feel free to set others to use 7pak too. Janek Kozicki (yade) said: (by the date of Fri, 4 Oct 2019 16:30:18 +0200) > The schedule to build images seems to have some problems: > > https://gitlab.com/yade-dev/docker-yade/pipeline_schedules > > however I have succesfully configures 7pak to be able to build these images. > I didn't test all of them, only the most "difficult" one: > > https://gitlab.com/yade-dev/docker-yade/pipelines/86378015 > > if the problems with building images on gitlab servers persist I > think we can fix them by adding "tags: special" like I did in the > ubuntu18.04_foam branch. > > 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 -- -- 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] Python inheritance
Great! Thanks for finding this out :)
William Chèvremont said: (by the date of Thu, 10 Oct 2019 11:13:23 +0200)
> Ok got it.
>
> The problem come from the Global Interpreter Lock from Python. run()
> seems to run the code in an other thread as step() run the code in the
> same thread as python. So, when calling the function via step(), the
> lock is already acquired by the thread. On the other hand, run() is into
> a different thread, and the lock has to be acquired manually.
>
> Using boost, I was expecting an exception instead of crash for this kind
> of error.
>
> Functions should look like:
>
> virtual Real contactForce(Real const& u) const {
> TRACE;
> gilLock lock; // Acquire GIL. (from pyutils/gil.hpp)
> LOG_TRACE("GIL State: " << PyGILState_Check());
> return get_override("contactForce")(u);
> }
>
> 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().
> William.
>
>
>
> On 08/10/2019 13:22, William Chèvremont wrote:
> >
> > Hi,
> >
> > Yes, there are the same behaviour with and without wait.
> >
> > William
> >
> >
> > On 08/10/2019 12:57, Bruno Chareyre wrote:
> >> 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
> >> >> <mailto: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
> >> <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
> >>
> >>
> >>
> >> --
> >> --
> >> ___
> >> 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
--
--
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] Python inheritance
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
Re: [Yade-dev] yadedaily packages are functional again - dbgsym: too large
> How about *-dbgsym packages, with debug symbols? I see that you tried to add it: https://gitlab.com/yade-dev/trunk/commit/26147d8d55c1c77ae7d34139b1ff7ddd59ec19ca But unfortunately we are hitting some hardcap limit on gitlab :( Uploading artifacts... ./deb: found 12 matching files ERROR: Uploading artifacts to coordinator... too large archive id=313028835 responseStatus=413 Request Entity Too Large status=413 Request Entity Too Large token=-uaVjBQR FATAL: too large ERROR: Job failed: exit code 1 I am not sure how to overcome this obstacle. I see following options: 1. disable dbgsym for bullseye 2. pay gitlab to have more space 3. install gitlab software on our servers and use gitlab there for start 1. seems to be the simplest one. But maybe someone has better idea? 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
[Yade-dev] Building docker images
The schedule to build images seems to have some problems: https://gitlab.com/yade-dev/docker-yade/pipeline_schedules however I have succesfully configures 7pak to be able to build these images. I didn't test all of them, only the most "difficult" one: https://gitlab.com/yade-dev/docker-yade/pipelines/86378015 if the problems with building images on gitlab servers persist I think we can fix them by adding "tags: special" like I did in the ubuntu18.04_foam branch. 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
Re: [Yade-dev] yadedaily packages are functional again
Thank you for thanking me Anton :) I am very happy that we all can work together so efficiently. I have tested these instructions in chroots. It works! :) How about *-dbgsym packages, with debug symbols? best regards Janek Anton Gladky said: (by the date of Thu, 3 Oct 2019 07:42:09 +0200) > Dear all, > > after months of work and tests yadedaily packages > are available again. Thanks all especially to the team > in 3sR in Grenoble and Janek. > > Instructions are here [1]. If you find some problems with > it, please file an issue on gitlab [2]. > > [1] https://yade-dem.org/doc/installation.html#packages > [2] https://gitlab.com/yade-dev/trunk/issues > > 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 -- 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] Call for testing, updated yadedaily packages
Hi, I created bullseye chroot, with https://lists.launchpad.net/yade-dev/msg14836.html it was very simple, just copy buster dir to bullseye, then change sources.list. I tested your package. I confirm it works :) cheers Janek Anton Gladky said: (by the date of Tue, 6 Aug 2019 20:54:36 +0200) > Dear all, > > packages for Debian 11 Bullseye are ready for testing. > In addition to the original mail [1], this action needs to be > done for this distribution: > > - *Debian 11 Bullseye*: > sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian > bullseye main" >> /etc/apt/sources.list.d/yadedaily.list' > > Feedback is welcome. > > 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. > > I am not planning to add some more distributions this year. Next year > we will prepare packages for Ubuntu 20.04. > > When the infrastructure question will be solved, I will update a > documentation > for the yadedaily packages. > > [1] https://lists.launchpad.net/yade-dev/msg14823.html > > Best regards > > Anton -- Janek Kozicki http://janek.kozicki.pl/ | ___ Mailing list: https://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
Hi, I confirm that it works in my xenial chroot. Anton Gladky said: (by the date of Sun, 28 Jul 2019 22:25:53 +0200) > Hello all, > > packages for Ubuntu 16.04 Xenial are ready for testing. > In addition to the original mail [1], this action needs to be > done for this distribution: > > - Ubuntu 16.04 Xenial: > sudo bash -c 'echo "deb http://yadedaily.s3.amazonaws.com/debian > xenial main" >> /etc/apt/sources.list.d/yadedaily.list' > > Feedback is welcome. > > Next week there will be no updates of the yadedaily packages due to some > technical reasons. Over the next week packages will be updated. > > [1] https://lists.launchpad.net/yade-dev/msg14823.html > > Best regards > > Anton > > > Anton > > > Am So., 28. Juli 2019 um 12:46 Uhr schrieb Janek Kozicki : > > > > Looks like this conversation is now split between yade-dev and > > https://gitlab.com/yade-dev/trunk/issues/58 > > > > Reply to whichever you want, I monitor both channels :) > > > > Bruno can you make an Account for Anton on yade-dem.org ? > > > > I asked Anton to make .deb packages with debug symbols, but he cannot > > upload them with his weak internet connection as they are quite large. > > > > After repo infrastructure is moved out of Anton's laptop we will be > > able to provide packages with debug symbols, which will be very > > useful: a normal user will be able to send us crash reports with > > debug symbols. > > > > cheers > > Janek > > > > Anton Gladky said: (by the date of Wed, 17 Jul 2019 20:17:18 +0200) > > > > > Hi Bruno, > > > > > > > Was there specific difficulties with ubuntu16.04 (even if it's getting > > > > old I'm sure there would be users of it)? > > > > > > Basically - Qt4 orientation of the GUI. So, debian rules should be > > > patched to use it. > > > But if you think it is necessary for the users - let's try to do it. > > > > > > > - 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. > > > > > > Yes. Ideally there should be possible to run a docker. And also it > > > would be good to have an access > > > to the folder, which is symlinced to the the yade-dem.org/packages. > > > > > > > - 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. > > > It is extremely easy. It runs similar to the documentation: packages > > > should be pulled from gitlab, > > > signing etc is done by this script [1] and aptly. Dockerfile for the > > > image is here [2] > > > > > > [1] > > > https://gitlab.com/yade-dev/trunk/blob/master/scripts/ppa_ci/aptly/update_repos_next.sh > > > [2] > > > https://gitlab.com/yade-dev/trunk/blob/master/scripts/ppa_ci/aptly/Dockerfile > > > > > > Regards > > > > > > Anton > > > > > > Am Mo., 15. Juli 2019 um 18:23 Uhr schrieb 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 coordinat
Re: [Yade-dev] Call for testing, updated yadedaily packages
Looks like this conversation is now split between yade-dev and https://gitlab.com/yade-dev/trunk/issues/58 Reply to whichever you want, I monitor both channels :) Bruno can you make an Account for Anton on yade-dem.org ? I asked Anton to make .deb packages with debug symbols, but he cannot upload them with his weak internet connection as they are quite large. After repo infrastructure is moved out of Anton's laptop we will be able to provide packages with debug symbols, which will be very useful: a normal user will be able to send us crash reports with debug symbols. cheers Janek Anton Gladky said: (by the date of Wed, 17 Jul 2019 20:17:18 +0200) > Hi Bruno, > > > Was there specific difficulties with ubuntu16.04 (even if it's getting old > > I'm sure there would be users of it)? > > Basically - Qt4 orientation of the GUI. So, debian rules should be > patched to use it. > But if you think it is necessary for the users - let's try to do it. > > > - 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. > > Yes. Ideally there should be possible to run a docker. And also it > would be good to have an access > to the folder, which is symlinced to the the yade-dem.org/packages. > > > - 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. > It is extremely easy. It runs similar to the documentation: packages > should be pulled from gitlab, > signing etc is done by this script [1] and aptly. Dockerfile for the > image is here [2] > > [1] > https://gitlab.com/yade-dev/trunk/blob/master/scripts/ppa_ci/aptly/update_repos_next.sh > [2] > https://gitlab.com/yade-dev/trunk/blob/master/scripts/ppa_ci/aptly/Dockerfile > > Regards > > Anton > > Am Mo., 15. Juli 2019 um 18:23 Uhr schrieb 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 > > ___ > Mailing list: https://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 http://janek.kozicki.pl/ | ___ Mailing list: https://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 said: (by the date of Mon, 15 Jul 2019 18:26:07 +0200) > > in practice any computer can have a gitlab-runner installed. You could [...] > 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)? This can be yade-runner, or the server that hosts yade-dem.org. Anything you decide is safe and secure enough. And perhaps giving Anton access would solve all the problems. Anton would just send you an id_rsa_yade.pub for ssh, and you are all set! :) Unfortunately I cannot provide a secure server here at Gdańsk. At least at the moment. I can provide compute resources for compiling though :) cheers 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
Re: [Yade-dev] Faster local testing chroots for everyone :) + graphics
I forgot to mention, that on the first run, you need to git clone yade. Just copy paste the command printed on the terminal in the welcome message. All future compilations in chroots are much faster because ccache is configured and working :) Janek Kozicki said: (by the date of Fri, 12 Jul 2019 22:54:44 +0200) > I forgot to mention, that in some of those chroots the graphics works. > On the host you need to run command: > > xhost +local: > > And inside chroots you need to make suer that $DISPLAY points to correct > display. You do this by: > > echo $DISPLAY # on the host > > export export DISPLAY=:0 # inside chroot. > > This is also in the last 5 minutes of this super long video > https://www.youtube.com/watch?v=sZ4zDj1mFdc > > cheers > Janek > > > Janek Kozicki said: (by the date of Fri, 12 Jul 2019 22:46:00 +0200) > > > Hi everyone, > > > > I have prepared the chroots testing suite for you. To make it all > > work you need about 100GB free HDD space. > > > > Here's how to use it: > > > > # by default it is in directory /home/extra_nobackup/distros > > # you can change this by editing file start_chroot_IN_DIR.sh > > mkdir -p /home/extra_nobackup/distros > > > > cd /home/extra_nobackup/distros > > > > # I will try to keep this sevver online, but unfortunately cannot guarentee > > this > > # at least this month it should stay online. > > wget http://wilis.pg.gda.pl:5/tmp/yadeChroots1.tar.bz2 > > > > # make sure your downloaded file is OK: > > md5sum yadeChroots1.tar.bz2 > > > > # e918acc8e2e099ff1ce6531dc2675fe5 yadeChroots1.tar.bz2 > > > > tar -xvjf ./yadeChroots1.tar.bz2 > > > > # You can safely copy ./yadeChroots1 to have multiple independent chroot > > sets, > > # but do this when chroot is not running. > > > > # move the start script into /root/bin > > mkdir /root/bin > > mv ./yadeChroots1/start_chroot_IN_DIR.sh /root/bin > > > > # use the custom ~/.screenrc config. If you have your own screen config > > already, > > # then don't do this step. It is to enable F11/F12 keys to change chroots. > > > > mv ./yadeChroots1/.screenrc /root > > > > # install necessary local packages. > > # BTW, I wonder if this can work on Mac-OSX with brew install chroot ?? > > > > apt-get install screen zsh > > > > # Now you can start chroot with command: > > > > /root/bin/start_chroot_IN_DIR.sh yadeChroots1 p3 zsh > > > > # Now inside chroots you can test yade > > > > ~/bin/test-branch.sh upstream master NODOC > > > > # Press F11, F12 to switch between chroots > > > > # then you can exit the chroots by pressing Ctrl-d > > # After you exit, use this command to check if you have other chroots > > # running: > > > > cat /etc/mtab > > > > > > I made a demo video on ubuntu 16.04 https://youtu.be/sZ4zDj1mFdc > > in case if you have any problems. > > > > The text file written during the video is in the attachment. > > > > I hope this will speed up yade testing for all of you :) > > > > best regards > > Janek Kozicki > > > -- > Janek Kozicki http://janek.kozicki.pl/ | > > ___ > Mailing list: https://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 http://janek.kozicki.pl/ | ___ Mailing list: https://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] Faster local testing chroots for everyone :) + graphics
I forgot to mention, that in some of those chroots the graphics works. On the host you need to run command: xhost +local: And inside chroots you need to make suer that $DISPLAY points to correct display. You do this by: echo $DISPLAY # on the host export export DISPLAY=:0 # inside chroot. This is also in the last 5 minutes of this super long video https://www.youtube.com/watch?v=sZ4zDj1mFdc cheers Janek Janek Kozicki said: (by the date of Fri, 12 Jul 2019 22:46:00 +0200) > Hi everyone, > > I have prepared the chroots testing suite for you. To make it all > work you need about 100GB free HDD space. > > Here's how to use it: > > # by default it is in directory /home/extra_nobackup/distros > # you can change this by editing file start_chroot_IN_DIR.sh > mkdir -p /home/extra_nobackup/distros > > cd /home/extra_nobackup/distros > > # I will try to keep this sevver online, but unfortunately cannot guarentee > this > # at least this month it should stay online. > wget http://wilis.pg.gda.pl:5/tmp/yadeChroots1.tar.bz2 > > # make sure your downloaded file is OK: > md5sum yadeChroots1.tar.bz2 > > # e918acc8e2e099ff1ce6531dc2675fe5 yadeChroots1.tar.bz2 > > tar -xvjf ./yadeChroots1.tar.bz2 > > # You can safely copy ./yadeChroots1 to have multiple independent chroot sets, > # but do this when chroot is not running. > > # move the start script into /root/bin > mkdir /root/bin > mv ./yadeChroots1/start_chroot_IN_DIR.sh /root/bin > > # use the custom ~/.screenrc config. If you have your own screen config > already, > # then don't do this step. It is to enable F11/F12 keys to change chroots. > > mv ./yadeChroots1/.screenrc /root > > # install necessary local packages. > # BTW, I wonder if this can work on Mac-OSX with brew install chroot ?? > > apt-get install screen zsh > > # Now you can start chroot with command: > > /root/bin/start_chroot_IN_DIR.sh yadeChroots1 p3 zsh > > # Now inside chroots you can test yade > > ~/bin/test-branch.sh upstream master NODOC > > # Press F11, F12 to switch between chroots > > # then you can exit the chroots by pressing Ctrl-d > # After you exit, use this command to check if you have other chroots > # running: > > cat /etc/mtab > > > I made a demo video on ubuntu 16.04 https://youtu.be/sZ4zDj1mFdc > in case if you have any problems. > > The text file written during the video is in the attachment. > > I hope this will speed up yade testing for all of you :) > > best regards > Janek Kozicki -- Janek Kozicki http://janek.kozicki.pl/ | ___ Mailing list: https://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] Faster local testing chroots for everyone :)
Hi everyone, I have prepared the chroots testing suite for you. To make it all work you need about 100GB free HDD space. Here's how to use it: # by default it is in directory /home/extra_nobackup/distros # you can change this by editing file start_chroot_IN_DIR.sh mkdir -p /home/extra_nobackup/distros cd /home/extra_nobackup/distros # I will try to keep this sevver online, but unfortunately cannot guarentee this # at least this month it should stay online. wget http://wilis.pg.gda.pl:5/tmp/yadeChroots1.tar.bz2 # make sure your downloaded file is OK: md5sum yadeChroots1.tar.bz2 # e918acc8e2e099ff1ce6531dc2675fe5 yadeChroots1.tar.bz2 tar -xvjf ./yadeChroots1.tar.bz2 # You can safely copy ./yadeChroots1 to have multiple independent chroot sets, # but do this when chroot is not running. # move the start script into /root/bin mkdir /root/bin mv ./yadeChroots1/start_chroot_IN_DIR.sh /root/bin # use the custom ~/.screenrc config. If you have your own screen config already, # then don't do this step. It is to enable F11/F12 keys to change chroots. mv ./yadeChroots1/.screenrc /root # install necessary local packages. # BTW, I wonder if this can work on Mac-OSX with brew install chroot ?? apt-get install screen zsh # Now you can start chroot with command: /root/bin/start_chroot_IN_DIR.sh yadeChroots1 p3 zsh # Now inside chroots you can test yade ~/bin/test-branch.sh upstream master NODOC # Press F11, F12 to switch between chroots # then you can exit the chroots by pressing Ctrl-d # After you exit, use this command to check if you have other chroots # running: cat /etc/mtab I made a demo video on ubuntu 16.04 https://youtu.be/sZ4zDj1mFdc in case if you have any problems. The text file written during the video is in the attachment. I hope this will speed up yade testing for all of you :) best regards Janek Kozicki # OK, I installed a fresh 16.04 in virtualbox to test if this chroot works. First download it to this dir: mkdir -p /home/extra_nobackup/distros ; cd /home/extra_nobackup/distros wget http://wilis.pg.gda.pl:5/tmp/yadeChroots1.tar.bz2 md5sum yadeChroots1.tar.bz2 # e918acc8e2e099ff1ce6531dc2675fe5 yadeChroots1.tar.bz2 tar -xvjf ./yadeChroots1.tar.bz2 # unpacking 40GB is going to take some time. Let's skip recording video of unpacking :) mkdir /root/bin ; mv ./yadeChroots1/start_chroot_IN_DIR.sh /root/bin ; mv ./yadeChroots1/.screenrc /root apt-get install screen zsh # is that all? Let's see if this works. /root/bin/start_chroot_IN_DIR.sh yadeChroots1 p3 zsh # started! F11, F12 to change tabs. # ONLY ONCE, to clone first: mkdir -p /home/ytest/yade ; cd /home/ytest/yade ; git clone https://gitlab.com/yade-dev/trunk.git ; cd trunk ; git remote rename origin upstream # Then start testing: ~/bin/test-branch.sh upstream master NODOC # heh, compilation will take some time, but let's do this. I will stop recording until they all compile. # Ouch, I see that F11 isn't working to move to left tab. Try to change this in options. # Future compilation will be much faster, because these chroots are configured with ccache # I also noticed that opensuse by default asks to confirm the `git log` nevermind. It is still compiling # Now the script continues, will --test first, then --check, then build documentation unless there was NODOC argument # hm. I never seen this checkMPI.py error before. Perhaps this chroot had a mistake in preparing it. # Tried to make dir /home/ytest/.ipython ; ok, it worked the second time. So now we can use the script # And use ccached compile. ~/bin/test-branch.sh upstream master NODOC # OK, so it all works. We see the result in here. DOC -1 means it was skipped. We can run tests again with commands # printed at the end: ~/yade/install/bin/yade-ci --test ~/yade/install/bin/yade-ci --check # also, in most of the chroots we will have working graphics. First need to make sure the DISPLAY number # if the number is the same, we need to run command: 'xhost +local:' on the host. # And now graphics will work! # hmm.. not always :( In some chroots it was working. Let me check. xterm works at least. # right, it's not working in 16.04, stretch and opensuse. But should work in others, let's try 18.04 # Nice, all test and check worked. now let's try graphics. # OK it all works. Now try again - logout from chroot and start it again. # Use this command to check if you have other chroots running: cat /etc/mtab # now start it again as root, to install maybe something. /root/bin/start_chroot_IN_DIR.sh yadeChroots1 p3 root # OK, nothing to install, go back to regular user. /root/bin/start_chroot_IN_DIR.sh yadeChroots1 p3 zsh # remember about the 'xhost +local:' on the host. for graphics. # # OK, it works, ready to announce on yade-dev :) # End of message. ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https
Re: [Yade-dev] Call for testing, updated yadedaily packages
Hi Anton, I checked your instructions inside chroots. They work great in all three distros: ubuntu 18.04, debian stretch and debian buster. cheers Janek Anton Gladky said: (by the date of Thu, 27 Jun 2019 21:15:08 +0200) > 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 -- Janek Kozicki http://janek.kozicki.pl/ | ___ Mailing list: https://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] Too many branches
Hi, is it okay if I delete all superficial branches from: https://gitlab.com/yade-dev/trunk/-/branches/active except the 6 branches that have an open MR? https://gitlab.com/yade-dev/trunk/merge_requests There is simply too much stuff there. I want to have a readable graph: https://gitlab.com/yade-dev/trunk/-/network/master best regards 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
Re: [Yade-dev] Call for testing, updated yadedaily packages
Jerome Duriez said: (by the date of Fri, 5 Jul 2019 17:03:45 +0200) > On 05/07/2019 14:07, Janek Kozicki wrote: > > I should write about this process in the developer documentation also. > > I actually just understood more (hopefully) what these dockers are.. > And I just realized the docker files like this one > <https://gitlab.com/yade-dev/docker-yade/blob/ubuntu16-py3/Dockerfile> > are up-to-date lists of required packages for the different OS (are they > ?), yes! > which is a very useful piece of information to point to from > https://yade-dem.org/doc/installation.html, as done in > https://yade-dem.org/doc/installation.html#supported-linux-releases.. > > InSections of installation page may thus be reordered and written in a > more independent fashion from our gitlab procedures. So that users > wanting to compile source may be better guided, whatever their Linux OS ? > > I may try to propose something this summer, but if someone agrees and > wants to do it before me... the more you do, the less I have to do, so please do! :) -- 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
Re: [Yade-dev] Call for testing, updated yadedaily packages
Bruno Chareyre said: (by the date of Fri, 28 Jun 2019 17:05:09 +0200) > 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 Just a quick reminder: you can manipulate the 5 supported docker images as you want on: https://gitlab.com/yade-dev/docker-yade/-/branches/active They are correctly built by gitlab after each git push. Then the gitlab pipeline CI automatically checks the timestamp/crc and fetches the latest docker image to build and test like this one: https://gitlab.com/yade-dev/trunk/pipelines/67185168 So if you need any other package or whatever else in the docker image, just push to the relevant branch * ubuntu16-py3 * ubuntu18.04 * debian-buster * debian-stretch * suse15 Maybe we should rename those branches so that their names are more clear about how they correspond to our pipeline. If the process: 1. "git push" ← you do only this one, rest is automatic. 2. "build docker image", 3. "use new image in gitlab-runner" is not working, then we have a bug, and I will fix it. I should write about this process in the developer documentation also. The two remaining branches are: * master - this was the jump-start branch for all other branches. Now it is a little out of date, but was supposed to follow closely the ubuntu18.04 branch * ubuntu18.04_foam - this branch won't built correctly on gitlab, becuse it involves total OpenFOAM recompilation. Maybe we can fix it later. I have built it locally in docker on 4pak, then later I will use it on https://gitlab.com/yade-dev/trunk/merge_requests/143 If you need somehow different docker images than those five present in gitlab CI, you can clone the relevant branch and make your own variation. The gitlab runner uses the name as it is given inside file .gitlab-ci.yml After it is built, it lands in https://gitlab.com/yade-dev/docker-yade/container_registry cheers 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
Re: [Yade-dev] Sporadic compilation error
Hi Anton, just to make sure: have you noticed Bruno's and my comments attached to your commits on gitlab? https://gitlab.com/yade-dev/trunk/commit/81652f1c47575ecbc9599308a449ccd3c28ff634 https://gitlab.com/yade-dev/trunk/commit/9d8211c3721b4bd9b3ceebe396a4bf14957d04e1 https://gitlab.com/yade-dev/trunk/commit/f76b011b0e083c6c73f4e09e5567306cd32ba8e7 To stay on track it is usefu to bookmark this page: https://gitlab.com/groups/yade-dev/-/activity best regards Janek Anton Gladky said: (by the date of Sun, 9 Jun 2019 08:00:44 +0200) > I think the problem is that two or more > processes are concurrently creating > moc-files and overwriting it, breaking > the structure. > > On Sat, Jun 8, 2019, 21:39 Anton Gladky wrote: > > > > Maybe investigating the difference between the "regular" setup and > > > "deb-packages" compilation would give some insight. > > > > Basically the same [1] > > > > [1] > > https://gitlab.com/yade-dev/trunk/blob/feature/dailypackages/scripts/ppa_ci/debian/rules#L18 > > > > Anton -- Janek Kozicki http://janek.kozicki.pl/ | ___ Mailing list: https://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 1832235] Re: The NewtonIntegrator does not apply angular motion for aspherical bodies
Please use https://gitlab.com/yade-dev/trunk/issues for bug reporting. I move this from https://bugs.launchpad.net/yade/+bug/1832235 to https://gitlab.com/yade-dev/trunk/issues/84 ** Bug watch added: gitlab.com/yade-dev/trunk/issues #84 https://gitlab.com/yade-dev/trunk/issues/84 -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1832235 Title: The NewtonIntegrator does not apply angular motion for aspherical bodies Status in Yade: New Bug description: I've tried several ways to impose an initial angular velocity on a free polyhedron but they do not work well as commented in the script and below. Please help me with this. Thanks! Here are things I've observed: [In the code below, I simulate 2 polyhedrons, poly1 is free and has an initial velocity while poly2 is fixed.] If I directly use state.angVel or utils.setBodyAngularVelocity to impost an angular velocity on both polyhedrons, nothing happens to poly1, I could observe no rotation but just transnational move. However, I could observe rotation on poly2, which is fixed. A work around is to use angMom. ## using: "b.state.angMom" Mom=b1.state.ori*b1.state.inertia # This results to angVel=Vector3(1,1,1). # Modify accordingly, to modify a specific angular velocity. e.g., to get an initial angVel=Vector3(5,6,7) Mom[0]=Mom[0]*5. Mom[1]=Mom[1]*6. Mom[2]=Mom[2]*7. O.bodies[0].state.angMom=Mom # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # ENGINES # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # O.engines=[ ForceResetter(), InsertionSortCollider([Bo1_Polyhedra_Aabb()],verletDist=0.01), InteractionLoop( [Ig2_Polyhedra_Polyhedra_PolyhedraGeom()], [Ip2_PolyhedraMat_PolyhedraMat_PolyhedraPhys()], [Law2_PolyhedraGeom_PolyhedraPhys_Volumetric()] ), NewtonIntegrator(damping=0.0,exactAsphericalRot=True,gravity=[0,0,0]), ] # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # POLYHEDRAL PARTICLES # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # from yade import polyhedra_utils m = PolyhedraMat() m.density = 2000 #kg/m^3 m.young = 150e6 #Pa m.poisson = .4 m.frictionAngle = 3.0 #rad edge=0.025 vertices=[(-edge, -edge, -edge), (-edge, edge, -edge), ( edge, -edge, -edge), ( edge, edge, -edge), (-edge, -edge, edge), (-edge, edge, edge), ( edge, -edge, edge), ( edge, edge, edge)] # Free b1 = polyhedra_utils.polyhedra(m,v=vertices) b1.state.pos = (0,0,0) O.bodies.append(b1) # Fixed b2 = polyhedra_utils.polyhedra(m,v=vertices,fixed=True) b2.state.pos = (4.*edge,0,0) O.bodies.append(b2) # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # INITIAL VELOCITY # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # Initial translational velocity O.bodies[0].state.vel=Vector3(1,0,0) # Initial angular velocity # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # ##Directly assigning the angular velocity- Not imposing initial angular velocity- No rotation for the free one but the fixed one will rotate #O.bodies[0].state.angVel=Vector3(1,1,0) #O.bodies[1].state.angVel=Vector3(1,1,0) ## using: "utils.setBodyAngularVelocity" - Not working for non-fixed bodies(poly1) but working for poly2 utils.setBodyAngularVelocity(0,5*Vector3(1,1,1)) utils.setBodyAngularVelocity(1,5*Vector3(1,1,1)) # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # from yade import qt v=qt.View() O.dt=1.0e-8 O.saveTmp() To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1832235/+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] Sporadic compilation error
This makes sense. It would explain why the words shown in errors are always some variable names cut in half. Anton Gladky said: (by the date of Sun, 9 Jun 2019 08:00:44 +0200) > I think the problem is that two or more > processes are concurrently creating > moc-files and overwriting it, breaking > the structure. > > On Sat, Jun 8, 2019, 21:39 Anton Gladky wrote: > > > > Maybe investigating the difference between the "regular" setup and > > > "deb-packages" compilation would give some insight. > > > > Basically the same [1] > > > > [1] > > https://gitlab.com/yade-dev/trunk/blob/feature/dailypackages/scripts/ppa_ci/debian/rules#L18 > > > > Anton > > > > Am Sa., 8. Juni 2019 um 21:01 Uhr schrieb Janek Kozicki > >: > > > > > > Also it is interesting that this error did not occur in hundreds of > > > pipeline compilations after each `git push` to gitlab. Maybe > > > investigating the difference between the "regular" setup and > > > "deb-packages" compilation would give some insight. > > > > > > > > > > > > Janek Kozicki said: (by the date of Sat, 8 Jun 2019 20:53:54 +0200) > > > > [...] > [...] > [...] > > moved > [...] > [...] > [...] > > https://salsa.debian.org/science-team/libqglviewer/merge_requests/1 ? > [...] > > janek_li...@wp.pl>: > [...] > > I implemented > [...] > > moved > [...] > > libraries? > [...] > > https://salsa.debian.org/science-team/libqglviewer/merge_requests/1 ? > [...] > > +0200) > [...] > [...] > [...] > > http://janek.kozicki.pl/ | > [...] > [...] > > | > [...] > > > > > > > > > -- > > > Janek Kozicki http://janek.kozicki.pl/ | > > > > > > ___ > > > Mailing list: https://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 http://janek.kozicki.pl/ | ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
