Re: [Yade-dev] Deprecate Debian Stretch, Ubuntu 16.04, 18.04

[Klaus Thoeni]

Ok, thanks for the clarification.

K

On Tue, 21 Nov 2023, 08:19 Bruno Chareyre, 
wrote:

> Hi Klaus,
>
> Removing from pipeline just means that we don't rebuild on 18.04 again and
> again in gitlab.
> The 18.04 release will still be available, so there is no special issue
> wrt openFoam in my view.
>
> Bruno
>
> On 20/11/2023 22:07, Klaus Thoeni wrote:
>
> HI guys,
>
> regarding 18.04. In the paper it is stated that OpenFOAM coupling is only
> working in 18.04. Would it make sense to keep it?
>
> Klaus
>
> On Tue, Nov 21, 2023 at 7:42 AM Bruno Chareyre <
> bruno.chare...@3sr-grenoble.fr> wrote:
>
>> Yes, that's perfect.
>>
>> B
>> On 20/11/2023 21:39, Anton Gladky wrote:
>>
>> Hi Bruno,
>>
>> we can freeze the daily versions and drop deprecated distros
>> from all CI pipelines.
>>
>> Regards
>>
>> Anton
>>
>> Am Mo., 20. Nov. 2023 um 21:01 Uhr schrieb Bruno 
>> Chareyre :
>>
>> Hi Anton,
>>
>> I agree to stop building them. To be sure: are you thinking about removing 
>> them from "daily" package repository as well, or just to freeze the versions 
>> there?
>>
>> Cheers
>>
>> Bruno
>>
>>
>> On 20/11/2023 20:52, Anton Gladky wrote:
>>
>> Dear all,
>>
>> We are adding more and more releases to be supported.|
>> Debian Trixie is being added in the near future, and later
>> next year, Ubuntu 24.04 LTS will also be included.
>>
>> My proposal is to deprecate at least Debian Stretch, Ubuntu 16.04,
>> and Ubuntu 18.04. We need to free up some resources, and
>> having always older distributions in pipelines is unlikely to bring
>> any benefit.
>>
>> What are your thoughts? How many users are really using those
>> distributions?
>>
>> Best regards
>>
>> Anton
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>> --
>>
>> Bruno Chareyre
>> Associate Professor
>>
>> Grenoble INP - UGA
>> Institut d'ingénierie et de management / Graduate Schools of engineering and 
>> management
>> 46 av. Félix-Viallet - 38301 Grenoblewww.grenoble-inp.fr
>>
>> 3SR Lab
>> Soils, Solids, Structures, Risks
>> 1270, rue de la piscine - 38400 Saint Martin 
>> d’Hèreswww.3sr.univ-grenoble-alpes.fr
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>> --
>>
>> * Bruno Chareyre*
>>
>> *Associate Professor *
>>
>>
>>
>>
>>
>> *Grenoble INP - UGA Institut d'ingénierie et de management / Graduate
>> Schools of engineering and management 46 av. Félix-Viallet - 38301 Grenoble
>> www.grenoble-inp.fr <http://www.grenoble-inp.fr> *
>>
>>
>>
>>
>>
>> *3SR Lab Soils, Solids, Structures, Risks 1270, rue de la piscine - 38400
>> Saint Martin d’Hères www.3sr.univ-grenoble-alpes.fr
>> <https://3sr.univ-grenoble-alpes.fr/en> *
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
> --
>
> * Bruno Chareyre*
>
> *Associate Professor *
>
>
>
>
>
> *Grenoble INP - UGA Institut d'ingénierie et de management / Graduate
> Schools of engineering and management 46 av. Félix-Viallet - 38301 Grenoble
> www.grenoble-inp.fr <http://www.grenoble-inp.fr> *
>
>
>
>
>
> *3SR Lab Soils, Solids, Structures, Risks 1270, rue de la piscine - 38400
> Saint Martin d’Hères www.3sr.univ-grenoble-alpes.fr
> <https://3sr.univ-grenoble-alpes.fr/en> *
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Deprecate Debian Stretch, Ubuntu 16.04, 18.04

[Klaus Thoeni]

HI guys,

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

Klaus

On Tue, Nov 21, 2023 at 7:42 AM Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> wrote:

> Yes, that's perfect.
>
> B
> On 20/11/2023 21:39, Anton Gladky wrote:
>
> Hi Bruno,
>
> we can freeze the daily versions and drop deprecated distros
> from all CI pipelines.
>
> Regards
>
> Anton
>
> Am Mo., 20. Nov. 2023 um 21:01 Uhr schrieb Bruno 
> Chareyre :
>
> Hi Anton,
>
> I agree to stop building them. To be sure: are you thinking about removing 
> them from "daily" package repository as well, or just to freeze the versions 
> there?
>
> Cheers
>
> Bruno
>
>
> On 20/11/2023 20:52, Anton Gladky wrote:
>
> Dear all,
>
> We are adding more and more releases to be supported.|
> Debian Trixie is being added in the near future, and later
> next year, Ubuntu 24.04 LTS will also be included.
>
> My proposal is to deprecate at least Debian Stretch, Ubuntu 16.04,
> and Ubuntu 18.04. We need to free up some resources, and
> having always older distributions in pipelines is unlikely to bring
> any benefit.
>
> What are your thoughts? How many users are really using those
> distributions?
>
> Best regards
>
> Anton
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
> --
>
> Bruno Chareyre
> Associate Professor
>
> Grenoble INP - UGA
> Institut d'ingénierie et de management / Graduate Schools of engineering and 
> management
> 46 av. Félix-Viallet - 38301 Grenoblewww.grenoble-inp.fr
>
> 3SR Lab
> Soils, Solids, Structures, Risks
> 1270, rue de la piscine - 38400 Saint Martin 
> d’Hèreswww.3sr.univ-grenoble-alpes.fr
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
> --
>
> * Bruno Chareyre*
>
> *Associate Professor *
>
>
>
>
>
> *Grenoble INP - UGA Institut d'ingénierie et de management / Graduate
> Schools of engineering and management 46 av. Félix-Viallet - 38301 Grenoble
> www.grenoble-inp.fr  *
>
>
>
>
>
> *3SR Lab Soils, Solids, Structures, Risks 1270, rue de la piscine - 38400
> Saint Martin d’Hères www.3sr.univ-grenoble-alpes.fr
>  *
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

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

[Klaus Thoeni]

Hello everyone,

I also fully support such a statement and am happy to contribute.

My thoughts are with all fellow Ukrainiens, especially you Anton. Hope your
family is safe.

Klaus

On Fri, Mar 4, 2022 at 8:24 AM Anton Gladky  wrote:

> Hello Bruno,
>
> thanks for this initiative! I do really support it.
>
> I am personally affected by this situation and my life is being splitted
> now on "before" and "after".
>
> Thanks you all for support.
>
> Anton
>
> Am Do., 3. März 2022 um 18:16 Uhr schrieb Bruno Chareyre
> :
> >
> > Hi guys,
> >
> > My heart is broken since the beginning of that war on Ukraine.
> > I believe international cooperation is one of our value in the Yade
> > community.
> >
> > If you agree we could include a statement on the website in support of
> > peace, like other scientific communities did [1].
> >
> > Regards
> >
> > Bruno
> >
> > [1]
> >
> https://www.interpore.org/index.php?page=acymailing_front=archive=view=120=559-kfFKWJJ3zkJa0l=1=1
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] yade-dev team tomorrow's zoom meeting reminder

[Klaus Thoeni]

Hi Deepak,

the next meeting is on the 12th of January. We are looking at one meeting
every two months. I can invite you if you are interested, just let me know.

Klaus

On Wed, Nov 10, 2021 at 6:00 AM Deepak Kn  wrote:

> Hello Janek,
>
> Just a question, how often do these meetings take place ?
>
> Thanks and best regards,
> Deepak
>
> On Tue, Nov 2, 2021 at 3:40 PM Janek Kozicki (yade) <
> jkozicki-y...@pg.edu.pl> wrote:
>
>> BTW, Klaus, here in Europe just three days ago we have switched to
>> winter time. That's one hour shift.
>>
>>
>>
>> Janek Kozicki (yade) said: (by the date of Tue, 2 Nov 2021 15:32:27
>> +0100)
>>
>> > Hello everyone,
>> >
>> > Just a reminder that tomorrow we have a developer zoom meeting at 11:00
>> CET.
>> >
>> > If someone yet uninvited wants to join I hope there's still time to
>> > reply to this message to get the zoom link from Klaus.
>> >
>> > best regards
>> > Janek
>> >
>> > --
>> > --
>> > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
>> > Gdansk University of Technology (Gdansk Tech)
>> > Faculty of Applied Physics and Mathematics
>> > Department of Theoretical Physics and Quantum Information
>> > --
>> > http://yade-dem.org/
>> > http://pg.edu.pl/jkozicki (click English flag on top right)
>>
>>
>> --
>> --
>> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
>> Gdansk University of Technology (Gdansk Tech)
>> Faculty of Applied Physics and Mathematics
>> Department of Theoretical Physics and Quantum Information
>> --
>> http://yade-dem.org/
>> http://pg.edu.pl/jkozicki (click English flag on top right)
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

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

[Klaus Thoeni]

Sounds great, I am in.

Klaus

On Mon, Oct 25, 2021 at 9:27 PM Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> wrote:

> Hi Devs,
>
> For your information, I will submit yade to a french "Open Science and
> Open Source Software Prize" that was opened recently.
> I've been invited to to so by local colleagues from Gricad (HPC people).
> The procedure is described here [1] (only in french unfortunately - the
> "english" button is only a broader overview).
>
> I didn't go through the whole documents but the various prizes are:
> "science/technology", "community", "documentation", "all criteria together".
> Deadline early December.
> I'll try and circulate a preliminary document here for possible review.
> If you want to be involved directly let me know.
> Bruno
>
>
> [1]
> https://www.ouvrirlascience.fr/ouverture-des-candidatures-du-prix-science-ouverte-du-logiciel-libre-de-la-recherche/
> --
>
>
> ___
> Bruno Chareyre
> Associate Professor
> 3SR lab., ENSE³, Grenoble INP
> Tél : +33 4 56 52 86 21
> 
>
> Email too brief?
> Here's why: email charter
> 
>
>
>
> ___
> Mailing list: https://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] A suggestion/contribution regarding bug of Yade-users #694548

[Klaus Thoeni]

Hi Gael,

thanks for your email. Somehow question #694548 slipped through the cracks
so I didn't follow the discussion. Indeed, there is a problem on how forces
are distributed. I will have to look into this. In the meantime, it would
be excellent if you could share your solution, best is to push your changes
to your fork on gitlab if you have one. Then send me the link and I will
have a look. Or you could send me the files you changed via email.

Thanks,
Klaus

On Wed, Feb 24, 2021 at 7:59 AM Gael Lorieul 
wrote:

> Hi ️
>
> It has been a long time…
>
> I have come accross thread #694548 on the "Yade-users" mailing list (from
> January 2021), which concerned unphysical collisions between PFacets (the
> dynamics of the rebound does not correspond to what one's physical/common
> sense would expect).
>
> I wanted to share that I encountered a very similar issue but with
> gridConnection objects (I work with cylinders), and that I found a
> solution. The latter should be easily extendible both to PFacet/PFacet and
> PFacet/gridConnection collisions (although I only tested
> gridConnection/gridConnection collisions). I am not sure how elegant or
> computationally efficient it is, but it has given me good results on the
> (very few) simulations I have tested it on.
>
> I initially wanted to test my solution on full-scale simulations before
> submiting it to the Yade code base, so as to present a code that is robust
> and mature. But as it has been almost a full year since then (the company I
> work for gave me assignments other than DEM), I feel that perhaps I should
> reach out for other ways to share this information…
>
> This implies that although I am quite confident of my fix, I am not 100%
> certain either…
>
> Perhaps a first step would be for me to present what I have found, and how
> my fix works? I am not sure as to where to present it: This mailing list?
> Thread #694548? You tell me ️
>
> Gaël
>
>
> PS: I have started to re-implement my solution in yade e07e530 (26 Nov
> 2020) (my previous implementation was based on yade 1b4ae97 (8 Feb 2020)).
> Hopefully the work I do on e07e530 will not be difficult to port to the
> latest yade versions… (It seems the yade project started using clang-format
> (or similar tool) sometime between e07e530 and 1b4ae97 so `diff` outputs
> half the file: not very helpful… ️)
>
> PS2: Could thread #695558 be also concerned by this same uncorrect
> physical behavior?
>
> PS3: I hope that I am not colliding with Bruno's work on the subject
> (according to Bruno's e-mail of Tue, 12 Jan 2021 07:50:51)
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] [Bug 1852197] [NEW] Segmentation fault on pfacet gridconnection contact

[Klaus Thoeni]

Public bug reported:

I seem to get a Segmentation fault (core dumped) when using
GridConnection, PFacet, and randomDensePack. And I am not sure why. I
have attached an image and "working" example.


Thanks in advance,
Justin


Edit: I could not seem to upload an picture or example code. Thus code
below:


from yade.gridpfacet import *
import numpy as np
from yade import utils
from yade import ymport
import sys,time,math,random

from yade import qt
qt.View()

#print(os.path.basename(__file__))
#quit()
### ParallelEngine, -j4

boxCenter = (0,0,.025)
## double check that /2 would create correct length, I.e., import based_70 to 
see if they match... they should
boxDem = (.2123/2,.212/2,.064/2)  ### based_70 is 212.3x212.21x63.65

boxDem = (.07,.07,.025)  ###

blen = boxDem[0]*2  ## Length of Ball pit
bhei = .025   ## Height of Ball pit

# Spheres information
sphereRadius = .004 # [m]
nu = .48 
#G = 30 # [Pa]
den_rub = 89724 # [kg/m^3]
yng_rub = 300 # [Pa] 
fric_rub = radians(38)  # [degrees] 
O.materials.append(FrictMat(frictionAngle=fric_rub,young=yng_rub,density=den_rub,poisson=nu,label='rubber'))
O.materials.append(FrictMat(young=200e9,density=8050,poisson=.3, 
label='steel')) # used steel properties to make rigid

## Stud informtion
#studStartZ = (.01+.022+.01905)
studStartZ = (.01+bhei+.01905)
transVel = 0.000222*2
rotVel = 0.00872665*2

### pack auto fills, i.e., I no longer pick the amount of spheres
pred = 
pack.inAlignedBox((-(boxDem[0]-.001),-(boxDem[0]-.001),bhei+sphereRadius/2+.001),((boxDem[0]-.001),(boxDem[0]-.001),bhei+.045))
sp = pack.randomDensePack(pred, radius=sphereRadius, 
memoizeDb='tmp/single_grass.sqlite', returnSpherePack=True)
sp.toSimulation(wire=False,material='rubber')

## Time step set to 20% of Rayleigh Wave
O.dt=.2*utils.RayleighWaveTimeStep() # 0.0011302534626965682
print(O.dt)

### Steps needed to run sim
sphereFalls = 1000  
### Steps spheres need to fall 
and level out and turn on studs
startRot = sphereFalls+math.floor((studStartZ-bhei-.01)/transVel/O.dt)  
### Step needed for transVel to get studs level with spheres

## Rotation steps
deg_to_rad_length = (60*pi/180); # [rad]
num_sec_roto = deg_to_rad_length/rotVel; # [s]
num_of_steps_roto = num_sec_roto/O.dt;

endSim   = startRot + math.floor(num_of_steps_roto)
### total steps in sim

O.engines=[
###Reset all forces stored in Scene::forces (O.forces in 
python). Typically, this is the first engine to be run at every step.  
In addition, reset those energies that should be reset, if energy tracing is 
enabled.
## Resets forces and moments that act on bodies
ForceResetter(),

## Using bounding boxes find possible body collisions.
InsertionSortCollider([
Bo1_Facet_Aabb(), 
Bo1_PFacet_Aabb(),
Bo1_Sphere_Aabb(),
Bo1_GridConnection_Aabb(),
Bo1_PFacet_Aabb(),
]),
InteractionLoop([
Ig2_Facet_Sphere_ScGeom(),
Ig2_Wall_PFacet_ScGeom(),
Ig2_Wall_Sphere_ScGeom(),
Ig2_Sphere_Sphere_ScGeom(),
Ig2_Sphere_GridConnection_ScGridCoGeom(),
Ig2_Sphere_PFacet_ScGridCoGeom(),
Ig2_GridNode_GridNode_GridNodeGeom6D(),
Ig2_GridConnection_GridConnection_GridCoGridCoGeom(),
Ig2_GridConnection_PFacet_ScGeom(),
Ig2_PFacet_PFacet_ScGeom(),
],
[
#   
Ip2_CohFrictMat_CohFrictMat_CohFrictPhys(setCohesionNow=True,setCohesionOnNewContacts=True),
# internal cylinder physics

Ip2_CohFrictMat_CohFrictMat_CohFrictPhys(setCohesionNow=True),  # internal 
cylinder physics
## Currently grass does not interact with facet, 
probably should not matter, since the spheres will be holding them up.  
   

Ip2_FrictMat_FrictMat_FrictPhys() # physics for 
external interactions, i.e., cylinder-cylinder, sphere-sphere, cylinder-sphere
],
[
Law2_ScGeom_FrictPhys_CundallStrack(),   # 
contact law for sphere-sphere
Law2_ScGridCoGeom_FrictPhys_CundallStrack(), # 
contact law for cylinder-sphere
Law2_ScGeom6D_CohFrictPhys_CohesionMoment(), # 
contact law for "internal" cylinder forces
Law2_GridCoGridCoGeom_FrictPhys_CundallStrack(), # 
contact law for cylinder-cylinder interaction
]),
NewtonIntegrator(damping=.2,gravity=[0,0,-9.81], 

Re: [Yade-dev] Migrating to GitLab

[Klaus Thoeni]

Hi Bruno,

yes, that's right. Dev's should have the rights to do that.

K

On Wed, Dec 12, 2018 at 2:00 AM Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> wrote:

>
>
> On 12/5/18 7:21 AM, Klaus Thoeni wrote:
> > I terms of branching, I think this should be kept flexible. I think
> > branches make sense if you work on major changes. However, I still
> > think main devs should be able to push directly to the trunk,
> > obviously with care ;-)
> I think we need to distinguish two aspects:
> 1- do we "push" or do we "request-merge"?
> 2- who is allowed to accept the merge requests?
>
> I don't see a real need to use direct push (point 1), one exception is
> when fixing simple bugs maybe.
> What you say is more  (I guess) that some devs need enough rights to
> accept their own MR (point 2). Right?
>
> 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] Migrating to GitLab

[Klaus Thoeni]

Hi Bruno,

thanks for taking the initiative here.

I have also used GitLab over the last year and I can only say positive
things (especially not owned by Microsoft). If you asked me it is probably
time to move everything (incl. code, Q, bug tracking etc.) to one single
platform and to leave Launchpad and Github behind. Not sure if this is
feasible. Yes, this would involve a bit of adaptation by some devs but I
can only see benefits having everything on one platform.

I terms of branching, I think this should be kept flexible. I think
branches make sense if you work on major changes. However, I still think
main devs should be able to push directly to the trunk, obviously with care
;-)

Cheers
Klaus


On Wed, Nov 28, 2018 at 5:54 AM Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> wrote:

> Hi devs,
> This is an announcement (1) and call for opinions (2).
>
> (1)  We will be migrating the integration framework to GitLab.com soon.
> That is: the config of buildbot, doc generation, and packaging will be
> using gitlab and will be hosted on gitlab.com [1], while hardware
> ressources will be provided locally by 3SR and/or Gricad's Gitlab [2].
> It should increase flexibility and decrease maintainance issues.
> Rémi made most of the work already (thank you!). Curious about it? You
> can check [3].
> The switch could happen in a couple months.
>
> ___
> (2)
> GitLab.com could also host the master branch in replacement of
> GitHub.com. It is not required though, and there is no problem to keep
> it on GitHub (like we kept bug tracking on launchpad after moving master
> to github), or not. This is open question to me. Migrating a branch is
> easy to do and easy to revert, so there is no technical constraint on
> us. It just needs to decide if we want to keep github or adopt gitlab
> for the source code (or both...).
>
> If source code was migrated, same question for bug tracking and answers?
>
> Whatever is decided for the above, the migration is also a good
> opportunity to think about the branch management model. Are we happy
> with it?
> Currently we have a centralized usage of a distributed CVS. Most
> contributors push to master directly  with strictly no pre-assessement
> of the contributions. Another possible (and classical) model would be to
> only accept merge requests from other branches. Which can have
> advantages, namely: easier to review since the the requests will usually
> collect a larger number of commits (all from a single user typically,
> hence self consistent), and more secured since it favors pre-assessment.
>
> Opinions?
>
> Cheers
>
> Bruno
>
> [1] https://about.gitlab.com/product/
> [2] https://gricad-gitlab.univ-grenoble-alpes.fr/
> [3] https://gitlab.com/remche/trunk
>
> --
> ___
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> Fax : +33 4 76 82 70 43
> 
>
> Email too brief?
> Here's why! http://emailcharter.org
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] [Bug 1474956] Re: Clump::updateProperties discretization not defined robustly

[Klaus Thoeni]

Sounds like a good fix to me.

Klaus

On Tue, May 22, 2018 at 7:11 AM, Bruno Chareyre <1474...@bugs.launchpad.net>
wrote:

> ** Changed in: yade
>Importance: Medium => Wishlist
>
> --
> You received this bug notification because you are a member of Yade
> developers, which is subscribed to Yade.
> https://bugs.launchpad.net/bugs/1474956
>
> Title:
>   Clump::updateProperties discretization not defined robustly
>
> Status in Yade:
>   Confirmed
>
> Bug description:
>   Most likely the reason for performance drop reported in [1]
>
>   dx in the voxel decomposition is minRad/discretization.
>   The problem is when a sphere of radius 1 is member of a clump which aabb
> has the size 1000 (for instance).
>   Using the minimal discretization=1 gives a number of voxel = 1e9 in such
> case and it is no possible to go below this number.
>   I think discretization should refer to aabb size, not member size. I
> have this fixed locally, let me know if you agree with the fix.
>
>   [1] https://answers.launchpad.net/yade/+question/268954
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/yade/+bug/1474956/+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
>

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

Title:
  Clump::updateProperties discretization not defined robustly

Status in Yade:
  Confirmed

Bug description:
  Most likely the reason for performance drop reported in [1]

  dx in the voxel decomposition is minRad/discretization.
  The problem is when a sphere of radius 1 is member of a clump which aabb has 
the size 1000 (for instance).
  Using the minimal discretization=1 gives a number of voxel = 1e9 in such case 
and it is no possible to go below this number.
  I think discretization should refer to aabb size, not member size. I have 
this fixed locally, let me know if you agree with the fix.

  [1] https://answers.launchpad.net/yade/+question/268954

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

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

[Yade-dev] [Bug 1772535] [NEW] DFNflow not working with CGAL 4.11

[Klaus Thoeni]

Public bug reported:

See discussion on:

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

** 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/1772535

Title:
  DFNflow not working with CGAL 4.11

Status in Yade:
  New

Bug description:
  See discussion on:

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1772535/+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] : Compilation on K/Ubuntu 18.04

[Klaus Thoeni]

Hi Robert,

thanks for your feedback.

Klaus

On Mon, May 21, 2018 at 4:42 PM, Robert Caulk <rob.ca...@gmail.com> wrote:

> Hey Klaus,
>
> Thanks for taking time to look at this, I’m sorry I missed your first
> email about this.
>
> Actually we have not updated DFNflow for CGAL 4.11 yet. The commit is
> fine, the key change that is fixing compilation is:
>
> #define DFNFlow
>
> Being commented out.
>
> I will push the change commenting out #define DFNFlow. Cleary it is not
> ready to be compiled by default until we make the necessary cgal 4.11
> changes.
>
> Cheers,
>
> Robert
>
>
> Le dim. 20 mai 2018 à 23:18, Klaus Thoeni <klaus.tho...@gmail.com> a
> écrit :
>
>> Hi guys,
>>
>> this commit seems to be the issue:
>>
>> https://github.com/yade/trunk/commit/12745740f2ff4b72aa09f55e9bbb0d
>> f367a838d4
>>
>> By reverting it, compilation, checks and test work just fine. However,
>> not sure if the revert causes other specific issues.
>>
>> Klaus
>>
>>
>> On Mon, May 14, 2018 at 5:20 PM, Klaus Thoeni <klaus.tho...@gmail.com>
>> wrote:
>>
>>> Hi guys,
>>>
>>> I remember a discussion with a CGAL problem to get yade ready for 18.04
>>> LTS. From the discussion it looks that everything is solved. However, I
>>> just did a fresh install of Kubuntu 18.04 and tried to compile the code
>>> (latest trunk version).
>>>
>>> cmake went fine but compilation didn't work as expected. I got an error
>>> related to some CGAL commands used in DFNFlow.cpp:
>>>
>>> /home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp: In member function ‘void
>>> DFNFlowEngine::interpolateCrack(TemplateFlowEngine_DFNFlowEngineT<DFNCellInfo,
>>> DFNVertexInfo, CGT::_Tesselation<CGT::TriangulationTypes<DFNVertexInfo,
>>> DFNCellInfo> >, DFNBoundingSphere>::Tesselation&, 
>>> TemplateFlowEngine_DFNFlowEngineT<DFNCellInfo,
>>> DFNVertexInfo, CGT::_Tesselation<CGT::TriangulationTypes<DFNVertexInfo,
>>> DFNCellInfo> >, DFNBoundingSphere>::Tesselation&)’:
>>> /home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp:216:136: error: no match
>>> for ‘operator-’ (operand types are 
>>> ‘CGAL::Regular_triangulation_vertex_base_3<CGAL::Epick,
>>> CGAL::Triangulation_ds_vertex_base_3>> data_structure_3<CGAL::Alpha_shape_vertex_base_3<CGAL::Epick,
>>> CGAL::Triangulation_vertex_base_with_info_3<DFNVertexInfo, CGAL::Epick,
>>> CGAL::Regular_triangulation_vertex_base_3 >,
>>> CGAL::Boolean_tag, CGAL::Boolean_tag >,
>>> CGAL::Alpha_shape_cell_base_3<CGAL::Epick,
>>> CGAL::Triangulation_cell_base_with_info_3<DFNCellInfo, CGAL::Epick,
>>> CGAL::Regular_triangulation_cell_base_3 >,
>>> CGAL::Boolean_tag, CGAL::Boolean_tag >, CGAL::Sequential_tag>
>>> > >::Point {aka CGAL::Weighted_point_3}’ and ‘const
>>> CGAL::Origin’)
>>>if (newCell->info().fictious()==0) for (int k=0;k<4;k++) center =
>>> center + 0.25*(Tes.vertex(newCell->vertex(k)->info().id())->
>>> point()-CGAL::ORIGIN);
>>>
>>> ^
>>>
>>>
>>> /home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp:218:71: error: no
>>> matching function for call to ‘CGAL::Regular_triangulation_3<CGAL::Epick,
>>> CGAL::Triangulation_data_structure_3<CGAL::Alpha_shape_vertex_base_3<CGAL::Epick,
>>> CGAL::Triangulation_vertex_base_with_info_3<DFNVertexInfo, CGAL::Epick,
>>> CGAL::Regular_triangulation_vertex_base_3 >,
>>> CGAL::Boolean_tag, CGAL::Boolean_tag >,
>>> CGAL::Alpha_shape_cell_base_3<CGAL::Epick,
>>> CGAL::Triangulation_cell_base_with_info_3<DFNCellInfo, CGAL::Epick,
>>> CGAL::Regular_triangulation_cell_base_3 >,
>>> CGAL::Boolean_tag, CGAL::Boolean_tag >,
>>> CGAL::Sequential_tag>, CGAL::Default>::locate(Point)’
>>>CellHandle oldCell = Tri.locate(Point(center[0],
>>> center[1],center[2]));
>>>^
>>> In file included from /usr/include/CGAL/Regular_triangulation_3.h:45:0,
>>>  from /home/yade/YADE-git/trunk/lib/triangulation/
>>> RegularTriangulation.h:13,
>>>  from /home/yade/YADE-git/trunk/lib/
>>> triangulation/Tesselation.h:9,
>>>  from /home/yade/YADE-git/trunk/pkg/
>>> dem/TesselationWrapper.hpp:15,
>>> 

Re: [Yade-dev] : Compilation on K/Ubuntu 18.04

[Klaus Thoeni]

Hi guys,

this commit seems to be the issue:

https://github.com/yade/trunk/commit/12745740f2ff4b72aa09f55e9bbb0df367a838d4

By reverting it, compilation, checks and test work just fine. However, not
sure if the revert causes other specific issues.

Klaus


On Mon, May 14, 2018 at 5:20 PM, Klaus Thoeni <klaus.tho...@gmail.com>
wrote:

> Hi guys,
>
> I remember a discussion with a CGAL problem to get yade ready for 18.04
> LTS. From the discussion it looks that everything is solved. However, I
> just did a fresh install of Kubuntu 18.04 and tried to compile the code
> (latest trunk version).
>
> cmake went fine but compilation didn't work as expected. I got an error
> related to some CGAL commands used in DFNFlow.cpp:
>
> /home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp: In member function ‘void
> DFNFlowEngine::interpolateCrack(TemplateFlowEngine_DFNFlowEngineT<DFNCellInfo,
> DFNVertexInfo, CGT::_Tesselation<CGT::TriangulationTypes<DFNVertexInfo,
> DFNCellInfo> >, DFNBoundingSphere>::Tesselation&, 
> TemplateFlowEngine_DFNFlowEngineT<DFNCellInfo,
> DFNVertexInfo, CGT::_Tesselation<CGT::TriangulationTypes<DFNVertexInfo,
> DFNCellInfo> >, DFNBoundingSphere>::Tesselation&)’:
> /home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp:216:136: error: no match
> for ‘operator-’ (operand types are 
> ‘CGAL::Regular_triangulation_vertex_base_3<CGAL::Epick,
> CGAL::Triangulation_ds_vertex_base_3 data_structure_3<CGAL::Alpha_shape_vertex_base_3<CGAL::Epick,
> CGAL::Triangulation_vertex_base_with_info_3<DFNVertexInfo, CGAL::Epick,
> CGAL::Regular_triangulation_vertex_base_3 >,
> CGAL::Boolean_tag, CGAL::Boolean_tag >,
> CGAL::Alpha_shape_cell_base_3<CGAL::Epick, 
> CGAL::Triangulation_cell_base_with_info_3<DFNCellInfo,
> CGAL::Epick, CGAL::Regular_triangulation_cell_base_3 >,
> CGAL::Boolean_tag, CGAL::Boolean_tag >, CGAL::Sequential_tag>
> > >::Point {aka CGAL::Weighted_point_3}’ and ‘const
> CGAL::Origin’)
>if (newCell->info().fictious()==0) for (int k=0;k<4;k++) center =
> center + 0.25*(Tes.vertex(newCell->vertex(k)->info().id())->
> point()-CGAL::ORIGIN);
>
> ^
>
>
> /home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp:218:71: error: no matching
> function for call to ‘CGAL::Regular_triangulation_3<CGAL::Epick,
> CGAL::Triangulation_data_structure_3<CGAL::Alpha_shape_vertex_base_3<CGAL::Epick,
> CGAL::Triangulation_vertex_base_with_info_3<DFNVertexInfo, CGAL::Epick,
> CGAL::Regular_triangulation_vertex_base_3 >,
> CGAL::Boolean_tag, CGAL::Boolean_tag >,
> CGAL::Alpha_shape_cell_base_3<CGAL::Epick, 
> CGAL::Triangulation_cell_base_with_info_3<DFNCellInfo,
> CGAL::Epick, CGAL::Regular_triangulation_cell_base_3 >,
> CGAL::Boolean_tag, CGAL::Boolean_tag >,
> CGAL::Sequential_tag>, CGAL::Default>::locate(Point)’
>CellHandle oldCell = Tri.locate(Point(center[0],center[1],center[2]));
>^
> In file included from /usr/include/CGAL/Regular_triangulation_3.h:45:0,
>  from /home/yade/YADE-git/trunk/lib/triangulation/
> RegularTriangulation.h:13,
>  from /home/yade/YADE-git/trunk/lib/
> triangulation/Tesselation.h:9,
>  from /home/yade/YADE-git/trunk/pkg/
> dem/TesselationWrapper.hpp:15,
>  from /home/yade/YADE-git/build/pkg/
> pfv/FlowEngine_DFNFlowEngineT.hpp:38,
>  from /home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp:20:
> /usr/include/CGAL/Triangulation_3.h:1012:3: note: candidate:
> CGAL::Triangulation_3<GT, Tds, Lock_data_structure>::Cell_handle
> CGAL::Triangulation_3<GT, Tds, Lock_data_structure>::locate(const Point&,
> CGAL::Triangulation_3<GT, Tds, Lock_data_structure>::Vertex_handle,
> bool*) const [with GT = CGAL::Epick; Tds_ = CGAL::Triangulation_data_
> structure_3<CGAL::Alpha_shape_vertex_base_3<CGAL::Epick,
> CGAL::Triangulation_vertex_base_with_info_3<DFNVertexInfo, CGAL::Epick,
> CGAL::Regular_triangulation_vertex_base_3 >,
> CGAL::Boolean_tag, CGAL::Boolean_tag >,
> CGAL::Alpha_shape_cell_base_3<CGAL::Epick, 
> CGAL::Triangulation_cell_base_with_info_3<DFNCellInfo,
> CGAL::Epick, CGAL::Regular_triangulation_cell_base_3 >,
> CGAL::Boolean_tag, CGAL::Boolean_tag >,
> CGAL::Sequential_tag>; Lock_data_structure_ = CGAL::Default;
> CGAL::Triangulation_3<GT, Tds, Lock_data_structure>::Cell_handle =
> CGAL::internal::CC_iterator<CGAL::Compact_container Alpha_shape_cell_base_3<CGAL::Epick, 
> CGAL::Triangulation_cell_base_with_info_3<DFNCellInfo,
> CGAL::Epick, CGAL::Regular_triangu

[Yade-dev] : Compilation on K/Ubuntu 18.04

[Klaus Thoeni]

Hi guys,

I remember a discussion with a CGAL problem to get yade ready for 18.04
LTS. From the discussion it looks that everything is solved. However, I
just did a fresh install of Kubuntu 18.04 and tried to compile the code
(latest trunk version).

cmake went fine but compilation didn't work as expected. I got an error
related to some CGAL commands used in DFNFlow.cpp:

/home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp: In member function ‘void
DFNFlowEngine::interpolateCrack(TemplateFlowEngine_DFNFlowEngineT >, DFNBoundingSphere>::Tesselation&,
TemplateFlowEngine_DFNFlowEngineT >,
DFNBoundingSphere>::Tesselation&)’:
/home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp:216:136: error: no match for
‘operator-’ (operand types are
‘CGAL::Regular_triangulation_vertex_base_3,
CGAL::Boolean_tag, CGAL::Boolean_tag >,
CGAL::Alpha_shape_cell_base_3,
CGAL::Boolean_tag, CGAL::Boolean_tag >, CGAL::Sequential_tag>
> >::Point {aka CGAL::Weighted_point_3}’ and ‘const
CGAL::Origin’)
   if (newCell->info().fictious()==0) for (int k=0;k<4;k++) center = center
+ 0.25*(Tes.vertex(newCell->vertex(k)->info().id())->point()-CGAL::ORIGIN);

^


/home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp:218:71: error: no matching
function for call to ‘CGAL::Regular_triangulation_3,
CGAL::Boolean_tag, CGAL::Boolean_tag >,
CGAL::Alpha_shape_cell_base_3,
CGAL::Boolean_tag, CGAL::Boolean_tag >,
CGAL::Sequential_tag>, CGAL::Default>::locate(Point)’
   CellHandle oldCell = Tri.locate(Point(center[0],center[1],center[2]));
   ^
In file included from /usr/include/CGAL/Regular_triangulation_3.h:45:0,
 from
/home/yade/YADE-git/trunk/lib/triangulation/RegularTriangulation.h:13,
 from
/home/yade/YADE-git/trunk/lib/triangulation/Tesselation.h:9,
 from
/home/yade/YADE-git/trunk/pkg/dem/TesselationWrapper.hpp:15,
 from
/home/yade/YADE-git/build/pkg/pfv/FlowEngine_DFNFlowEngineT.hpp:38,
 from /home/yade/YADE-git/trunk/pkg/pfv/DFNFlow.cpp:20:
/usr/include/CGAL/Triangulation_3.h:1012:3: note: candidate:
CGAL::Triangulation_3::Cell_handle
CGAL::Triangulation_3::locate(const Point&,
CGAL::Triangulation_3::Vertex_handle, bool*)
const [with GT = CGAL::Epick; Tds_ =
CGAL::Triangulation_data_structure_3,
CGAL::Boolean_tag, CGAL::Boolean_tag >,
CGAL::Alpha_shape_cell_base_3,
CGAL::Boolean_tag, CGAL::Boolean_tag >,
CGAL::Sequential_tag>; Lock_data_structure_ = CGAL::Default;
CGAL::Triangulation_3::Cell_handle =
CGAL::internal::CC_iterator,
CGAL::Boolean_tag, CGAL::Boolean_tag >,
CGAL::Alpha_shape_cell_base_3,
CGAL::Boolean_tag, CGAL::Boolean_tag >, CGAL::Sequential_tag>
> >, CGAL::Hidden_points_memory_policy,
std::__cxx11::list > > >,
CGAL::Boolean_tag, CGAL::Boolean_tag >, CGAL::Default,
CGAL::Default, CGAL::Default>, false>; CGAL::Triangulation_3::Point = CGAL::Weighted_point_3;
CGAL::Triangulation_3

[Yade-dev] [Bug 1718872] Re: Ip2_FrictMat_FrictViscoMat_FrictViscoPhys() law body assignation problem

[Klaus Thoeni]

Hi Loic,

thanks for reporting. I found the problem. Will try to fix it.

Klaus

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

Title:
  Ip2_FrictMat_FrictViscoMat_FrictViscoPhys() law body assignation
  problem

Status in Yade:
  New

Bug description:
  Hi,

  I was working with the Ip2_FrictMat_FrictViscoMat_FrictViscoPhys() law and I 
think there is a bug with it. In this little script, the two particles must be 
glued after contact, it is the case with the option 2 but in the option 1 it is 
not. The difference between the two options is only the position of the spheres 
(in one case the frictmat in on the top and in the other case this is the 
frictviscomat).
  I think the bug comes from this assignation of the material 1 and 2 in the 
C++ code but I'm not enough familiar with it to solve it.

  I'm working with yadedaily : Yade 2017.01a-99-968a759~trusty

  Loïc

  Here's the script:
  
###

  from yade import qt, plot
  from yade.gridpfacet import *
  import gts, os, locale, sys
  import numpy as np

  O.engines=[
  ForceResetter(),
  InsertionSortCollider([Bo1_Sphere_Aabb(aabbEnlargeFactor = 1)]),
  InteractionLoop([Ig2_Sphere_Sphere_ScGeom(interactionDetectionFactor = 
1)],
  [Ip2_FrictMat_FrictViscoMat_FrictViscoPhys()],
  [Law2_ScGeom_FrictViscoPhys_CundallStrackVisco()]),
  NewtonIntegrator(gravity=(0,0,0),damping=0.3,label='newton'),
  ]

  R = 0.008

  # Materiaux #

  FrictViscoMat = O.materials.append( FrictViscoMat(betan = 1,young=5e9, 
poisson=0.3, frictionAngle=radians(10),density = 4000))
  FrictMat = O.materials.append( FrictMat(young=5e9, poisson=0.3, 
frictionAngle=radians(10),density = 4000))

   Option 1 => Not Working
  s1 = O.bodies.append(utils.sphere((0,0,2), radius=R,color=[1,0,0], material = 
FrictViscoMat))
  s2 = O.bodies.append(utils.sphere((0,0,0), radius=R,color=[0,1,0], material = 
FrictMat))
  O.bodies[s1].state.vel[2] = -5
  O.bodies[s2].state.vel[2] = 5

   Option 2 => Working
  #s1 = O.bodies.append(utils.sphere((0,0,0), radius=R,color=[1,0,0], material 
= FrictViscoMat))
  #s2 = O.bodies.append(utils.sphere((0,0,2), radius=R,color=[0,1,0], material 
= FrictMat))
  #O.bodies[s1].state.vel[2] = 5
  #O.bodies[s2].state.vel[2] = -5

  ###
  v=qt.Controller()
  v=qt.View()
  v.viewDir = (0,1,0)
  v.eyePosition = Vector3( 0, -5,1)
  O.run()
  O.dt = 1e-7
  O.saveTmp()

  
#

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1718872/+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] 2nd Yade-DEM workshop

[Klaus Thoeni]

Hi Jerome,

congrats to your new position also from my side and thank you very much for 
your initiative.

I had a look at your proposal which seems to be specifically related to hydro-
mechanical modelling. Is there any particular reason? If I remember correctly, 
the first workshop was not related to a particular topic. I am just wondering 
because you might be approaching different people.

Is the date locked in? I just came back from the Particles conference with the 
following information. The next DEM8 conference is at Uni Twente, July 22-26 
2019. Another international conference people might be attending is SolMech 
2018, 27-31 Aug in Warsaw.

Thanks again for organising this.

Klaus


