[Yade-dev] Release, GitLab?

[Anton Gladky]

Hello yade devs,

as far as I understand we are moving (have moved already) to
GitLab. But I saw some commits on github as well.

Some  questions:

- Should we disable commits on github?
- Should all links in the Yade code be updated to GitLab variants?
- Do we prepare release from GitLab?

Also we need to decide, how this release will be done. As usually,
creating 2019.01-branch and tagging the release there? Or creating
the single "stable" branch for all other future releases?

I am ready to postpone the release for the next couple of days to
solve this questions, if necessary.

Thanks for your work on Yade code.

Anton

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

Re: [Yade-dev] Fixing the examples FEMxDEM

[Janek Kozicki]

I did read https://yade-dev.gitlab.io/trunk/FEMxDEM.html :) Wondering
what I could add there if I manage to make it work.

But no, it still doesn't work.

But I am getting closer. I see that the error is related to missing
file ./py/FEMxDEM/msFEM2D.py, I tried export PYTHONPATH=../../py/FEMxDEM
with this I have a more familiar error:

ImportError: No module named yadeimport

which means that I'm on the right track.


Bruno Chareyre said: (by the date of Sun, 27 Jan 2019 18:31:28 +0100)

> So it now works? If so congrats.
> I realize you may not be aware of doc pages about using fem*dem. There was
> maybe a solution there.
> Bruno
> 
> Le dim. 27 janv. 2019 17:39, Janek Kozicki  a écrit :
> 
> > I discovered that running this:
> >
> > run-escript yade ./biaxialSmooth.py
> >
> > produces a different error message:
> >
> > Traceback (most recent call last):
> >   File "../yade", line 241, in runScript
> > execfile(script,globals())
> >   File "./biaxialSmooth.py", line 9, in 
> > from msFEM2D import MultiScale
> > ImportError: No module named msFEM2D
> >
> > So finally importing esys.escript worked.
> >
> >
> > Janek Kozicki said: (by the date of Sun, 27 Jan 2019 15:54:17 +0100)
> >  
> > > I have found out that if I run from shell /usr/bin/run-escript (which
> > > is a part of python-escript package) then a python shell is started
> > > inside which the command
> > >
> > >   from esys.escript import *
> > >
> > > works. That is some progress. Now I don't know how to make it work
> > > inside yade python shell.
> > >
> > >
> > > Janek Kozicki said: (by the date of Sun, 27 Jan 2019 01:28:47 +0100)
> > >  
>  [...]  
> > +0100)  
>  [...]  
>  [...]  
>  [...]  
> > >
> > >
> > > --
> > > 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
> >
> >  


-- 
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 1813488] [NEW] build robot location moved during gitlab switch?

[Janek Kozicki]

Public bug reported:

Hi, in ./doc/sphinx/prog.rst line 118 it is written:

A build robot hosted at `3SR lab. `__ 
is tracking souce code changes.
...
The buildbot activity and logs can be `browsed online 


Is that still correct?

** Affects: yade
 Importance: Undecided
 Status: New

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

Title:
  build robot location moved during gitlab switch?

Status in Yade:
  New

Bug description:
  Hi, in ./doc/sphinx/prog.rst line 118 it is written:

  A build robot hosted at `3SR lab. 
`__ 
  is tracking souce code changes.
  ...
  The buildbot activity and logs can be `browsed online 


  Is that still correct?

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1813488/+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] Fixing the examples FEMxDEM

[Bruno Chareyre]

So it now works? If so congrats.
I realize you may not be aware of doc pages about using fem*dem. There was
maybe a solution there.
Bruno

Le dim. 27 janv. 2019 17:39, Janek Kozicki  a écrit :

