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

[Chia Weng Boon]

Sorry I missed clicking the subsequent buttons.  I just merged upstream,
committed and pulled again.

https://github.com/yade/trunk/pulls

Boon

On Sun, Jan 27, 2019 at 11:06 PM Janek Kozicki  wrote:

> Hi Boon,
>
> great thanks. I think that fixing orientation should be possible :)
> I cannot find your pull request though. Can you send a link?
>
> cheers
> Janek
>
> Chia Weng Boon said: (by the date of Sun, 27 Jan 2019 22:28:11 +0800)
>
> > Hi Janek,
> > I submitted a Pull Request.  I fixed the display for the free fall
> examples
> > using Marching Cubes.  However, the orientation of the particles are not
> > completely correct yet in QT.  See for example the Wedge Example.
> > I think that was the reason why I moved to ParaView.
> >
> > Boon
> >
> > On Sat, Jan 26, 2019 at 11:19 PM Janek Kozicki 
> wrote:
> >
> > > Hi Boon,
> > >
> > > thanks for you reply. Yes, I think that this marching cubes method
> > > can work really good. The only missing thing is to make the caching
> > > of calculated triangles correctly. Once the triangles for the shape
> > > are calculated you can use them all the time, unless the body deforms
> or
> > > is cut in half (I'm not sure if this can happen).
> > >
> > > A thing to discuss: you could store cached triangles not inside
> > > Gl1_PotentialParticle but inside PotentialParticle with Attr::hidden
> > > or (Attr::hidden|Attr::noSave). For example see into
> > > pkg/common/Cylinder.hpp as an example. In this way you will not need
> > > this loop in pkg/common/Gl1_PotentialParticle.cpp line 112, and
> > > automatically you have solved the problem what to draw when a body
> > > was deleted or added to scene. Because you only recalculate marching
> > > cubes for particular single body when you need to draw it and it
> > > wasn't generated yet.
> > >
> > > I hope that the post which I have just sent to mailing list about
> > > object oriented design deficiencies of your code wasn't too harsh.
> > > My apologies.
> > >
> > > best regards
> > > Janek
> > >
> > > Chia Weng Boon said: (by the date of Sat, 26 Jan 2019 11:12:40
> +0800)
> > >
> > > > Dear Janek,
> > > > I will look into it. Thanks. In the python script, the vtk files at
> > > > specific time intervals are output into the vtk folder.  I have
> been
> > > using
> > > > ParaView mainly for visualisation for both Potential Particles and
> > > > Potential Blocks.  The colour of the particles can also be changed in
> > > > ParaView.  I suspect that the Marching Cube display is not showing
> the
> > > > position and size of the particles correctly (I abandoned the
> marching
> > > > cubes quite long ago, but agree that real time display with
> simulation is
> > > > more user friendly)
> > > >
> > > > Let me check the example files again.
> > > >
> > > > Boon
> > >
> > > ___
> > > Mailing list: https://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 - Documentation

[Janek Kozicki]

Hi Boon,

great thanks. I think that fixing orientation should be possible :)
I cannot find your pull request though. Can you send a link?

cheers
Janek

Chia Weng Boon said: (by the date of Sun, 27 Jan 2019 22:28:11 +0800)

