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

[Vasileios Angelidakis (PGR)]

Dear Bruno,

I agree 100% to add a message in support of peace. Please include me in any 
communications and let me know how I can help write this together.

Kind Regards,

Vasileios

-Original Message-
From: Yade-dev  
On Behalf Of Bruno Chareyre
Sent: 03 March 2022 17:17
To: yade-dev@lists.launchpad.net
Subject: [Yade-dev] Yade vs. war in Ukraine

⚠ External sender. Take care when opening links or attachments. Do not provide 
your login details.

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.interpore.org%2Findex.php%3Fpage%3Dacymailing_front%26ctrl%3Darchive%26task%3Dview%26id%3D120%26userid%3D559-kfFKWJJ3zkJa0l%26noheader%3D1%26noheader%3D1&data=04%7C01%7CV.Angelidakis2%40newcastle.ac.uk%7C78e296b5be6e45f5d0f508d9fd39a2fa%7C9c5012c9b61644c2a91766814fbe3e87%7C1%7C0%7C637819246521558666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mhjSCYPFMg7x%2BogkmyMeOlsDuAnIdq5lbhoWbl%2F7XRc%3D&reserved=0


___
Mailing list: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flaunchpad.net%2F~yade-dev&data=04%7C01%7CV.Angelidakis2%40newcastle.ac.uk%7C78e296b5be6e45f5d0f508d9fd39a2fa%7C9c5012c9b61644c2a91766814fbe3e87%7C1%7C0%7C637819246521558666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9nWtLdD54ll1cDxc%2BX%2FZ6aHjsTs8xAiayyqVpWwQHtU%3D&reserved=0
Post to : yade-dev@lists.launchpad.net
Unsubscribe : 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flaunchpad.net%2F~yade-dev&data=04%7C01%7CV.Angelidakis2%40newcastle.ac.uk%7C78e296b5be6e45f5d0f508d9fd39a2fa%7C9c5012c9b61644c2a91766814fbe3e87%7C1%7C0%7C637819246521558666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9nWtLdD54ll1cDxc%2BX%2FZ6aHjsTs8xAiayyqVpWwQHtU%3D&reserved=0
More help   : 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.launchpad.net%2FListHelp&data=04%7C01%7CV.Angelidakis2%40newcastle.ac.uk%7C78e296b5be6e45f5d0f508d9fd39a2fa%7C9c5012c9b61644c2a91766814fbe3e87%7C1%7C0%7C637819246521558666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UytvGQ7UE8FMqC1SM%2FVgGvQPX%2BIcnd4B8Bz5YIApyDw%3D&reserved=0
___
Mailing list: https://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 ?

[Vasileios Angelidakis (PGR)]

Hi all,

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.

All the best,
Vasileios

From: Yade-dev  
on behalf of Bruno Chareyre 
Sent: Tuesday, March 10, 2020 12:13:47 PM
To: Yade developers 
Subject: Re: [Yade-dev] should we drop qt4 support? + clang-format ?



On Mon, 9 Mar 2020 at 23:28, Janek Kozicki (yade) 
mailto:jkozicki-y...@pg.edu.pl>> wrote:

Since I have finished all the large modifications in master I thought about 
clang-formatting it.
But maybe somebody else has some ongoing large changes and prefers to wait with 
this?
Hi,
Do you mean to reformat the whole repository?
Hopefully someone will raise hands in such case. Vasileios maybe?
B

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

Re: [Yade-dev] Potential Blocks and Potential Particles - brief analysis of the Object Oriented C++ source code

[Vasileios Angelidakis (PGR)]

Hi,


To clarify, this should happen before compilation.


Kind Regards,


Vasileios


Vasileios Angelidakis

Post-Graduate Researcher in Geotechnical Engineering

School of Engineering, Newcastle University

Room 3.04, Drummond Building

Devonshire Terrace, Newcastle upon Tyne, NE1 7RU, UK

E: v.angelidak...@ncl.ac.uk<mailto:v.angelidak...@ncl.ac.uk> T: +44 
(0)7380317986 W: Personal Page<https://www.students.ncl.ac.uk/vangelidakis2/>


From: Yade-dev  
on behalf of Vasileios Angelidakis (PGR) 
Sent: 16 February 2019 16:40:44
To: Janek Kozicki; Yade developers
Subject: Re: [Yade-dev] Potential Blocks and Potential Particles - brief 
analysis of the Object Oriented C++ source code


Hi,