> I discovered that running this:
>
> run-escript yade ./biaxialSmooth.py
>
> produces a different error message:
>
> Traceback (most recent call last):
>   File "../yade", line 241, in runScript
> execfile(script,globals())
>   File "./biaxialSmooth.py", line 9, in 
> from msFEM2D import MultiScale
> ImportError: No module named msFEM2D
>
> So finally importing esys.escript worked.
>
>
> Janek Kozicki said: (by the date of Sun, 27 Jan 2019 15:54:17 +0100)
>
> > I have found out that if I run from shell /usr/bin/run-escript (which
> > is a part of python-escript package) then a python shell is started
> > inside which the command
> >
> >   from esys.escript import *
> >
> > works. That is some progress. Now I don't know how to make it work
> > inside yade python shell.
> >
> >
> > Janek Kozicki said: (by the date of Sun, 27 Jan 2019 01:28:47 +0100)
> >
> > > Bruno Chareyre said: (by the date of Thu, 24 Jan 2019 19:09:26
> +0100)
> > >
> > > > FEMxDEM: Ning Guo (if this adress does not work I know Ning has
> > > > successors in HK)
> > >
> > > I am trying to make it work. I found that
> > > https://launchpad.net/escript-finley is probably inside package
> > > python-escript.
> > >
> > > I have compiled version python-escript_5.3-1_amd64.deb from source
> > > and installed it, But still I have this error when starting the
> > > FEMxDEM example:
> > >
> > >   from esys.escript import *
> > >   ImportError: No module named esys.escript
> > >
> > > The strangest thing is that when I do:
> > >
> > >   grep esys.escript . -r --color
> > >
> > > inside the source of package python-escript_5.3-1_amd64.deb I find
> > > hundreds of lines that are doing this `from esys.escript import *`.
> > > So I conclude that in yade it should work.
> > >
> > > However my devuan ascii is based on debian stretch, so maybe some of
> > > my packages are too old. I don't know which ones, though :( Or have a
> > > bug regarding python detecting newly installed modules.
> > >
> > > Maybe I should try this in devuan experimental, perhaps there it will
> > > work.
> > >
> > > Do you guys have any idea?
> > > --
> > > 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
>
>
> --
> 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] Fixing the examples FEMxDEM

[Janek Kozicki]

I discovered that running this:

run-escript yade ./biaxialSmooth.py

produces a different error message:

Traceback (most recent call last):
  File "../yade", line 241, in runScript
execfile(script,globals())
  File "./biaxialSmooth.py", line 9, in 
from msFEM2D import MultiScale
ImportError: No module named msFEM2D

So finally importing esys.escript worked.


Janek Kozicki said: (by the date of Sun, 27 Jan 2019 15:54:17 +0100)

> I have found out that if I run from shell /usr/bin/run-escript (which
> is a part of python-escript package) then a python shell is started
> inside which the command
> 
>   from esys.escript import *
> 
> works. That is some progress. Now I don't know how to make it work
> inside yade python shell.
> 
> 
> Janek Kozicki said: (by the date of Sun, 27 Jan 2019 01:28:47 +0100)
> 
> > Bruno Chareyre said: (by the date of Thu, 24 Jan 2019 19:09:26 +0100)
> >   
> > > FEMxDEM: Ning Guo (if this adress does not work I know Ning has 
> > > successors in HK)
> > 
> > I am trying to make it work. I found that
> > https://launchpad.net/escript-finley is probably inside package
> > python-escript.
> > 
> > I have compiled version python-escript_5.3-1_amd64.deb from source
> > and installed it, But still I have this error when starting the
> > FEMxDEM example:
> > 
> >   from esys.escript import *
> >   ImportError: No module named esys.escript
> > 
> > The strangest thing is that when I do:
> > 
> >   grep esys.escript . -r --color
> > 
> > inside the source of package python-escript_5.3-1_amd64.deb I find
> > hundreds of lines that are doing this `from esys.escript import *`.
> > So I conclude that in yade it should work.
> > 
> > However my devuan ascii is based on debian stretch, so maybe some of
> > my packages are too old. I don't know which ones, though :( Or have a
> > bug regarding python detecting newly installed modules.
> > 
> > Maybe I should try this in devuan experimental, perhaps there it will
> > work.
> > 
> > Do you guys have any idea?
> > -- 
> > 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


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

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 - brief analysis of the Object Oriented C++ source code

[Chia Weng Boon]

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 a nonlinear constrained optimisation
problem.  The code uses second order coning programming, where there are
two options.  The first is to call the function I wrote, or to call MOSEK
(only free for academics).  PB is faster than PP, since PB is easier to
solve.

The similar points between PB and PP are the way the contact normal is
calculated (PB without the spherical term), and the way the overlap
distance is calculated.

The reason why the physical contact properties were stored in the Shape
file (rather than Material) is because they were originally developed for
rock mechanics problems, where each face will have a different physical
property.The Potential Block contact detection algorithm is compatible with
the block generation algorithm here:
https://www.sciencedirect.com/science/article/pii/S0266352X14002122

Vasileios and myself were in touch.  From what I know, he's using the
PotentialBlock section (and also extracting the display with ParaView).  I
agree there are many redundant variables that need to be removed in order
to avoid confusion, and keen users may help greatly.  While I am much less
active, I am still using YADE very occasionally as a hobby, and would like
to see the algorithms get integrated better (eg display in QT, periodic
boundaries, etc).  Hopefully in the spirit of open source, interested users
will continue with this effort, leading to more possibilities.