On Fri, 29 Sep 2017 01:11:33 PM Jerome Duriez wrote:
> Dear all;
> 
> 
> Attached is a very first draft of a possible "Call" for the workshop
> (not published anywhere yet). I'm sharing it here in order to have some
> feedback from your side on the date/venue/topics: all of those should
> ideally fit you, so that we can get together.
> 
> 
> I probably won't be able to drastically change these date/venue/topics,
> but I could try to accommodate to some extent your suggestions/needs if
> any.
> 
> 
> As a side note, and depending on the success to the call (when
> launched), I could try to plan some half-day session "YADE specials"
> gathering very technical presentations/discussions on YADE itself, or
> YADE-based scientific presentations at the scientific margins of the
> workshop.
> 
> 
> The goal is to advertise the workshop before end of (November ?) 2017,
> but your inputs would be welcome much earlier than this date.
> 
> 
> Let me know,
> 
> 
> Jérôme
> 
> Le 04/09/2017 à 18:21, Jerome Duriez a écrit :
> > Hi there,
> > 
> > 
> > I 'm now in my new position (notwithstanding the used email address)
> > in french institute Irstea. It seems my new boss is very open to the
> > idea of such a workshop, probably including for what concerns his wallet.
> > 
> > 
> > I can thus push this idea further, probably with the help of Grenoble
> > to remind me the number of participants at the 1st workshop and to
> > give me an idea about the required credit (how much did the 1st
> > workshop cost ?).
> > 
> > 
> > I guess the goal could still be next summer for now. I noticed another
> > DEM symposium in Glasgow (UK) June 11th - June 18th 2018 (ECCM-ECFD
> > Conferences 2018), which could serve as a first random idea for the
> > Yade workshop dates in case we try to fit with another conference
> > where overseas participants could also go.
> > 
> > 
> > As for the venue (most important), it would be in Aix en Provence, a
> > lovely city near the French Riviera (the Cote d'Azur, along the
> > Mediterranean).
> > 
> > 
> > Thoughts ?
> > 
> > 
> > Jerome
> > 
> > 
> > 
> > --
> > 
> > Jerome Duriez, Research Associate
> > 
> > University of Calgary, Dpt of Civil Engineering
> > 
> > +1 403 220 7367
> > 
> > 
> > 
> > 
> > *From:* Yade-dev
> >  on
> > behalf of Bruno Chareyre 
> > *Sent:* July 20, 2017 5:08 AM
> > *To:* yade-dev@lists.launchpad.net
> > *Subject:* Re: [Yade-dev] 2nd Yade-DEM workshop
> > Hello Jérôme,
> > It sounds like an interesting option, thank you for suggestion.
> > There are many yade users at IRSTEA.
> > Keep in mind that organizing such things needs time to secure some
> > funding, followed by more time to announce the event (people will
> > hardly change their schedule if they discover it just a couple months
> > in advance) and invite some speakers. Next summer could be a bit too
> > early already if you'll start the position in september (congrats!).
> > Or you'd have to be very efficient. :)
> > Let us know when you know more precisely what could be possible.
> > Cheers
> > Bruno
> > 
> > On 07/14/2017 06:07 PM, Jerome Duriez wrote:
> >> Hi,
> >> 
> >> 
> >> I should start a new position in some french institute in September,
> >> and trying to organize next summer a 2d Yade workshop there was
> >> actually something I had in mind.
> >> 
> >> 
> >> Since this position has not officially started and I did not discuss
> >> this idea yet with anyone from this institute (with anyone else
> >> before this email actually..) I won't give much more specifics at the
> >> moment, but would like to say I'm interested in the idea.
> >> 
> >> 
> >> I personally had in mind the standalone version, though I agree
> >> combining with a greater conference would economically make sense. If
> >> the combined version should materialize, I'd propose to keep some
> >> strong YADE connection in the title (even though users from other
> >> codes may still be welcome), because that's what we are and I think
> >> there is already way enough micromechanics symposia...
> >> 
> >> 
> >> Just to start the 

Re: [Yade-dev] yade on windows 10

[Klaus Thoeni]

Hi guys,

I have been playing with the Linux subsystem in Win 10 (mainly the bash 
terminal) for a while. First thing to note is that everything without graphics 
works as expected. However, once you are looking to run something with 
graphics it becomes tricky. You need to install an X server on Windows (e.g. 
Xming). Simple programs would than run with GUI. 

I also tried to install yade and it works, at least without graphical user 
interface. I did not investigate this any further and I don't think it will be 
straight forward to fix.

Cheers
Klaus

On Thu, 13 Jul 2017 05:52:57 PM Bruno Chareyre wrote:
> Hello devs,
> I recently heard that windows 10 was now embedding a bash/ubuntu
> terminal, so that it is technically possible to "apt-get install yade"
> in MS windows!
> Apparently it still needs a couple magic hacks and a few reboot to
> make bash available but nothing very difficult. I don't have access to
> any windows 10 myself but I wanted to let you know in case someone
> would like to give it a try.
> It would be great to have a few lines of documentation on this topic.
> 
> Cheers
> 
> Bruno
> 
> 
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://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 1604266] Re: yade not working prpoperly on Ubuntu/Kubuntu 16.04

[Klaus Thoeni]

Yes, compiling yade without QT is another solution :-)

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

Title:
  yade not working prpoperly on Ubuntu/Kubuntu 16.04

Status in Yade:
  New

Bug description:
  Any version of yade (package, yadedaily, compiled) is giving problems
  on Ubuntu/Kubuntu 16.04. The ipython terminal shows a strange
  behaviour when starting yade with a script. In addition, yade might
  crash when doing some simple operations in the ipython command line.
  Also, using the Inspector does not work for the packaged version (it
  works for yadedaily and compiled). See discussions [1] and [2].
  Problem might be related to QT5 and IPyhton.

  [1] https://answers.launchpad.net/yade/+question/295951
  [2] https://answers.launchpad.net/yade/+question/295827

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

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

[Yade-dev] [Bug 1604266] Re: yade not working prpoperly on Ubuntu/Kubuntu 16.04

[Klaus Thoeni]

Hi all,

here a follow up on this from my side and a "work-around". I know what's
causing the problem and it can be avoided

First of all, this is definitely not a Kubuntu specific problem. I could
not identify a specific pattern but I tried various distros on various
computers and the problem seems to be related to certain computers
(maybe graphic card/driver?).

Anyway, I could figure out what is causing the problem. It is related to
QT and not loading yade.qt.Controller() at start-up is solving the
problem. In order to deactivate this you have to manually modify your
yade executable script after install (e.g., /home/user/path-to-your-
local-yade-install/install/bin/yade... or /usr/bin/yade or
/usr/bin/yadedaily). Look for this line:

if (gui<>'none'): yade.qt.Controller()

It should be around line 174. Comment this line and safe the script.
Launch yade and it should work. In the ipython terminal you can now
press F12 to load the Controller and it will be fine.

Note that this means that you should not load the qt.Controller() in
your scripts either but rather do it once you are in the ipython
terminal.

I even thought about committing this fix, it just involves
commenting/deleting the same line in core/main/main.py.in but wasn't
sure if is in all our interests as some are not having this problem and
it would mean that the qt.Controller() is not loaded by default.

Let me know what you think or if anyone has deeper understanding on
what's going on. At least we know what is causing the problem and that
there is a workaround.

HTH
Klaus

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

Title:
  yade not working prpoperly on Ubuntu/Kubuntu 16.04

Status in Yade:
  New

Bug description:
  Any version of yade (package, yadedaily, compiled) is giving problems
  on Ubuntu/Kubuntu 16.04. The ipython terminal shows a strange
  behaviour when starting yade with a script. In addition, yade might
  crash when doing some simple operations in the ipython command line.
  Also, using the Inspector does not work for the packaged version (it
  works for yadedaily and compiled). See discussions [1] and [2].
  Problem might be related to QT5 and IPyhton.

  [1] https://answers.launchpad.net/yade/+question/295951
  [2] https://answers.launchpad.net/yade/+question/295827

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1604266/+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] Capillary scripts

[Klaus Thoeni]

Hi Jerome,

great addition and thanks for sharing the scripts.

One question, why did you use Matlab/Octave and not python? Python scripts 
would "fit" better into the trunk ;-)

I terms of where to upload the scripts. I would suggest a folder in  
"examples" with an example, your scripts and instructions. I think some people 
already used this approach. But anyway, this is just a suggestion. 

Cheers
Klaus

On Wed, 14 Sep 2016 01:19:16 AM Jerome Duriez wrote:
> Hello,
> 
> 
> After a couple of private emails with Bruno, I can confirm that these
> scripts work with GNU Octave as well (in addition to the less open-source
> friendly MATLAB )
> 
> 
> We mentionned with Bruno the possibility uploading these .m scripts on the
> wiki, however I would greatly prefer they are in trunk, in order to enjoy
> the revision tracking tools.
> 
> As these scripts are not bound, from my point of view, to any non
> open-source tool, I think it should be fine. Any opinion ? (Bruno ? others
> ?)
> 
> 
> Another question is what would be the best trunk subfolder for these files ?
> trunk/scripts ?
> 
> 
> 
> --
> 
> Jerome Duriez, Research Associate
> 
> University of Calgary, Dpt of Civil Engineering
> 
> +1 403 220 7367
> 
> 
> 
> From: Yade-dev
>  on behalf
> of Jerome Duriez  Sent: September-08-16 6:02 PM
> To: Yade dev
> Subject: [Yade-dev] Capillary scripts
> 
> 
> Hi there,
> 
> 
> Attached are three .m scripts aimed at generating capillary files for use
> with Law2_ScGeom_CapillaryPhys_Capillarity. Obviously, the idea, discussed
> previously here and there on the mailing lists, is to make this part of
> YADE more "open-source". Also, there is two major differences with previous
> (L. Scholtes') work:
> 
> 
> * these scripts may generate capillary files accommodating any contact angle
> value, instead of 0 previously
> 
> 
> * they provide new output as an "orientation tensor" defined from the
> fluid-fluid interface of capillary bridges. These data would constitute new
> attributes of CapillaryPhys, see "nn11" and "nn33" in the attached version
> of CapillaryPhys.hpp. (Note that these nn11 and nn33 can be used to get the
> bridge fluid-fluid interface S as S = 2*nn11 + nn33). This is about
> post-processing only.
> 
> 
> The attached README.txt details the role of the .m files and how to use
> them: interested users in the end just need to give a look to, and launch,
> writesCapFile.m.
> 
> 
> 
> The core of the work, as usual, is solving the Laplace-Young equation for a
> capillary bridge configuration. The corresponding, quite classical,
> equations appear in solveLiqBridge file/function. There will be a dedicated
> journal paper on this topic, currently under "Minor Revision" review.
> 
> 
> 
> These files are ready to be pushed to trunk, together with updated
> CapillaryPhys (see attached), and Law2_ScGeom_CapillaryPhys_Capillarity, in
> order to read the new data (nn11 and nn33) from generated capillary files.
> 
> 
> This email is for possible discussion before I perform the commit.
> 
> 
> Cheers,
> 
> 
> Jerome
> 
> 
> PS: Vaclav, I took the liberty cc-ing you since I had once the feeling you
> would be interested in such scripts. (Woo does not include any capillary
> interactions at the moment, though ?)
> 
> 
> 
> --
> 
> Jerome Duriez, Research Associate
> 
> University of Calgary, Dpt of Civil Engineering
> 
> +1 403 220 7367


___
Mailing list: https://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 1604266] Re: yade not working prpoperly on Ubuntu/Kubuntu 16.04

[Klaus Thoeni]

Hi Anton,

thanks for having a look at this. Nevertheless, this should not be
restricted to Kubuntu. In fact, I can reproduce the exactly same
behaviour in Ubuntu and 3 more users have confirmed the problem on
Ubuntu. Ubuntu and Kubuntu use the same packages/library versions so
this makes also sense.

The IPython version from packages is 2.4.1 and as Vaclav pointed out it
does not support QT5. Installing IPython 5.0.0 with pip however does not
solve the problem. The strange terminal behaviour is gone but the GUI is
not working properly (it only works in "idle" mode, i.e., after pressing
Ctrl+D). The warnings when launching yade with IPython 5.0.0 are as
follows:

Welcome to Yade 1.20.0 
TCP python prompt on localhost:9000, auth cookie `cuasek'
XMLRPC info provider on http://localhost:21000
QSettings::value: Empty key passed
QSettings::value: Empty key passed
/home/yade/.local/lib/python2.7/site-packages/IPython/config.py:13: 
ShimWarning: The `IPython.config` package has been deprecated. You should 
import from traitlets.config instead.
  "You should import from traitlets.config instead.", ShimWarning)
/home/yade/.local/lib/python2.7/site-packages/IPython/core/interactiveshell.py:440:
 UserWarning: As of IPython 5.0 `PromptManager` config will have no effect and 
has been replaced by TerminalInteractiveShell.prompts_class
  warn('As of IPython 5.0 `PromptManager` config will have no effect'
[[ ^L clears screen, ^U kills line. F12 controller, F11 3d view (use h-key for 
showing help), F10 both, F9 generator, F8 plot. ]]

In [1]:


BTW, I tried to compile with QT4 by installing corresponding packages and 
USE_QT5=0. Configuration and compilation was smooth. However, when launching 
yade it crashes:

Welcome to Yade 2016-07-09.git-9003796 
TCP python prompt on localhost:9000, auth cookie `escsay'
XMLRPC info provider on http://localhost:21000
Traceback (most recent call last):
  File "./yade-2016-07-09.git-9003796", line 281, in 
import yade.qt # this yade.qt is different from the one that comes with qt3
  File 
"/home/yade/YADE/source-code/install/lib/x86_64-linux-gnu/yade-2016-07-09.git-9003796/py/yade/qt/__init__.py",
 line 15, in 
from yade.qt.Inspector import *
  File 
"/home/yade/YADE/source-code/install/lib/x86_64-linux-gnu/yade-2016-07-09.git-9003796/py/yade/qt/Inspector.py",
 line 3, in 
from PyQt5.QtCore import *
RuntimeError: the PyQt5.QtCore and PyQt4.QtCore modules both wrap the QObject 
class
*** Error in `/usr/bin/python': free(): invalid pointer: 0x7f38a12c67c0 ***

It looks like it's still accessing some qt5 libs.

Would appreciate if we could solve the issue either way (qt4 or qt5).

Cheers
Klaus

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

Title:
  yade not working prpoperly on Ubuntu/Kubuntu 16.04

Status in Yade:
  New

Bug description:
  Any version of yade (package, yadedaily, compiled) is giving problems
  on Ubuntu/Kubuntu 16.04. The ipython terminal shows a strange
  behaviour when starting yade with a script. In addition, yade might
  crash when doing some simple operations in the ipython command line.
  Also, using the Inspector does not work for the packaged version (it
  works for yadedaily and compiled). See discussions [1] and [2].
  Problem might be related to QT5 and IPyhton.

  [1] https://answers.launchpad.net/yade/+question/295951
  [2] https://answers.launchpad.net/yade/+question/295827

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

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

[Yade-dev] [Bug 1604266] Re: yade not working prpoperly on Ubuntu/Kubuntu 16.04

[Klaus Thoeni]

Hi Anton,

did you use IPython from pip as indicated by Vaclav or just standard
packages?

I can provide you the virtual machine for Ubuntu/Kubuntu if it helps.
Let me know.

Cheers
Klaus

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

Title:
  yade not working prpoperly on Ubuntu/Kubuntu 16.04

Status in Yade:
  New

Bug description:
  Any version of yade (package, yadedaily, compiled) is giving problems
  on Ubuntu/Kubuntu 16.04. The ipython terminal shows a strange
  behaviour when starting yade with a script. In addition, yade might
  crash when doing some simple operations in the ipython command line.
  Also, using the Inspector does not work for the packaged version (it
  works for yadedaily and compiled). See discussions [1] and [2].
  Problem might be related to QT5 and IPyhton.

  [1] https://answers.launchpad.net/yade/+question/295951
  [2] https://answers.launchpad.net/yade/+question/295827

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

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

[Yade-dev] [Bug 1604266] [NEW] yade not working prpoperly on Ubuntu/Kubuntu 16.04

[Klaus Thoeni]

Public bug reported:

Any version of yade (package, yadedaily, compiled) is giving problems on
Ubuntu/Kubuntu 16.04. The ipython terminal shows a strange behaviour
when starting yade with a script. In addition, yade might crash when
doing some simple operations in the ipython command line. Also, using
the Inspector does not work for the packaged version (it works for
yadedaily and compiled). See discussions [1] and [2]. Problem might be
related to QT5 and IPyhton.

[1] https://answers.launchpad.net/yade/+question/295951
[2] https://answers.launchpad.net/yade/+question/295827

** 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/1604266

Title:
  yade not working prpoperly on Ubuntu/Kubuntu 16.04

Status in Yade:
  New

Bug description:
  Any version of yade (package, yadedaily, compiled) is giving problems
  on Ubuntu/Kubuntu 16.04. The ipython terminal shows a strange
  behaviour when starting yade with a script. In addition, yade might
  crash when doing some simple operations in the ipython command line.
  Also, using the Inspector does not work for the packaged version (it
  works for yadedaily and compiled). See discussions [1] and [2].
  Problem might be related to QT5 and IPyhton.

  [1] https://answers.launchpad.net/yade/+question/295951
  [2] https://answers.launchpad.net/yade/+question/295827

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1604266/+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] HydroForceEngine

[Klaus Thoeni]

Hi Raphael,

thank you very much for the examples, I think they are really helpful to 
understand your HydroForceEngine.

You have to log in into the wiki and then you can edit the pages. You have to 
request an account here [1].

And yes, you are right, we should inform users and devs about the folder. I am 
going to add something to the doc pages.

Cheers
Klaus

[1] https://yade-dem.org/wiki/Special:UserLogin


On Sat, 9 Jul 2016 12:36:11 AM Maurin Raphaël wrote:
> Hi Klaus,
> 
> I can upload the movie on youtube soon. How can I add it to the wiki after ?
> 
> I made one very basic script to apply buoyancy to three particles of
> different densities. I also made a "fluidized bed" test case, which is
> quite rough but looks ok. It gives an idea of what could be done more
> rigourously, and helps to get familiar with the discrete random walk
> fluctuation model included inside HydroForceEngine. You need to use the
> last version from the source code to make this last two scripts work, I
> made some small modifications in the same time.
> 
> By the way, it may look surprising but I was not aware of the presence of
> this example folder which contains a lot of informations about other
> developments. I think there is no obvious link to this folder/examples
> scripts on the yade website (at least I didn't find one), maybe it would be
> nice to highlight it (at the end of the tutorial for example).
> 
> Best,
> 
> Raphael Maurin, PhD
> Post-doctoral researcher
> IMFT, Univ. Toulouse
> raphael.mau...@imft.fr
> 
> 
> - Mail original -
> De: "Klaus Thoeni" <klaus.tho...@gmail.com>
> À: "Maurin Raphaël" <raphael.mau...@irstea.fr>
> Cc: yade-dev@lists.launchpad.net
> Envoyé: Jeudi 7 Juillet 2016 13:31:25
> Objet: Re: [Yade-dev]  HydroForceEngine
> 
> Hi Raphael,
> 
> thanks for the script (haven't been able to test it yet) and the great
> movie. Are you going to upload it on youtube? I think it should be added to
> fluid- solid coupling part even if you have to impose the fluid part at
> this stage.
> 
> BTW, do you have a some more simpler example as well (maybe constant flow,
> or buoyancy only)? I came across this [1] but when I tried the script it
> was not working.
> 
> Someone here asked me if your engine can be used for simulation fluidised
> beds. That should work, right?
> 
> Cheers
> Klaus
> 
> [1] https://answers.launchpad.net/yade/+question/269831
> 
> On Mon, 4 Jul 2016 06:34:10 PM Maurin Raphaël wrote:
> > Hi Klaus,
> > 
> > I made a commented example script and I placed it in the (new) folder
> > examples/HydroForceEngine, I hope it is fine for you. It is not using all
> > the capabilities of HydroForceEngine as the latter is made to couple Yade
> > with a 1D RANS fluid resolution, while the example script uses an imposed
> > fluid profile. The fluid code I am using is still in Fortran77 and I
> > didn't
> > have the time to write it in C++, so that it will stay like that for now.
> > I
> > hope it already helps to get into HydroForceEngine.
> > 
> > Therefore, I don't know if it is appropriate to put something in the
> > fluid-solid coupling part of the wiki for now, what do you think ?
> > 
> > Best,
> > 
> > Raphael
> > 
> > Raphael Maurin, PhD
> > Post-doctoral researcher
> > IMFT, Univ. Toulouse
> > raphael.mau...@imft.fr
> > 
> > - Mail original -
> > De: "Klaus Thoeni" <klaus.tho...@gmail.com>
> > À: "Maurin Raphaël" <raphael.mau...@irstea.fr>
> > Cc: "Yade developers" <yade-dev@lists.launchpad.net>
> > Envoyé: Dimanche 3 Juillet 2016 12:38:55
> > Objet: Re: [Yade-dev]  HydroForceEngine
> > 
> > Hi Raphael,
> > 
> > it would be great to have some basic examples showing the usage and the
> > capabilities of the HydroForceEngine. Apparently, there are so many
> > parameters in that engine that it is quite tricky to understand. I think
> > there is as well room to improve the documentation, maybe the examples
> > will
> > make things clearer.
> > 
> > BTW, do you have a nice movie you could put on youtube. I think we should
> > add something here:
> > 
> > https://yade-dem.org/wiki/Fluid-solid_coupling
> > 
> > Thanks a lot,
> > Klaus
> > 
> > On Sun, 3 Jul 2016 01:00:26 AM Maurin Raphaël wrote:
> > > Hi Klaus,
> > > 
> > > What exactly do you want ? An example script using HydroForceEngine ?
> > > If that is the case I can do one, just tell me where I am suppose to
> > > write
> > >

Re: [Yade-dev] HydroForceEngine

[Klaus Thoeni]

Hi Raphael,

thanks for the script (haven't been able to test it yet) and the great movie. 
Are you going to upload it on youtube? I think it should be added to fluid-
solid coupling part even if you have to impose the fluid part at this stage.

BTW, do you have a some more simpler example as well (maybe constant flow, or 
buoyancy only)? I came across this [1] but when I tried the script it was not 
working.

Someone here asked me if your engine can be used for simulation fluidised beds. 
That should work, right?

Cheers
Klaus

[1] https://answers.launchpad.net/yade/+question/269831

On Mon, 4 Jul 2016 06:34:10 PM Maurin Raphaël wrote:
> Hi Klaus,
> 
> I made a commented example script and I placed it in the (new) folder
> examples/HydroForceEngine, I hope it is fine for you. It is not using all
> the capabilities of HydroForceEngine as the latter is made to couple Yade
> with a 1D RANS fluid resolution, while the example script uses an imposed
> fluid profile. The fluid code I am using is still in Fortran77 and I didn't
> have the time to write it in C++, so that it will stay like that for now. I
> hope it already helps to get into HydroForceEngine.
> 
> Therefore, I don't know if it is appropriate to put something in the
> fluid-solid coupling part of the wiki for now, what do you think ?
> 
> Best,
> 
> Raphael
> 
> Raphael Maurin, PhD
> Post-doctoral researcher
> IMFT, Univ. Toulouse
> raphael.mau...@imft.fr
> 
> - Mail original -
> De: "Klaus Thoeni" <klaus.tho...@gmail.com>
> À: "Maurin Raphaël" <raphael.mau...@irstea.fr>
> Cc: "Yade developers" <yade-dev@lists.launchpad.net>
> Envoyé: Dimanche 3 Juillet 2016 12:38:55
> Objet: Re: [Yade-dev]  HydroForceEngine
> 
> Hi Raphael,
> 
> it would be great to have some basic examples showing the usage and the
> capabilities of the HydroForceEngine. Apparently, there are so many
> parameters in that engine that it is quite tricky to understand. I think
> there is as well room to improve the documentation, maybe the examples will
> make things clearer.
> 
> BTW, do you have a nice movie you could put on youtube. I think we should
> add something here:
> 
> https://yade-dem.org/wiki/Fluid-solid_coupling
> 
> Thanks a lot,
> Klaus
> 
> On Sun, 3 Jul 2016 01:00:26 AM Maurin Raphaël wrote:
> > Hi Klaus,
> > 
> > What exactly do you want ? An example script using HydroForceEngine ?
> > If that is the case I can do one, just tell me where I am suppose to write
> > that in the source code.
> > 
> > Best,
> > 
> > Raphael
> > 
> > 
> > Raphael Maurin
> > PhD, Post-doctoral researcher
> > IMFT, Univ. Toulouse
> > raphael.mau...@imft.fr
> > 
> > - Mail original -
> > 
> > De: "Klaus Thoeni" <klaus.tho...@gmail.com>
> > À: "Yade developers" <yade-dev@lists.launchpad.net>
> > Envoyé: Samedi 2 Juillet 2016 14:33:24
> > Objet: [Yade-dev] HydroForceEngine
> > 
> > Hi guys (Raphael?),
> > 
> > I couldn't find any example scripts for the HydroForceEngine. Please could
> > you add some to the source code?
> > 
> > Thanks a lot,
> > Klaus
> > 
> > ___
> > Mailing list: https://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] HydroForceEngine

[Klaus Thoeni]

Hi Raphael,

it would be great to have some basic examples showing the usage and the 
capabilities of the HydroForceEngine. Apparently, there are so many parameters 
in that engine that it is quite tricky to understand. I think there is as well 
room to improve the documentation, maybe the examples will make things 
clearer.

BTW, do you have a nice movie you could put on youtube. I think we should add 
something here:

https://yade-dem.org/wiki/Fluid-solid_coupling

Thanks a lot,
Klaus

On Sun, 3 Jul 2016 01:00:26 AM Maurin Raphaël wrote:
> Hi Klaus,
> 
> What exactly do you want ? An example script using HydroForceEngine ?
> If that is the case I can do one, just tell me where I am suppose to write
> that in the source code.
> 
> Best,
> 
> Raphael
> 
> 
> Raphael Maurin
> PhD, Post-doctoral researcher
> IMFT, Univ. Toulouse
> raphael.mau...@imft.fr
> 
> - Mail original -
> 
> De: "Klaus Thoeni" <klaus.tho...@gmail.com>
> À: "Yade developers" <yade-dev@lists.launchpad.net>
> Envoyé: Samedi 2 Juillet 2016 14:33:24
> Objet: [Yade-dev] HydroForceEngine
> 
> Hi guys (Raphael?),
> 
> I couldn't find any example scripts for the HydroForceEngine. Please could
> you add some to the source code?
> 
> Thanks a lot,
> Klaus
> 
> ___
> Mailing list: https://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] HydroForceEngine

[Klaus Thoeni]

Hi guys (Raphael?),

I couldn't find any example scripts for the HydroForceEngine. Please could
you add some to the source code?

Thanks a lot,
Klaus
___
Mailing list: https://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] Naming GridConnection

[Klaus Thoeni]

Yes, will do!

On Thu, 16 Jun 2016 07:30:52 PM Anton Gladky wrote:
> Hi Klaus,
> 
> could you please update also a test-case. Because during yade --test
> one get a notification " chainedCylinder is deprecated."
> 
> Thanks
> 
> Anton
> 
> 
> 2016-06-10 14:43 GMT+02:00 Klaus Thoeni <klaus.tho...@gmail.com
> 
> <javascript:;>>:
> > Hi guys,
> > 
> > just pulled some helper functions for cylinders and some related examples.
> > 
> > I also created a script examples/cylinders/cylinderconnection-roots.py
> 
> which
> 
> > is aimed to replace examples/chained-cylinders/chained-cylinder-roots.py.
> 
> I
> 
> > couldn't get the box-gridConnection interactions to working, but I guess
> 
> I am
> 
> > missing something.
> > 
> > In addition, have a look at examples/cylinders/cylinder-cylinder.py. Is
> 
> there
> 
> > a way of linking the rotation of the GridNodes to the
> 
> GridConnection/Cylinder?
> 
> > I guess increasing the bending stiffness would help but how can we make it
> > independent of this? Any suggestions?
> > 
> > Cheers
> > Klaus


___
Mailing list: https://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] Naming GridConnection

[Klaus Thoeni]

Hi guys,

just pulled some helper functions for cylinders and some related examples.

I also created a script examples/cylinders/cylinderconnection-roots.py which 
is aimed to replace examples/chained-cylinders/chained-cylinder-roots.py. I 
couldn't get the box-gridConnection interactions to working, but I guess I am 
missing something.

In addition, have a look at examples/cylinders/cylinder-cylinder.py. Is there 
a way of linking the rotation of the GridNodes to the GridConnection/Cylinder? 
I guess increasing the bending stiffness would help but how can we make it 
independent of this? Any suggestions?

Cheers
Klaus

On Tue, 17 May 2016 09:31:13 AM François wrote:
> 2016-05-11 15:11 GMT+02:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>:
> > On 05/11/2016 01:52 PM, Klaus Thoeni wrote:
> >> I think sooner or later we should get rid of the current ChainedCylinder
> >> implementation.
> > 
> > Agreed
> > 
> >> But you are right, the algorithms are slightly different,
> >> although it might just the physics (?). I haven't compared the code yet
> >> but I
> >> added two examples in examples/grids which are the same as in
> >> examples/chained-cylinders and the results are slightly different.
> > 
> > Mmmhh.. I'll have to have a look.
> 
> Sliding contact ​tracking algorithm is slightly different so the results
> are a little different too.
> 
> >   Any idea how
> >> 
> >> many people are using ChainedCylinder?
> > 
> > Not many AFAIK
> 
> I converted everyone to grid here at Irstea.​
> 
> > 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] Naming GridConnection

[Klaus Thoeni]

 Hi again,

> ChainedCylinder could also print a warning, doing nothing in the simulation
> but suggesting to have a look at GridNodes/Connections documentation.
> Cylinders and Grid don't have exactly the same algorithms, therefore I
> think it is safer to do nothing rather than letting the user think it is
> working as before.

I think sooner or later we should get rid of the current ChainedCylinder 
implementation. But you are right, the algorithms are slightly different, 
although it might just the physics (?). I haven't compared the code yet but I 
added two examples in examples/grids which are the same as in 
examples/chained-cylinders and the results are slightly different. Any idea how 
many people are using ChainedCylinder?

> An other "problem" is linked to the grid-grid contacts : Grids elements
> need a set of specific masks and the collider "avoidSelfInteractionMask" to
> be set, OR to add the GridCo-GridCo IGeom/Law2 in the engines.

Yes, but this is something which should be pointed out by appropriate 
examples.

Cheers
K


> 2016-05-11 13:33 GMT+02:00 François <francois.kn...@gmail.com>:
> > Hi,
> > ChainedCylinder could also print a warning, doing nothing in the
> > simulation but suggesting to have a look at GridNodes/Connections
> > documentation.
> > Cylinders and Grid don't have exactly the same algorithms, therefore I
> > think it is safer to do nothing rather than letting the user think it is
> > working as before.
> > 
> > François
> > 
> > 2016-05-11 13:23 GMT+02:00 Klaus Thoeni <klaus.tho...@gmail.com>:
> >> Hi Bruno,
> >> 
> >> here my suggestion: add Cylinder and ChainedCylinder functions to
> >> gridpfacet.py. Both functions would not require to define GridNodes to
> >> avoid
> >> confusion but they would be generated by the functions (hidden from the
> >> user).
> >> Grids would still require the generation of GridNodes.
> >> 
> >> What do you think? Let me know, I am happy to implement it.
> >> 
> >> Cheers
> >> Klaus
> >> 
> >> On Wed, 11 May 2016 12:04:44 PM Bruno Chareyre wrote:
> >> > Hi all,
> >> > Reading Klaus' answer below I realize that replacing "cylinder" by
> >> > "grid
> >> > connection" will not help to intuitively recognize which class can be
> >> > used to modelize a single cylinder.
> >> > I wonder how it could be improved. Beyhond renaming GridConnection
> >> > (still an option), we could make ChainedCylinder, or maybe just
> >> > Cylinder
> >> > an alias of GridConnection.
> >> > Other suggestions?
> >> > 
> >> > Bruno
> >> > 
> >> > On 05/06/2016 03:32 AM, Klaus Thoeni wrote:
> >> > > Question #293342 on Yade changed:
> >> > > https://answers.launchpad.net/yade/+question/293342
> >> > > 
> >> > > Klaus Thoeni proposed the following answer:
> >> > > Hi Alex,
> >> > > 
> >> > > in addition ChainedCylinder is deprecated and might be removed in the
> >> > > future. You should use GridConnection instead to create cylinders.
> >> > > For
> >> > > examples see [1]
> >> > > 
> >> > > K
> >> > > 
> >> > > [1] https://github.com/yade/trunk/tree/master/examples/grids
> >> > 
> >> > ___
> >> > Mailing list: https://launchpad.net/~yade-dev
> >> > Post to : yade-dev@lists.launchpad.net
> >> > Unsubscribe : https://launchpad.net/~yade-dev
> >> > More help   : https://help.launchpad.net/ListHelp
> >> 
> >> ___
> >> Mailing list: https://launchpad.net/~yade-dev
> >> Post to : yade-dev@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~yade-dev
> >> More help   : https://help.launchpad.net/ListHelp


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

Re: [Yade-dev] Naming GridConnection

[Klaus Thoeni]

Hi Bruno,

here my suggestion: add Cylinder and ChainedCylinder functions to 
gridpfacet.py. Both functions would not require to define GridNodes to avoid 
confusion but they would be generated by the functions (hidden from the user). 
Grids would still require the generation of GridNodes. 

What do you think? Let me know, I am happy to implement it.

Cheers
Klaus

On Wed, 11 May 2016 12:04:44 PM Bruno Chareyre wrote:
> Hi all,
> Reading Klaus' answer below I realize that replacing "cylinder" by "grid
> connection" will not help to intuitively recognize which class can be
> used to modelize a single cylinder.
> I wonder how it could be improved. Beyhond renaming GridConnection
> (still an option), we could make ChainedCylinder, or maybe just Cylinder
> an alias of GridConnection.
> Other suggestions?
> 
> Bruno
> 
> On 05/06/2016 03:32 AM, Klaus Thoeni wrote:
> > Question #293342 on Yade changed:
> > https://answers.launchpad.net/yade/+question/293342
> > 
> > Klaus Thoeni proposed the following answer:
> > Hi Alex,
> > 
> > in addition ChainedCylinder is deprecated and might be removed in the
> > future. You should use GridConnection instead to create cylinders. For
> > examples see [1]
> > 
> > K
> > 
> > [1] https://github.com/yade/trunk/tree/master/examples/grids
> 
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Yade-dev] Yade release, new versioning?

[Klaus Thoeni]

I like the idea, either way sounds good to me.

Klaus

On Wed, 20 Apr 2016 08:35:29 AM Jan Stránský wrote:
> Hi Anton,
> I am ok with .MM. What about just YY.MM, 16.04, like Ubuntu?
> cheers
> Jan
> 
> 2016-04-19 22:13 GMT+02:00 Anton Gladky :
> > Dear all,
> > 
> > I am planning to release new Yade version soon, because
> > the 1.20.0 was released about 6 months ago and we have
> > over 120 commits now.
> > 
> > Some projects now are using the following versioning for
> > releases: .MM (i.e. 2016.04). Do we want to adopt
> > such a system?
> > 
> > I think this versioning is better in comparison to our numbering,
> > because it includes the information about release time.
> > 
> > Looking forward for your comments.
> > 
> > Best regards
> > 
> > Anton
> > 
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp


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

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3806: better handling of double contacts, get gid of function ScGem goOneWay

[Klaus Thoeni]

Hi Bruno,

actually, we have been using this just committed version of the code for quite 
a while as we found as well that there was a problem with GridConnection-
PFacet interactions. The tests we did for the paper did mainly include sphere-
grid and sphere-pfacet interactions. Our examples should not be affected but I 
will ask Anna to re-run the tests.

I know that the fix is probably not the nicest one as there is a lot of 
duplicated code but it fixes the seg fault issue for GridConnection-PFacet 
interactions and avoids some other issues with duplicated contacts with 
PFacets.

We will add some check-scripts.

Cheers
Klaus

On Thu, 10 Mar 2016 04:23:35 PM Bruno Chareyre wrote:
> Hi Klaus,
> I see many new lines just to fix one bug. Could you explain a bit?
> Would you have a couple scripts to suggest (our paper has good
> benchmarks tests) that we could include in check-scripts to be sure the
> main things don't get silently broken?
> Bruno
> 
> On 10/03/16 14:30, nore...@launchpad.net wrote:
> > 
> > revno: 3806
> > committer: Klaus Thoeni <klaus.tho...@gmail.com>
> > timestamp: Thu 2016-03-10 21:35:34 +1100
> > 
> > message:
> >   better handling of double contacts, get gid of function ScGem goOneWay
> > 
> > modified:
> >   pkg/common/PFacet.cpp
> >   pkg/common/PFacet.hpp
> > 
> > --
> > lp:yade
> > https://code.launchpad.net/~yade-pkg/yade/git-trunk
> > 
> > Your team Yade developers is subscribed to branch lp:yade.
> > To unsubscribe from this branch go to
> > https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription
> > 
> > 
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp


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

[Yade-dev] {yade-dev] Online documentation / Server

[Klaus Thoeni]

Hi guys,

just realised that the online documentation is not up-to-date with the latest 
trunk version. In addition, as pointed out by Anton --test causes a segfault. 
This must be to an earlier commit.  Isn't the server supposed to automatically 
compile and run --test and make doc?

Cheers
Klaus

___
Mailing list: https://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] Move utils for "grid and more" in separate file

[Klaus Thoeni]

Hi Jan,

thanks for you comments.

add 2): I think a file for every shape is probably an overkill. Or anyone 
disagrees? I would keep general stuff like sphere, facet, box, wall in utils.py 
and use separate modules for polyhedra and gridpfacet as they are very 
specific. Regarding the latter, I think grids and pfacets should be one module 
because the concept is the same, i.e., a pfacet is a grid with closed 
openings. The latest trunk version already includes this module 
(py/gridpfacet.py). Finally, I think the polyhedra stuff in utlis.py should be 
moved into polyhedra_utils.py. You agree?

Thanks
Klaus

On Thu, 10 Dec 2015 11:00:28 PM Jan Stránský wrote:
> Hi Klaus,
> 
> 1) no problem
> 2) the logic is that the original author Jan Elias made polyhedra_utils.py
> file and then I made modifications of utils.py, adding sphere() like
> function for polyhedra. I was thinkink about creating special file just for
> different shapes (sphere, facet, polyhedra, box, wall...), but never did
> it. Still I think it is a good idea. Anyway any file split is ok for me..
> 
> cheers
> Jan
> 
> 2015-12-08 7:30 GMT+01:00 Klaus Thoeni <klaus.tho...@gmail.com>:
> > Hi guys,
> > 
> > I am about to push the pfacet code (as a Xmas present) but before I wanted
> > to
> > discuss the following:
> > 
> > 1) The utils module is massive and I suggest that we move everything
> > related
> > to cylinder, grids and pfacets in a new file, e.g. gridpfacet_utils.py.
> > Are you
> > happy if I chance this?
> > 
> > 2) Something similar seems already to exist for the polyhedra. However,
> > there
> > are still some polyhedra functions in utils.py. Wouldn't it make sense to
> > move
> > them as well into polyhedra_utils.py? @Jan, what is the logic behind this?
> > 
> > 3) @Bruno: Is the chainedCylinder going to die or are we still keeping it?
> > The
> > implementation of the contact law for the connection/chain seems not to be
> > exactly the same as for gridConnection, as I was not able to reproduce the
> > results with the same parameters. Nevertheless,  the concept is the same,
> > right?
> > 
> > Cheers
> > Klaus
> > 
> > ___
> > Mailing list: https://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] Move utils for "grid and more" in separate file

[Klaus Thoeni]

Hi guys,

I am about to push the pfacet code (as a Xmas present) but before I wanted to 
discuss the following:

1) The utils module is massive and I suggest that we move everything related 
to cylinder, grids and pfacets in a new file, e.g. gridpfacet_utils.py. Are you 
happy if I chance this?

2) Something similar seems already to exist for the polyhedra. However, there 
are still some polyhedra functions in utils.py. Wouldn't it make sense to move 
them as well into polyhedra_utils.py? @Jan, what is the logic behind this?

3) @Bruno: Is the chainedCylinder going to die or are we still keeping it? The 
implementation of the contact law for the connection/chain seems not to be 
exactly the same as for gridConnection, as I was not able to reproduce the 
results with the same parameters. Nevertheless,  the concept is the same, 
right?

Cheers
Klaus

___
Mailing list: https://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] Server down???

[Klaus Thoeni]

I just updated it. Apparently it doesn't look like you can download any 
revision from github. I just found releases. Well should be fine anyway.

Cheers
Klaus

On Tue, 28 Oct 2014 05:32:34 PM Bruno Chareyre wrote:
 Proposal:
 For those behind firewall, you can download any revision of the repository
 as compressed archive from the github page of the corresponding revision.
 
 
 No need for a tarball repository, github is doing that for us.
 
 B
 
 On 27/10/14 23:15, Klaus Thoeni wrote:
  Hi guys,
  
  the link is here [1], under Source code - Download it says:
  
  For those behind firewall, you can download any revision of the repository
  as compressed archive.
  
  Anton introduced it here [2].
  
  Anyway, do we need it? Let me know, if not I delete it.
  
  Cheers
  Klaus
  
  [1] https://yade-dem.org/doc/installation.html
  [2]
  https://github.com/yade/trunk/commit/0395cea640732904e05040462d47215989f9b
  be7 
  On Mon, 27 Oct 2014 05:14:11 PM Bruno Chareyre wrote:
  Remi is not more than me aware of any page at this adress. How did you
  get such url Klaus?
  B
  
  On 27/10/14 15:39, Eulitz, Alexander wrote:
  That's the same question I did not dare to ask ;)
  
  -Ursprüngliche Nachricht-
  Von: Yade-dev
  [mailto:yade-dev-bounces+alexander.eulitz=iwf.tu-berlin.de@lists.launchp
  a
  d.net] Im Auftrag von Bruno Chareyre Gesendet: Montag, 27. Oktober 2014
  15:37
  An: yade-dev@lists.launchpad.net
  Betreff: Re: [Yade-dev] Server down???
  
  I guess it is a problem on 3sr server, but... dumb question: what is
  found
  there usually? B
  
  On 27/10/14 05:45, Klaus Thoeni wrote:
  Hi guys,
  
  the access on [1] is not working.
  
  Not sure who is responsible for it but can we fix it?
  
  Thanks,
  Klaus
  
  
  [1] https://www.yade-dem.org/source/
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
  
  --
  ___
  Bruno Chareyre
  Associate Professor
  ENSE³ - Grenoble INP
  Lab. 3SR
  BP 53
  38041 Grenoble cedex 9
  Tél : +33 4 56 52 86 21
  Fax : +33 4 76 82 70 43
  
  
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://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] Server down???

[Klaus Thoeni]

Hi guys,

the link is here [1], under Source code - Download it says:

For those behind firewall, you can download any revision of the repository as 
compressed archive.

Anton introduced it here [2].

Anyway, do we need it? Let me know, if not I delete it.

Cheers
Klaus

[1] https://yade-dem.org/doc/installation.html
[2] 
https://github.com/yade/trunk/commit/0395cea640732904e05040462d47215989f9bbe7

On Mon, 27 Oct 2014 05:14:11 PM Bruno Chareyre wrote:
 Remi is not more than me aware of any page at this adress. How did you
 get such url Klaus?
 B
 
 On 27/10/14 15:39, Eulitz, Alexander wrote:
  That's the same question I did not dare to ask ;)
  
  -Ursprüngliche Nachricht-
  Von: Yade-dev
  [mailto:yade-dev-bounces+alexander.eulitz=iwf.tu-berlin.de@lists.launchpa
  d.net] Im Auftrag von Bruno Chareyre Gesendet: Montag, 27. Oktober 2014
  15:37
  An: yade-dev@lists.launchpad.net
  Betreff: Re: [Yade-dev] Server down???
  
  I guess it is a problem on 3sr server, but... dumb question: what is found
  there usually? B
  
  On 27/10/14 05:45, Klaus Thoeni wrote:
  Hi guys,
  
  the access on [1] is not working.
  
  Not sure who is responsible for it but can we fix it?
  
  Thanks,
  Klaus
  
  
  [1] https://www.yade-dem.org/source/
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
  
  --
  ___
  Bruno Chareyre
  Associate Professor
  ENSE³ - Grenoble INP
  Lab. 3SR
  BP 53
  38041 Grenoble cedex 9
  Tél : +33 4 56 52 86 21
  Fax : +33 4 76 82 70 43
  
  
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp


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

[Yade-dev] Server down???

[Klaus Thoeni]

Hi guys,

the access on [1] is not working.

Not sure who is responsible for it but can we fix it?

Thanks,
Klaus


[1] https://www.yade-dem.org/source/

___
Mailing list: https://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] Minimal required Eigen3 version is 3.2.1

[Klaus Thoeni]

Hi Anton,

why is Eigen3 version 3.2.1 for Trusty not included on our ppa:yade-
users/external but instead on http://yade-dem.org/packages? The default 
version in Trusty is 3.2.0-8.

Cheers
Klaus

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

Re: [Yade-dev] [Yade-users] [Question #251712]: Two problems for post-processing

[Klaus Thoeni]

On Thursday 17 July 2014 12:47:30 Bruno Chareyre wrote:
 On 17/07/14 10:26, Jérôme Duriez wrote:
  Yade must be be consistent and the convention for strain/stress is
  traction positive. If python says -1 then paraview should also say -1,
  not +1.
  
  I'm learning it...
 
 If you prefer, here is a more general guideline: record output values as
 they are.
 It's a pain if they can be tricked randomly at each step of the
 processing: e.g. yade.plot and vtkRecorder would show opposite signs for
 the same thing.

I completely agree with you Bruno.

Just wanted to add, one can easily modify values in paraview using Filter-
Calculator, e.g. multiply stress by -1.

Klaus___
Mailing list: https://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] Brainstorming for workshop

[Klaus Thoeni]

Hi guys,

I created a wiki page where you can add your thoughts about what we should 
discuss and implement during the Coding Fest which is part of day 3 of the 
1st Yade Workshop.

Please feel free to add things you would like to discuss here:

https://yade-dem.org/wiki/Brainstorming

A discussion over the mailing list is welcome too.

See you in Grenoble,
Klaus

___
Mailing list: https://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] [Branch ~yade-pkg/yade/git-trunk] Rev 4013: improve output and remove first iteration in calculation velocity estimation

[Klaus Thoeni]

Hi Alex,

you are right. There should not be a +1. I changed it already.

Klaus

On Wednesday 11 June 2014 13:14:07 Eulitz, Alexander wrote:
 Hi Klaus,
 I just checked your script. In my eyes the revision does the first 
iteration
 wasn't considered in calculation of velocity before Rev4013. O.run(1)
 O.wait()
 O.run(2000)
 print O.iter
 Gives 2001 as output.
 Using your revised script:
 O.run(1)
 O.wait()
 O.run(2000+1)
 print O.iter
 Gives 2002 as output.
 
 Nevertheless the other part of the commit concerning improved output is 
nice
 to have.
 
 Alex
 
 
 
 Von: Yade-dev im Auftrag von nore...@launchpad.net
 Gesendet: Di 10.06.2014 10:15
 An: Yade developers
 Betreff: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 4013: improve
 output and remove first iteration in calculation velocity estimation
 
 
 
 
 revno: 4013
 committer: Klaus Thoeni klaus.tho...@gmail.com
 timestamp: Tue 2014-06-10 13:36:47 +1000
 message:
   improve output and remove first iteration in calculation velocity
 estimation modified:
   examples/test/performance/checkPerf.py
 
 
 --
 lp:yade
 https://code.launchpad.net/~yade-pkg/yade/git-trunk
 
 Your team Yade developers is subscribed to branch lp:yade.
 To unsubscribe from this branch go to
 https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription

___
Mailing list: https://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] Constitutive laws

[Klaus Thoeni]

Hi Jérôme,

nice idea. However, not sure if this is the way to go. I don't think we
need a new attribute. Why not just adding a little table in each LawFunctor
description in the doc? We can still grep for the table and build up the
current wiki table.

BTW, if we don't find a solution here we can discuss and implement it at
the workshop. I can put it on the list ;-)

Cheers
Klaus


On Mon, May 26, 2014 at 10:27 PM, Jérôme Duriez 
jerome.dur...@3sr-grenoble.fr wrote:

  So, I have a proposal, introducing two new attributes :

 One would be LawFunctor.status in ... LawFunctor. Here is a possible
 c++ implementation in LawFunctor.hpp
 ((bool, status,0,,boolean expressing the status of the considered
 LawFunctor. The use is safe if status=True (law validated, support might
 come from mailing list..), whereas for status=False, no warranty exists
 that the law is validated and/or maintained/used by anyone else. A warning,
 see InteractionLoop.Law2warning, is displayed in this case.))
 The idea is to put in InteractionLoop something like (please apologize
 possible syntax mistakes) :
 if (LawFunctor-status==False)
 cout/cerr  You're using a non validated constitutive law ! Please
 consider using another LawFunctor with status = True (e.g.
 Law2_ScGeom_FrictPhys_CundallStrack), unless you are 100% autonom;

 This warning would display at each iteration, so that users
 necessarily see it. To not bother 100% autonom people, here comes the
 second attribute : InteractionLoop.Law2warning ! Wich has such a c++
 implementation, in InteractionLoop.hpp, for example :
 ((bool,Law2warning,1,,Autonom people that use constitutive laws with
 status=0 may set this attribute to False to get rid of related warnings.))


 In this framework :
 - For what concerns the devs, we get rid of the wiki page. Devs would
 only have to take care of defining correctly the value of their status,
 rather than painting in green or red in the wiki page. All other
 informations such as description, publications, example scripts, should be
 already in the sphinx doc (If not, such infos would probably be neither on
 the wiki). There would be no risk of deprecation of the wiki page compared
 to c++ code. If new laws are commited, it is easy to check which status
 value is defined in the commit.
 - For users, the warning of
 https://www.yade-dem.org/doc/user.html#law2-functor-s would be rephrased,
 to put attention of users on LawFunctor.status, rather than pointing
 towards the wiki page. Users that did not read nor this warning, nor the
 doc of their Law and pick unfortunately a red Law2 would be bored by the
 warning, and quickly would use e.g. Law2_ScGeom_FrictPhys_CundallStrack,
 before asking useless questions.

 Among the drawbacks, I confess that there is no synthetic presentation
 with such design, compared with the coloured table of the wiki. But maybe
 this could be generated automaticcaly, grepping for status,1 in the code
 ? And I consider in any case, that an up-to-date not so synthetic
 information is better that a deprecated synthetic one...

 Tell me what you think !

 Jérôme




 Le 26/05/2014 11:06, Bruno Chareyre a écrit :

 2/ is very unlikely to happen. More realistic is to translate the table in
 *.rst. I was secretely hopping that you would be volunteer for that. :)
 Besides, I'm open to suggestions on how to improve.
 B


 On 26/05/14 10:19, Jérôme Duriez wrote:

 Hi,

 Many thanks to the guy who in fact updated
 Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity for me ! I had only
 to add the name of the example script... So, I edited my one (or even two)
 lines in the wiki page.

 I do not know how much you were serious about your 2/ proposition, Bruno
 (this could be a project for a computer science student ?), but let us hope
 that this day will come. Otherwise I have no doubt that the destiny of this
 page is to be most of the time deprecated. We just had another example with
 Law2_ScGeom_ViscElPhys_Basic, with guys that are nevertheless quite
 involved in Yade... (there is an euphemism there)

 Jérôme


 Le 23/05/2014 13:21, Bruno Chareyre a écrit :

 Hi Jerome,
 Thank you for suggestions. First, I'm glad you recognize that the functors
 table is less puzzling than the inheritance diagram (or let's say, they
 have different purpose). I saw many situations where users would come with
 a very specific question, then we realize that they picked a wrong contact
 law (bugged and/or unmaintained, L3 to name one). Frustrating for users,
 wasted time for everyone. It was the reason to write this table.
 Another possible solution would be to reduce the total number of functors.
 For instance eliminate from the source code every law which results at
 least partly from code duplication, and/or has no example script, and/or is
 not documented, and/or has no known maintainer.

 Now, your message is twofold: 1/ where this content should be, and 2/ what
 this content should be.
 1/ If someone could 

Re: [Yade-dev] parallel collider - testing needed

[Klaus Thoeni]

Hi guys,

just to let you know. I updated the results on the wiki [1]. Still performance 
test but with more iterations and up to 1 million particles. 

Cheers,
Klaus

[1] https://yade-dem.org/wiki/Performance_Test#Test_2

___
Mailing list: https://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] parallel collider - testing needed

[Klaus Thoeni]

Hi Bruno,

just to clarify, Test 2 is done by increasing the number of iterations (1x, 3x 
and 12x the number of iterations specified in checkPerf.py). This means the 
number of interactions should increase as well and, hence, particle velocities 
should decrease because of more interactions.

I added a table with the collider scaling factor for 1 million particles and 
iter x 12.

Note your T(j8)=T(j1)/5.8 is actually T(j8)=T(j1)/4.8. Where did you get the 
number from? You must look into the uploaded files in order to get this numbers 
;-)

Cheers
Klaus

On Wednesday 09 April 2014 14:58:19 Bruno Chareyre wrote:
 Thanks!
 If I understand correctly, particles velocities are decreasing with
 iterations. So, more iterations means less weight for the collider
 overall (hence less effect of parallelizing it).
 From you results with 1million, I see for the collider T(j8)=T(j1)/5.8.
 Could you tell if the collider time alone still decreases with j8 for
 1million of particles?
 
 Bruno
 
 On 09/04/14 14:32, Klaus Thoeni wrote:
  Hi guys,
  
  just to let you know. I updated the results on the wiki [1]. Still
  performance test but with more iterations and up to 1 million particles.
  
  Cheers,
  Klaus
  
  [1] https://yade-dem.org/wiki/Performance_Test#Test_2
 
 --
 ___
 Bruno Chareyre
 Associate Professor
 ENSE³ - Grenoble INP
 Lab. 3SR
 BP 53
 38041 Grenoble cedex 9
 Tél : +33 4 56 52 86 21
 Fax : +33 4 76 82 70 43
 
 
 
 ___
 Mailing list: https://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] parallel collider - testing needed

[Klaus Thoeni]

Hi guys,

I run some dynamic tests with my mesh too (some times ago, but I forgot to 
check). Implementation is fine and speed up is only about 6-8%. However, the 
simulation has just about 30 particles.

I even have more results for the performance check (with 1 Mio particles) 
which I will put on the wiki, at some stage (if I find time to analyse the 
results :-)). But something I can tell you, the maximum scaling for 1 Mio 
particles I get is about 3-4.

Cheers,
Klaus


On Monday 31 March 2014 10:29:03 Bruno Chareyre wrote:
  I have tested this version of collider and have got a speedup for
  about 5..10% with number of cores 2..6. But it was quasi-static
  simulations, so the contact list is updating not so often.
 
 Thanks Anton for feedback. Testing in quasistatic cases is indeed not
 very interesting.
 Or, in that case, it needs to report the collider's timing, not the wall
 clock time of yade as a whole.
 
  I think, we can include this code into the master branch in git.
  Let`s check the code more precisely and merge it.
 
 For me the code is in its final version and ready to merge if nobody
 find bugs (at least you could run your QS simulation without crash - the
 good part!).
 But if someone wants to review it is never bad.
 
 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

[Yade-dev] [Bug 1290194] Re: O.reset() does not free memory

[Klaus Thoeni]

Hi Anton,

you are right, changing the script as follows has the same effect:

# -*- coding: utf-8
import subprocess

numberTests = 10

for z in range(numberTests):
#O.reset()

bodies= 
O.bodies.append(pack.regularHexa(pack.inSphere((Vector3(0.0,0.0,0.0)),0.5),radius=0.01,gap=0))
print number of bodies:, len(O.bodies)

for b in bodies:
O.bodies.erase(b)

cmd = ps -o vsz -p `pgrep yade` | grep -v VSZ
process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True)
meminfo = process.communicate()[0].strip()
print Yade memory usage: , meminfo, kB

cmd = egrep 'MemFree' /proc/meminfo
process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True)
meminfo = process.communicate()[0]
print meminfo

sys.exit(0)

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

Title:
  O.reset() does not free memory

Status in Yet Another Dynamic Engine:
  New

Bug description:
  O.reset() does not free the memory, i.e. if you run a series of
  simulations in a loop the memory usage is accumulating. Here is a
  script which reproduces the issue (it should affect all versions):

  # -*- coding: utf-8
  import subprocess

  numberTests = 10

  for z in range(numberTests):

O.reset()


O.bodies.append(pack.regularHexa(pack.inSphere((Vector3(0.0,0.0,0.0)),0.5),radius=0.01,gap=0))
print number of bodies:, len(O.bodies)

cmd = ps -o vsz -p `pgrep yade` | grep -v VSZ
process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True)
meminfo = process.communicate()[0].strip()
print Yade memory usage: , meminfo, kB

cmd = egrep 'MemFree' /proc/meminfo
process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True)
meminfo = process.communicate()[0]
print meminfo

  sys.exit(0)

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

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

[Yade-dev] [Bug 1290194] [NEW] O.reset() does not free memory

[Klaus Thoeni]

Public bug reported:

O.reset() does not free the memory, i.e. if you run a series of
simulations in a loop the memory usage is accumulating. Here is a script
which reproduces the issue (it should affect all versions):

# -*- coding: utf-8
import subprocess

numberTests = 10

for z in range(numberTests):

O.reset()


O.bodies.append(pack.regularHexa(pack.inSphere((Vector3(0.0,0.0,0.0)),0.5),radius=0.01,gap=0))
print number of bodies:, len(O.bodies)

cmd = ps -o vsz -p `pgrep yade` | grep -v VSZ
process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True)
meminfo = process.communicate()[0].strip()
print Yade memory usage: , meminfo, kB

cmd = egrep 'MemFree' /proc/meminfo
process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True)
meminfo = process.communicate()[0]
print meminfo

sys.exit(0)

** Affects: yade
 Importance: Low
 Status: New

** Changed in: yade
   Importance: Undecided = Low

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

Title:
  O.reset() does not free memory

Status in Yet Another Dynamic Engine:
  New

Bug description:
  O.reset() does not free the memory, i.e. if you run a series of
  simulations in a loop the memory usage is accumulating. Here is a
  script which reproduces the issue (it should affect all versions):

  # -*- coding: utf-8
  import subprocess

  numberTests = 10

  for z in range(numberTests):

O.reset()


O.bodies.append(pack.regularHexa(pack.inSphere((Vector3(0.0,0.0,0.0)),0.5),radius=0.01,gap=0))
print number of bodies:, len(O.bodies)

cmd = ps -o vsz -p `pgrep yade` | grep -v VSZ
process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True)
meminfo = process.communicate()[0].strip()
print Yade memory usage: , meminfo, kB

cmd = egrep 'MemFree' /proc/meminfo
process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True)
meminfo = process.communicate()[0]
print meminfo

  sys.exit(0)

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1290194/+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] parallel collider - testing needed

[Klaus Thoeni]

  https://yade-dem.org/wiki/Performance_Test
 
 Wow! Speed x6 for 500k particules?!
 It was definitely worth trying with larger numbers, it changes the
 picture completely when the last points are included.
 
 Very nice page.
 Could you also give some absolute timings for completness? A convenient
 value could be the Cundall's number: Np*Nt/Tcpu
 With Np number of bodies, Nt number of iterations, Tcpu computation time.

I just updated the page:

https://yade-dem.org/wiki/Performance_Test


___
Mailing list: https://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] parallel collider - testing needed

[Klaus Thoeni]

Hi Bruno,

 2/ Hyperthreading is completely useless for heavy computing tasks,
 actually even bad, as your results suggest.

I did some tests by enabling and disabling hyperthreading some time ago. 
Conclusions: always disable hyperthreading, as you say it makes no sense for 
the kind of thinks we are doing. Maybe we should mention it somewhere on our 
web page. Any suggestions where?

 Benchmarking 8 threads via this technique is irrelevant for this reason.
 What I would really like to see is how the collider scales with 8
 non-virtual cores and more.
 I think they can do that in Freiberg and Newcastle (in Grenoble as well,
 in fact, I just didn't find the time).

I did some testing with --performance on our grid on 3 different nodes and with 
various numbers of cores. I am rerunning the test with 50 particles at the 
moment and will try to post a summary of all the results here or on the wiki 
later.

In the mean time some results of our slow AMD Opteron Processor 6282 SE:


yade -j4
5037  spheres, velocity= 94.8073682494 +- 3.55139591623 %
25103  spheres, velocity= 27.7389795715 +- 8.63375047506 %
50250  spheres, velocity= 16.0519684282 +- 5.60688183622 %
100467  spheres, velocity= 6.67235752786 +- 8.84758076674 %
200813  spheres, velocity= 2.66158958354 +- 7.70653861779 %

yade-pc -j4
5037  spheres, velocity= 78.264605326 +- 4.06741633055 %
25103  spheres, velocity= 26.0879865929 +- 2.61754448363 %
50250  spheres, velocity= 15.7245773611 +- 2.24679654566 %
100467  spheres, velocity= 7.64762330727 +- 2.59000324319 %
200813  spheres, velocity= 3.64194000319 +- 1.80798282427 %


yade -j8
5037  spheres, velocity= 138.024763661 +- 14.7299332104 %
25103  spheres, velocity= 35.7526851013 +- 4.24184671794 %
50250  spheres, velocity= 22.0071042904 +- 8.36195041437 %
100467  spheres, velocity= 11.1704832541 +- 11.725537817 %
200813  spheres, velocity= 3.54394003786 +- 5.48119712335 %

yade-pc -j8
5037  spheres, velocity= 133.311680084 +- 1.88168292497 %
25103  spheres, velocity= 34.3688804144 +- 7.43189318211 %
50250  spheres, velocity= 21.3620031259 +- 3.8532356508 %
100467  spheres, velocity= 11.3218727607 +- 3.77428592406 %
200813  spheres, velocity= 6.16209240352 +- 6.24680400297 %


yade -j16
5037  spheres, velocity= 71.8232644642 +- 41.7059425388 %
25103  spheres, velocity= 24.6342039841 +- 3.98148164778 %
50250  spheres, velocity= 16.1247061321 +- 4.73981941981 %
100467  spheres, velocity= 9.23509237236 +- 2.14822969955 %
200813  spheres, velocity= 2.91721702399 +- 3.88145803663 %

yade-pc -j16
5037  spheres, velocity= 129.908588625 +- 15.6874714595 %
25103  spheres, velocity= 33.526601121 +- 13.7594343427 %
50250  spheres, velocity= 17.7898704143 +- 7.7469432427 %
100467  spheres, velocity= 11.3877154372 +- 1.74832633634 %
200813  spheres, velocity= 6.95545612967 +- 2.35988760251 %


yade -j32
5037  spheres, velocity= 59.0283160736 +- 51.2569740982 %
25103  spheres, velocity= 18.7622567759 +- 6.54660223453 %
50250  spheres, velocity= 12.3588048445 +- 8.49295845839 %
100467  spheres, velocity= 7.6569548227 +- 6.71719242602 %
200813  spheres, velocity= 2.47982732752 +- 10.4129796959 %

yade-pc -j32
5037  spheres, velocity= 88.990043 +- 15.7295668423 %
25103  spheres, velocity= 18.1857423869 +- 1.17387945175 %
50250  spheres, velocity= 12.6321967406 +- 5.31792620843 %
100467  spheres, velocity= 8.98513348696 +- 4.48699885744 %
200813  spheres, velocity= 6.12495571697 +- 1.48933071382 %

Summary for 20 particles:
- -j4: scale =1.37
- -j8: scale =1.74
- -j16: scale =2.38
- -j32: scale =2.47

These numbers might look differently on our Intel nodes, I still have to check.

 What I need also before pushing to trunk is more testing with real
 scripts, not just --performance.
 I only covered a narrow range of situations with my own scripts, I would
 like to be sure that it will not break in other cases.

Maybe ask mister Fu, he really seems to be keen on increasing his computing 
scale ;-) 