I have a diplomatic solution.

If we remove the unused parameters from the shape class, they have to be 
removed from the BlockGen.cpp as well, as they are inherited to the 
child-blocks after their generation.


What if we "hide" these parameters inside a boolean "useBartonBandis"? When it 
is True, the PotentialBlock shape class and the BlockGen algorithm will entail 
these parameters, while when it's False, it won't.


Regards,


Vasileios


From: Yade-dev  
on behalf of Janek Kozicki 
Sent: 16 February 2019 15:39:31
To: Yade developers
Subject: Re: [Yade-dev] Potential Blocks and Potential Particles - brief 
analysis of the Object Oriented C++ source code

IMHO it is better to remove what is not used, then derive a child
class for Barton-Bandis rock joint model to add new stuff when it is
needed.

Unused variables will just confuse newcomers. And cause compilation warnings.

best regards
Janek

Vasileios Angelidakis (PGR) said: (by the date of Sat, 16 Feb 2019 15:31:13 
+)

> Hi Boon,
>
>
> Okay, I won't touch the unused  parameters in the
> PotentialBlocks, to keep them available for future development of
> the Barton-Bandis rock joint model.
>
>
> Kind Regards,
>
>
> Vasileios
>
>
> Vasileios Angelidakis
>
> Post-Graduate Researcher in Geotechnical Engineering
>
> School of Engineering, Newcastle University
>
> Room 3.04, Drummond Building
>
> Devonshire Terrace, Newcastle upon Tyne, NE1 7RU, UK
>
> E: v.angelidak...@ncl.ac.uk<mailto:v.angelidak...@ncl.ac.uk> T: +44
> (0)7380317986 W: Personal
> Page<https://www.students.ncl.ac.uk/vangelidakis2/>
>
> ____
> From: Yade-dev
>  on
> behalf of Chia Weng Boon  Sent: 16 February
> 2019 14:17:32 To: Vasileios Angelidakis (PGR); Janek Kozicki Cc:
> Yade developers Subject: Re: [Yade-dev] Potential Blocks and
> Potential Particles - brief analysis of the Object Oriented C++
> source code
>
> Thanks Vasileios.
> I suggest not to remove the  in PB yet because it is used
> in the block generation code.  Also some variables are redundant
> now , e.g. JRC, JCS, aperture, etc, and they are for the Barton
> Bandis rock joint model, which is an important feature, but not
> pursued during my PhD. If it is deleted now, later on, I suspect
> that someone may add it back in the future.
>
> In PP, these  are not required
>
> Boon
>
>
> 
> From: Vasileios Angelidakis (PGR) 
> Sent: Saturday, February 9, 2019 2:15 AM
> To: Janek Kozicki; boo...@hotmail.com
> Cc: Yade developers
> Subject: Re: [Yade-dev] Potential Blocks and Potential Particles -
> brief analysis of the Object Oriented C++ source code
>
>
> Hi,
>
>
> I will start a WIP branch to remove unused variables and functions
> from both the PB & the PP code, to make them more readable, right
> after I finish writing the documentation. Boon please let me know
> if you are about to do something similar, so we don't overlap. Any
> pointers to unused parts of the codes are welcome!
>
>
> Kind Regards,
>
>
> Vasileios
>
>
> Vasileios Angelidakis
>
> Post-Graduate Researcher in Geotechnical Engineering
>
> School of Engineering, Newcastle University
>
> Room 3.04, Drummond Building
>
> Devonshire Terrace, Newcastle upon Tyne, NE1 7RU, UK
>
> E: v.angelidak...@ncl.ac.uk<mailto:v.angelidak...@ncl.ac.uk> T: +44
> (0)7380317986 W: Personal
> Page<https://www.students.ncl.ac.uk/vangelidakis2/>
>
> 
> From: Yade-dev
>  on
> behalf of Janek Kozicki  Sent: 06 February 2019
> 15:02:05 Cc: Yade developers Subject: Re: [Yade-dev] Potential
> Blocks and Potential Particles - brief analysis of the Object
> Oriented C++ source code
>
> Janek Kozicki said: (by the date of Wed, 6 Feb 2019 13:53:46
> +0100)
>
> > Hi, I didn't see the reply from Vasileios on the mailing list. I
> > see it only no

Re: [Yade-dev] Potential Blocks and Potential Particles - brief analysis of the Object Oriented C++ source code

[Vasileios Angelidakis (PGR)]

Hi,


I have a diplomatic solution.

If we remove the unused parameters from the shape class, they have to be 
removed from the BlockGen.cpp as well, as they are inherited to the 
child-blocks after their generation.


What if we "hide" these parameters inside a boolean "useBartonBandis"? When it 
is True, the PotentialBlock shape class and the BlockGen algorithm will entail 
these parameters, while when it's False, it won't.


Regards,


Vasileios


From: Yade-dev  
on behalf of Janek Kozicki 
Sent: 16 February 2019 15:39:31
To: Yade developers
Subject: Re: [Yade-dev] Potential Blocks and Potential Particles - brief 
analysis of the Object Oriented C++ source code

IMHO it is better to remove what is not used, then derive a child
class for Barton-Bandis rock joint model to add new stuff when it is
needed.

Unused variables will just confuse newcomers. And cause compilation warnings.

best regards
Janek

Vasileios Angelidakis (PGR) said: (by the date of Sat, 16 Feb 2019 15:31:13 
+)

> Hi Boon,
>
>
> Okay, I won't touch the unused  parameters in the
> PotentialBlocks, to keep them available for future development of
> the Barton-Bandis rock joint model.
>
>
> Kind Regards,
>
>
> Vasileios
>
>
> Vasileios Angelidakis
>
> Post-Graduate Researcher in Geotechnical Engineering
>
> School of Engineering, Newcastle University
>
> Room 3.04, Drummond Building
>
> Devonshire Terrace, Newcastle upon Tyne, NE1 7RU, UK
>
> E: v.angelidak...@ncl.ac.uk<mailto:v.angelidak...@ncl.ac.uk> T: +44
> (0)7380317986 W: Personal
> Page<https://www.students.ncl.ac.uk/vangelidakis2/>
>
> ________
> From: Yade-dev
>  on
> behalf of Chia Weng Boon  Sent: 16 February
> 2019 14:17:32 To: Vasileios Angelidakis (PGR); Janek Kozicki Cc:
> Yade developers Subject: Re: [Yade-dev] Potential Blocks and
> Potential Particles - brief analysis of the Object Oriented C++
> source code
>
> Thanks Vasileios.
> I suggest not to remove the  in PB yet because it is used
> in the block generation code.  Also some variables are redundant
> now , e.g. JRC, JCS, aperture, etc, and they are for the Barton
> Bandis rock joint model, which is an important feature, but not
> pursued during my PhD. If it is deleted now, later on, I suspect
> that someone may add it back in the future.
>
> In PP, these  are not required
>
> Boon
>
>
> 
> From: Vasileios Angelidakis (PGR) 
> Sent: Saturday, February 9, 2019 2:15 AM
> To: Janek Kozicki; boo...@hotmail.com
> Cc: Yade developers
> Subject: Re: [Yade-dev] Potential Blocks and Potential Particles -
> brief analysis of the Object Oriented C++ source code
>
>
> Hi,
>
>
> I will start a WIP branch to remove unused variables and functions
> from both the PB & the PP code, to make them more readable, right
> after I finish writing the documentation. Boon please let me know
> if you are about to do something similar, so we don't overlap. Any
> pointers to unused parts of the codes are welcome!
>
>
> Kind Regards,
>
>
> Vasileios
>
>
> Vasileios Angelidakis
>
> Post-Graduate Researcher in Geotechnical Engineering
>
> School of Engineering, Newcastle University
>
> Room 3.04, Drummond Building
>
> Devonshire Terrace, Newcastle upon Tyne, NE1 7RU, UK
>
> E: v.angelidak...@ncl.ac.uk<mailto:v.angelidak...@ncl.ac.uk> T: +44
> (0)7380317986 W: Personal
> Page<https://www.students.ncl.ac.uk/vangelidakis2/>
>
> 
> From: Yade-dev
>  on
> behalf of Janek Kozicki  Sent: 06 February 2019
> 15:02:05 Cc: Yade developers Subject: Re: [Yade-dev] Potential
> Blocks and Potential Particles - brief analysis of the Object
> Oriented C++ source code
>
> Janek Kozicki said: (by the date of Wed, 6 Feb 2019 13:53:46
> +0100)
>
> > Hi, I didn't see the reply from Vasileios on the mailing list. I
> > see it only now in quote in the reply from Boon. I will answer to
> > both.
>
> hm. I see your email in the archive:
> https://lists.launchpad.net/yade-dev/ that must have been some
> problem with my mail server. Yes, I have found it in spam :( I need
> to switch away from this wp.pl email server.
>
> --
> 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


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

Re: [Yade-dev] Potential Blocks and Potential Particles - brief analysis of the Object Oriented C++ source code

[Vasileios Angelidakis (PGR)]

Hi Boon,


Okay, I won't touch the unused  parameters in the PotentialBlocks, to 
keep them available for future development of the Barton-Bandis rock joint 
model.


Kind Regards,


Vasileios


Vasileios Angelidakis

Post-Graduate Researcher in Geotechnical Engineering

School of Engineering, Newcastle University

Room 3.04, Drummond Building

Devonshire Terrace, Newcastle upon Tyne, NE1 7RU, UK

E: v.angelidak...@ncl.ac.uk<mailto:v.angelidak...@ncl.ac.uk> T: +44 
(0)7380317986 W: Personal Page<https://www.students.ncl.ac.uk/vangelidakis2/>


From: Yade-dev  
on behalf of Chia Weng Boon 
Sent: 16 February 2019 14:17:32
To: Vasileios Angelidakis (PGR); Janek Kozicki
Cc: Yade developers
Subject: Re: [Yade-dev] Potential Blocks and Potential Particles - brief 
analysis of the Object Oriented C++ source code

Thanks Vasileios.
I suggest not to remove the  in PB yet because it is used in the block 
generation code.  Also some variables are redundant now , e.g. JRC, JCS, 
aperture, etc, and they are for the Barton Bandis rock joint model, which is an 
important feature, but not pursued during my PhD.
If it is deleted now, later on, I suspect that someone may add it back in the 
future.

In PP, these  are not required

Boon


____
From: Vasileios Angelidakis (PGR) 
Sent: Saturday, February 9, 2019 2:15 AM
To: Janek Kozicki; boo...@hotmail.com
Cc: Yade developers
Subject: Re: [Yade-dev] Potential Blocks and Potential Particles - brief 
analysis of the Object Oriented C++ source code


Hi,


I will start a WIP branch to remove unused variables and functions from both 
the PB & the PP code, to make them more readable, right after I finish writing 
the documentation. Boon please let me know if you are about to do something 
similar, so we don't overlap. Any pointers to unused parts of the codes are 
welcome!


Kind Regards,


Vasileios


Vasileios Angelidakis

Post-Graduate Researcher in Geotechnical Engineering

School of Engineering, Newcastle University

Room 3.04, Drummond Building

Devonshire Terrace, Newcastle upon Tyne, NE1 7RU, UK

E: v.angelidak...@ncl.ac.uk<mailto:v.angelidak...@ncl.ac.uk> T: +44 
(0)7380317986 W: Personal Page<https://www.students.ncl.ac.uk/vangelidakis2/>


From: Yade-dev  
on behalf of Janek Kozicki 
Sent: 06 February 2019 15:02:05
Cc: Yade developers
Subject: Re: [Yade-dev] Potential Blocks and Potential Particles - brief 
analysis of the Object Oriented C++ source code

Janek Kozicki said: (by the date of Wed, 6 Feb 2019 13:53:46 +0100)

> Hi, I didn't see the reply from Vasileios on the mailing list. I see
> it only now in quote in the reply from Boon. I will answer to both.

hm. I see your email in the archive: https://lists.launchpad.net/yade-dev/
that must have been some problem with my mail server. Yes, I have
found it in spam :( I need to switch away from this wp.pl email server.

--
Janek Kozicki

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

Re: [Yade-dev] Potential Blocks and Potential Particles - brief analysis of the Object Oriented C++ source code

[Vasileios Angelidakis (PGR)]

Hi,


I will start a WIP branch to remove unused variables and functions from both 
the PB & the PP code, to make them more readable, right after I finish writing 
the documentation. Boon please let me know if you are about to do something 
similar, so we don't overlap. Any pointers to unused parts of the codes are 
welcome!


Kind Regards,


Vasileios


Vasileios Angelidakis

Post-Graduate Researcher in Geotechnical Engineering

School of Engineering, Newcastle University

Room 3.04, Drummond Building

Devonshire Terrace, Newcastle upon Tyne, NE1 7RU, UK

E: v.angelidak...@ncl.ac.uk T: +44 
(0)7380317986 W: Personal Page


From: Yade-dev  
on behalf of Janek Kozicki 
Sent: 06 February 2019 15:02:05
Cc: Yade developers
Subject: Re: [Yade-dev] Potential Blocks and Potential Particles - brief 
analysis of the Object Oriented C++ source code

Janek Kozicki said: (by the date of Wed, 6 Feb 2019 13:53:46 +0100)

> Hi, I didn't see the reply from Vasileios on the mailing list. I see
> it only now in quote in the reply from Boon. I will answer to both.

hm. I see your email in the archive: https://lists.launchpad.net/yade-dev/
that must have been some problem with my mail server. Yes, I have
found it in spam :( I need to switch away from this wp.pl email server.

--
Janek Kozicki

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

Re: [Yade-dev] Potential Blocks and Potential Particles - brief analysis of the Object Oriented C++ source code

[Vasileios Angelidakis (PGR)]

Hi,


Janek thanks for the in-depth remarks on the PB (PotentialBlock) & PP 
(PotentialParticle) codes. It will be very useful to have a discussion on the 
matter and try to improve them.


Regarding the compilation warnings that stem from unused variables, I can help 
suppress them by commenting out the unused variables, if Chia can verify with 
me that he does not intend to use any them in the near future. For the other 
warnings, I will track them inside the code and try to suppress them as well. I 
will let you know if I find any difficulties.


Personally, I believe that we could unify some classes of the PB & PP, since a 
part of the code is overlapping; although some parts of the codes are 
completely different. Some comments on this -I see Chia just discussed some of 
these matters earlier today-. (Chia please correct me if I have misinterpreted 
something):


  *   The distinction between the two codes, conceptually, is that the 
PotentialBlocks have flat faces with no curvature, while the PotentialParticles 
can have curved faces and look like "cushions" (I liked that reference!). This 
curvature of the latter is controlled by the parameters "k" and "R" in the 
PotentialParticle shape class.

Also, the PotentialBlocks code has been developed to incorporate some more 
parameters and to be compatible with the BlockGen code, in which a 
PotentialBlock can be subdivided to more blocks, by intersecting the particle 
with discontinuity planes.

You will find in the source code that "R" is used in some parts of the PB code 
as well, but as a reference length unit and not as the "radius of a shadow 
particle", as it is in the PP class. So, in a case where the PB and PP are 
unified, one should choose "k=0", in order to get a particle with flat faces 
(like the PB) or "k>0", in order to get a particle with curved faces (like the 
PP). I should clarify, that when using the PB code, even if a non-zero value is 
given for "k", it is not used; the faces remain flat. I guess it just stayed in 
the code, to maintain some architectural similarity between the PB & PP classes.


  *   The most important distinction between the PB and PP codes from a 
programming standpoint is the contact detection algorithms used, as, in the 
former contact is established using linear programming (and CLP software), 
while in the latter contact is established using conical optimisation (either 
with MOSEK or Chia's second order code).

So, if we were to merge the Shape (PotentialBlock & PotentialParticle), Bound 
(PotentialBlock2AABB & PotentialParticle2AABB), a distinction could be made 
regarding the IPhys functor, so that, when k=0 (PB particles) we use the 
Ig2_PB_PB_ScGeom & Ip2_FrictMat_FrictMat_KnKsPBPhys functors, while if k>0 
(curved faces), we use the Ig2_PP_PP_ScGeom & Ip2_FrictMat_FrictMat_KnKsPhys 
functors, respectivelly. As Chia said, I'm not sure we can unify the IGeom 
functors, as they were developed under different conceptions; though, new ideas 
are welcome :) .

I am interested to improve these codes, since I currently use the 
PotentialBlock class for my PhD. I don't think that I have the technical 
knowledge to apply these changes by myself. Maybe we can achieve this with some 
periodic consulting from Chia and some help from you Janek? Send me an email if 
you have the time to assist on this, I'm happy to discuss.

Chia and Janek, do you think it would be of value to merge just part of the 
codes, i.e. only the Shape and Bound classes for now, to simplify things?


  *   Regarding the the "heat-capacity" parameter, I'm afraid I can't help 
much, as I am not familiar with the topic.


These are some thoughts on my part. I'm very interested to hear more from you 
Janek, as you know YADE through and through and from Chia, as he is the 
original developer of all this work and I believe he can give us a better 
understanding of the conceptual design of the codes and if he thinks we should 
merge them.


I will go through with removing the warnings during the next days & I will also 
be sending a piece of documentation in .rst format regarding these codes soon.


Sorry for the long post.

Best Regards,


Vasileios





From: Yade-dev  
on behalf of Chia Weng Boon 
Sent: 27 January 2019 15:03:54
Cc: Yade developers
Subject: Re: [Yade-dev] Potential Blocks and Potential Particles - brief 
analysis of the Object Oriented C++ source code

Hi Janek,
Potential Blocks and Potential Particles are different algorithms.  Potential 
Blocks (PB) were developed for polygonal particles "without the spherical 
term".  Potential Particles (PP) were developed for general convex 
non-spherical particles.

The PB algorithm is based on linear programming (solved by calling linear 
programming libraries, now CLP ), and the contact point is calculated as the 
analytic centre.

The PP algorithm requires solving

Re: [Yade-dev] Potential Blocks and Potential Particles - Documentation

[Vasileios Angelidakis (PGR)]

Hi,


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

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


All the best,


Vasileios



From: Yade-dev  
on behalf of Janek Kozicki 
Sent: 21 January 2019 20:19:04
To: Chia Weng Boon
Cc: Yade developers
Subject: Re: [Yade-dev] Potential Blocks and Potential Particles - Documentation

Hi Boon,

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

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

Here's the list of problems I encountered:

WedgeYADE.py

The scene is empty until I click Display->intrAllWire

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

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

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


cubePBscaled.py

The same problem as above also there are extra messages:

../yade:70: DeprecationWarning: dynamic=True is deprecated, use fixed=False 
instead
  print 20*'*'+' UNEXPECTED EXCEPTION WHILE RUNNING TESTS '+20*'*'
  print 'WARNING: compiled without OpenMP, -j/--threads/--cores have no effect.'
  else: os.environ['OMP_NUM_THREADS']='1'

basic.py

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


cubePPscaled.py

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


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

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



best regards
Janek




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

> Hi all,
>
> In my DPhil thesis submitted in 2013, I previously developed algorithms for
> (i) block generation and contact detection between polyhedral blocks (I
> have named it as Potential Blocks in YADE), and also (ii) contact detection
> between general non-spherical particles (Potential Particles).
>
> http://www2.eng.ox.ac.uk/civil/publications/theses/boon
>
> It is now being updated with Coin-OR's clp library (2015) and I've added it
> into the config file in YADE (2016-2017).  I've written a brief
> introduction as to how to enable this feature in YADE (attached), so that
> it can be incorporated into YADE's Documentation (maybe 3rd edition?).  I
> am working in the industry currently, and can only spend time on a casual
> basis as a hobby (once in a few months).
>
> The algorithms for block generation and contact detection are already being
> used by other research groups.
>
> https://github.com/cb-geo/spark-rocks
>
> https://www.ce.berkeley.edu/news/2044
>
> https://www.cb-geo.com/team/
>
> Btw, recently I submitted a pull request, to update the description of some
> variables.
>
> Yours,
> CWBoon
>
>
> 
> Virus-free.
> www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


--
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
___
Mailing list: https://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] Trouble building from source on Ubuntu 18.04

[Vasileios Angelidakis (PGR)]

Hi all,


I just upgraded to Ubuntu 18.04 (which in retrospect doesn't feel like a good 
idea) and I have some difficulty building YADE from source. I cite below 1. the 
errors I get during configuring the build files and then 2. the errors I get 
when I try to compile them. Has anyone experienced similar problems? I would 
appreciate any advice on this.


Many thanks,


Vasileios


  *   1. Configuration of the compilation files

b7063391@sage17-drum008:~/myYade/newBuild_21_Jan_19$ cd 
/home/b7063391/myYade/newBuild_21_Jan_19/build
b7063391@sage17-drum008:~/myYade/newBuild_21_Jan_19/build$ cmake 
-DCMAKE_INSTALL_PREFIX=/home/b7063391/myYade/newBuild_21_Jan_19/install 
/home/b7063391/myYade/newBuild_21_Jan_19/trunk
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /usr/bin/python (found version "2.7.15")
-- Found OpenMP_C: -fopenmp (found version "4.5")
-- Found OpenMP_CXX: -fopenmp (found version "4.5")
-- Found OpenMP: TRUE (found version "4.5")
CMake Warning at /usr/share/cmake-3.10/Modules/FindQt4.cmake:620 (message):
  /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib/x86_64-linux-gnu"
  but QtCore could not be found there.  Qt is NOT installed correctly for the
  target build environment.
Call Stack (most recent call first):
  CMakeLists.txt:39 (INCLUDE)


-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Version is set to 2019-01-04.git-f5aa5f7
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so
-- GTS using gts-config /usr/bin/gts-config
-- Using GTS from /usr
-- Found GL2PS: /usr/lib/x86_64-linux-gnu/libgl2ps.so
-- Found CGAL: /usr/include, /usr/lib/x86_64-linux-gnu/libCGAL.so
-- Found NumPy: version "1.13.3" 
/usr/lib/python2.7/dist-packages/numpy/core/include
-- Found Loki: /usr/include
-- GCC Version >= 4.8. Adding -ftrack-macro-expansion=0
-- GCC Version >= 4.8. Adding -save-temps
-- GCC Version >= 4.9. Adding -fstack-protector-strong
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   python
--   thread
--   filesystem
--   iostreams
--   regex
--   serialization
--   system
--   date_time
--   chrono
--   atomic
--   Boost_VERSION: 106501
--   Boost_LIB_VERSION: 1_65_1
--   Boost_INCLUDE_DIRS: /usr/include
--   Boost_LIBRARIES: 
/usr/lib/x86_64-linux-gnu/libboost_python.so/usr/lib/x86_64-linux-gnu/libboost_thread.so/usr/lib/x86_64-linux-gnu/libboost_filesystem.so/usr/lib/x86_64-linux-gnu/libboost_iostreams.so/usr/lib/x86_64-linux-gnu/libboost_regex.so/usr/lib/x86_64-linux-gnu/libboost_serialization.so/usr/lib/x86_64-linux-gnu/libboost_system.so/usr/lib/x86_64-linux-gnu/libboost_date_time.so/usr/lib/x86_64-linux-gnu/libboost_chrono.so/usr/lib/x86_64-linux-gnu/libboost_atomic.so/usr/lib/x86_64-linux-gnu/libpthread.so
-- Found Eigen3: /usr/include/eigen3 (Required is at least version "2.91.0")
-- Found BZip2: /usr/lib/x86_64-linux-gnu/libbz2.so (found version "1.0.6")
-- Looking for BZ2_bzCompressInit
-- Looking for BZ2_bzCompressInit - found
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version 
"2.7.15rc1")
-- Found Eigen3, version: 3.3.4
-- Disable vectorization
-- The imported target "vtkRenderingPythonTkWidgets" references the file
   "/usr/lib/x86_64-linux-gnu/libvtkRenderingPythonTkWidgets.so"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/cmake/vtk-6.3/VTKTargets.cmake"
but not all the files it references.

-- The imported target "vtk" references the file
   "/usr/bin/vtk"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/cmake/vtk-6.3/VTKTargets.cmake"
but not all the files it references.

-- Found VTK
-- Found OpenMP_C: -fopenmp (found version "4.5")
-- F

Re: [Yade-dev] Potential Blocks in a Periodic Box

[Vasileios Angelidakis (PGR)]

Hi Bruno,


Thanks for taking the time to aid me.

I looked for the the "shift2" variable and it seems exactly what I need to 
focus on; cheers!

I will try to sort this out and let you know of the outcome.


Jan, if you beat me to the solution in the meanwhile, you 'll be making my week 
:)


Kind Regards,


Vasileios


Vasileios Angelidakis

Post-Graduate Researcher in Geotechnical Engineering

School of Engineering, Newcastle University

Room 3.04, Drummond Building

Devonshire Terrace, Newcastle upon Tyne, NE1 7RU, UK


From: Yade-dev  
on behalf of Bruno Chareyre 
Sent: 02 November 2018 15:08:58
To: yade-dev@lists.launchpad.net
Subject: Re: [Yade-dev] Potential Blocks in a Periodic Box

Hi Vasileios,
Periodicity is relatively easy to implement since it only has to deal
with periodicity of interactions.
You should grep variable "shift2" in the source code to see how
interactions are made periodic.
Bruno




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

Re: [Yade-dev] Potential Blocks in a Periodic Box

[Vasileios Angelidakis (PGR)]

Hi,


Jan, thank you for even trying to give a solution to this! :) It is much 
appreciated!


I am using the latest version of YADE downloaded from github (I don't have a 
number of the version, as it appears as yade-Unknown) and my operating system 
is Ubuntu 16.04.5 LTS. I have compiled the code after enabling the 
"PotentialBlock" and the "PotentialParticle" classes.


I found something interesting. Using the PotentialBlocks class, contact 
detection works smoothly, but the periodic boundaries are not respected, while 
if I use the PotentialParticles class, the contact detection does not work, but 
the generated particles interact with the periodic box. This is quite bizarre, 
since these two classes are practically twins (same mathematical formulation of 
the particles, using different contact detection algorithms each).


Kind Regards,


Vasileios


Vasileios Angelidakis

Post-Graduate Researcher in Geotechnical Engineering

School of Engineering, Newcastle University

Room 3.04, Drummond Building

Devonshire Terrace, Newcastle upon Tyne, NE1 7RU, UK

E: v.angelidak...@ncl.ac.uk<mailto:v.angelidak...@ncl.ac.uk> T: +44 
(0)7380317986 W: Personal Page<https://www.students.ncl.ac.uk/vangelidakis2/>


From: Yade-dev  
on behalf of Jan Stránský 
Sent: 01 November 2018 08:38:42
To: Vasileios Angelidakis (PGR)
Cc: Yade developers
Subject: Re: [Yade-dev] Potential Blocks in a Periodic Box