Boon


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

> Hi,
>
> I looked a bit more into PotentialBlocks, and there are some things
> which surprise me, there seem to be some mistakes.
>
> 1. we strive to remove all compiler warnings. Currently when yade is
> compiled without PotentialBlocks, there are only 6 warnings, and
> four of them are caused by external libraries. Problem is that when
> compiling with PotentialBlocks there are 198 warnings, especially
> about unused variables and narrowing conversion. I've filed a
> respective bug report about that:
> https://bugs.launchpad.net/yade/+bug/1813401
>
> 2. material parameters (like stiffness or heat capacity) are stored
> inside Shape class PotentialBlock.hpp. But they should be stored
> inside a class derived from Material. My impression (I might be
> wrong, in that case please correct me) is that PotentialParticle is
> using default materials and default contact law. Then later you
> decided that you need a more customized Material (e.g. with heat
> capacity) and you have cloned PotentialParticle into PotentialBlock,
> instead of adding a Material class. This error propagates down
> through all my next remarks.
>
> 3. As a result of above mistake there is no IPhys (interaction
> physics) functor. Its main purpose  is to calculate the physical
> parameters of the contact. Eg. the heat capacity of two
> PotentialBlocks that are in contact. Its contents was put into IGeom
> functor Ig2_PB_PB_ScGeom.cpp
>
> 4. Ig2_PB_PB_ScGeom.cpp and Ig2_PP_PP_ScGeom.cpp are the duplicates of
> each other. The code that is a difference between them is about
> physics and would better go to the IPhys functor. Please do not
> duplicate code. Duplicate code is the worst source of all bugs.
> Because someone after a long debugging session finally corrects some
> mistake, and believes that it has been corrected. And later the same
> bug resurfaces in the duplicated part of the code.
>
> 5. PotentialBlock.hpp and PotentialParticle.hpp are duplicates of each
> other, the difference between them is what would better go into
> Material class
>
> 6. because they are duplicates the drawing of class PotentialBlock is
> not implemented, while it would work perfectly well with
> Gl1_PotentialParticle functor
>
> I am sorry that my remarks are so fundamental in a sense. But this is
> all in good will, I hope that fixing these problems would make the
> code much more easier to work with for others, and much less prone to
> bugs.
>
> After you make a class derived from Material to handle
> PotentialBlocks properly, you will see that it will work best with
> interaction physics (IPhys) functor which handlles this material. And
> suddenly there is no need to duplicate code from
> PotentialParticle.hpp into PotentialBlock.hpp. There will be only
> PotentialParticle which sometimes can use the newly created material
> and also will work with the default material. And this will cause
> Gl1_PotentialParticle functor to draw correctly "both" of them.
> "Both" in quotes, because there in fact will be inly one, but with
> different material.
>
> I hope that 

Re: [Yade-dev] Fixing the examples FEMxDEM

[Janek Kozicki]

I have found out that if I run from shell /usr/bin/run-escript (which
is a part of python-escript package) then a python shell is started
inside which the command

  from esys.escript import *

works. That is some progress. Now I don't know how to make it work
inside yade python shell.


Janek Kozicki said: (by the date of Sun, 27 Jan 2019 01:28:47 +0100)

> Bruno Chareyre said: (by the date of Thu, 24 Jan 2019 19:09:26 +0100)
> 
> > FEMxDEM: Ning Guo (if this adress does not work I know Ning has 
> > successors in HK)  
> 
> I am trying to make it work. I found that
> https://launchpad.net/escript-finley is probably inside package
> python-escript.
> 
> I have compiled version python-escript_5.3-1_amd64.deb from source
> and installed it, But still I have this error when starting the
> FEMxDEM example:
> 
>   from esys.escript import *
>   ImportError: No module named esys.escript
> 
> The strangest thing is that when I do:
> 
>   grep esys.escript . -r --color
> 
> inside the source of package python-escript_5.3-1_amd64.deb I find
> hundreds of lines that are doing this `from esys.escript import *`.
> So I conclude that in yade it should work.
> 
> However my devuan ascii is based on debian stretch, so maybe some of
> my packages are too old. I don't know which ones, though :( Or have a
> bug regarding python detecting newly installed modules.
> 
> Maybe I should try this in devuan experimental, perhaps there it will
> work.
> 
> Do you guys have any idea?
> -- 
> 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

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