Cheers
Klaus


___
Mailing list: https://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] clump discretization/integrateInertia

[Klaus Thoeni]

Hi guys,

is there a reason why we have two parameters here? Wouldn't one be enough? 
E.i. we just use discretization and if discretization==0 than the properties 
are not updated. What do you thing?

Klaus

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

[Yade-dev] [yade-dev] clump discretization/integrateInertia

[Klaus Thoeni]

Hi guys,

is there a reason why we have two parameters here? Wouldn't one be enough? 
E.i. we just use discretization and if discretization==0 than the properties 
are not updated. What do you thing?

Klaus

___
Mailing list: https://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] Why Ip2 functors must be symmetric?

[Klaus Thoeni]

Hi Bruno

 Why would you define a body with FrictPhys if is supposed to have a
 cohesive behavior with others?
 You can just give CohFrictPhys to everyone.

That's what I did so far but it is not always possible.

  Any idea about the goReverse? Can it be removed?
 
 Maybe not removed. I think it is necessary, precisely because we can
 have non-symmetric functors. If you swap ids in Ip2 you may break the
 work of the Ig2.
 The go reverse is here for this reason (handling non-symmetric cases
 without forcing a specific ordering of id1/id2 and without the need to
 define to functors).

The comment in line 98  in IntersectionLoop.cpp says:

// arguments for the geom functor are in the reverse order (dispatcher would 
normally call goReverse).
// we don't remember the fact that is reverse, so we swap bodies within the 
interaction
// and can call go in all cases

In fact, it seams goReverse is never called because bodies are swapped before. 
So maybe we can get rid of it???

Klaus



___
Mailing list: https://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] Why Ip2 functors must be symmetric?

[Klaus Thoeni]

Hi Bruno

 Swapping for the Ig2 and swapping for the Ip2 are two different things.
 This comment at L98 applies for geometry only.
 
 Swapping for the Ip2 after computing the geometry would break everything
 (contact normal should be inverted, etc.)
 It is also what L125  suggests: assert(!swap); it is clear that the
 Ip2 must NOT swap.

OK, I can see the point here. 

 The only way to go without swapping is to call goReverse, as far as I
 understand.

Ok, so we have two options:
a) swap for Ig2 (as it is now) and therefore get rid of goReverse in Ig2, and 
call go/goReverse for Ip2
b) get rid of swap for Ig2 and call go/goReverse in both cases (maybe more 
consistent?)

What do you think? 

Something I couldn't find out, do we need to do something like
if(swap) goReverse() else go() or is this handled automatically? 

 Removing goReverse was maybe an objective of Vaclav, then the present
 situation would be half way to it. Not sure.

That's probably the case. Looking into WooDem reveals that there is no 
goReverse. BTW, it there any chance to get Vaclav's opinion on this topic?

Thanks a lot
Klaus


___
Mailing list: https://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] Why Ip2 functors must be symmetric?

[Klaus Thoeni]

Hi Bruno

 I think non-symmetric functors are rarely necessary since most
 combinations can be dealt with via inheritance (e.g. Frict vs CohFrict
 is interpreted as Frict vs. Frict since CohFrict inherits from Frict).

Exactly, but what if you want it to behave it like a cohesive contact. This is 
not possible at the current stage. So non-symmetric Ip2 functors would make 
sense here, right? And looking at the variety of material we have (some are 
not inherited from FrictMat) I can see some more benefits.

 However, I am like you, I don't see the reason why it is asserted
 symmetric. I suggest to try your idea after removing this constraint and
 see if it works as accepted.

Ok, I will try.

Any idea about the goReverse? Can it be removed?

Klaus



___
Mailing list: https://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] [Branch ~yade-pkg/yade/git-trunk] Rev 3804: new simple contact law with normal viscose damping which allows to specify kn and ks/kn in Ip2

[Klaus Thoeni]

Hi Bruno

  Sorry for late reply, but here my thoughts. I think a separation at
  material level would be better, i.e. FrictMat inherits ViscElastMat which
  inherits something like  ViscElCapillarMat. I think it would make sense
  because not all visco-elastic materials have capillar forces. What do you
  think?
 
 I think this is also what Anton had in mind. Base types should be free
 of capillary things, which are very specific.

So you agree that the parameters should already be separated at material 
level, correct?

  In the case of CapillaryPhys none of the parameters is stored in FrictMat.
 
 And it is good that way, isn't it? FrictMat has the contact parameters,
 CapillaryPhys inherits them and add the capillary parameters.
 It should be the same for ViscEl, as you suggest.
 
  There seams to be a bit of inconsistency. Same with kn and kt. Should the
  material have these parameters or the Ip2 functor? IMO, stiffness is
  related to a specific contact and should therefore be in the Ip2.
 
 I don't get your point here. Ip2's are not supposed to have parameters
 at all, they convert material data to interaction data (e.g. they
 convert Material::Young to IPhys::kn).
 I know many Ip2 still have a few physical parameters but it is only lazy
 implementation, we should avoid that. Ip2_Frict and Ip2_CohFrict, for
 instance have no parameters at all.

The point is that MatchMaker only work for Ip2 functors and to me they really 
make sense for some specific cases (especially if you have many different 
materials). And as I said before, contact stiffness is a property of the 
contact and not the material. We generally calculate it as a harmonic average 
of the Youngs' modulus of the two materials in contact but in some cases you 
might want to define it explicitly. In this cases I think it should be defined 
in the Ip2 functor, or not?

Klaus


___
Mailing list: https://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] [Branch ~yade-pkg/yade/git-trunk] Rev 3804: new simple contact law with normal viscose damping which allows to specify kn and ks/kn in Ip2

[Klaus Thoeni]

Hi Anton,

are you planning to split the parameters at material level (see discussion 
with Bruno)?

Thanks
Klaus

On Tuesday 28 January 2014 14:10:53 Anton Gladky wrote:
  On 28/01/14 01:14, Klaus Thoeni wrote:
 Last but not least I think we could probably split visco-elastic and
 capillary parameters.
 That is true. I actually moved an implementations into
 ViscoelasticCapillarPM [1], but parameters are still in the parent class.
 Any suggestions how to improve it are very welcome.
 
 [1]
 https://github.com/yade/trunk/blob/master/pkg/dem/ViscoelasticCapillarPM.cp
 p
 
 Anton
 
 ___
 Mailing list: https://launchpad.net/~yade-dev
 Post to : yade-dev@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~yade-dev
 More help   : https://help.launchpad.net/ListHelp

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

[Yade-dev] Why Ip2 functors must be symmetric?

[Klaus Thoeni]

Hi guys

is there I reason why we only have symmetric Ip2 functors? I recently committed 
a contact law with non-symmetric Ip2 functor 
(Ip2_FrictMat_FrictViscoMat_FrictViscoPhys) but at the moment it is not working 
as expected. It turns out that the reason is in InteractionLoop.cpp line 122 
and following (and maybe somewhere else too):

// IPhysDispatcher
if(!I-functorCache.phys){

I-functorCache.phys=physDispatcher-getFunctor2D(b1-material,b2-material,swap);
assert(!swap); // InteractionPhysicsEngineUnits are 
symmetric
}

It assumes swap is always false. Is there a reason why we are not doing it the 
same way as for the Ig2 functors (see lines 90-104)? Well, if there is no 
reason I would like to change it to something like this:

bool swap=false;
// IPhysDispatcher
if(!I-functorCache.phys){

I-functorCache.phys=physDispatcher-getFunctor2D(b1-material,b2-material,swap);
}
if(swap){I-swapOrder();}
// body pointers must be updated, in case we swapped
const shared_ptrBody bb1=swap?b2:b1;
const shared_ptrBody bb2=swap?b1:b2;

What do you think? Would this change work or am I missing something?

Further, I can see that in the Ig2 functors we have a goReverse. Is this ever 
called? A quick grep did not show any calls but only definitions. Not sure, but 
is this something we can get rid of?

Cheers,
Klaus

___
Mailing list: https://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] [Branch ~yade-pkg/yade/git-trunk] Rev 3804: new simple contact law with normal viscose damping which allows to specify kn and ks/kn in Ip2

[Klaus Thoeni]

Sorry for late reply, but here my thoughts. I think a separation at material 
level would be better, i.e. FrictMat inherits ViscElastMat which inherits 
something like  ViscElCapillarMat. I think it would make sense because not all 
visco-elastic materials have capillar forces. What do you think?

In the case of CapillaryPhys none of the parameters is stored in FrictMat. 
There seams to be a bit of inconsistency. Same with kn and kt. Should the 
material have these parameters or the Ip2 functor? IMO, stiffness is related to 
a specific contact and should therefore be in the Ip2. 

I think we need to make a decision. I think we should keep it one way and not 
mix it.  

Klaus

On Tuesday 28 January 2014 15:25:04 Bruno Chareyre wrote:
 On 28/01/14 14:10, Anton Gladky wrote:
  That is true. I actually moved an implementations into
  ViscoelasticCapillarPM [1], but parameters are still in the parent
  class. Any suggestions how to improve it are very welcome.
 
 If I don't miss something, it could be just like CapillaryPhys, which
 inherits from FrictPhys.
 The cappilar version of the contact law would read
 
 Law2_ScGeom_ViscElPhys_Capillar::go(...) {
 Law2_ScGeom_ViscElPhys_Basic::go(...);
// add capillary forces here
...
 }
 
 If not possible (*), you can extract code blocks from
 Law2_ScGeom_ViscElPhys_Basic::go and put them in separate functions that
 can be called in child classes.
 
 Law2_ScGeom_ViscElPhys_Capillar::go(...) {
 Law2_ScGeom_ViscElPhys_Basic::computeForceTorque(...,f);
// add capillary forces here
...
 }
 
 (*) one problem I anticipate is that Law2_ScGeom_ViscElPhys_Basic::go()
 could erase an interaction that is still alive wrt the capillary model.
 Hence the split of go() in different functions.
 
 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

[Yade-dev] [Bug 1250928] Re: Compilation from source probably miss some documentation

[Klaus Thoeni]

Hi Bruno,

the only library of you list I have installed at the moment is:
libsuitesparse-dev  1:3.4.0-2ubuntu3

Not sure why openblas is giving trouples on my machines. Just to verify, my 
Kubuntu version is 12.04.3 LTS. Are you using the same? Here the python verison 
installed on my machines:
python  2.7.3-0ubuntu2.2
python-numpy1:1.6.1-6ubuntu1

Well, if I am the nly one having this problem we can close the bug. I
don't need this feature at the moment and I am alread looking forward to
the 14.04 LTS

Cheers
Klaus

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

Title:
  Compilation from source probably miss some documentation

Status in Yet Another Dynamic Engine:
  Invalid

Bug description:
  
  It seems the instructions for installing prerequisites [1] will fail on 
ubuntu 12.04 if yade-users ppa is not enabled first.
  Trying to compile anyway leads to a few cmake warnings but it will let one 
build. Then boot failure because of missing lib (didn't do the build myself, 
I've seen the result on a colleagues computer).

  The bug is that the ppa is not mentionned anywhere on the installation page.
  If anyone confirm I can update the doc, though I'm not sure if this situation 
is for 12.04 only, or if the ppa should be considered mandatory for all 
platforms.

  [1] https://yade-dem.org/doc/installation.html#prerequisites

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

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

[Yade-dev] [Bug 1250928] Re: Compilation from source probably miss some documentation

[Klaus Thoeni]

@Bruno
Well I copy pasted the sudo apt-get install from the instructions. But this 
did't work in my case. I got the cmake error I showed above. Nervertheless, 
un-installing libopenblas-base solved the problem for me. That's whay it's not 
installed ;-)

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

Title:
  Compilation from source probably miss some documentation

Status in Yet Another Dynamic Engine:
  Invalid

Bug description:
  
  It seems the instructions for installing prerequisites [1] will fail on 
ubuntu 12.04 if yade-users ppa is not enabled first.
  Trying to compile anyway leads to a few cmake warnings but it will let one 
build. Then boot failure because of missing lib (didn't do the build myself, 
I've seen the result on a colleagues computer).

  The bug is that the ppa is not mentionned anywhere on the installation page.
  If anyone confirm I can update the doc, though I'm not sure if this situation 
is for 12.04 only, or if the ppa should be considered mandatory for all 
platforms.

  [1] https://yade-dem.org/doc/installation.html#prerequisites

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1250928/+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] [Bug 1250928] Re: Compilation from source probably miss some documentation

[Klaus Thoeni]

Yes, yade-users ppa is available. However, I have not installed metis. But 
this shouldn't have an influence on this specific problem with lapack, or I am 
wrong? I can't see any other package on the ppa which might be relevant.

Anyway, I will see if I can reproduce the problem on my desktop.

Klaus

On Tuesday 19 November 2013 11:00:13 Bruno Chareyre wrote:
 @Klaus
 Is it with yade-users ppa available?
 In that case it should work like a charm in my experience.
 
 Bruno
 
 --
 You received this bug notification because you are a member of Yade
 developers, which is subscribed to Yade.
 https://bugs.launchpad.net/bugs/1250928
 
 Title:
   Compilation from source probably miss some documentation
 
 Status in Yet Another Dynamic Engine:
   New
 
 Bug description:
 
   It seems the instructions for installing prerequisites [1] will fail on
 ubuntu 12.04 if yade-users ppa is not enabled first. Trying to compile
 anyway leads to a few cmake warnings but it will let one build. Then boot
 failure because of missing lib (didn't do the build myself, I've seen the
 result on a colleagues computer).
 
   The bug is that the ppa is not mentionned anywhere on the installation
 page. If anyone confirm I can update the doc, though I'm not sure if this
 situation is for 12.04 only, or if the ppa should be considered mandatory
 for all platforms.
 
   [1] https://yade-dem.org/doc/installation.html#prerequisites
 
 To manage notifications about this bug go to:
 https://bugs.launchpad.net/yade/+bug/1250928/+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
-- 
Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling
Civil, Surveying and Environmental Engineering - Engineering Building EA
The University of Newcastle, Callaghan, NSW 2308, Australia
web: http://www.newcastle.edu.au/research-centre/cgmm
phone: +61 (0)2 4921 5735

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

Title:
  Compilation from source probably miss some documentation

Status in Yet Another Dynamic Engine:
  New

Bug description:
  
  It seems the instructions for installing prerequisites [1] will fail on 
ubuntu 12.04 if yade-users ppa is not enabled first.
  Trying to compile anyway leads to a few cmake warnings but it will let one 
build. Then boot failure because of missing lib (didn't do the build myself, 
I've seen the result on a colleagues computer).

  The bug is that the ppa is not mentionned anywhere on the installation page.
  If anyone confirm I can update the doc, though I'm not sure if this situation 
is for 12.04 only, or if the ppa should be considered mandatory for all 
platforms.

  [1] https://yade-dem.org/doc/installation.html#prerequisites

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1250928/+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] [Bug 1250928] [NEW] Compilation from source probably miss some documentation

[Klaus Thoeni]

Hi Bruno

it probably depends on which options you are using when compiling. I am not 
using the ppa and everything is working for me on 12.04.

Nevertheless, you are right the ppa should probably be mentioned in the 
installation section. But I don't think it is mandatory.

Cheers
Klaus

On Wednesday 13 November 2013 16:23:49 Bruno Chareyre wrote:
 Public bug reported:
 
 
 It seems the instructions for installing prerequisites [1] will fail on
 ubuntu 12.04 if yade-users ppa is not enabled first. Trying to compile
 anyway leads to a few cmake warnings but it will let one build. Then boot
 failure because of missing lib (didn't do the build myself, I've seen the
 result on a colleagues computer).
 
 The bug is that the ppa is not mentionned anywhere on the installation page.
 If anyone confirm I can update the doc, though I'm not sure if this
 situation is for 12.04 only, or if the ppa should be considered mandatory
 for all platforms.
 
 [1] https://yade-dem.org/doc/installation.html#prerequisites
 
 ** 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/1250928
 
 Title:
   Compilation from source probably miss some documentation
 
 Status in Yet Another Dynamic Engine:
   New
 
 Bug description:
 
   It seems the instructions for installing prerequisites [1] will fail on
 ubuntu 12.04 if yade-users ppa is not enabled first. Trying to compile
 anyway leads to a few cmake warnings but it will let one build. Then boot
 failure because of missing lib (didn't do the build myself, I've seen the
 result on a colleagues computer).
 
   The bug is that the ppa is not mentionned anywhere on the installation
 page. If anyone confirm I can update the doc, though I'm not sure if this
 situation is for 12.04 only, or if the ppa should be considered mandatory
 for all platforms.
 
   [1] https://yade-dem.org/doc/installation.html#prerequisites
 
 To manage notifications about this bug go to:
 https://bugs.launchpad.net/yade/+bug/1250928/+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
-- 
Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling
Civil, Surveying and Environmental Engineering - Engineering Building EA
The University of Newcastle, Callaghan, NSW 2308, Australia
web: http://www.newcastle.edu.au/research-centre/cgmm
phone: +61 (0)2 4921 5735


___
Mailing list: https://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] gmplib and other libraries

[Klaus Thoeni]

Hi guys

it's deleted from the install  list. It will indeed be installed with libcgal-
dev. So the question is if we should get rid of the FindGMP.cmake as well 
since it depends on libcgal.

Cheers
Klaus

On Tuesday 29 October 2013 15:54:35 Anton Gladky wrote:
 True, Bruno.
 libcgal-dev depends on libgmp-dev [1]. So, if you install libcgal-dev,
 libgmp-dev will be installed automatically. So I do not see any reasons
 to install  libgmp-dev explicitly if we do not use it directly in the code.
 
 [1] http://packages.debian.org/sid/libcgal-dev
 
 Anton
 
 2013/10/29 Bruno Chareyre bruno.chare...@hmg.inpg.fr:
  gmp lib was a dependency of cgal some time ago, and it probably still is.
  The link may be implicit so you don't see the problem. Did you try to
  uninstall the lib from your system and start yade?
 
 ___
 Mailing list: https://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] gmplib and other libraries

[Klaus Thoeni]

  do you know where gmplib is used in yade? A grep for gmp doesn't give any
  results and it seams that yade is running without the library even if
  cmake is complaining/warning. Any idea? If it is not used we should get
  rid of it in the install requirements.
 
 Sure, go ahead and remove it. It was probably used some time ago, but no
 more in the current code.

Ok, I will.

  What do you think about extending the list of external libraries with our
  optionals like CGAL, OpenBLAS etc. It would be nice to have a complete
  list.
 I am not sure, what you mean. cgal and openblas are in fact optional.
 If they are not in the system, it will disable some corresponding features,
 but will not break the compilation. Or what you meant?

I meant the list on yade's installation web page under Prerequisites in 
addition to the sudo apt-get install list.

Cheers
Klaus


___
Mailing list: https://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] gmplib and other libraries

[Klaus Thoeni]

Hi guys,

do you know where gmplib is used in yade? A grep for gmp doesn't give any 
results and it seams that yade is running without the library even if cmake is 
complaining/warning. Any idea? If it is not used we should get rid of it in 
the install requirements.

What do you think about extending the list of external libraries with our 
optionals like CGAL, OpenBLAS etc. It would be nice to have a complete list.

Cheers
Klaus

___
Mailing list: https://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] [Branch ~yade-pkg/yade/git-trunk] Rev 3713: Remove pkg/dem/DomainLimiter.*

[Klaus Thoeni]

Hi guys

the DomainLimiter is very useful as well. It removes particles which exit a 
defined region from the simulation. I am using it. What is the problem with it?

Klaus

On Tuesday 15 October 2013 12:37:18 Bruno Chareyre wrote:
 Hi Anton,
 I don't know what DomainLimiter is (or was). In the same file however
 there is LawTester which is used in a script and is a very interesting
 piece of work (from Vaçlav).
 I think we should keep that one.
 
 Bruno
 
 On 14/10/13 23:48, nore...@launchpad.net wrote:
  
  revno: 3713
  committer: Anton Gladky gladky.an...@gmail.com
  timestamp: Mon 2013-10-14 22:51:11 +0200
  
  message:
Remove pkg/dem/DomainLimiter.*

It seems, the code is unmaintained and requires too much
RAM for compilation.

Feel free to recover it, if it is necessary.
  
  removed:
pkg/dem/DomainLimiter.cpp
pkg/dem/DomainLimiter.hpp
  
  --
  lp:yade
  https://code.launchpad.net/~yade-pkg/yade/git-trunk
  
  Your team Yade developers is subscribed to branch lp:yade.
  To unsubscribe from this branch go to
  https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription
  
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
 
 --
 ___
 Bruno Chareyre
 Associate Professor
 ENSE³ - Grenoble INP
 Lab. 3SR
 BP 53
 38041 Grenoble cedex 9
 Tél : +33 4 56 52 86 21
 Fax : +33 4 76 82 70 43
 

-- 
Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling
Civil, Surveying and Environmental Engineering - Engineering Building EA
The University of Newcastle, Callaghan, NSW 2308, Australia
web: http://www.newcastle.edu.au/research-centre/cgmm
phone: +61 (0)2 4921 5735


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

Re: [Yade-dev] [Bug 1229783] Re: packs.py example hangs due to appendClumped command

[Klaus Thoeni]

Hi guys

loading a clump takes ages indeed (I have clumps with 100 particles) but not 
sure if this is a bug. Maybe there is something wrong with the loops?

Klaus

On Thursday 26 September 2013 08:55:19 Bruno Chareyre wrote:
 A question for Christian:
 If I have a clump with, let's say, 20 particles. Will there be 20
 computations of inertia (each time we add a new member) or only one?
 We should find a default behavior that do not take ages to compute
 anyway, be it at the price of big approximations.
 
 Bruno
 
 --
 You received this bug notification because you are a member of Yade
 developers, which is subscribed to Yade.
 https://bugs.launchpad.net/bugs/1229783
 
 Title:
   packs.py example hangs due to appendClumped command
 
 Status in Yet Another Dynamic Engine:
   Invalid
 
 Bug description:
   The examples/packs/packs.py hangs in line 46 [1] because
   of appendClumped command.
 
   Changing it to append fixes the problem. So, it seems,
   appendClump has infinite loop  somewhere.
 
   [1]
   https://github.com/yade/trunk/blob/master/examples/packs/packs.py#L46
 
 To manage notifications about this bug go to:
 https://bugs.launchpad.net/yade/+bug/1229783/+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

-- 
Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling
Civil, Surveying and Environmental Engineering - Engineering Building EA
The University of Newcastle, Callaghan, NSW 2308, Australia
web: http://www.newcastle.edu.au/research-centre/cgmm
phone: +61 (0)2 4921 5735


___
Mailing list: https://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] Logging and debugging

[Klaus Thoeni]

Hi Anton,

I put a std::cerr in the first line of Newtonintegrator::action() in 
Newtonintegrator.cpp. Any script with NewtonIntegrator should call this 
method. Or am I wrong? 

Klaus

On Wednesday 28 August 2013 07:43:48 Anton Gladky wrote:
 Could you, please, send a minimal script to localize the problem?
 
 Anton
 
 2013/8/27 Klaus Thoeni klaus.tho...@gmail.com:
  Hi Anton
  
  On Thursday 22 August 2013 08:33:58 Anton Gladky wrote:
  2013/8/22 Klaus Thoeni klaus.tho...@gmail.com:
   So what can I use to see the log output? Is there an other way for
   doing
   it
   now? Or is this feature completely removed? If so all the LOGs in the
   code
   are for nothing now.
  
  LOG_WARN, LOG_ERROR, LOG_FATAL should work [1].
  
   I see. Do I have to set something else? I just tried to put some
   std::cerr
   output in the code and I compiled with debug but it is not appearing.
  
  When I debug the code, I am doing exactly the same. It should appear or
  this part of code is not executed.
  
  I thought so too but this seems not to be the case at least for me. It's
  working e.g. for classes like the contact law but if I put some outputs in
  methods of NewtonIntegrator or Shop which are definitely called it's not
  working. Even after recompiling debug from scratch. I have no idea what's
  going on here. Any idea?
  
   BTW, do you think it is possible that yade tells you that you are
   running
   it in debug mode? Maybe something like: Welcome to Yade
   2013-08-15.git-4ef35b0 (debug)?
  
  Need to think about that. Debug-mode is just adding so-called
  debug-symbols. It means, that during the crash you should get some more
  information about that. That is a normal practice for the software.See,
  how many packages are having -dbg
  suffix. Most of them are just those symbols.
  
  [1] https://github.com/yade/trunk/blob/master/lib/base/Logging.hpp#L22
  
  Anton
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp


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

Re: [Yade-dev] bool MatchMaker

[Klaus Thoeni]

Hi Bruno

On Wednesday 28 August 2013 12:07:40 Bruno Chareyre wrote:
 Hi Klaus,
 There are other problems in this line.
 * The parameter itself has to be declared as a matchMaker. For instance
 Ip2_FrictMat_FrictMat_MindlinPhys::en is a MatchMaker (or None, then
 default code is used). includeMoment is not a MatchMaker, so it will not
 work.
 
 * The code itself has to use the object as a MatchMaker, not as a
 builtin type, for instance in HertzMinlin.cpp:
 Real logE = log((*en)(mat1-id,mat2-id));
 instead of
 Real logE = log(en);

 So, it will clearly not work to pick a random attribute of an engine and
 make it a MatchMaker in a python script. It needs to be already
 anticipated by the c++ side.

I completely forgot about it but changing this should not be a problem. The 
definition just needs to be changed to:
(shared_ptrMatchMaker,includeMoment,,,bool to consider rolling resistance)

 * The last thing, is that MM are indeed only returning scalar values,
 but it should not be a problem to convert Real to bool.

I could use 0 and 1 instead of False and True in the python script:
includeMoment=MatchMaker(matches=((mat1,mat1,1), (mat1,mat2,0

In the code we can use something like this to convert the Real to a Boolean:

((*includeMoment)(mat1-id,mat2-id) != 0)

but this probably brakes the conventional way: 
includeMoment=True

What do you think?

 I see that we don't have a real example script for matchMakers. That is
 bad...

This script for example shows the use of MatchMaker:
examples/spheresFactory.py

 Bruno
 
 On 28/08/13 04:18, Klaus Thoeni wrote:
  Hi guys
  
  it seems that MatchMakers are working with Real only. I tried something
  like this:
  
  O.engines=[
  ...
  [Law2_ScGeom_MindlinPhys_Mindlin(includeMoment=MatchMaker(matches=((mat1,m
  at1,True), (mat1,mat2,False]
  ...
  ]
  
  which gives the following error:
  
  TypeError: No registered converter was able to produce a C++ rvalue of
  type
  bool from this Python object of type MatchMaker
  
  When looking into the code it is obvious because the whole class is
  defined for Real only. Is there a workaround for Booleans? If not, any
  idea how to implement it?
  
  Thanks
  Klaus
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
 
 --
 ___
 Bruno Chareyre
 Associate Professor
 ENSE³ - Grenoble INP
 Lab. 3SR
 BP 53
 38041 Grenoble cedex 9
 Tél : +33 4 56 52 86 21
 Fax : +33 4 76 82 70 43
 
 
 
 ___
 Mailing list: https://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] bool MatchMaker

[Klaus Thoeni]

  I completely forgot about it but changing this should not be a problem.
  The
  definition just needs to be changed to:
  (shared_ptrMatchMaker,includeMoment,,,bool to consider rolling
  resistance)
 Yes.
 
  I could use 0 and 1 instead of False and True in the python script:
  includeMoment=MatchMaker(matches=((mat1,mat1,1), (mat1,mat2,0
  
  In the code we can use something like this to convert the Real to a
  Boolean:
  
  ((*includeMoment)(mat1-id,mat2-id) != 0)
  
  but this probably brakes the conventional way:
  includeMoment=True
  
  What do you think?
 
 I don't see what it would break. Remember to keep the behavior unchanged
 in case includeMoment is none (in c++ the pointer will be null).

Well, ((*includeMoment)(mat1-id,mat2-id) != 0) should work as well for the 
case if includeMoment is none which corresponds to the default (false) at the 
moment. But includeMoment=True or False in the python script should give a 
problem or at least a compiler warning in ((*includeMoment)(mat1-id,mat2-id) 
!= 0), because conversion of bool with int. Don't you think so?

Another option is to make MatchMakers for krot and ktwist and set them to 0 so 
the moment will be 0. It might be an easier solution but not the most efficient.



___
Mailing list: https://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] bool MatchMaker

[Klaus Thoeni]

  Another option is to make MatchMakers for krot and ktwist and set them to
  0 so the moment will be 0. It might be an easier solution but not the
  most efficient.
 The best thing I can imagine is to add a MatchMaker that would not
 replace includeMoment, let's call it momentMatch here.
 
 if (includeMoment  (!momentMatch || (*momentMatch)(mat1,mat2)){
 // ... the moment code
 }

Sounds good to me,  thanks for that.

BTW, don't you think it would make sense to make MatchMakers for most of the 
parameters in the IP2 functors? It would give more flexibility when working 
with different materials.

___
Mailing list: https://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] Logging and debugging

[Klaus Thoeni]

Hi Anton

On Thursday 22 August 2013 08:33:58 Anton Gladky wrote:
 2013/8/22 Klaus Thoeni klaus.tho...@gmail.com:
  So what can I use to see the log output? Is there an other way for doing
  it
  now? Or is this feature completely removed? If so all the LOGs in the code
  are for nothing now.
 
 LOG_WARN, LOG_ERROR, LOG_FATAL should work [1].
 
  I see. Do I have to set something else? I just tried to put some std::cerr
  output in the code and I compiled with debug but it is not appearing.
 
 When I debug the code, I am doing exactly the same. It should appear or this
 part of code is not executed.

I thought so too but this seems not to be the case at least for me. It's 
working e.g. for classes like the contact law but if I put some outputs in 
methods of NewtonIntegrator or Shop which are definitely called it's not 
working. Even after recompiling debug from scratch. I have no idea what's 
going on here. Any idea?

  BTW, do you think it is possible that yade tells you that you are running
  it in debug mode? Maybe something like: Welcome to Yade
  2013-08-15.git-4ef35b0 (debug)?
 
 Need to think about that. Debug-mode is just adding so-called debug-symbols.
 It means, that during the crash you should get some more information about
 that. That is a normal practice for the software.See, how many packages are
 having -dbg
 suffix. Most of them are just those symbols.
 
 [1] https://github.com/yade/trunk/blob/master/lib/base/Logging.hpp#L22
 
 Anton
 
 ___
 Mailing list: https://launchpad.net/~yade-dev
 Post to : yade-dev@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~yade-dev
 More help   : https://help.launchpad.net/ListHelp


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

[Yade-dev] bool MatchMaker

[Klaus Thoeni]

Hi guys

it seems that MatchMakers are working with Real only. I tried something like 
this:

O.engines=[
...
[Law2_ScGeom_MindlinPhys_Mindlin(includeMoment=MatchMaker(matches=((mat1,mat1,True),
(mat1,mat2,False]
...
]

which gives the following error:

TypeError: No registered converter was able to produce a C++ rvalue of type 
bool from this Python object of type MatchMaker

When looking into the code it is obvious because the whole class is defined for 
Real only. Is there a workaround for Booleans? If not, any idea how to 
implement it?

Thanks
Klaus

___
Mailing list: https://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] Logging and debugging

[Klaus Thoeni]

Hi Anton

On Thursday 22 August 2013 07:50:28 Anton Gladky wrote:
 Hi Klaus,
 
 2013/8/22 Klaus Thoeni klaus.tho...@gmail.com
 
  Hi guys
  
  log4cxx feature and yade.log module are not available any more, right? So
  how
  do you print your logs? I am used to use something like this in my
  scripts:
  
  import yade.log
  yade.log.setLevel('TheClassOfWhichLoggerYouWantToSet',yade.log.TRACE)
 
 setLevel does not work any more.

So what can I use to see the log output? Is there an other way for doing it 
now? Or is this feature completely removed? If so all the LOGs in the code are 
for nothing now.

  One can cmake with -DDEBUG=ON which should compile yade in debug mode.
  Before
  cmake yade --debug was used to run yade in debug mode. It seems that
  this
  option is not valid any more. So how do you guys run debug and optimized
  at
  the same time? Do you define an other INSTALL_PREFIX for debug?
 
 Yes, you should have 2 different build-places and install debug and
 optimized
 versions in different paths or with different suffixes.

I see. Do I have to set something else? I just tried to put some std::cerr 
output in the code and I compiled with debug but it is not appearing. I am 
calling the right version of yade because I removed everything else before ;-) 

BTW, do you think it is possible that yade tells you that you are running it 
in debug mode? Maybe something like: Welcome to Yade 2013-08-15.git-4ef35b0 
(debug)? 

Thanks
Klaus




___
Mailing list: https://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] Logging and debugging

[Klaus Thoeni]

Hi guys

log4cxx feature and yade.log module are not available any more, right? So how 
do you print your logs? I am used to use something like this in my scripts:

import yade.log
yade.log.setLevel('TheClassOfWhichLoggerYouWantToSet',yade.log.TRACE)

One can cmake with -DDEBUG=ON which should compile yade in debug mode. Before 
cmake yade --debug was used to run yade in debug mode. It seems that this 
option is not valid any more. So how do you guys run debug and optimized at 
the same time? Do you define an other INSTALL_PREFIX for debug?

Thanks
Klaus

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

[Yade-dev] Some other clump issues

[Klaus Thoeni]

Hi guys

I really like the idea of having clump properties updated, thanks Christian. 
However, I found a little problem: line 121-122 in Clump.cpp. Clumps with no 
physical overlap are detected with intersecting=true, i.e. try this and you 
have to wait quite a while:

O.bodies.appendClumped(regularOrtho(inAlignedBox((0.,0.,0.),
(2,2,2)),radius=0.1,gap=0.0))

There should be no overlap but it seems that updateProperties is called.

I guess it is because of the numerical rounding error in line 121. The check 
in line 122 un0 should probably be changed to something like 
un-0.001*min(r1,r2) with a tolerance. What do you think?

Secondly, I think we should leave it up to the user to define if he wants to 
update the properties. It makes sense to let the user choose the divisor for 
the regular grid and maybe divisor=0 could mean no update.

Any additional thought on this?

Klaus

P.S.: Thanks Bruno for starting the clump discussion ;-)


___
Mailing list: https://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] plot.show() and pylab.show() block konsole

[Klaus Thoeni]

Hi guys

I run one of the example scripts, i.e. /examples/test/psd.py.

The script uses pylab to plot the psd curve. However, once the plots are shown 
the ipython konsole is blocked. One has to close all the windows/figures 
including Yade's cotroller and viewer in order to access it again. Same 
applies if I use yade.plot.show().

Can anyone reproduce this behaviour? Is it a bug in yade or mathplotlib? I 
think it was fine on my old installation so the problem might be related to 
matplotlib. Now I am running kubuntu 12.04.2 with matplotlib 1.1.1.

Thanks
Klaus

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

Re: [Yade-dev] Yade does not start, linker problem?

[Klaus Thoeni]

Hi Anton

thank you very much, it's working now. Just in time ;-)

Why didn't anyone else have this problem? How can we avoid such problems in 
the future? 

Thanks again
Klaus

On Monday 01 July 2013 21:09:14 Anton Gladky wrote:
 Hi all,
 
 Klaus, if you have not yet reinstalled the system, please check
 the latest 34ba150-commit, it should fix your problem. It was a bug,
 which became visible after 1e52860.
 
 Christian has used functions from libplugins (e.g. pkg/* -directory), but
 Clumps are in libcore, which are not linked against libplugins, but
 libplugins were linked against libcore...
 
 So, to escape any other confusions and cross- and over-linkage I merged
 libplugins, libsupport and libcore into libyade, It should fix all issues.
 
 Thanks all for contribution.
 
 Anton
 
 2013/7/1 Jan Stránský honzik.stran...@gmail.com:
  Hi guys, did you find the solution? I did a fresh installation from the
  scratch ending with exactly the same error as Klaus..
  Thanks
  Jan
  
  
  2013/6/27 Anton Gladky gladky.an...@gmail.com
  
  2013/6/27 Klaus Thoeni klaus.tho...@gmail.com:
   I am actually considering to re-install kubuntu. Any recommendations on
   what
   version I should use (12.04 or 13.04)?
  
  From my point of view there are not so much changes in scientific
  packages
  between these versions, because Debian was frozen in this period.
  
  Anton
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp

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

Re: [Yade-dev] Yade does not start, linker problem?

[Klaus Thoeni]

I tried to install and build in another directory. I even created a new user 
to see if it is related to my local settings. But I still have the same issue.

I am actually considering to re-install kubuntu. Any recommendations on what 
version I should use (12.04 or 13.04)? 

Thanks
Klaus

On Wednesday 26 June 2013 21:26:03 Anton Gladky wrote:
 Hmm, difficult to say, what is going on. Did you try to install
 and build in some other directory?
 
 Anton
 
 2013/6/26 Klaus Thoeni klaus.tho...@gmail.com:
  Files are attached attached. ldd gives a similar error.
  
  On Wednesday 26 June 2013 08:25:26 Anton Gladky wrote:
  ldd -d
  /home/thoeni/YADE-git/master/install/lib/x86_64-linux-gnu/yade-2013-06-21
  .g
  it-1e52860/libcore.so

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

[Yade-dev] Yade does not start, linker problem?

[Klaus Thoeni]

Hi guys

I just updated one of my machines and compiled yade. Everything went smoothly 
but when I try to run yade I get the following:

thoeni@thoeni:~/YADE-git/master/build$ yade
Welcome to Yade 2013-06-21.git-1e52860
Traceback (most recent call last):
  File /home/thoeni/YADE-git/master/install/bin/yade-2013-06-21.git-1e52860, 
line 115, in module
import yade
  File /home/thoeni/YADE-git/master/install/lib/x86_64-linux-
gnu/yade-2013-06-21.git-1e52860/py/yade/__init__.py, line 65, in module
import boot
ImportError: /home/thoeni/YADE-git/master/install/lib/x86_64-linux-
gnu/yade-2013-06-21.git-1e52860/libcore.so: undefined symbol: 
_ZTVN4yade6SphereE

To me it seems like a liking error but I was not able to fix it. I am running 
kubuntu 12.04 with gcc 4.6.3 and cmake 2.8.9. I have another machine with the 
same operating system but cmake 2.8.7 and it is working. Any suggestions?

BTW, is anyone running yade on ubuntu 12.10 or 13.04? Do you recommend to 
upgrade?

Thnaks
Klaus


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

Re: [Yade-dev] Yade does not start, linker problem?

[Klaus Thoeni]

I actually did re-run cmake. I even deleted everything in my build directory 
to be sure. So I guess this is not the problem. Any other ideas?


On Tuesday 25 June 2013 10:48:33 Bruno Chareyre wrote:
 Did you re-run cmake?
 When new cpp files are added (and it was the case recently) it is necessary.
 
 B
 
 On 25/06/13 08:49, Klaus Thoeni wrote:
  Hi guys
  
  I just updated one of my machines and compiled yade. Everything went
  smoothly but when I try to run yade I get the following:
  
  thoeni@thoeni:~/YADE-git/master/build$ yade
  Welcome to Yade 2013-06-21.git-1e52860
  
  Traceback (most recent call last):
File
/home/thoeni/YADE-git/master/install/bin/yade-2013-06-21.git-1e52860, 
  line 115, in module
  
  import yade

File /home/thoeni/YADE-git/master/install/lib/x86_64-linux-
  
  gnu/yade-2013-06-21.git-1e52860/py/yade/__init__.py, line 65, in module
  
  import boot
  
  ImportError: /home/thoeni/YADE-git/master/install/lib/x86_64-linux-
  gnu/yade-2013-06-21.git-1e52860/libcore.so: undefined symbol:
  _ZTVN4yade6SphereE
  
  To me it seems like a liking error but I was not able to fix it. I am
  running kubuntu 12.04 with gcc 4.6.3 and cmake 2.8.9. I have another
  machine with the same operating system but cmake 2.8.7 and it is working.
  Any suggestions?
  
  BTW, is anyone running yade on ubuntu 12.10 or 13.04? Do you recommend to
  upgrade?
  
  Thnaks
  Klaus
  
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
 
 --
 ___
 Bruno Chareyre
 Associate Professor
 ENSE³ - Grenoble INP
 Lab. 3SR
 BP 53
 38041 Grenoble cedex 9
 Tél : +33 4 56 52 86 21
 Fax : +33 4 76 82 70 43
 
 
 
 ___
 Mailing list: https://launchpad.net/~yade-dev
 Post to : yade-dev@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~yade-dev
 More help   : https://help.launchpad.net/ListHelp

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

[Yade-dev] yade --check

[Klaus Thoeni]

I added a check script: scripts/checks-and-tests/checks/checkWirePM.py

Now when running yade --check it should automatically be detected by 
checkList.py. There is no need to add it to a list, right? But it's not 
running. Is something wrong with my script?

Thanks
Klaus

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

Re: [Yade-dev] Yade does not start, linker problem?

[Klaus Thoeni]

No, I am not using yade from packages. I am only running my own compiled 
version. Could it be a problem with the cmake version? Is anyone using cmake 
2.8.9? What else could it be?

On Tuesday 25 June 2013 11:43:17 Anton Gladky wrote:
 Do you have installed yade from packages on that machine? It can so happen,
 that the shared libraries are taken from the packaged Yade version, but
 you try to use the compiled one.
 
 
 Anton
 
 2013/6/25 Klaus Thoeni klaus.tho...@newcastle.edu.au:
  I actually did re-run cmake. I even deleted everything in my build
  directory to be sure. So I guess this is not the problem. Any other
  ideas?
  
  On Tuesday 25 June 2013 10:48:33 Bruno Chareyre wrote:
  Did you re-run cmake?
  When new cpp files are added (and it was the case recently) it is
  necessary.
  
  B
  
  On 25/06/13 08:49, Klaus Thoeni wrote:
   Hi guys
   
   I just updated one of my machines and compiled yade. Everything went
   smoothly but when I try to run yade I get the following:
   
   thoeni@thoeni:~/YADE-git/master/build$ yade
   Welcome to Yade 2013-06-21.git-1e52860
   
   Traceback (most recent call last):
 File
 /home/thoeni/YADE-git/master/install/bin/yade-2013-06-21.git-1e52860
 ,
   
   line 115, in module
   
   import yade
 
 File /home/thoeni/YADE-git/master/install/lib/x86_64-linux-
   
   gnu/yade-2013-06-21.git-1e52860/py/yade/__init__.py, line 65, in
   module
   
   import boot
   
   ImportError: /home/thoeni/YADE-git/master/install/lib/x86_64-linux-
   gnu/yade-2013-06-21.git-1e52860/libcore.so: undefined symbol:
   _ZTVN4yade6SphereE
   
   To me it seems like a liking error but I was not able to fix it. I am
   running kubuntu 12.04 with gcc 4.6.3 and cmake 2.8.9. I have another
   machine with the same operating system but cmake 2.8.7 and it is
   working.
   Any suggestions?
   
   BTW, is anyone running yade on ubuntu 12.10 or 13.04? Do you recommend
   to
   upgrade?
   
   Thnaks
   Klaus
   
   
   ___
   Mailing list: https://launchpad.net/~yade-dev
   Post to : yade-dev@lists.launchpad.net
   Unsubscribe : https://launchpad.net/~yade-dev
   More help   : https://help.launchpad.net/ListHelp
  
  --
  ___
  Bruno Chareyre
  Associate Professor
  ENSE³ - Grenoble INP
  Lab. 3SR
  BP 53
  38041 Grenoble cedex 9
  Tél : +33 4 56 52 86 21
  Fax : +33 4 76 82 70 43
  
  
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
 
 ___
 Mailing list: https://launchpad.net/~yade-dev
 Post to : yade-dev@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~yade-dev
 More help   : https://help.launchpad.net/ListHelp
-- 
Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling
Civil, Surveying and Environmental Engineering - Engineering Building EA
The University of Newcastle, Callaghan, NSW 2308, Australia
web: http://www.newcastle.edu.au/research-centre/cgmm
phone: +61 (0)2 4921 5735

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

Re: [Yade-dev] Yade does not start, linker problem?

[Klaus Thoeni]

Hi Jan

I usually delete everything in my build directory before compiling a new 
version. I guess that should do the job as well, or not?

Thanks
Klaus

On Tuesday 25 June 2013 08:54:19 you wrote:
 Hi Klaus,
 I met the same problem some time ago.. After what time did you do the
 update? sometimes make clean is needed if there are some significant
 changes.
 HTH
 Jan
 
 
 
 
 2013/6/25 Klaus Thoeni klaus.tho...@gmail.com
 
  Hi guys
  
  I just updated one of my machines and compiled yade. Everything went
  smoothly
  but when I try to run yade I get the following:
  
  thoeni@thoeni:~/YADE-git/master/build$ yade
  Welcome to Yade 2013-06-21.git-1e52860
  
  Traceback (most recent call last):
File
  
  /home/thoeni/YADE-git/master/install/bin/yade-2013-06-21.git-1e52860,
  line 115, in module
  
  import yade

File /home/thoeni/YADE-git/master/install/lib/x86_64-linux-
  
  gnu/yade-2013-06-21.git-1e52860/py/yade/__init__.py, line 65, in module
  
  import boot
  
  ImportError: /home/thoeni/YADE-git/master/install/lib/x86_64-linux-
  gnu/yade-2013-06-21.git-1e52860/libcore.so: undefined symbol:
  _ZTVN4yade6SphereE
  
  To me it seems like a liking error but I was not able to fix it. I am
  running
  kubuntu 12.04 with gcc 4.6.3 and cmake 2.8.9. I have another machine with
  the
  same operating system but cmake 2.8.7 and it is working. Any suggestions?
  
  BTW, is anyone running yade on ubuntu 12.10 or 13.04? Do you recommend to
  upgrade?
  
  Thnaks
  Klaus
  
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp

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

Re: [Yade-dev] yade --check

[Klaus Thoeni]

Ok, now it's running as well on my machine. So, if I understand it right you 
have to touch CMakeLists.txt when you add new files, right? So it's not 
enough to delete your build and install directory.

Thanks Anton

On Tuesday 25 June 2013 11:59:43 Anton Gladky wrote:
 It is running [1].
 Just do touch CMakeLists.txt
 
 [1]
 https://yade-dem.org/buildbot/builders/yade-full/builds/1997/steps/test_1/l
 ogs/stdio
 
 Anton
 
 2013/6/25 Klaus Thoeni klaus.tho...@gmail.com:
  I added a check script: scripts/checks-and-tests/checks/checkWirePM.py
  
  Now when running yade --check it should automatically be detected by
  checkList.py. There is no need to add it to a list, right? But it's not
  running. Is something wrong with my script?
  
  Thanks
  Klaus
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp

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

Re: [Yade-dev] Yade does not start, linker problem?

[Klaus Thoeni]

No, I am executing the right file. 

However, some new hint. When comparing the local directory install/lib/x86_64-
linux-gnu/yade-2013-06-15.git-e88d195/py to another working one I can see that 
in my directory all pyc-files are missing. I guess this is the problem. But why 
are they missing? Has it something to to with PYTHONPATH or so? 

On Tuesday 25 June 2013 12:51:57 you wrote:
 Yes, if you delete everything and cmake - make from scratch, it is stronger
 than make clean :-) but I have no idea in your case.. Try also to delete
 the yade executable, is it possible that you are executing different file?
 Jan
 
 
 2013/6/25 Klaus Thoeni klaus.tho...@gmail.com
 
  Hi Jan
  
  I usually delete everything in my build directory before compiling a new
  version. I guess that should do the job as well, or not?
  
  Thanks
  Klaus
  
  On Tuesday 25 June 2013 08:54:19 you wrote:
   Hi Klaus,
   I met the same problem some time ago.. After what time did you do the
   update? sometimes make clean is needed if there are some significant
   changes.
   HTH
   Jan
   
   
   
   
   2013/6/25 Klaus Thoeni klaus.tho...@gmail.com
   
Hi guys

I just updated one of my machines and compiled yade. Everything went
smoothly
but when I try to run yade I get the following:

thoeni@thoeni:~/YADE-git/master/build$ yade
Welcome to Yade 2013-06-21.git-1e52860

Traceback (most recent call last):
  File

/home/thoeni/YADE-git/master/install/bin/yade-2013-06-21.git-1e52860
,
line 115, in module

import yade
  
  File /home/thoeni/YADE-git/master/install/lib/x86_64-linux-

gnu/yade-2013-06-21.git-1e52860/py/yade/__init__.py, line 65, in
  
  module
  
import boot

ImportError: /home/thoeni/YADE-git/master/install/lib/x86_64-linux-
gnu/yade-2013-06-21.git-1e52860/libcore.so: undefined symbol:
_ZTVN4yade6SphereE

To me it seems like a liking error but I was not able to fix it. I am
running
kubuntu 12.04 with gcc 4.6.3 and cmake 2.8.9. I have another machine
  
  with
  
the
same operating system but cmake 2.8.7 and it is working. Any
  
  suggestions?
  
BTW, is anyone running yade on ubuntu 12.10 or 13.04? Do you recommend
  
  to
  
upgrade?

Thnaks
Klaus


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

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

Re: [Yade-dev] Yade does not start, linker problem?

[Klaus Thoeni]

No, I don't set it manually. I am just guessing because I encountered this 
problem after I tried to compile yade's documentation and after installing 
GenGeo by compiling the sources, and both are somehow using PYTHONPATH.

Well I am not sure what's going on. It seams that the pyc files are created 
when launching yade the first time, so it is not related to that since yade is 
not starting.

Any other guess? 


On Tuesday 25 June 2013 13:55:41 Anton Gladky wrote:
 2013/6/25 Klaus Thoeni klaus.tho...@gmail.com:
 Has it something to to with PYTHONPATH or so?
 
 Do you set it explicitly? It can cause problems.
 
 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

[Yade-dev] [yade/trunk] ad4f51: various wire contact laws available now, add refer...

[Klaus Thoeni]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: ad4f512969efc02fa092966817a79f696667eb26
  
https://github.com/yade/trunk/commit/ad4f512969efc02fa092966817a79f696667eb26
  Author: Klaus Thoeni klaus.tho...@gmail.com
  Date:   2013-06-24 (Mon, 24 Jun 2013)

  Changed paths:
A scripts/checks-and-tests/checks/checkWirePM.py

  Log Message:
  ---
  various wire contact laws available now, add reference with details, add a 
check script for the wire model



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

[Yade-dev] [yade/trunk] f14104: various wire contact laws available now (new versi...

[Klaus Thoeni]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: f1410403c3b0f0828b7bb4106b108886bfd3d1a8
  
https://github.com/yade/trunk/commit/f1410403c3b0f0828b7bb4106b108886bfd3d1a8
  Author: Klaus Thoeni klaus.tho...@gmail.com
  Date:   2013-06-24 (Mon, 24 Jun 2013)

  Changed paths:
M doc/references.bib
M doc/yade-articles.bib
M pkg/dem/WirePM.cpp
M pkg/dem/WirePM.hpp

  Log Message:
  ---
  various wire contact laws available now (new version), add reference with 
details



___
Mailing list: https://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 850864] Re: strange facet-sphere behaviour

[Klaus Thoeni]

Hi guys,

I just found this paper:

http://onlinelibrary.wiley.com/doi/10.1002/nme.4487/abstract

Maybe it could be one way to implement the contact detection between
spheres and facets in yade.

What do you think?

Klaus

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

Title:
  strange facet-sphere behaviour

Status in Yet Another Dynamic Engine:
  Won't Fix

Bug description:
  See https://answers.launchpad.net/yade/+question/171223

  Spheres that are exactly on an edge between facets behave strangely.
  Maybe related to other (closed, but never solved) bugs in sphere-
  facet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/850864/+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] Removing scons

[Klaus Thoeni]

Well, I thought so too, sice I saw your commits but if a go on 

https://yade-dem.org/doc/installation.html

everything is still with scons and bzr.

Maybe because of this:

This documentation decribes Yade version 2012-06-24.git-00a175d / 
2012-06-24.git-00a175d.

So the doc on the server needs to be re-compiled. BTW, how often is this done?


On Wed, 4 Jul 2012 03:33:30 PM Anton Gladky wrote:
 Hi Klaus,
 scons stuff is already replaced by cmake in docs.
 
 Anton
 
 2012/7/4 Klaus Thoeni klaus.tho...@gmail.com:
  Hi guys,
  
  before removing scons I would strongly suggest to update the
  documentation. We should also get rid of all the bzr stuff if we really
  want to stay with git.
  
  Klaus
 
 ___
 Mailing list: https://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] [Bug 850864] Re: strange facet-sphere behaviour

[Klaus Thoeni]

Ok, this job might be too big for the studend indeed.

On Wed, 11 Apr 2012 11:45:52 PM Bruno Chareyre wrote:
 Well, basically, it is not possible to fix this problem with the current
 logic, where each facet is an independant body.
 We need to consider a triangulated surface as one entity and define
 contacts differently if they are on facets, edges, or vertices.
 In order to do that, we need a well designed data structure defining the
 connectivity of facets, and used by Ig functors to track the contacts
 passing from one facet to the other.
 
 The problem is similar as in chained cylinder, but in 2D (while chained
 cylinders are 1D). It would be a big step, but it is not a small job.
 
 Bruno
 
 On 11/04/12 13:08, Klaus Thoeni wrote:
  Hi Bruno, I might have found a student which can work on it. What do you
  think? Is it tricky? I didn't have a look at it since last time we
  talked about it and it seams the bug is still existing. Let me know.

___
Mailing list: https://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 850864] Re: strange facet-sphere behaviour

[Klaus Thoeni]

Hi Bruno, I might have found a student which can work on it. What do you
think? Is it tricky? I didn't have a look at it since last time we
talked about it and it seams the bug is still existing. Let me know.

-- 
You received this bug notification because you are a member of Yade
developers, which is the registrant for Yade.
https://bugs.launchpad.net/bugs/850864

Title:
  strange facet-sphere behaviour

Status in Yet Another Dynamic Engine:
  Confirmed

Bug description:
  See https://answers.launchpad.net/yade/+question/171223

  Spheres that are exactly on an edge between facets behave strangely.
  Maybe related to other (closed, but never solved) bugs in sphere-
  facet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/850864/+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] own compiled boost

[Klaus Thoeni]

Thanks Anton, but LD_LIBRARY_PATH is not an option in scons.profile.

Any other guesses?

On Mon, 20 Feb 2012 05:39:02 PM Anton Gladky wrote:
 Hi Klaus,
 
 try adding LD_LIBRARY_PATH='/usr/local/boost_1_46_1'
 
 Sorry, just a guess. Never tried.
 
 Anton
 
 2012/2/20 Klaus Thoeni klaus.tho...@newcastle.edu.au:
  Hi guys,
  
  as you might have noticed I am trying to run yade on a Red Hat server.
  However, saving and loading of simulations is not working. My guess is it
  could be related to the boost version used on the server (1.41.0-11) so I
  compiled version 1.46.1 in /usr/local. After adding LIBPATH =
  '/usr/local/boost_1_46_1/stage/lib' and CPPPATH =
  '/usr/local/boost_1_46_1' to my scons.profile I could compile the code.
  However, when launching yade I have the following problem now.
  
  Welcome to Yade bzr2999
  Traceback (most recent call last):
File ./yade-bzr2999, line 118, in module
  import yade
File
  /home/kt748/YADE-bzr/install/lib/yade-bzr2999/py/yade/__init__.py,
  line 58, in module
  import boot
  ImportError: libboost_system.so.1.46.1: cannot open shared object file:
  No such file or directory
  
  But libboost_system.so.1.46.1 exists in /usr/local/boost_1_46_1/. Any
  suggestions?
  
  Thanks
  Klaus
  
  ___
  Mailing list: https://launchpad.net/~yade-dev
  Post to : yade-dev@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~yade-dev
  More help   : https://help.launchpad.net/ListHelp
 
 ___
 Mailing list: https://launchpad.net/~yade-dev
 Post to : yade-dev@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~yade-dev
 More help   : https://help.launchpad.net/ListHelp

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

Re: [Yade-dev] own compiled boost

[Klaus Thoeni]

Hi Anton,

the path to the dynamic libraries was incomplete. I solved it with:

export D_LIBRARY_PATH=/usr/local/boost_1_46_1/stage/lib

And yade finally works. So the problem was really related to the boost version.

So what do you think, should update the documentation for the installation and 
point out that boost 1.42 or later is required? Well it was not working with 
1.41.0 on Red Hat and 1.42.0 works on my ubuntu machine.

Guys, what do you think?

Thanks again,
Klaus

On Tue, 21 Feb 2012 08:18:02 AM Anton Gladky wrote:
 Try to start yade:
 
 export LD_LIBRARY_PATH=/usr/local/boost_1_46_1; yade
 
 Anton
 
 ___
 Mailing list: https://launchpad.net/~yade-dev
 Post to : yade-dev@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~yade-dev
 More help   : https://help.launchpad.net/ListHelp

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

[Yade-dev] own compiled boost

[Klaus Thoeni]

Hi guys,

as you might have noticed I am trying to run yade on a Red Hat server.
However, saving and loading of simulations is not working. My guess is it
could be related to the boost version used on the server (1.41.0-11) so I
compiled version 1.46.1 in /usr/local. After adding LIBPATH =
'/usr/local/boost_1_46_1/stage/lib' and CPPPATH = '/usr/local/boost_1_46_1'
to my scons.profile I could compile the code. However, when launching yade
I have the following problem now.

Welcome to Yade bzr2999
Traceback (most recent call last):
  File ./yade-bzr2999, line 118, in module
import yade
  File /home/kt748/YADE-bzr/install/lib/yade-bzr2999/py/yade/__init__.py,
line 58, in module
import boot
ImportError: libboost_system.so.1.46.1: cannot open shared object file: No
such file or directory

But libboost_system.so.1.46.1 exists in /usr/local/boost_1_46_1/. Any
suggestions?

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

Re: [Yade-dev] [Bug 918948] Re: yade.qt documentation missing

[Klaus Thoeni]

Thanks Remi, it's working now.

On Thu, 16 Feb 2012 03:34:45 AM Rémi wrote:
 Hi,
 
 Le 08/02/2012 23:15, Klaus Thoeni a écrit :
  actually at some stage it was working, see bzr2704:
  https://www.yade-dem.org/sphinx/yade.qt.html
  I don't know if in the mean time something changed in the doc
  generation.
 
 This was old way automatic building, not on buildbot.
 
 Doc is now generated using xvfb (a virtual x server), it should contains
 qt specific parts.
 
 Cheers,
 rémi
 
  Cheers,
  Klaus
  
  On Wed, 8 Feb 2012 10:02:38 PM Chareyre wrote:
  It is not very easy I'm afraid. I see windows manipulation in the Viewer
  constructor itself. Since generating the documentation needs to
  instanciate one object of each class, we are stuck I think (not sure
  though). A workaround would be to generate the documentation on one of
  these server slots that allow graphical sessions. Is that possible?

-- 
You received this bug notification because you are a member of Yade
developers, which is the registrant for Yade.
https://bugs.launchpad.net/bugs/918948

Title:
   yade.qt documentation missing

Status in Yet Another Dynamic Engine:
  New

Bug description:
  There is something wrong with the documentation of module yade.qt.
  Nothing is shown on the doc site:

  https://yade-dem.org/doc/yade.qt.html

  and it's not listed in the index:

  https://yade-dem.org/doc/py-modindex.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/918948/+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] [Bug 931263] Re: localhost info

[Klaus Thoeni]

Yes, thanks Anton!

On Tue, 14 Feb 2012 05:42:19 PM Anton Gladky wrote:
 Hi Klaus,
 
 it should be ok in r3026. There was a typo in a formulation.
 
 Thanks for pointing that out.
 
 Anton
 
 2012/2/14 Klaus Thoeni 931...@bugs.launchpad.net:
  Hi Anton,
  
  well done! The information shown by the localhost are fine now. The only
  thing which is still strange is that the estimated day/time when
  finished is wrong even if the iter/sec is more or less constant. It
  gives dates like 20 March whereas the simulation is finished in 5
  minutes. Towards the end of the simulation (90%) it's getting more
  realistic. The same problem exists for simulations starting from the
  beginning.
  
  Not sure how the time/date is estimated. But since value iter/sec is
  correct it shouldn't behave so strange.
  
  Thanks,
  Klaus
  
  On Tue, 14 Feb 2012 08:07:57 AM Anton Gladky wrote:
  I hope r3025 will fix the bug.
  
  --
  You received this bug notification because you are subscribed to Yade.
  https://bugs.launchpad.net/bugs/931263
  
  Title:
   localhost info
  
  Status in Yet Another Dynamic Engine:
   Fix Released
  
  Bug description:
   When running a simulation, which has already some pre-history (e.g.
   load a simulation which has done already 10 iterations and run
   some more simulations), in batch mode some information in localhost
   info are wrong. I guess the average iterations per seconds include the
   iterations from the loaded state. Therefore, the value is far to high
   and the estimate for the finishing time/date is as well wrong. When
   running without batch mode the controller is showing the correct
   value.
  
  To manage notifications about this bug go to:
  https://bugs.launchpad.net/yade/+bug/931263/+subscriptions

-- 
You received this bug notification because you are a member of Yade
developers, which is the registrant for Yade.
https://bugs.launchpad.net/bugs/931263

Title:
  localhost info

Status in Yet Another Dynamic Engine:
  Fix Released

Bug description:
  When running a simulation, which has already some pre-history (e.g.
  load a simulation which has done already 10 iterations and run
  some more simulations), in batch mode some information in localhost
  info are wrong. I guess the average iterations per seconds include the
  iterations from the loaded state. Therefore, the value is far to high
  and the estimate for the finishing time/date is as well wrong. When
  running without batch mode the controller is showing the correct
  value.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/931263/+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