Hello,
what version of Yade and what operating system do you use?
PotentialBlocks are not compiled by default. I can **try** your code and to 
help you (without any guarantee to succeed :-)

In general, bodies should have no problems with O.periodic=True, but 
interaction evaluation should implement something extra..

cheers
Jan


st 31. 10. 2018 v 17:11 odesílatel Vasileios Angelidakis 
mailto:b7063...@newcastle.ac.uk>> napsal:

Hi,

I have started working on the "PotentialBlock" code in YADE for the generation 
of polyhedra using the Potential Particles approach. I want to use these 
particles in a periodic cell, but it seems the PotentialBlock class is not 
compatible with periodic boundaries. Would be grateful to get any advice on 
whether this is the case and where I should focus to implement it myself? (FYI 
I am still a rookie in C++ development).



In the following lines I paste a minimal working script to demonstrate a 
potential block falling through the periodic cell.
Visualisation of the simulation is available only in a VTK format (not in qt).

Cheers,



Vasileios



Vasileios Angelidakis

Post-Graduate Researcher in Geotechnical Engineering

School of Engineering, Newcastle University



The script:

from yade import pack
import math

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 
# # # # # # # # # # # # # # # # # # # # # # # # # # #
# Clear the directory where the VTK results will be written of all files (but 
not subdirectories).
# The directory is cleared, so files from previous runs do not interfere with 
files from new runs.
# If the directory does not exist, it is created.

import os, shutil
folder = './vtk_ele'
try:
os.mkdir(folder[2:])
except:
for the_file in os.listdir(folder):
file_path = os.path.join(folder, the_file)
try:
if os.path.isfile(file_path):
os.unlink(file_path)
#elif os.path.isdir(file_path): shutil.rmtree(file_path) #uncomment 
to also delete the subdirectories
except Exception as e:
print(e)
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 
# # # # # # # # # # # # # # # # # # # # # # # # # # #



# Engines
O.engines=[
ForceResetter(),
InsertionSortCollider([PotentialBlock2AABB()],verletDist=0.01),
InteractionLoop(
[Ig2_PB_PB_ScGeom()],
[Ip2_FrictMat_FrictMat_KnKsPBPhys(kn_i=1e8, ks_i=1e8, Knormal = 1e8, 
Kshear = 1e8, useFaceProperties=False, calJointLength=False, 
twoDimension=False, unitWidth2D=1.0, viscousDamping=0.05)],
[Law2_SCG_KnKsPBPhys_KnKsPBLaw(label='law',neverErase=False)]
),
NewtonIntegrator(damping=0.0,exactAsphericalRot=False,gravity=[0,-10,0]),

VTKRecorder(fileName=folder+'/vtkPeriodicCell-VTKRecorder-',recorders=['pericell'],iterPeriod=200)
]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 
# # # # # # # # # # # # # # # # # # # # # # # # # # #



# Basic dimensions used in the model
distanceToCentre= 0.5
meanSize = 1.0
heightOfBase = 5.0*meanSize

# Material definition
powderDensity = 2000
O.materials.append(FrictMat(young=150e6,poisson=.4,frictionAngle=radians(0.0),density=powderDensity,label='frictionless'))

# Creation of a spheres packing, following a desired PSD
sp=pack.SpherePack()

mn,mx=(Vector3(0,0,0),
   Vector3(4*heightOfBase, 4*heightOfBase, 4*heightOfBase))

sphereRad = sqrt(3.0)*0.5*meanSize
sp.mak