> Hi Janek,
> I submitted a Pull Request.  I fixed the display for the free fall examples
> using Marching Cubes.  However, the orientation of the particles are not
> completely correct yet in QT.  See for example the Wedge Example.
> I think that was the reason why I moved to ParaView.
> 
> Boon
> 
> On Sat, Jan 26, 2019 at 11:19 PM Janek Kozicki  wrote:
> 
> > Hi Boon,
> >
> > thanks for you reply. Yes, I think that this marching cubes method
> > can work really good. The only missing thing is to make the caching
> > of calculated triangles correctly. Once the triangles for the shape
> > are calculated you can use them all the time, unless the body deforms or
> > is cut in half (I'm not sure if this can happen).
> >
> > A thing to discuss: you could store cached triangles not inside
> > Gl1_PotentialParticle but inside PotentialParticle with Attr::hidden
> > or (Attr::hidden|Attr::noSave). For example see into
> > pkg/common/Cylinder.hpp as an example. In this way you will not need
> > this loop in pkg/common/Gl1_PotentialParticle.cpp line 112, and
> > automatically you have solved the problem what to draw when a body
> > was deleted or added to scene. Because you only recalculate marching
> > cubes for particular single body when you need to draw it and it
> > wasn't generated yet.
> >
> > I hope that the post which I have just sent to mailing list about
> > object oriented design deficiencies of your code wasn't too harsh.
> > My apologies.
> >
> > best regards
> > Janek
> >
> > Chia Weng Boon said: (by the date of Sat, 26 Jan 2019 11:12:40 +0800)
> >  
> > > Dear Janek,
> > > I will look into it. Thanks. In the python script, the vtk files at
> > > specific time intervals are output into the vtk folder.  I have been  
> > using  
> > > ParaView mainly for visualisation for both Potential Particles and
> > > Potential Blocks.  The colour of the particles can also be changed in
> > > ParaView.  I suspect that the Marching Cube display is not showing the
> > > position and size of the particles correctly (I abandoned the marching
> > > cubes quite long ago, but agree that real time display with simulation is
> > > more user friendly)
> > >
> > > Let me check the example files again.
> > >
> > > Boon  
> >
> > ___
> > Mailing list: https://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] Potential Blocks and Potential Particles - Documentation

[Chia Weng Boon]

Hi Janek,
I submitted a Pull Request.  I fixed the display for the free fall examples
using Marching Cubes.  However, the orientation of the particles are not
completely correct yet in QT.  See for example the Wedge Example.
I think that was the reason why I moved to ParaView.

Boon

On Sat, Jan 26, 2019 at 11:19 PM Janek Kozicki  wrote:

> Hi Boon,
>
> thanks for you reply. Yes, I think that this marching cubes method
> can work really good. The only missing thing is to make the caching
> of calculated triangles correctly. Once the triangles for the shape
> are calculated you can use them all the time, unless the body deforms or
> is cut in half (I'm not sure if this can happen).
>
> A thing to discuss: you could store cached triangles not inside
> Gl1_PotentialParticle but inside PotentialParticle with Attr::hidden
> or (Attr::hidden|Attr::noSave). For example see into
> pkg/common/Cylinder.hpp as an example. In this way you will not need
> this loop in pkg/common/Gl1_PotentialParticle.cpp line 112, and
> automatically you have solved the problem what to draw when a body
> was deleted or added to scene. Because you only recalculate marching
> cubes for particular single body when you need to draw it and it
> wasn't generated yet.
>
> I hope that the post which I have just sent to mailing list about
> object oriented design deficiencies of your code wasn't too harsh.
> My apologies.
>
> best regards
> Janek
>
> Chia Weng Boon said: (by the date of Sat, 26 Jan 2019 11:12:40 +0800)
>
> > Dear Janek,
> > I will look into it. Thanks. In the python script, the vtk files at
> > specific time intervals are output into the vtk folder.  I have been
> using
> > ParaView mainly for visualisation for both Potential Particles and
> > Potential Blocks.  The colour of the particles can also be changed in
> > ParaView.  I suspect that the Marching Cube display is not showing the
> > position and size of the particles correctly (I abandoned the marching
> > cubes quite long ago, but agree that real time display with simulation is
> > more user friendly)
> >
> > Let me check the example files again.
> >
> > Boon
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

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

[Janek Kozicki]

Hi Boon,

thanks for you reply. Yes, I think that this marching cubes method
can work really good. The only missing thing is to make the caching
of calculated triangles correctly. Once the triangles for the shape
are calculated you can use them all the time, unless the body deforms or
is cut in half (I'm not sure if this can happen).

A thing to discuss: you could store cached triangles not inside
Gl1_PotentialParticle but inside PotentialParticle with Attr::hidden
or (Attr::hidden|Attr::noSave). For example see into
pkg/common/Cylinder.hpp as an example. In this way you will not need
this loop in pkg/common/Gl1_PotentialParticle.cpp line 112, and
automatically you have solved the problem what to draw when a body
was deleted or added to scene. Because you only recalculate marching
cubes for particular single body when you need to draw it and it
wasn't generated yet.

I hope that the post which I have just sent to mailing list about
object oriented design deficiencies of your code wasn't too harsh.
My apologies.

best regards
Janek

Chia Weng Boon said: (by the date of Sat, 26 Jan 2019 11:12:40 +0800)

> Dear Janek,
> I will look into it. Thanks. In the python script, the vtk files at
> specific time intervals are output into the vtk folder.  I have been using
> ParaView mainly for visualisation for both Potential Particles and
> Potential Blocks.  The colour of the particles can also be changed in
> ParaView.  I suspect that the Marching Cube display is not showing the
> position and size of the particles correctly (I abandoned the marching
> cubes quite long ago, but agree that real time display with simulation is
> more user friendly)
> 
> Let me check the example files again.
> 
> Boon

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

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

[Chia Weng Boon]

Dear Janek,
I will look into it. Thanks. In the python script, the vtk files at
specific time intervals are output into the vtk folder.  I have been using
ParaView mainly for visualisation for both Potential Particles and
Potential Blocks.  The colour of the particles can also be changed in
ParaView.  I suspect that the Marching Cube display is not showing the
position and size of the particles correctly (I abandoned the marching
cubes quite long ago, but agree that real time display with simulation is
more user friendly)

Let me check the example files again.

Boon



On Saturday, January 26, 2019, Bruno Chareyre <
bruno.chare...@grenoble-inp.fr> wrote:

>
>
> On 1/25/19 3:41 PM, Janek Kozicki wrote:
>
>>
>> To explain it in simplest terms: a triangular side of a polyhedron is
>> not flat. It has some curvature, calculation of this curvature would
>> require solving equation f(x,y,z)==0. And this is difficult.
>>
>
> Got it, thanks for clarification.
> Bruno
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

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

[Bruno Chareyre]

On 1/25/19 3:41 PM, Janek Kozicki wrote:


To explain it in simplest terms: a triangular side of a polyhedron is
not flat. It has some curvature, calculation of this curvature would
require solving equation f(x,y,z)==0. And this is difficult.


Got it, thanks for clarification.
Bruno


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

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

[Bruno Chareyre]

On 1/24/19 8:07 PM, Janek Kozicki wrote:


Actually PotentialParticles are not Minkowski sums. [...] he adds 
x^2+y^2+z^2-R^2 to this
formula. This means that he is adding a sphere to this formula, and
all the shapes suddenly look like cushions with soft corners instead
of polyhedral Minkowki sums.


What you describe seems to be what I called Minkowski sum (polyhedron + 
sphere).
It boils down geometrically to a set of spheres, cylinders, and planar 
faces. That's what we have with PFacets.
You can see an example with examples/pfacet/mesh-pfacet.py (note that 
the edges are not sharp).


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

[Janek Kozicki]

Bruno Chareyre said: (by the date of Wed, 23 Jan 2019 11:03:27 +0100)

> On 1/22/19 2:38 PM, Chia Weng Boon wrote:
> >
> > Can someone lead me to the file for polyhedra display in YADE? Maybe I 
> > can try to get the display to work in qt.  I can't recall how I made 
> > it work for Potential Particles in qt.  At one point in time, I always 
> > playing with marching cubes..but it used too much memory and the 
> > rendering was not very nice.
> >  
> 
> Hi,
> I don't know the marching cube method but if potential blocks are 
> Minkowski sums of polyhedra and spheres - as I think they are, then it 
> should be enough to combine existing functors since that's exactly how 
> PFacet polyhedra are displayed. And it should be efficient.
> Let me know.
> See the figures in [1], they are from yade GUI for most of them.
> Bruno

Actually PotentialParticles are not Minkowski sums. This would be the
case if a sphere was not added to the particle shape. Previous
sentence might sound weird, but that's actually how it works. Chia
defines a formula for the shape of the particle (declaring each side
of a polyhedral). The isosurface at which this formula==0 is the
surface of this particle. Up to this point it would be directly a
Minkowski sum. But afterwards he adds x^2+y^2+z^2-R^2 to this
formula. This means that he is adding a sphere to this formula, and
all the shapes suddenly look like cushions with soft corners instead
of polyhedral Minkowki sums.

Chia, I have discovered that setting Gl1_PotentialParticle().store=True
fixes all the display problems which I had with
examples/PotentialParticles/cubePBscaled.py
Why did you set it to false by default in C++ code?

When it was false the marching cubes algorithm was executed for every
display refresh, and when drawing just one particle it was
recalculating marching cubes for all perticles. No wonder it was
slow. Like n^2 slow.


So after setting store=True, the display now works nicely. But still
the collisions do not work. I hope that you can fix that. I made a
short video to demonstrate what I'm talking about:

https://www.youtube.com/watch?v=1XEtGrbo7lM


Regarding other two examples:

PotentialBlocks/WedgeYADE.py
PotentialBlocks/cubePBscaled.py

I could not get them to work no matter what. The particles just sit
there and never move. I will write next mail about that, because I
have done some analysis of your C++ code and it might be useful to
someone who plans to continue working on PotentailParticles, maybe
Vasileios?

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

[Bruno Chareyre]

On 1/22/19 2:38 PM, Chia Weng Boon wrote:


Can someone lead me to the file for polyhedra display in YADE? Maybe I 
can try to get the display to work in qt.  I can't recall how I made 
it work for Potential Particles in qt.  At one point in time, I always 
playing with marching cubes..but it used too much memory and the 
rendering was not very nice.




Hi,
I don't know the marching cube method but if potential blocks are 
Minkowski sums of polyhedra and spheres - as I think they are, then it 
should be enough to combine existing functors since that's exactly how 
PFacet polyhedra are displayed. And it should be efficient.

Let me know.
See the figures in [1], they are from yade GUI for most of them.
Bruno

[1] https://www.sciencedirect.com/science/article/abs/pii/S0266114415001235


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

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

[Janek Kozicki]

Hi Chia,

I hope that Jan could fix basic.py, because he has written it :)

If you execute command `grep Gl1_PotentialParticle . -r` you will find that 
polyhedra display is in ./pkg/common/Gl1_PotentialParticle.cpp

Actually by fiddling around in GUI → Display → Gl1_PotentialParticle
I saw that after reducing the marching cube size the display can
speed up a little bit.

I tried locally commenting out //TRVAR3(…) and the examples start to
look a bit better. After toggling GUI → Display → bound, at least
boxes are shown.

I never used paraview that much actually. Are PotentialParticles drawn
properly there? Using those a,b,c,d arguments? Then perhaps we could
have a look at the code how they are being drawn. That could help to
speed up drawing without marching cubes.

If paraview can draw them, then what name paraview uses for them?
Maybe I can find this code with command `grep TheirName . -r` in the
paraview source code. They have BSD license and creative commons in
some parts. So we can use their code without any problems :)

best regards
Janek


Chia Weng Boon said: (by the date of Tue, 22 Jan 2019 21:38:48 +0800)

> Hi Janek,
> Thanks for checking.
> TRVAR3 - I didn't realise that this was uncommented in KnKsPhysPB my
> commit.
> basic.py - I couldn't recall how the file came about.
> 
> I just submitted another pull request, uncommenting TRVAR3 and removing
> basic.py
> I use ParaView for display, and the vtk files would appear in the vtk
> folder.
> 
> Can someone lead me to the file for polyhedra display in YADE? Maybe I can
> try to get the display to work in qt.  I can't recall how I made it work
> for Potential Particles in qt.  At one point in time, I always playing with
> marching cubes..but it used too much memory and the rendering was not very
> nice.
> 
> 
> HI all,
> Thanks for your suggestions.  I will look into the rst file.
> 
> Yours,
> Boon

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

[Chia Weng Boon]

Hi Janek,
Thanks for checking.
TRVAR3 - I didn't realise that this was uncommented in KnKsPhysPB my
commit.
basic.py - I couldn't recall how the file came about.

I just submitted another pull request, uncommenting TRVAR3 and removing
basic.py
I use ParaView for display, and the vtk files would appear in the vtk
folder.

Can someone lead me to the file for polyhedra display in YADE? Maybe I can
try to get the display to work in qt.  I can't recall how I made it work
for Potential Particles in qt.  At one point in time, I always playing with
marching cubes..but it used too much memory and the rendering was not very
nice.


HI all,
Thanks for your suggestions.  I will look into the rst file.

Yours,
Boon


On Tue, Jan 22, 2019 at 8:25 PM Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> wrote:

> I confirm *.rst is the best, especially if it is about package
> dependencies, install procedure, classes and such.
> «inflating» documentation is not a risk at all, it is a very suitable
> thing.
> Bruno
>
> Le mar. 22 janv. 2019 10:13, Robert Caulk  a écrit :
>
>> >>Is there any practical preference between .rst or latex files?
>>
>> 2 more cents:
>>
>> If you are focused on a practical tutorial/guide, it is really best to
>> write it in .rst so it can be easily added to the website (and version
>> controlled as Jerome points out). If, on the other hand, you want to
>> present some methods, add a couple supporting results, and you want your
>> work to be citable with google scholar visibility, then a tex file with
>> Yade Technical Archive is best (and "frozen" as Jerome points out).  If you
>> prefer the later,  let me know so I can send you the current latex
>> template.
>>
>> -rc
>>
>>
>>
>> On Tue, Jan 22, 2019 at 9:35 AM Jerome Duriez 
>> wrote:
>>
>>> > Is there any practical preference between .rst or latex files?
>>>
>>>
>>> In my opinion :
>>>
>>> - .rst files, and being somehow part of the doc, as we see it on
>>> https://yade-dem.org/doc, is much more visible and much easier to
>>> maintain (by different people, in particular) : it's under git version
>>> control for instance...
>>>
>>> On the other hand, the doc would not survive if it were inflated by new
>>> additions of sections each time someone proposes new stuff (which is
>>> otherwise obviously good)..
>>>
>>>
>>> - .tex files and Yade Technical archives make it much more one
>>> person-specific (for maintenance purposes). In my view, it's like a
>>> publication : almost frozen for all time.
>>>
>>> As a matter of fact we do not have any .tex files under version control
>>> (at the moment), and, in the way as I see things, it does not work for
>>> maintenance purposes to have something too deeply related with someone :
>>> people end up working at different institutions, or on a different
>>> subject, and they logically end up at some point not being able to
>>> maintain what they proposed earlier..
>>>
>>>
>>>
>>> As you see, this will not tremendously help you to make a choice, but I
>>> wanted to take the opportunity to express some general opinions on the
>>> subject. Others are welcome..
>>>
>>>
>>> Jérôme
>>>
>>> --
>>> Chargé de Recherche / Research Associate
>>> Irstea, RECOVER
>>> 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
>>> +33 (0)4 42 66 99 21
>>>
>>> On 21/01/2019 21:31, Vasileios Angelidakis (PGR) wrote:
>>> >
>>> > Hi,
>>> >
>>> >
>>> > Regarding the writing of a documentation for the "Potential Particles"
>>> > and the "Potential Blocks" codes, I am happy to help
>>> > on a more consistent basis, as I currently use them. Is there any
>>> > practical preference between .rst or latex files?
>>> >
>>> > Chia, I can transcribe your introductory word file and add some
>>> > "command-to-command" comments.
>>> >
>>> >
>>> > All the best,
>>> >
>>> >
>>> > Vasileios
>>> > <https://www.students.ncl.ac.uk/vangelidakis2/>
>>> >
>>> 
>>> > *From:* Yade-dev
>>> >  on
>>> > behalf of Janek Kozicki 
>>> > *Sent:* 21 January 2019 20:19:04
>>> > *To:* Chia Weng Boon
>>> >

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

[Bruno Chareyre]

I confirm *.rst is the best, especially if it is about package
dependencies, install procedure, classes and such.
«inflating» documentation is not a risk at all, it is a very suitable thing.
Bruno

Le mar. 22 janv. 2019 10:13, Robert Caulk  a écrit :

> >>Is there any practical preference between .rst or latex files?
>
> 2 more cents:
>
> If you are focused on a practical tutorial/guide, it is really best to
> write it in .rst so it can be easily added to the website (and version
> controlled as Jerome points out). If, on the other hand, you want to
> present some methods, add a couple supporting results, and you want your
> work to be citable with google scholar visibility, then a tex file with
> Yade Technical Archive is best (and "frozen" as Jerome points out).  If you
> prefer the later,  let me know so I can send you the current latex
> template.
>
> -rc
>
>
>
> On Tue, Jan 22, 2019 at 9:35 AM Jerome Duriez 
> wrote:
>
>> > Is there any practical preference between .rst or latex files?
>>
>>
>> In my opinion :
>>
>> - .rst files, and being somehow part of the doc, as we see it on
>> https://yade-dem.org/doc, is much more visible and much easier to
>> maintain (by different people, in particular) : it's under git version
>> control for instance...
>>
>> On the other hand, the doc would not survive if it were inflated by new
>> additions of sections each time someone proposes new stuff (which is
>> otherwise obviously good)..
>>
>>
>> - .tex files and Yade Technical archives make it much more one
>> person-specific (for maintenance purposes). In my view, it's like a
>> publication : almost frozen for all time.
>>
>> As a matter of fact we do not have any .tex files under version control
>> (at the moment), and, in the way as I see things, it does not work for
>> maintenance purposes to have something too deeply related with someone :
>> people end up working at different institutions, or on a different
>> subject, and they logically end up at some point not being able to
>> maintain what they proposed earlier..
>>
>>
>>
>> As you see, this will not tremendously help you to make a choice, but I
>> wanted to take the opportunity to express some general opinions on the
>> subject. Others are welcome..
>>
>>
>> Jérôme
>>
>> --
>> Chargé de Recherche / Research Associate
>> Irstea, RECOVER
>> 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
>> +33 (0)4 42 66 99 21
>>
>> On 21/01/2019 21:31, Vasileios Angelidakis (PGR) wrote:
>> >
>> > Hi,
>> >
>> >
>> > Regarding the writing of a documentation for the "Potential Particles"
>> > and the "Potential Blocks" codes, I am happy to help
>> > on a more consistent basis, as I currently use them. Is there any
>> > practical preference between .rst or latex files?
>> >
>> > Chia, I can transcribe your introductory word file and add some
>> > "command-to-command" comments.
>> >
>> >
>> > All the best,
>> >
>> >
>> > Vasileios
>> > <https://www.students.ncl.ac.uk/vangelidakis2/>
>> > 
>> > *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 

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

[Robert Caulk]

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

2 more cents:

If you are focused on a practical tutorial/guide, it is really best to
write it in .rst so it can be easily added to the website (and version
controlled as Jerome points out). If, on the other hand, you want to
present some methods, add a couple supporting results, and you want your
work to be citable with google scholar visibility, then a tex file with
Yade Technical Archive is best (and "frozen" as Jerome points out).  If you
prefer the later,  let me know so I can send you the current latex
template.

-rc



On Tue, Jan 22, 2019 at 9:35 AM Jerome Duriez 
wrote:

> > Is there any practical preference between .rst or latex files?
>
>
> In my opinion :
>
> - .rst files, and being somehow part of the doc, as we see it on
> https://yade-dem.org/doc, is much more visible and much easier to
> maintain (by different people, in particular) : it's under git version
> control for instance...
>
> On the other hand, the doc would not survive if it were inflated by new
> additions of sections each time someone proposes new stuff (which is
> otherwise obviously good)..
>
>
> - .tex files and Yade Technical archives make it much more one
> person-specific (for maintenance purposes). In my view, it's like a
> publication : almost frozen for all time.
>
> As a matter of fact we do not have any .tex files under version control
> (at the moment), and, in the way as I see things, it does not work for
> maintenance purposes to have something too deeply related with someone :
> people end up working at different institutions, or on a different
> subject, and they logically end up at some point not being able to
> maintain what they proposed earlier..
>
>
>
> As you see, this will not tremendously help you to make a choice, but I
> wanted to take the opportunity to express some general opinions on the
> subject. Others are welcome..
>
>
> Jérôme
>
> --
> Chargé de Recherche / Research Associate
> Irstea, RECOVER
> 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
> +33 (0)4 42 66 99 21
>
> On 21/01/2019 21:31, Vasileios Angelidakis (PGR) wrote:
> >
> > Hi,
> >
> >
> > Regarding the writing of a documentation for the "Potential Particles"
> > and the "Potential Blocks" codes, I am happy to help
> > on a more consistent basis, as I currently use them. Is there any
> > practical preference between .rst or latex files?
> >
> > Chia, I can transcribe your introductory word file and add some
> > "command-to-command" comments.
> >
> >
> > All the best,
> >
> >
> > Vasileios
> > <https://www.students.ncl.ac.uk/vangelidakis2/>
> > ----
> > *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 i

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

[Jerome Duriez]

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



In my opinion :

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


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



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


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




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



Jérôme

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

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


Hi,


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


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



All the best,


Vasileios
<https://www.students.ncl.ac.uk/vangelidakis2/>

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

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

<https://www.students.ncl.ac.uk/vangelidakis2/>

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
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> Virus-free.
> www.avast.com<http://www.avast.com>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> <#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

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

[Janek Kozicki]

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

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

[Bruno Chareyre]

Hi Boon,

Brilliant! Thank you for this, very much!
First of all, is it ok to send replies to yade-dev or do you want 
messages to your personal mailbox as well (currently in cc)?


I will check you pull request.
Please note that we will be migrating from github to gitlab soon for 
hosting source code.
If you have too limited time to follow this switch everything should be 
fine as long as you notify us on yade-dev list (else merge requests to 
github could remain unnoticed - if not impossible when/if the github 
repo will be closed).


The attached file for introduction will be a problem to handle. Opening 
it with libreoffice is enough to mess things up completely on my side.
A minimal solution is to convert it to pdf and sending some upload. 
Better solutions are to type in an *.rst format or latex format for 
inclusion in yade technical archives.


Also feel free to include additional references in the list of yade 
publications[1,2] (even possibly not by you but by people using your 
implementation).


Best regards

Bruno

[1] https://github.com/yade/trunk/blob/master/doc/yade-articles.bib (source)
[2] https://www.yade-dem.org/doc/publications.html (output)


On 1/21/19 6:02 AM, Chia Weng Boon wrote:

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 
 




___
Mailing list: https://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] Potential Blocks and Potential Particles - Documentation

[Chia Weng Boon]

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>


PotentialParticles_PotentialBlocks_guide.docx
Description: MS-Word 2007 document
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp