[Yade-dev] Disabling/redirecting questions on launchpad?

[Jan Stránský]

Hello,
there are regularly new questions on launchpad.
Would it be possible to disable new questions?
Or better, somehow automatically redirect to GitLab?
Cheers
Jan
___
Mailing list: https://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] Test

[Jan Stránský]

yes, I got the e-mail
Jan


Dne st 30. 8. 2023 19:23 uživatel Janek Kozicki (yade) <
jkozicki-y...@pg.edu.pl> napsal:

> Hi Bruno,
>
> I did not receive your email. I copied it from list archive website.
> I am not sure how is it possible that you received it and I didn't.
> Maybe something is wrong with my filters? No idea. But when did they
> break - I didn't change anything in my configuration for years.
>
> Did anyone else receive this mailing list post?
>
> Yeah, moving to another mailing list server for yade-dev seems reasonable.
>
> best regards
> Janek
>
> @ email copied from https://lists.launchpad.net/yade-dev/msg15150.html
> @
> @ I see your test in my mailbox.
> @ Maybe we will have to host a "yade-dev" list somewhere else if we
> @ drop launchpad?
> @ B
>
> Janek Kozicki (yade) said: (by the date of Tue, 29 Aug 2023 19:36:56
> +0200)
>
> > I am testing yade-dev mailing list. I can see latest Bruno's email in
> > the mailing list archive:
> >
> > https://lists.launchpad.net/yade-dev/date.html
> >
> > but I didn't receive it as email.
> >
> > I wonder what's going on.
> >
> > Janek
>
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdansk University of Technology (Gdansk Tech)
> Faculty of Applied Physics and Mathematics
> Institute of Physics and Applied Computer Science
> Division of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/p/jan-kozicki-19725
> http://mostwiedzy.pl/en/jan-kozicki,19725-1
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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] Website down?

[Jan Stránský]

no..
Jan


čt 26. 5. 2022 v 16:55 odesílatel Robert Caulk  napsal:

> Anyone else able to reach yade-dem.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

[Yade-dev] Wiki is down

[Jan Stránský]

Hello,

In case you do not know it, wiki is currently not accessible, showing HTTP
ERROR 500 www.yade-dem.org is currently unable to handle this request.

I cannot link to https://www.yade-dem.org/wiki/Howtoask :-D

Cheers
Jan
___
Mailing list: https://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] Pictures in Yade questions?

[Jan Stránský]

Hello,

regarding no external links for questions, it is reasonable.
However, sometimes a *picture* might be necessary or at least convenient
(or?).
Would it be worth declaring some "standard pictures repository" for Yade
questions?
To allow putting certain attachment, but in a standard way overcoming
problems mentioned in Please, no external links!


cheers
Jan
___
Mailing list: https://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] Wiki FAQ

[Jan Stránský]

I also would not entirely delete the page / content.


> maybe they should go somewhere else, but where?


one option is to put them to the source code in the .rst format and  create
a new "main page link" similar to tutorial

cheers
Jan



út 21. 7. 2020 v 15:45 odesílatel Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> napsal:

> Hi,
> This page is indeed rather old. I would suggest to remove all the content
> that is irrelevant/obsolete, about Scons and stuff and see what remains.
> Because there are a couple valid points, maybe they should go somewhere
> else, but where?
> - What is "Young" and "Poisson" in ElastMat material?
> - I want to get 2 plots, how can I do it?
> - Is it possible to make another color of the background from python
> script?
> B
>
>
> On Tue, 21 Jul 2020 at 13:56, Jerome Duriez 
> wrote:
>
>> Hi everyone,
>>
>> This question [*] made me wander on https://www.yade-dem.org/wiki/FAQ.
>>
>> A nice place to remember old ages with mentions about bzr, scons, .. but
>> maybe not really useful to any new user and, as it appears, maybe
>> impossible to maintain..
>>
>> I'm thus proposing to remove this page from the wiki :-)
>> (since I'll not propose here to remove the wiki ;-) )
>>
>> Thoughts ?
>>
>>
>> Jérôme
>>
>> [*] https://answers.launchpad.net/yade/+question/691986
>> But it seems this is not on that FAQ the OP found a github URL
>> --
>> Chargé de Recherche / Research Associate
>> Inrae, RECOVER
>> 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
>> +33 (0)4 42 66 99 21
>>
>> https://www6.paca.inrae.fr/recover/membres-du-laboratoire/pages-personnelles/jerome-duriez
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://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] Publications with yade

[Jan Stránský]

Hello,

thanks for the info

> Please find attached some of the resulting publications

there was no attachment...

> ... if deemed relevant.

I think all publications directly using Yade are relevant to the
"publication" part of the main page.
>From source code point of view (you will be author of the changes and
developers just "approve" them), it would be ideal if you created a "merge
request" on gitlab. What is your opinion?

cheers
Jan



út 7. 7. 2020 v 13:15 odesílatel Jan De Pue  napsal:

> Dear Yade developers,
>
> I recently finished my PhD, using a Yade for a substantial part of the
> research.
>
> Please find attached some of the resulting publications, and here's a link
> to the thesis<
> https://www.researchgate.net/publication/336604225_Advances_in_modelling_vehicle-induced_stress_transmission_in_relation_to_soil_compaction
> >.
>
> They can be included in the Yade publication list, if deemed relevant.
>
>
> Many thanks for developing and maintaining Yade!
>
> Jan
> ___
> Mailing list: https://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 1810283] Re: Wiki homepage broken

[Jan Stránský]

Hello,
just a note concerning wiki, I know (but have no experience with them) that
gitlab offers wiki pages. Maybe it would be worth moving also wiki within
the gitlab migration..
cheers
Jan


pá 22. 2. 2019 v 15:13 odesílatel Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> napsal:

> Hi,
> The wiki is back. No space on disk was the issue.
>
> The same physical machine has publications [1], daily packages [2] - and
> previously the html documentation which is now on gitlab.
> I discussed a migration of that server to another physical machine with
> our one-man IT support (Jérôme Branon) since it is an old machine.
> It can be done it seems.
> In this event I'm considering getting the html doc back to its previous
> place, it would avoid the hacky "gitlab.io" url substitution. More
> precisely, yade-dem.org/doc would mirror yade-dev.gitlab.io/trunk/.
>
> Cheers
>
> Bruno
>
> [1] https://yade-dem.org/publi/
> [2] http://packages.yade-dem.org/
>
> On Mon, 7 Jan 2019 at 17:36, Janek Kozicki  wrote:
>
>> Bruno Chareyre said: (by the date of Mon, 07 Jan 2019 15:23:11 -)
>>
>> > To be honest that wiki hosted on some 3SR server will get less and less
>> support with Rémi gone.
>> > I don't even know which computer exactly is hosting this.
>> >
>> > Finding a replacement would be a good thing. Gitlab is hosting wiki
>> pages indeed (even Github actually) but I don't if it is possible to just
>> dump everything and upload it elsewhere...
>> > If the bug appear randomly I suspect an issue on the host computer,
>> like full HD or exhausted RAM.
>>
>> I propose to not edit wiki until the migration process to gitlab is
>> finished. Maybe Rémi could find the hosting computer and send us the
>> compressed directory with it?
>>
>> Then we would investigate possible ways to import it into gitlab?
>>
>> --
>> Janek Kozicki
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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 1814052] Re: Unreproductible simulation (one core, one computer, one script) with a tutorial example

[Jan Stránský]

Hello,

> Sorry I forgot to underline the fact that my packing is the same for
each run.

please provide the exact script you are using. There is no packing loading in 
the current script..
Or the information how you load the packing..

thanks
Jan

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

Title:
  Unreproductible simulation (one core, one computer, one script) with a
  tutorial example

Status in Yade:
  New

Bug description:
  In the framework of my PhD thesis, I use Yade and shear numerical 
simulations. 
  While using a script based on the periodic simple shear tutorial example 
given on the web side, I noticed that my simulation is not reproducible : the 
physical time, the controlling and the output parameters differ when a 
sequential yade calculation is run several times on the same core, same 
computer, same day, same script, same sample.
  I supposed there is/are several parameter(s) which is/are not initialized 
when closing/opening Yade. Do you know them ?

  I use Yade program on a Ubuntu 18.

  Thanks in advance

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814052/+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] [Yade-users] [Question #676841]: the definition of porosity

[Jan Stránský]

Hi Bruno,
sorry for late answer, during Christmas I totally forgot about the topic :-)
yes, reading it once more, it sounds contradictory.. but anyway it make
sense to me and I am sure there are words that would explain/define it
better..

apparently the topic would deserve something like FAQ [1] :-)
Jan

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



út 18. 12. 2018 v 20:07 odesílatel Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> napsal:

>
>
> Le mar. 18 déc. 2018 16:37, Jan Stránský  a
> écrit :
>
>>
>>
>> see my previous (slightly modified):
>> - assuming the particles rigid
>> - computing the force under assumption that in reality there would be no
>> overlap and some deformation.
>>
>
> This is self contradictory, no? What would be a model where you assume the
> contrary of what you consider reality and expected result?!
> By this statement you are efficiently killing the rigid assumption.
> Obviously it doesn't fit in the general picture and it it is useless.
> 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] Fixing the examples

[Jan Stránský]

Hmm, it seems you are right, but I don't remember at all creating such
example :-D so most likely I will be of no help fixing it..
Jan


st 23. 1. 2019 v 11:44 odesílatel Janek Kozicki  napsal:

> Jan Stránský said: (by the date of Tue, 22 Jan 2019 23:15:32 +0100)
>
> > > Chia Weng Boon wants to delete it, but you have written it.
> > no, maybe I have just made some changes..
>
>
> https://github.com/yade/trunk/commit/2b8f7b0a00de5573f126c6bcd0c5fb669deaf640
>
> I could not trace history back further than this :/
> Maybe you can help finding the real author ;)
>
> --
> Janek Kozicki
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Fixing the examples

[Jan Stránský]

> Chia Weng Boon wants to delete it, but you have written it.

no, maybe I have just made some changes..
Jan


út 22. 1. 2019 v 22:03 odesílatel Janek Kozicki  napsal:

> Hi Jan,
>
> could you also have a look at examples/PotentialParticles/basic.py ?
> Chia Weng Boon wants to delete it, but you have written it. Maybe
> there is a chance to recover it?
>
> best regards
> Janek
>
> Jan Stránský said: (by the date of Sun, 20 Jan 2019 21:44:29 +0100)
>
> > Hi Janek,
> >
> > thanks for the detailed look :-)
> >
> > > If you have any hints on how to fix any of those examples, please
> tell!
> >
> > several mentioned not working script is from me. I think than correcting
> > them and pushing to gitlab is better than telling :-)
> >
> > > Also I see that https://yade-dem.org/doc/tutorial-examples.html
> looks
> > very strange - the youtube videos are not shown
> >
> > I don't remember the reason (have read it long time ago), but the youtube
> > videos does work using http (not https) in the address
> >
> > cheers
> > Jan
> >
> >
> >
> > ne 20. 1. 2019 v 20:27 odesílatel Janek Kozicki 
> napsal:
> >
> > > Hi,
> > >
> > > I did small or cosmetic fixes in 17 examples.
> > > Currently 21% of examples (46 out of 215) are broken.
> > >
> > > I tried every example in a very quick manner. I checked if it has any
> > > explanations inside the comments, then I tried to just run it.
> > > It is possible that some of them failed only because they need a bit
> > > fiddling before starting them. In that case we need to explain the
> > > fiddling inside the file, in comments. And tell me what is the
> fiddling to
> > > do!
> > >
> > > If you have any hints on how to fix any of those examples, please tell!
> > >
> > > ResetRandomPosition.py
> > >  : SIGSEGV/SIGABRT handler called;
> > >  : gdb [with T = IGeomFunctor; typename
> > > boost::detail::sp_member_access::type = IGeomFunctor*]: Assertion
> `px !=
> > > 0' failed.
> > >
> > > DeformEngine/LOedometricDeform.py and OedometricDeform.py
> > >  : NameError: name 'DeformControl' is not defined
> > >
> > > FEMxDEM
> > >  : ImportError: No module named esys.escript
> > >  I am reading https://launchpad.net/escript-finley to fix this.
> > >
> > > HydroForceEngine/twoWayCoupling/postProcessing_sedim.py
> > >  : line:49 ValueError: operands could not be broadcast together with
> > > shapes (900,) (901,) (900,)
> > >
> > > LudingPM/LudingPM_1.py and LudingPM_2.py
> > >  : NewtonIntegrator: NaN force acting on #0.
> > >
> > > PotentialBlocks/WedgeYADE.py and cubePBscaled.py
> > > PotentialParticles/basic.py and cubePPscaled.py
> > >  : NameError: name 'PotentialBlock2AABB' is not defined
> > >  I will recompile with ENABLE_POTENTIAL_BLOCKS=ON and see if they work.
> > >
> > > agglomerate/simulation.py
> > >  : AttributeError: 'Body' object has no attribute 'agglomerate'
> > >
> > > capillary/liquidmigration/showcase.py
> > >  : NameError: name 'LiqControl' is not defined
> > >  I will recompile with LIQMIGRATION  and see if it works.
> > >
> > > clumps/save-load-clumps.py
> > >  : SIGSEGV/SIGABRT handler called; gdb
> > >  : Assertion `member->isClumpMember()' failed.
> > >
> > > deformableelem/Minimal.py
> > >  : the graphs are empty
> > >
> > > deformableelem/main.py
> > >  : I suppose this file is here by mistake ?
> > >
> > > jointedCohesiveFrictionalPM/packInGtsSurface.py and all other files
> > >  : spams terminal with messages: UnbalancedForce=-nan, rel stress nan
> > >
> > > mortar/modelTests/failureEnvelope.py
> > >  : MortarMat.cpp:12 go: MortarMat not implemented for non-cohesive
> contacts
> > >
> > > oar/sim.py
> > >  : KeyError: 'Invalid key: description.'
> > >
> > > sph/dam_break.py and all other files there
> > >  : AttributeError: No such attribute: KernFunctionPressure.
> > >  I will recompile with SPH and see if they work.
> > >
> > > test/WireMatPM/net-2part-strain.py
> > >  : UniaxialStrainer::action(): Assertion
> `posIds.size()==posCoords.size()
> > > && negIds.size()==negCoords.size() && originalLength>0 &&
> > > crossSectionArea>0' failed.
> > >  : SIGSEGV/SIGA

Re: [Yade-dev] Fixing the examples

[Jan Stránský]

Hi Janek,

thanks for the detailed look :-)

> If you have any hints on how to fix any of those examples, please tell!

several mentioned not working script is from me. I think than correcting
them and pushing to gitlab is better than telling :-)

> Also I see that https://yade-dem.org/doc/tutorial-examples.html looks
very strange - the youtube videos are not shown

I don't remember the reason (have read it long time ago), but the youtube
videos does work using http (not https) in the address

cheers
Jan



ne 20. 1. 2019 v 20:27 odesílatel Janek Kozicki  napsal:

> Hi,
>
> I did small or cosmetic fixes in 17 examples.
> Currently 21% of examples (46 out of 215) are broken.
>
> I tried every example in a very quick manner. I checked if it has any
> explanations inside the comments, then I tried to just run it.
> It is possible that some of them failed only because they need a bit
> fiddling before starting them. In that case we need to explain the
> fiddling inside the file, in comments. And tell me what is the fiddling to
> do!
>
> If you have any hints on how to fix any of those examples, please tell!
>
> ResetRandomPosition.py
>  : SIGSEGV/SIGABRT handler called;
>  : gdb [with T = IGeomFunctor; typename
> boost::detail::sp_member_access::type = IGeomFunctor*]: Assertion `px !=
> 0' failed.
>
> DeformEngine/LOedometricDeform.py and OedometricDeform.py
>  : NameError: name 'DeformControl' is not defined
>
> FEMxDEM
>  : ImportError: No module named esys.escript
>  I am reading https://launchpad.net/escript-finley to fix this.
>
> HydroForceEngine/twoWayCoupling/postProcessing_sedim.py
>  : line:49 ValueError: operands could not be broadcast together with
> shapes (900,) (901,) (900,)
>
> LudingPM/LudingPM_1.py and LudingPM_2.py
>  : NewtonIntegrator: NaN force acting on #0.
>
> PotentialBlocks/WedgeYADE.py and cubePBscaled.py
> PotentialParticles/basic.py and cubePPscaled.py
>  : NameError: name 'PotentialBlock2AABB' is not defined
>  I will recompile with ENABLE_POTENTIAL_BLOCKS=ON and see if they work.
>
> agglomerate/simulation.py
>  : AttributeError: 'Body' object has no attribute 'agglomerate'
>
> capillary/liquidmigration/showcase.py
>  : NameError: name 'LiqControl' is not defined
>  I will recompile with LIQMIGRATION  and see if it works.
>
> clumps/save-load-clumps.py
>  : SIGSEGV/SIGABRT handler called; gdb
>  : Assertion `member->isClumpMember()' failed.
>
> deformableelem/Minimal.py
>  : the graphs are empty
>
> deformableelem/main.py
>  : I suppose this file is here by mistake ?
>
> jointedCohesiveFrictionalPM/packInGtsSurface.py and all other files
>  : spams terminal with messages: UnbalancedForce=-nan, rel stress nan
>
> mortar/modelTests/failureEnvelope.py
>  : MortarMat.cpp:12 go: MortarMat not implemented for non-cohesive contacts
>
> oar/sim.py
>  : KeyError: 'Invalid key: description.'
>
> sph/dam_break.py and all other files there
>  : AttributeError: No such attribute: KernFunctionPressure.
>  I will recompile with SPH and see if they work.
>
> test/WireMatPM/net-2part-strain.py
>  : UniaxialStrainer::action(): Assertion `posIds.size()==posCoords.size()
> && negIds.size()==negCoords.size() && originalLength>0 &&
> crossSectionArea>0' failed.
>  : SIGSEGV/SIGABRT handler called; gdb
>
> test/batch/sim.py
>  : KeyError: 'Invalid key: description.'
>
> test/exact-rot-facet.py and exact-rot.py
>  : [with T = IGeomFunctor; typename
> boost::detail::sp_member_access::type = IGeomFunctor*]: Assertion `px !=
> 0' failed.
>  : SIGSEGV/SIGABRT handler called; gdb
>
> test/genCylLSM.py
>  : InsertGenerator3D::seedParticles
>  : bbx: -15 -15 -15 - 15 15 215
>  : SIGSEGV/SIGABRT handler called; gdb batch file is
>
> test/helix.py
>  : script runs and is not crashing, but nothing happens
>
> test/pack-predicates.py
>  : nothing happens, scene is empty
>
> test/paraview-spheres-solid-section/
>  yade export_text.py
>  apt install paraview-python
>  python pv_section.py
>  : Traceback (most recent call last):
>  : File "pv_section.py", line 29, in 
>  :   RenderView1.UseInteractiveRenderingForSceenshots = 0
>  : File "/usr/lib/python2.7/dist-packages/paraview/servermanager.py", line
> 307, in __setattr__
>  :   "to add this attribute.")
>  : AttributeError: Attribute UseInteractiveRenderingForSceenshots does not
> exist.  This class does not allow addition of new attributes to avoid
> mistakes due to typos. Use add_attribute() if you really want to add this
> attribute.
>
> test/psd.py
>  : the scene is empty, apparently makeCloud didn't do anything. Or I would
> have to wait longer.
>
> test/qt4-attributes.py and qt4-pyqglviewer.py
>  : Error: already imported an Incompatible QT Binding: pyqt5
>  I will try to convert this to qt5
>
>
> test/remove-body.py
>  : AttributeError: No such attribute: nBins
>
> test/shear.py
>  : sp_member_access::type = IGeomFunctor*: Assertion `px != 0' failed
>  : SIGSEGV/SIGABRT handler called; gdb
>
> test/test_Ip2_FrictMat_CpmMat_FrictPhys.py
>  : After collision 

Re: [Yade-dev] [Yade-users] [Question #676841]: the definition of porosity

[Jan Stránský]

>> I like my point of view very much :-) ...
> No luck then. :(

it was just explanation why I did the answer. In general I agree with both
options, just wanted to "defend" my approach.
I also think we come to philosophy area in many places here :-) especially
because finally one arrives to the same results and formulas from both
sides.

>>> I would suggest that Cundall/Yade DEM makes no assumption of
rigidity/overlaps.
>> but does not make any assumption on non-rigidity at the same time,
right? :-)
> It does. Starting from an elastic force-displacement equation in the
first place really implies non-rigidity.

see my previous (slightly modified):
- assuming the particles rigid
- computing the force under assumption that in reality there would be no
overlap and some deformation.
Then the elastic force-displacement equation just computes force assuming
some deformation in reality, but the model of particle may remain rigid.

>> Relative motion between bodies says nothing about (non)rigidity of the
bodies, or?
> If you have a sticking (elastic) contact it means two material points
from two different objects are co-moving. If at the same time the reference
position-orientation of the inertial frames attached to each particle are
not undergoing rigid body motion the only solution is that there is an
internal deformation somewhere.

Relative motion is just relative motion. You can define it both for rigid
and deformable particles. In both cases it is just a consequence of the
previous paragraph and decision if particles are or are not rigid :-)

> But my claim is that there is not one context in which the geometrical
overlap would be justified.
> Can you evaluate this volume change by the overlaps? NO! Absolutely not.
> Overlapped volume is not an approximation of anything.

Yes, I agree that from physical point of view, the "purely geometrical"
overlaps does not make much sense. In the launchpad question I just
described how I would do it, but with no experience in the topic..
But it would be nice to actually compare this geometrical and physical
approaches :-) maybe "by chance" the geometrical (non-pysical) overlap
justification is not that far from physical evaluation, even for the first
sight there is no reason for it (I have a fresh experience with something
similar).

cheers
Jan
___
Mailing list: https://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 #676841]: the definition of porosity

[Jan Stránský]

Hi Bruno,

A) I am currently not so active contributor, so I do not insist on my point
of view
B) I like my point of view very much :-) and it makes to me much more sense
and I wanted to present it here

as I understand DEM and always explained it is that:
1) DEM represents material as a set of perfectly rigid particles whose
motion is governed by Newton's second law.
2) Based on particles' mutual motion, interparticle forces are computed
according to constitutive laws.
3) Just after there would be a picture of overlapping particles emphasizing
the overlapping volume/area and explanation that in reality there would be
no overlap but a repulsive force, which is computed by the constitutive law
somehow according to that overlap
4) Interparticle forces are put into equations of motion and numerically
integrated.
5) final note that DEM is "nothing more" :-) and that very large amount of
variants are formed using different particle shapes, constitutive laws and
some other extensions (bonded particles.)

I think it is dual to the point of view presented by you and they are
nicely interchangable.
However, I think my point of view is more natural and easier to understand
and accept some other assumptions.

The fact that deformations are not plotted nor taken into account in
NewtonIntegrator IMO supports my point of view.

> It would be better if we could speak the same language in answers

100% agreement

> I would suggest that Cundall/Yade DEM makes no assumption of
rigidity/overlaps.

but does not make any assumption on non-rigidity at the same time, right?
:-)

> The notion of overlap is misleading and should be avoided. I usually
speak of normal displacement wrt. equilibrium state, instead.

This applies to spherical shapes. More general shapes can change their
overlap just by rotation.
On the other hand, rigid particles assumption and word overlap express
exactly what one (or at least me :-) would expect.

> In contact models it is admitted that the bodies are not rigid, since
there can be relative motion between bodies in contact.

Relative motion between bodies says nothing about (non)rigidity of the
bodies, or?

> Hertz-Mindlin is a perfect example, it is directly accounting for
internal deformation, and it is derived on the basis that solid surfaces
*cannot* overlap.
> The other models can be seen as linearizations of HM, and along this line
they don't introduce overlaps either.

see point 3) at the beginning. This can be also achieved using the dual
approach: assuming the particles rigid, but computing the force under
assumption that in reality there would be no overlap.

> The fact is that we never display deformed shapes of particles. We could
in some cases (with HM at least), and then the spheres would appear with
surface deflection instead of overlaps. It would be painful to implement
and rendering would be much slower, but virtually it can be done. Hence why
overlap is just a geometrical artifact. It is not needed in the governing
equations, it only appears as a byproduct of graphical display.

Or a dual view: particle overlap is intrinsic feature of the method and
deformation just computational artifact :-) which can easily be done in a
post-processing stage.

> Rejecting the notion of overlap is I think the only way to escape
classical ill-posed questions on porosity. "Should overlapped volumes be
removed?"

Such question always needs a close context. Missing context is IMO making
it most ill-posed.
- I have a loose packing and by some normal compression make it denser. Do
I need to bother with overlaps while computing porosite? Most likely not
- I have a dense assembly by triaxial compression I squeeze it ti 2/3 of
its original volume.. probably in this case it makes sense to somehow treat
overlap/deformation.

> What is the change of volume of a compressed contact then? Well, HM tells
you exactly the volume change as part of the closed form solution.

Well, you always have some limit on accuracy.
HM tells the volume change for one sphere-sphere contact, but many contacts
with "big" overlaps would influence each other and you again ends with an
approximation.
I see three levels of usage (depending on context):
a) you don't take into account overlaps/deformation at all
b) you compute exactly "geometrical" porosity (applicable only on rigid
body assumption) excluding the overlapping volume of rigid particles
c) you compute porosity based on constitutive law (which may be HM based or
may fall to case b) "by default")

> But in any case, the overlapping volume is irrelevant to physics.

Yes. But in "my" point of view, it is an input for the constitutive law :-)

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

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

[Jan Stránský]

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

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

cheers
Jan


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

> Hi,
>
> I have started working on the "PotentialBlock" code in YADE for the
> generation of polyhedra using the Potential Particles approach. I want to
> use these particles in a periodic cell, but it seems the PotentialBlock
> class is not compatible with periodic boundaries. Would be grateful to get
> any advice on whether this is the case and where I should focus to
> implement it myself? (FYI I am still a rookie in C++ development).
>
>
>
> In the following lines I paste a minimal working script to demonstrate a
> potential block falling through the periodic cell.
> Visualisation of the simulation is available only in a VTK format (not in
> qt).
>
>
> Cheers,
>
>
>
> Vasileios
>
>
>
> Vasileios Angelidakis
>
> Post-Graduate Researcher in Geotechnical Engineering
>
> School of Engineering, Newcastle University
>
>
>
> The script:
>
>
> from yade import pack
> import math
>
> # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
> # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
> # Clear the directory where the VTK results will be written of all files
> (but not subdirectories).
> # The directory is cleared, so files from previous runs do not interfere
> with files from new runs.
> # If the directory does not exist, it is created.
>
> import os, shutil
> folder = './vtk_ele'
> try:
> os.mkdir(folder[2:])
> except:
> for the_file in os.listdir(folder):
> file_path = os.path.join(folder, the_file)
> try:
> if os.path.isfile(file_path):
> os.unlink(file_path)
> #elif os.path.isdir(file_path): shutil.rmtree(file_path)
> #uncomment to also delete the subdirectories
> except Exception as e:
> print(e)
> # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
> # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
>
>
>
> # Engines
> O.engines=[
> ForceResetter(),
> InsertionSortCollider([PotentialBlock2AABB()],verletDist=0.01),
> InteractionLoop(
> [Ig2_PB_PB_ScGeom()],
> [Ip2_FrictMat_FrictMat_KnKsPBPhys(kn_i=1e8, ks_i=1e8, Knormal =
> 1e8, Kshear = 1e8, useFaceProperties=False, calJointLength=False,
> twoDimension=False, unitWidth2D=1.0, viscousDamping=0.05)],
> [Law2_SCG_KnKsPBPhys_KnKsPBLaw(label='law',neverErase=False)]
> ),
>
>  NewtonIntegrator(damping=0.0,exactAsphericalRot=False,gravity=[0,-10,0]),
>
>  
> VTKRecorder(fileName=folder+'/vtkPeriodicCell-VTKRecorder-',recorders=['pericell'],iterPeriod=200)
> ]
>
> # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
> # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
>
>
>
> # Basic dimensions used in the model
> distanceToCentre= 0.5
> meanSize = 1.0
> heightOfBase = 5.0*meanSize
>
> # Material definition
> powderDensity = 2000
>
> O.materials.append(FrictMat(young=150e6,poisson=.4,frictionAngle=radians(0.0),density=powderDensity,label='frictionless'))
>
> # Creation of a spheres packing, following a desired PSD
> sp=pack.SpherePack()
>
> mn,mx=(Vector3(0,0,0),
>Vector3(4*heightOfBase, 4*heightOfBase, 4*heightOfBase))
>
> sphereRad = sqrt(3.0)*0.5*meanSize
> sp.makeCloud(mn,mx,sphereRad,0,10,periodic=True)
>
> # Replacement of the spheres with cuboids
> count= 0
> rPP=0.05*meanSize
> for s in sp:
> b=Body()
> dynamic=True
> wire=False
> color=[0,0,255.0]
> highlight=False
> b.shape=PotentialBlock(
> k=0.2, r=0.05*meanSize, R=1.02*sphereRad,
> a=[1.0,-1.0,0.0,0.0,0.0,0.0],
> b=[0.0,0.0,1.0,-1.0,0.0,0.0],
> c=[0.0,0.0,0.0,0.0,1.0,-1.0],
> d=[distanceToCentre-rPP,distanceToCentre-rPP,distanceToCentre-rPP,distanceToCentre-rPP,distanceToCentre-rPP,distanceToCentre-rPP],
> isBoundary=False, color=color, wire=wire, highlight=highlight,
> minAabb=Vector3(1.0*sphereRad,1.0*sphereRad,1.0*sphereRad),
> maxAabb=Vector3(1.0*sphereRad,1.0*sphereRad,1.0*sphereRad),
> maxAabbRotated=Vector3(1.0*sphereRad,1.0*sphereRad,1.0*sphereRad),
> minAabbRotated=Vector3(1.0*sphereRad,1.0*sphereRad,1.0*sphereRad),
> AabbMinMax=True,fixedNormal=False)
>
> length=meanSize
> V= 1.0
> geomInert=(2./5.)*powderDensity*V*sphereRad**2
> utils._commonBodySetup(b,V,Vector3(geomInert,geomInert,geomInert),
> material='frictionless',pos=s[0],  dynamic=True, fixed=False)
> b.state.pos = s[0] #s[0] stores center
> b.state.ori =
> Quaternion((random.random(),random.random(),random.random()),random.random())
> #s[2]
> b.state.mass =V*powderDensity
> O.bodies.append(b)
> b.dynamic = True
> count =count+1
>
> # # # 

[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop

[Jan Stránský]

Hi Jerome,

to find where the segfault problem comes from, you can run
catchsegv yade script.py
the output tells the last actions before the segfault.
If the output is too long, you can try
catchsegv yade script.py > /tmp/segv.err
or
catchsegv yade script.py 2> /tmp/segv.err
(don't remember) and provde the segv.err file

cheers
Jan

PS: this is exactly the point I mentioned in [1]. If you use these
functions in C++, using boost::python stuff is extra, std::vector should
be used instead of boost::python::tuple and the buust::python stuff
should only be used to interact with Python :-)

[1] https://www.mail-archive.com/yade-
d...@lists.launchpad.net/msg13300.html

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

Title:
  Segfaults with boost::python::tuple during simulation loop

Status in Yade:
  New

Bug description:
  Hi,

  I'm currently facing segmentation fault when using "my"
  MeasureCapStress post-processing engine (this constitutes a
  regression..).

  A example script appears at the end of this message (it's better,
  though not necessary here, to have the capillary files from
  https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I
  get the crash with the trunk version as of today or yadedaily (for
  instance), and having Python 2.7.12 installed on my machine.


  There is some random pattern in the way crashs occur, with e.g. the following 
messages:
  - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 
***
  followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted 
(core dumped)"
  - or just "Segmentation fault (core dumped)"
  that appear after a variable number (not much, though) of iterations.

  It seems also possible to go through a greater number of iterations by
  hand-clicking on GUI step button than by asking O.run()...


  Anyway, the crash seems to occur during (or just after) the definition
  of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at
  [*].

  I'm quite puzzled by all this, would someone have an idea ?
  Is there any particular (de-allocating ?) practice to follow when using such 
Python-C interfaced variables in the C++ code ?


  Thank you very much,

  Jerome

  
  ### Script example ###
  # two contacting particles with a capillary bridge inbetween. Segfaults 
because of MeasureCapStress on my machine
  r1,r2 = 1e-4,4e-4
  z1,z2=0,0.95*(r1+r2)

  O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0))
  O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0))

  O.engines=[ForceResetter()
 ,InsertionSortCollider([Bo1_Sphere_Aabb()])
 ,InteractionLoop(
 [Ig2_Sphere_Sphere_ScGeom()],
 [Ip2_FrictMat_FrictMat_CapillaryPhys()],
 [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)]
 )
 ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3)
 ,NewtonIntegrator()
 ,GlobalStiffnessTimeStepper()
 ,MeasureCapStress(iterPeriod=1)
]

  O.run()
  ### End of script example ###

  
  [*] 
https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. 
While another boost:python: appears L64, it seems L63 is enough to cause the 
crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" 
(making L63 useless but still annoying enough to cause the crash)

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

[Jan Stránský]

Hi Bruno,

answering here not to pollute the original question [1].

You can impose the velocity of the piston as b.state.vel=(x,y,z) after
> setting b.state.blockedDOFs='xyzXYZ'. You then make it zero in the begining
> and change for something else at some point.
> TranslationEngine makes this simple thing excessively complex in my
> opinion. I would suggest to forget it (*).
> Bruno
> (*) and even to remove it from source code for its anti-didactic effect,
> to keep only truly involved helico-rotational motion engines present


I agree that for single body / a few bodies, blockedDOFs + setting vel is
much more easier and that TranslationEngine has anti-didactic effect.

I disagree with removing it from source code (if you don't mean just
examples, there yes). TranslationEngine is IMO more appropriate for
multiple bodies. You can also use dead=True/False easily etc.
Also it is useful for CombinedKinematicEngine (although a new very general
kinematic engine altering current functionality could be implemented).

cheers
Jan

[1] https://answers.launchpad.net/yade/+question/671132
___
Mailing list: https://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 _utils.hpp and Shop.hpp ? Shop::getPorosity vs Shop__getPorosity

[Jan Stránský]

Hi Jerome,

below please find my opinion. If the approach proposed by you works and
does not break existing code (or it is not easy to fix it), I would have
nothing against the refactoring.


What is the reason for having (for instance) Shop__getPorosity() in
> py/_utils.hpp/cpp and Shop::getPorosity() in pkg/dem/Shop.hpp / Shop_01.cpp
> ?


In **my opinion**:
1) Shop functions should be C++ only, not returning or accepting
boost::python stuff. The python stuff (like converting std::vector to
python tuple/list or modifying input/output like [1]) is (should be) the
reason for py/_utils existence.
2) In the same way, there should not be non-python function in py/_utils
(should be moved to Shop).
Not 1) nor 2) is the case now..

Maybe the scene as argument is left from the past and it is safe to remove
it?

I wanted to write that another reason could be compatibility, because come
functions are named differently in C++and python (e.g. bodyStressTensor
and getStressLWForEachBody), but this is irrelevant since you can have any
name for python functions (put here for backward reference if anybody has
the same idea :-)


having py/_utils.*pp in addition to pkg/dem/Shop*


Both following comments are extensions of my first paragraph

There are some "python wrapping", see e.g. [1], where the inputs and return
types are a bit modified to be more user friendly (you don't need to create
a Material first, pass it to function and dig data from it, a plain dict is
returned).

But more importantly, to be able to have these Shop functions in Python,
you need some boost::python tricks, which IMO should be placed in a
separate file, so py/_utils.*pp would stay anyway (although it could be
cleaner).


cheers
Jan

[1] https://github.com/yade/trunk/blob/master/py/_utils.cpp#L111



2018-07-16 11:21 GMT+02:00 Jerome Duriez :

> Hi,
>
> What is the reason for having (for instance) Shop__getPorosity() in
> py/_utils.hpp/cpp and Shop::getPorosity() in pkg/dem/Shop.hpp / Shop_01.cpp
> ?
>
> I can see the latter has "scene" as an argument [1] in addition to
> "volume" (contrary to the former [2]), but probably this could be removed
> from the definition, always using Omega::instance().getScene() in the
> implementation [3] ? So, I'm not sure this is the reason
>
> Is this for Python wrapping ? Could we not use Shop::getPorosity (once we
> removed the scene argument) at https://github.com/yade/trunk/
> blob/master/py/_utils.cpp#L463 ?
>
>
> The same question goes for many other functions, I guess, and the general
> philosophy behind having py/_utils.*pp in addition to pkg/dem/Shop*
>
> Thank you,
>
> Jérôme
>
>
> [1] https://github.com/yade/trunk/blob/master/pkg/dem/Shop.hpp#L56
> [2] https://github.com/yade/trunk/blob/master/py/_utils.hpp#L123
> [3] just modifying https://github.com/yade/trunk/
> blob/master/pkg/dem/Shop_01.cpp#L300
>
> --
> Chargé de Recherche / Research Associate
> Irstea, RECOVER
> 3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
> +33 (0)4 42 66 99 21
>
>
> ___
> Mailing list: https://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] About pastebin and data files in launchpad questions

[Jan Stránský]

I agree too,

I would add a note that the problem might be solved by the process of
creating MWE..

> Jan is probably too kind for that ;-)

well, it annoys me more and more, too, so I will at least answer with delay
:-)

cheers
Jan


2018-06-29 14:09 GMT+02:00 Jerome Duriez :

> Hi all,
>
> I agree Bruno with your description of the annoying extra efforts that are
> required to try to help with such questions. As far as I am concerned, I do
> not try downloading things and help in these cases...
>
> My first suggestion would be to further push users to propose (for real
> !!!) minimal working examples, but I think the only efficient way to do
> this would be not answering many of the questions and Jan is probably too
> kind for that ;-)
>
> Anyway, I think myself it sounds realistic to ask users to avoid extra
> files in their MWE, and do not have any other suggestions..
>
>
> Jérôme
>
> --
> Chargé de Recherche / Research Associate
> Irstea, RECOVER
> 3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
> +33 (0)4 42 66 99 21
>
> On 29/06/2018 12:33, Bruno Chareyre wrote:
>
> Hi Yade devs,
> When I try to save a few minutes to answer some questions I very ofen find
> myself clicking here and there to access a pastebin file which is needed
> for a given script to run. The [pastebin|whateve|...] file can't downloaded
> directly in many cases. I then have to copy - which can imply substantial
> scrooling, paste, save in the right place, go back to terminal, run.
> And sometimes it is just to find that the script itself will not run, even
> with the proper data file.
>
> If you want to see this cycle in action you can have a look at [1] where
> four posts more or less are just to sort out the data files, implying than
> Jan had to repeatedly reproduce the cycle mentioned above. Worth
> mentioning, post #11 introduces additional links for the same filenames
> (same content? who knows?), so it is absolutely unclear now what someone is
> supposed to download to simply test a script and help someone else.
>
> I was thinking that we could go deeper in the MWE part of
> https://yade-dem.org/wiki/Howtoask, to push questionners toward
> self-contained scripts.
> An issue is that even among the devs I see this tendency to manipulate
> data files.
> There are a few cases where it can't be avoided, like stl mesh. But in
> most cases I think a data file is not needed MWE, specifically for sphere
> positions and clump data (which are just positions).
> What do you think? Does it sound realistic to ask users to avoid extra
> files in MWEs?
>
> We could even provide a way to make sure that no "file not found" will
> occur. For instance, every mwe.py should be compatible with:
> mkdir MWE
> cp mwe.py ./MWE/mweTest.py
> cd MWE
> /path/to/yade mweTest.py
> rm -rf ../MWE
>
> Other suggestions?
>
> Bruno
>
> [1] https://answers.launchpad.net/yade/+question/670501
>
>
>
> ___
> Mailing list: https://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 1738747] Re: ymport.unv - global name 'facets' is not defined

[Jan Stránský]

Hello Jouny,
thanks for reporting the bug, I have fixed it [1].
As Bruno pointed, next time please provide more info (like I have tried this 
example, I have tried the code below, I use this version of yade etc.)
cheers
Jan

[1]
https://github.com/yade/trunk/commit/925f7358f89e17ddfa91ee4b657a3cc6f10440e7


** Changed in: yade
   Status: Incomplete => Fix Committed

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

Title:
  ymport.unv - global name 'facets' is not defined

Status in Yade:
  Fix Committed

Bug description:
  Probably the missing instance 'unvReader' before its member 'facets'
  in the return value of the function.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1738747/+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 1666838] [NEW] aperiodic randomDensePack huge overlaps and strange behavior

[Jan Stránský]

Public bug reported:

Based on question https://answers.launchpad.net/yade/+question/473518, I
did some simple tests using Yade 1.20.0 on Ubuntu 16.04


from yade import pack
pred=pack.inAlignedBox((0,0,0),(2,1,1))
spheres=pack.randomDensePack(pred, radius=0.1)
O.bodies.append(spheres)
O.step()
print max(i.geom.penetrationDepth for i in O.interactions)
O.bodies.append(box((1,.5,.5),(1,.5,.5),wire=True))


I got:
- packing smaller than predicate
- huge overlaps: r=0.1, max penetrationDepth=0.09 (!)

playing with cropLayers and dim parameters did not help much (especially
concerning the overlaps).

Am I missing something, or is the default behavior that bad?

cheers
Jan

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

Title:
  aperiodic randomDensePack huge overlaps and strange behavior

Status in Yade:
  New

Bug description:
  Based on question https://answers.launchpad.net/yade/+question/473518,
  I did some simple tests using Yade 1.20.0 on Ubuntu 16.04

  
  from yade import pack
  pred=pack.inAlignedBox((0,0,0),(2,1,1))
  spheres=pack.randomDensePack(pred, radius=0.1)
  O.bodies.append(spheres)
  O.step()
  print max(i.geom.penetrationDepth for i in O.interactions)
  O.bodies.append(box((1,.5,.5),(1,.5,.5),wire=True))
  

  I got:
  - packing smaller than predicate
  - huge overlaps: r=0.1, max penetrationDepth=0.09 (!)

  playing with cropLayers and dim parameters did not help much
  (especially concerning the overlaps).

  Am I missing something, or is the default behavior that bad?

  cheers
  Jan

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1666838/+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 1654753] [NEW] getStress does not fail for non NormShearPhys intrs

[Jan Stránský]

Public bug reported:

Hello,
As reporetd in [1], BubblePhys (directly derived from IPhys) passes getStress 
without error. In the function, 
NormShearPhys* nsi=YADE_CAST ( I->phys.get() );
nsi->shearForce is used, however it is something strange now in that case..

Should be fixed for this minor case (as majority of IPhys classes is
derived from NormShearPhy)?

cheers
Jan

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

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

Title:
  getStress does not fail for non NormShearPhys intrs

Status in Yade:
  New

Bug description:
  Hello,
  As reporetd in [1], BubblePhys (directly derived from IPhys) passes getStress 
without error. In the function, 
  NormShearPhys* nsi=YADE_CAST ( I->phys.get() );
  nsi->shearForce is used, however it is something strange now in that case..

  Should be fixed for this minor case (as majority of IPhys classes is
  derived from NormShearPhy)?

  cheers
  Jan

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1654753/+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 1652529] [NEW] segmentation fault (core dumped)

[Jan Stránský]

Hi Amiya,
thanks for the report. We will try to find the problem, but first we need a
MWE, a mininal WORKING script. The one you provided ends with SyntaxError
because of the first "else" statement.
You can attach files to bug reports, so if you attached the script directly
as a file, it would be perfect
Thanks
Jan

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

Title:
  segmentation fault (core dumped)

Status in Yade:
  New

Bug description:
  Hi I am trying to run this code, which is an example given in the
  package. But every time i try to execute this file, i get segmentation
  fault error. I am using Ubuntu 16.04 LTS and Yade 2016.06a

  
  #!/usr/bin/python
  # -*- coding: utf-8 -*-

  """
  To run this script you need to have all 10 text files from 
https://yade-dem.org/wiki/CapillaryTriaxialTest
  in the same folder as you run this script in console!

  This script shows how to use Law2_ScGeom_CapillaryPhys_Capillarity. The user 
can switch between hertz and 
  linear model by setting "model_type"
  """

  model_type  = 1 #1=Hertz model with capillary forces,
  else linear model with capillary model

  #some parameters:
  shear_modulus = 1e5
  poisson_ratio = 0.3
  young_modulus = 2*shear_modulus*(1+poisson_ratio)
  friction  = 0.5
  angle = atan(friction)
  local_damping = 0.01
  viscous_normal= 0.021
  viscous_shear = 0.8*viscous_normal
  lowercorner   = Vector3(0,0,0)
  uppercorner   = Vector3(0.002,0.002,0.004)

  #creating a material (FrictMat):
  
id_SphereMat=O.materials.append(FrictMat(young=young_modulus,poisson=poisson_ratio,density=2500,frictionAngle=angle))
  SphereMat=O.materials[id_SphereMat]

  #generate particles:
  sp=pack.SpherePack()
  sp.makeCloud(lowercorner,uppercorner,.0002,rRelFuzz=.3)
  O.bodies.append([sphere(c,r,material=SphereMat) for c,r in sp])

  #generate boundary:
  
O.bodies.append(geom.facetBox(uppercorner/2,uppercorner/2,wire=True,fixed=True,material=SphereMat))

  #define engines:
  if model_type == 1:#hertz model with capillary forces
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom()],

[Ip2_FrictMat_FrictMat_MindlinCapillaryPhys(label='ContactModel')],#for hertz 
model only
[Law2_ScGeom_MindlinPhys_Mindlin()]#for hertz model only
),

Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1),#for hertz model 
only
NewtonIntegrator(damping=local_damping,gravity=(0,0,-9.81)),
]
ContactModel.betan=viscous_normal
ContactModel.betas=viscous_shear
ContactModel.useDamping=True
  else:
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_CapillaryPhys()],#for 
linear model only
[Law2_ScGeom_FrictPhys_CundallStrack()],#for 
linear model only
),

Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1),#for linear 
model only
NewtonIntegrator(damping=local_damping,gravity=(0,0,-9.81)),
]

  #set time step and run simulation:
  O.dt=0.5*PWaveTimeStep()

  from yade import qt
  qt.View()
  print('Press PLAY button')
  #O.run(1,True)

  
  looking forward to hear soon..!!

  Cheers
  Amiya

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1652529/+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] Frequency of documentation update

[Jan Stránský]

Ok, thanks for explanation.
Jan

PS: I was positively surprised, that github itself renders the .rst files
nicely [1]
[1] https://github.com/yade/trunk/blob/master/doc/sphinx/user.rst


2016-11-16 19:35 GMT+01:00 Anton Gladky :

> 2016-11-16 17:58 GMT+01:00 Bruno Chareyre  >:
> > We are actually changing this at the moment. If I'm not wrong (still
> > possible because it is a bit intricate): previously the builds were
> > triggered manually, by Anton, then the doc uploaded and yadedaily
> released.
>
> Buildbot built and uploaded the documentation. Yadedaily builds only
> offline documentation for packages.
>
> 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] Frequency of documentation update

[Jan Stránský]

Hello,

some time ago, I modified tutorial by replacing L3Geom by ScGeom, the
change appeared on the web very quickly.

I a different commit, I updated user's manual, but the modification is not
yet present..

How often is the documentation updated and/or should one do something
manually to make the user's manual be current version?

thanks
Jan

[1]
https://github.com/yade/trunk/commit/660c5d6ac9a2db90dc8a174012135337169964b4
[2]
https://github.com/yade/trunk/commit/d18e6f462b0453f5e475eb2a9c4d30fee7aeeeff
___
Mailing list: https://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 1634434] [NEW] Tutorial example script 04-periodic-simple-shear.py does not work

[Jan Stránský]

Public bug reported:

limitMeanStress=-5e5
...
if stress.trace()/3.https://bugs.launchpad.net/bugs/1634434

Title:
  Tutorial example script 04-periodic-simple-shear.py does not work

Status in Yade:
  New

Bug description:
  limitMeanStress=-5e5
  ...
  if stress.trace()/3.https://bugs.launchpad.net/yade/+bug/1634434/+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] Block Generation, Contact Detection, Rock Bolt and Rock Lining

[Jan Stránský]

Hi Boon,
thanks for the answer. I will try to have a look on the graphics of
potential blocks, will inform you if I am successful.

If you find some time, could you please check if the potential particles I
added a few moths ago works OK? I did some modifications in the code and am
not sure if I did not break something..

Regards
Jan


2016-09-27 15:39 GMT+02:00 Chia Weng Boon <chiaw...@gmail.com>:

> Yes.  Thanks Jan. Your contribution to the Graphics implementation of
> Potential Blocks will be appreciated (now using vtk exporting to
> ParaView).  I understand YADE has polyhedron display.
>
> Boon
>
> On Tue, Sep 27, 2016 at 4:01 PM, Jan Stránský <honzik.stran...@gmail.com>
> wrote:
>
>> Hi Boon,
>>
>> What is the current situation? Did I get it correctly that you managed to
>> insert your code in Yade trunk on your own?
>> Is there something I can help with (sorry, I was still a bit busy)?
>>
>> Thanks for the update
>> Jan
>>
>>
>> 2016-09-18 12:41 GMT+02:00 Chia Weng Boon <chiaweng.b...@oxfordalumni.org
>> >:
>>
>>> Realised that this info is required.  In CMakeCache.txt:
>>>
>>> CLP2_INCLUDE_DIR:PATH=/home/boon/coin-Clp/lib/pkgconfig
>>>
>>> CLP2_LIBRARY:FILEPATH=/home/boon/coin-Clp/Clp/src/.libs/libClpSolver.so
>>>
>>> CLP3_INCLUDE_DIR:PATH=/home/boon/coin-Clp/CoinUtils/src
>>>
>>> CLP3_LIBRARY:FILEPATH=/home/boon/coin-Clp/Clp/src/OsiClp/.li
>>> bs/libOsiClp.so
>>>
>>> CLP4_LIBRARY:FILEPATH=/home/boon/coin-Clp/lib/libCoinUtils.so
>>>
>>> CLP_INCLUDE_DIR:PATH=/home/boon/coin-Clp/Clp/src
>>>
>>> CLP_LIBRARY:FILEPATH=/home/boon/coin-Clp/Clp/src/.libs/libClp.so
>>>
>>>
>>> However, it is better to get CLP from the packages, as suggested by
>>> Bruno.  Now there is a compiling error in my PC, even for the fresh clean
>>> latest checkout from trunk.  Posted about that in another thread.
>>>
>>>
>>> Boon
>>> --
>>> *From:* Bruno Chareyre <bruno.chare...@3sr-grenoble.fr>
>>> *Sent:* Monday, September 12, 2016 8:29:11 PM
>>> *To:* Chia Weng Boon; Jan Stránský
>>> *Cc:* s.ut...@warwick.ac.uk; yade-dev@lists.launchpad.net
>>>
>>> *Subject:* Re: [Yade-dev] Block Generation, Contact Detection, Rock
>>> Bolt and Rock Lining
>>>
>>> Dear Boon,
>>> From now on I would suggest to communicate through the yade-dev mailing
>>> list.
>>> Packaging CLP *with* Yade (if you really meant to include CLP in yade
>>> source) is not an option as it would progressively diverge from the main
>>> version.
>>> CLP should be installed independently of Yade via package manager, just
>>> like every other library yade is using.
>>> Cheers
>>> Bruno
>>>
>>> On 09/12/2016 08:46 AM, Chia Weng Boon wrote:
>>>
>>> Dear Jan,
>>>
>>> Thanks for your reply.  The codes developed during my PhD and based on
>>> integration efforts in March:
>>>
>>>
>>> Potential Particles:
>>>
>>> https://drive.google.com/open?id=0BzNu2_9w6dfwYmRYM25UdFhZRmc
>>>
>>>
>>> Potential Blocks:
>>>
>>> https://drive.google.com/open?id=0BzNu2_9w6dfwdlN4N0tEcDBoUnM
>>>
>>>
>>> They should compile and run fine (March version).   I would imagine
>>> further integration effort is desirable to maintain coherence of the
>>> programming style, but not mandatory for running the code, if time is
>>> limited for you.  Of course packaging CLP with YADE in the next release
>>> might take some effort. Thanks Jan again.
>>>
>>>
>>> Thanks,
>>>
>>> Boon
>>> --
>>> *From:* Jan Stránský <honzik.stran...@gmail.com>
>>> <honzik.stran...@gmail.com>
>>> *Sent:* Friday, September 9, 2016 8:16:56 PM
>>> *To:* Chia Weng Boon
>>> *Cc:* bruno.chare...@3sr-grenoble.fr; s.ut...@warwick.ac.uk;
>>> yade-dev@lists.launchpad.net; chiaw...@gmail.com; Chia Weng Boon
>>> *Subject:* Re: [Yade-dev] Block Generation, Contact Detection, Rock
>>> Bolt and Rock Lining
>>>
>>> Dear all,
>>> sorry for not responding, I am completely out of time until Sep 17. Then
>>> I hope I will have some time on this topic.
>>>
>>> @Boon: for the sake of clarity, could you please send once more all the
>>> files that needs to be integrated (even if you

Re: [Yade-dev] Block Generation, Contact Detection, Rock Bolt and Rock Lining

[Jan Stránský]

Hi Boon,

What is the current situation? Did I get it correctly that you managed to
insert your code in Yade trunk on your own?
Is there something I can help with (sorry, I was still a bit busy)?

Thanks for the update
Jan


2016-09-18 12:41 GMT+02:00 Chia Weng Boon <chiaweng.b...@oxfordalumni.org>:

> Realised that this info is required.  In CMakeCache.txt:
>
> CLP2_INCLUDE_DIR:PATH=/home/boon/coin-Clp/lib/pkgconfig
>
> CLP2_LIBRARY:FILEPATH=/home/boon/coin-Clp/Clp/src/.libs/libClpSolver.so
>
> CLP3_INCLUDE_DIR:PATH=/home/boon/coin-Clp/CoinUtils/src
>
> CLP3_LIBRARY:FILEPATH=/home/boon/coin-Clp/Clp/src/OsiClp/.
> libs/libOsiClp.so
>
> CLP4_LIBRARY:FILEPATH=/home/boon/coin-Clp/lib/libCoinUtils.so
>
> CLP_INCLUDE_DIR:PATH=/home/boon/coin-Clp/Clp/src
>
> CLP_LIBRARY:FILEPATH=/home/boon/coin-Clp/Clp/src/.libs/libClp.so
>
>
> However, it is better to get CLP from the packages, as suggested by
> Bruno.  Now there is a compiling error in my PC, even for the fresh clean
> latest checkout from trunk.  Posted about that in another thread.
>
>
> Boon
> --
> *From:* Bruno Chareyre <bruno.chare...@3sr-grenoble.fr>
> *Sent:* Monday, September 12, 2016 8:29:11 PM
> *To:* Chia Weng Boon; Jan Stránský
> *Cc:* s.ut...@warwick.ac.uk; yade-dev@lists.launchpad.net
>
> *Subject:* Re: [Yade-dev] Block Generation, Contact Detection, Rock Bolt
> and Rock Lining
>
> Dear Boon,
> From now on I would suggest to communicate through the yade-dev mailing
> list.
> Packaging CLP *with* Yade (if you really meant to include CLP in yade
> source) is not an option as it would progressively diverge from the main
> version.
> CLP should be installed independently of Yade via package manager, just
> like every other library yade is using.
> Cheers
> Bruno
>
> On 09/12/2016 08:46 AM, Chia Weng Boon wrote:
>
> Dear Jan,
>
> Thanks for your reply.  The codes developed during my PhD and based on
> integration efforts in March:
>
>
> Potential Particles:
>
> https://drive.google.com/open?id=0BzNu2_9w6dfwYmRYM25UdFhZRmc
>
>
> Potential Blocks:
>
> https://drive.google.com/open?id=0BzNu2_9w6dfwdlN4N0tEcDBoUnM
>
>
> They should compile and run fine (March version).   I would imagine
> further integration effort is desirable to maintain coherence of the
> programming style, but not mandatory for running the code, if time is
> limited for you.  Of course packaging CLP with YADE in the next release
> might take some effort. Thanks Jan again.
>
>
> Thanks,
>
> Boon
> --
> *From:* Jan Stránský <honzik.stran...@gmail.com>
> <honzik.stran...@gmail.com>
> *Sent:* Friday, September 9, 2016 8:16:56 PM
> *To:* Chia Weng Boon
> *Cc:* bruno.chare...@3sr-grenoble.fr; s.ut...@warwick.ac.uk;
> yade-dev@lists.launchpad.net; chiaw...@gmail.com; Chia Weng Boon
> *Subject:* Re: [Yade-dev] Block Generation, Contact Detection, Rock Bolt
> and Rock Lining
>
> Dear all,
> sorry for not responding, I am completely out of time until Sep 17. Then I
> hope I will have some time on this topic.
>
> @Boon: for the sake of clarity, could you please send once more all the
> files that needs to be integrated (even if you have sent them already and
> did not do any changes from that time)?
> thanks in advance :-)
> maybe also those that are already implemented, I did some modifications
> but did not test them very much, I am afraid after my modifications the
> particles does not work as expected..
>
> cheers
> Jan
>
>
> 2016-09-07 1:22 GMT+02:00 Chia Weng Boon <boo...@hotmail.com>:
>
>> Bruno,
>>
>> The one shared in January is a different algorithm called Potential
>> Pariticles. It can accomodate a variety of shapes from rounded to
>> polyhedral.  I can see that Jan has helped me clean the code and assisted
>> in the Marching Cube display (Thanks Jan!). Previously I was relying on vtk
>> files and displaying through ParaView. The algorithm is solved using conic
>> optimisation. I commented out parts of the code where an external library
>> Mosek is called. It is optional but highly recommended. Now the algorithm
>> relies on the in house code I wrote for the conic solver.
>>
>> The code that I shared in March is different and is for polyhedral blocks
>> which I call Potential Blocks. It relies on external libraries eg CLP. It
>> is faster than Potential Particles. It comes with a suite of Block
>> Generation, Rock bolt and lining routines. This is not available in trunk
>> yet. Probably there is lots of cleaning to do. Its availability in trunk
>> can be done in a progressive manner starting from just

[Yade-dev] [Bug 1621869] [NEW] 3d postprocessing tutorial script segfaults in VTKRecorder

[Jan Stránský]

Public bug reported:

A "3d postprocessing" tutorial script [1] gives segmentation fault. If I
comment VTKRecorder line, everything works ok.

Thanks feda [2] to indirectly find this problem

[1] https://yade-dem.org/doc/tutorial-examples.html#d-postprocessing
[2] https://answers.launchpad.net/yade/+question/383099

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

Title:
  3d postprocessing tutorial script segfaults in VTKRecorder

Status in Yade:
  New

Bug description:
  A "3d postprocessing" tutorial script [1] gives segmentation fault. If
  I comment VTKRecorder line, everything works ok.

  Thanks feda [2] to indirectly find this problem

  [1] https://yade-dem.org/doc/tutorial-examples.html#d-postprocessing
  [2] https://answers.launchpad.net/yade/+question/383099

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1621869/+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] Block Generation, Contact Detection, Rock Bolt and Rock Lining

[Jan Stránský]

Dear all,
sorry for not responding, I am completely out of time until Sep 17. Then I
hope I will have some time on this topic.

@Boon: for the sake of clarity, could you please send once more all the
files that needs to be integrated (even if you have sent them already and
did not do any changes from that time)?
thanks in advance :-)
maybe also those that are already implemented, I did some modifications but
did not test them very much, I am afraid after my modifications the
particles does not work as expected..

cheers
Jan


2016-09-07 1:22 GMT+02:00 Chia Weng Boon :

> Bruno,
>
> The one shared in January is a different algorithm called Potential
> Pariticles. It can accomodate a variety of shapes from rounded to
> polyhedral.  I can see that Jan has helped me clean the code and assisted
> in the Marching Cube display (Thanks Jan!). Previously I was relying on vtk
> files and displaying through ParaView. The algorithm is solved using conic
> optimisation. I commented out parts of the code where an external library
> Mosek is called. It is optional but highly recommended. Now the algorithm
> relies on the in house code I wrote for the conic solver.
>
> The code that I shared in March is different and is for polyhedral blocks
> which I call Potential Blocks. It relies on external libraries eg CLP. It
> is faster than Potential Particles. It comes with a suite of Block
> Generation, Rock bolt and lining routines. This is not available in trunk
> yet. Probably there is lots of cleaning to do. Its availability in trunk
> can be done in a progressive manner starting from just the Potential Blocks
> first. I am thinking Jan would perhaps be the best administrator to assist,
> if his time permits it since he had helped with uploading and cleaning of
> the PotentialParticle code previously.  Jan, would you be available to
> assist please? I know you are occupied with your PhD/postdoc work?
>
> Boon
>
>
> Get Outlook for Android 
>
>
>
> On Wed, Sep 7, 2016 at 1:17 AM +0800, "Bruno Chareyre" <
> bruno.chare...@3sr-grenoble.fr> wrote:
>
>
>
> On 09/06/2016 03:47 PM, Chia Weng Boon wrote:
>
> Dear Bruno,
>
>
> Yes it is working as expected.  I have shared the codes since March, but
> it is still not in the public domain.  So,  I was wondering if there are
> any difficulties faced by YADE's administrators to make it available.  I
> thought it could be the external library.
>
> What do you mean by "public domain"?
> As I see it the code is already publicly available for everyone as part of
> trunk since January (see e.g. [1] - thx. to Jan).
> Do I miss something?
>
>
>   In fact, I had also shared the modifications to the Makefile how the
> library could be linked.  If it is shared, the user is supposed to compile
> his own version of CLP.
>
> That is not a very good point. Why not using the packaged version of CLP
> available through standard package manager (you don't compile your own
> firefox, then why compiling your own CLP?)?.
>
> Bruno
>
> [1] https://github.com/yade/trunk/commit/576941f605609384c32fb95c47e4e2
> 6225b0d6e8
>
>
>
> ___
> Mailing list: https://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 1596021] Re: O.tags['params'] for 2 batchs and 1 save

[Jan Stránský]

Hi Jerome,

in my opinion it is not bug nor indesirable feature. O.load should load
everything what is saved, including O.tags. I think there would be plenty
of situations where you define O.tags, save it and after load you want to
have them. As an extreme, one may complain that after O.load, the bodies
are loaded from previous simulation :-)

what about this as a solution (readParamsFromTable after O.load)?

## second.py 
O.load('first.yade')
readParamsFromTable(secondParam = 'toto')
from yade.params.table import *
print 'In second.py at the end, O.tags[params] =', O.tags['params']
###

cheers
Jan


2016-06-24 18:27 GMT+02:00 Jérôme Duriez :

> ** Attachment added: "second.table"
>
> https://bugs.launchpad.net/yade/+bug/1596021/+attachment/4689856/+files/second.table
>
> --
> You received this bug notification because you are a member of Yade
> developers, which is subscribed to Yade.
> https://bugs.launchpad.net/bugs/1596021
>
> Title:
>   O.tags['params'] for 2 batchs and 1 save
>
> Status in Yade:
>   New
>
> Bug description:
>   Hello,
>
>   I've faced some issue for batch simulation. I have a batch simulation
>   that loads a .yade save from a previous simulation that was also
>   launched in batch mode.
>
>   The two batch-mode simulations consider different parameters in their
>   .table. And in the second simulation, O.tags['params'] refers to the
>   parameters of the first batch-mode simulation, while I would like it
>   refers to the parameters of the current simulation..
>
>   I'm attaching example scripts "first.py" and "second.py", together
>   with their "first.table" and "second.table" to illustrate. "first.py"
>   will generate a .yade that will be used by "second.py". During the
>   batch execution of "second.py", O.tags['params'] refers to first.table
>   instead of second.table.
>
>   It turns out the O.load erases the right O.tags['params']
>
>   Do we agree it is a bug or, at least, an indesirable feature ? Would
>   it be possible to not save O.tags['params'] in .yade files ?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/yade/+bug/1596021/+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/1596021

Title:
  O.tags['params'] for 2 batchs and 1 save

Status in Yade:
  New

Bug description:
  Hello,

  I've faced some issue for batch simulation. I have a batch simulation
  that loads a .yade save from a previous simulation that was also
  launched in batch mode.

  The two batch-mode simulations consider different parameters in their
  .table. And in the second simulation, O.tags['params'] refers to the
  parameters of the first batch-mode simulation, while I would like it
  refers to the parameters of the current simulation..

  I'm attaching example scripts "first.py" and "second.py", together
  with their "first.table" and "second.table" to illustrate. "first.py"
  will generate a .yade that will be used by "second.py". During the
  batch execution of "second.py", O.tags['params'] refers to first.table
  instead of second.table.

  It turns out the O.load erases the right O.tags['params']

  Do we agree it is a bug or, at least, an indesirable feature ? Would
  it be possible to not save O.tags['params'] in .yade files ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1596021/+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 1582775] Re: ymport needs to import polyhedra_utils module

[Jan Stránský]

Thanks for reporting, it is fixed now
Jan


** Changed in: yade
   Status: New => Fix Released

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

Title:
  ymport needs to import polyhedra_utils module

Status in Yade:
  Fix Released

Bug description:
  The ymport module doesn't import the polyhedra_utils module. If you
  call ymport.textPolyhedra function an error occurs even if your code
  itself imports polyhedra_utils module.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1582775/+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] Yade release, new versioning?

[Jan Stránský]

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

[Yade-dev] [Bug 1570679] Re: Memory leak during updating position of tetrapoly elements

[Jan Stránský]

In previous comment, I meant 
O.bodies[0].shape.setVertices(a[0],a[1],a[2],a[3])
O.bodies[0].shape.setVertices(a)
to be consistent with original bug report

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

Title:
  Memory leak during updating position of tetrapoly elements

Status in Yade:
  Fix Released

Bug description:
  There exists severe memory leaking problem when using intermediate
  variables to update positions of tetraPoly in a loop:

  running the code, the memory will keep leaking:
  #
  a = [[0,0,0],[0,0,1],[0,1,0],[1,0,0]]
  O.bodies.append(yade.utils.tetraPoly(a))
  for i in range(100):
  b = [[0,0,0],[0,0,1],[0,1,0],[i+2,0,0]]
  O.bodies[0].shape.setVertices(b)
  O.bodies[0].state.ori = O.bodies[0].shape.GetOri()
  O.bodies[0].state.pos = O.bodies[0].shape.GetCentroid()
  O.bodies[0].state.mass = O.bodies[0].mat.density * 
O.bodies[0].shape.GetVolume()
  O.bodies[0].state.inertia = O.bodies[0].mat.density * 
O.bodies[0].shape.GetInertia()

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1570679/+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 1570679] Re: Memory leak during updating position of tetrapoly elements

[Jan Stránský]

setVertices now works without memory leaks passing each vertex as single
argument

O.bodies[0].shape.setVertices(b[0],b[1],b[2],b[3])

or

O.bodies[0].shape.setVertices(*b) # *b in Python does internally the
above code

currently implemented only for 4 vertices, if needed it is easy to
extend to more vertices

Jan

** Changed in: yade
   Status: New => Fix Released

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

Title:
  Memory leak during updating position of tetrapoly elements

Status in Yade:
  Fix Released

Bug description:
  There exists severe memory leaking problem when using intermediate
  variables to update positions of tetraPoly in a loop:

  running the code, the memory will keep leaking:
  #
  a = [[0,0,0],[0,0,1],[0,1,0],[1,0,0]]
  O.bodies.append(yade.utils.tetraPoly(a))
  for i in range(100):
  b = [[0,0,0],[0,0,1],[0,1,0],[i+2,0,0]]
  O.bodies[0].shape.setVertices(b)
  O.bodies[0].state.ori = O.bodies[0].shape.GetOri()
  O.bodies[0].state.pos = O.bodies[0].shape.GetCentroid()
  O.bodies[0].state.mass = O.bodies[0].mat.density * 
O.bodies[0].shape.GetVolume()
  O.bodies[0].state.inertia = O.bodies[0].mat.density * 
O.bodies[0].shape.GetInertia()

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1570679/+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] Block Generation, Contact Detection, Rock Bolt and Rock Lining

[Jan Stránský]

Hi Boon,
thanks for the effort also from me and sorry for late answer.
What is the situation now? I can help to merge the files not to conflict
with current branch, but probably not before May..
Regards
Jan


2016-03-17 17:11 GMT+01:00 Chia Weng Boon :

> Bruno,
>
> You are absolutely right in all those cases.   ScGeom can make use of a
> boolean for the twist.  Yes, Cundall's paper is almost 30 years old.  He
> may have changed his mind too.  I remember the code crashed when I was
> using the new updateProperties.  I am not a good debugger.   And the
> Clump::del should work.
>
> In fact, there had been some changes in YADE's main program that I had to
> modify my old code, to make it work.  I mentioned those few regressions,
>  so that active developers are able to identify them and fix it.  I decided
> that if I were to keep the code and try to update it nicely before sharing
> it out, YADE may get updated again, before I can catch up.  I better share
> it when it is working.  This is my advice for other researchers.  Don't
> keep your code, because you will likely have to keep up with the
> developments in YADE. And you won't have time to play/maintain with your
> own code anyway when you move on with life.   Now that I am in construction
> and not in a university, it is very difficult to have the luxury of finding
> time for this hobby.
>
>
>
> Yours,
> Boon
>
> On Thu, Mar 17, 2016 at 11:01 PM, Bruno Chareyre <
> bruno.chare...@3sr-grenoble.fr> wrote:
>
>> Hi Boon,
>> Thank you for progress report!
>>
>> On 16/03/16 16:37, Chia Weng Boon wrote:
>> > I have also changed some of the existing files to make it compatible
>> with
>> > my old files.  Please update and modify it accordingly if you think
>> there
>> > is a better way to do it.
>> > ScGeom:  I took away the twist update because for polygons this is not
>> used
>> > in Cundall's paper.  Please modify accordingly if there is some
>> theoretical
>> > discovery.
>> Does it mean that the twist will be also disabled if someone has, let's
>> say, a sphere-sphere contact?
>> And did you find a reason why the twist should be defined differently
>> (or even undefined) in the case of polygons?
>> In general Yade is not meant to reproduce Cundall's equations on every
>> aspect.
>>
>> > Clump:  The Update Properties looked different from the old one, and I
>> had
>> > problems with clumps earlier on when updating the code.  Not sure if
>> this
>> > is the problem, but i used the old one anyway.
>> We must make sure that adding some code does not imply regressions as
>> side effects.
>> Do you have any clue why the polyhedra code needs an older version of
>> updateProperties? What sort of problem do you find?
>> Rolling back such a function is most likely breaking, or at least
>> changing the behavior, of other parts of the code.
>>
>> > YadeWrapper:  Added deleteClumpMembers function, since it was in my old
>> > version.
>> Is Clump::del not doing the same thing? Do you need such a function?
>>
>> As far as I understand, you are half-way to a compatible code overall.
>> It will be really compatible when no changes will be required in other
>> files.
>> If somene else will do the remaining work, it would be helpful to him to
>> have more detailed explanations of why you had to roll back some changes
>> (which really means something to fix in your code, not something to roll
>> back in trunk).
>>
>> 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
>
>
___
Mailing list: https://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 1476159] Re: several ForceContainer.addF behaves non-intuitively with permanent=True

[Jan Stránský]

Fixed in r4982

** Changed in: yade
   Status: New => Fix Released

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

Title:
  several ForceContainer.addF behaves non-intuitively with
  permanent=True

Status in Yade:
  Fix Released

Bug description:
  Hi all,

  consider

  O.forces.addF(id,(2,0,0),True)
  ... # some code, a few steps or whatever
  O.forces.addF(id,(4,0,0),True)

  what should be the result? Intuitively (according to addF name), I
  would expect applied force (6,0,0). However, the permanent force is
  rewritten with (4,0,0), so applied force (4,0,0) is the result..

  I suggest to split addF to 2 cases:
  1) addF without permanent parameter
  2) setPermanentForce ()or something similar), substituting 
addF(permanent=True), with the name reflecting more accurately what it really 
does..

  any suggestions or comments?
  cheers
  Jan

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1476159/+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] Potential Particles (DEM non-spherical particles)

[Jan Stránský]

Hi Chia,
did you try cmake from the scratch, i.e. deleting build directory and
running cmake again?
cheers
Jan


2015-12-31 16:41 GMT+01:00 Chia Weng Boon <chiaw...@gmail.com>:

> Hi,
>
> I have this problem with linking with external library
>
>
> I added onto my build directory, CMakeCache.txt
>
> CLP2_INCLUDE_DIR:PATH=/home/boon/coin-Clp/lib/pkgconfig
> CLP2_LIBRARY:FILEPATH=/home/boon/coin-Clp/Clp/src/.libs/libClpSolver.so
> CLP3_INCLUDE_DIR:PATH=/home/boon/coin-Clp/CoinUtils/src
> CLP3_LIBRARY:FILEPATH=/home/boon/coin-Clp/Clp/src/OsiClp/.libs/libOsiClp.so
> CLP4_LIBRARY:FILEPATH=/home/boon/coin-Clp/lib/libCoinUtils.so
> CLP_INCLUDE_DIR:PATH=/home/boon/coin-Clp/Clp/src
> CLP_LIBRARY:FILEPATH=/home/boon/coin-Clp/Clp/src/.libs/libClp.so
>
>
> Created FindCLP.cmake in trunk/cMake/
> FIND_PATH(CLP_INCLUDE_DIR *)
> FIND_PATH(CLP2_INCLUDE_DIR *)
> FIND_PATH(CLP3_INCLUDE_DIR CoinPragma.hpp)
> FIND_LIBRARY(CLP_LIBRARY NAMES Clp)
> FIND_LIBRARY(CLP2_LIBRARY NAMES ClpSolver)
> FIND_LIBRARY(CLP3_LIBRARY NAMES OsiClp)
> FIND_LIBRARY(CLP4_LIBRARY NAMES CoinUtils)
>
>
> Added in CMakeLists.txt in trunk:
>  INCLUDE(FindCLP)
>
>
> But I still get the following error when compiling:
> /home/boon/coin-Clp/Clp/src/ClpPackedMatrix.hpp:9:26: fatal error:
> CoinPragma.hpp: No such file or directory
>
> And when running:
> import yade
>   File
> "/home/boon/yadeRev/install/lib/x86_64-linux-gnu/yade-2015-11-06.git-c5330ac6/py/yade/__init__.py",
> line 65, in 
> import boot
> ImportError:
> /home/boon/yadeRev/install/lib/x86_64-linux-gnu/yade-2015-11-06.git-c5330ac6/libyade.so:
> undefined symbol: _ZN10ClpSimplex4dualEii
>
>
>
> I have already added onto my bashrc the PATH and LD_LIBRARY_PTATH.
>
> It appears I have not done things correctly.  Hope someone could help.
>
> Happy New Year 2016~!  Planning to get some programming done over the
> holidays!
>
>
>
> Yours,
> BOON
>
> On Wed, Dec 16, 2015 at 12:54 PM, chiaweng <chiaw...@gmail.com> wrote:
>
>> Can someone advise what do i need to do to link to an external library
>> with this new cmake?
>>
>>
>>
>> Sent from my Samsung Galaxy smartphone.
>>  Original message 
>> From: Anton Gladky <gladky.an...@gmail.com>
>> Date: 16/12/2015 01:50 (GMT+08:00)
>> To: Jan Stránský <honzik.stran...@gmail.com>
>> Cc: chiaweng <chiaw...@gmail.com>, Yade developers <
>> yade-dev@lists.launchpad.net>
>> Subject: Re: [Yade-dev] Potential Particles (DEM non-spherical particles)
>>
>> Hi Jan,
>>
>> 2015-12-15 16:47 GMT+01:00 Jan Stránský <honzik.stran...@gmail.com>:
>> > @Anton: Do you have any suggestions / link how to work with pull
>> requests?
>>
>> We need to review them and to check, whether it does not cause compilation
>> failures. After that we can merge them. I will try to have a closer look
>> within
>> the next few days.
>>
>> 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

Re: [Yade-dev] Potential Particles (DEM non-spherical particles)

[Jan Stránský]

Hello,

@Chia: thanks a lot again. I asked for the files, I should take
responsibility for them :-) I will start to work on it in January (no time
at the end of the year)

@Anton: Do you have any suggestions / link how to work with pull requests?

Thanks
Jan


2015-12-15 6:24 GMT+01:00 chiaweng :

> Thx all - Jan, Anton and Bruno. I have uploaded them again yesterday
> nicely n submitted a pull request.
>
> Will look into the other things later
>
>
>
> Sent from my Samsung Galaxy smartphone.
>  Original message 
> From: Bruno Chareyre 
> Date: 15/12/2015 01:48 (GMT+08:00)
> To: yade-dev@lists.launchpad.net
> Subject: Re: [Yade-dev] Potential Particles (DEM non-spherical particles)
>
> On 13/12/15 11:34, Anton Gladky wrote:
> >> How do I access onto YADE's website so that I can add a Section on how
> to
> >> use the function?
> > You can just write a simple text and send to somebody of us and we will
> > commit it into the github. Also you can just send us a complete patch
> > or a "pull request". All variants are OK.
> Hello Chia,
> We recently had the situation of a relatively self-contained module by
> Ning Guo [1].
> The corresponding source file is [2] (also attached).
> You could follow the same strategy.
> Bruno
>
> [1] https://yade-dem.org/doc/FEMxDEM.html
> [2] https://github.com/yade/trunk/blob/master/doc/sphinx/FEMxDEM.rst
>
> >
> >> There is an example file in trunks/examples/PotentialParticles.   Note
> that
> >> when defining the particle aabb is used to define the display, whereas
> >> AabbRotated is used for bounding boxes.  The vtk files can be opened
> with
> >> ParaView-4.3.  I have uploaded both my personal implementation and
> another
> >> function to call an external library MOSEK.  The latter is not
> mandatory but
> >> helps in improving robustness.  It is commented out.  Please uncomment
> it if
> >> you can link it to MOSEK (strongly recommended).  I am not able to check
> >> whether or not MOSEK's new release is still compatible with my old one
> (ver
> >> 6), but it is not too difficult to update that part since it is just
> passing
> >> of variables.
> > I am not able to find this example in the trunk. Please send a patch or
> your
> > files then we will be able to try to compile and discuss it.
> >
> > 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
> 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] SoftwareX

[Jan Stránský]

Hello all,
recently I have found links bellow, might be useful for the discussion how
to cite Yade in future and for newer versions. Mainly sent not to forget
completely :-)
cheers
Jan

[1] https://www.youtube.com/watch?v=l1cWoHKCBak
[2] http://www.journals.elsevier.com/softwarex
___
Mailing list: https://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 #269724]: What are particular features of CpmMat model?

[Jan Stránský]

Hello (and sorry for late reply),

in Cpm classes the approach is (if I understand correctly) the same as in
JCFpm, see example code in [1]. At interaction born, all interactions are
set forcesfree by default. I am quite happy with the approach, even thought
you need to run one time step.

cheers
Jan

[1] https://yade-dem.org/doc/user.html#creating-interactions



2015-07-29 23:42 GMT+02:00 Jerome Duriez jerome.dur...@ucalgary.ca:

  Ok, one happy end of this discussion is that we agree that more lines
 than a single unp = penetrationDepth are required to build a stress free
 initial bond network. And in fact I think we finally agree on all points,
 since I understand/share your preferences for python scripting with respect
 to C++, even though I do not seek as much you do replacing C++ lines with
 python ones.

 I add just some precisions about this particular example. First, regarding
 this hypothesis:
 - should the interaction network be based on a constant multiplier
 applied to all sphere radius?

 It is exactly what JCFpm users currently do ! Taking advantage of
 Bo1_Sphere_Aabb.aabbEnlargeFactor and
 Ig2_Sphere_Sphere_ScGeom.interactionDetectionFactor and using one initial
 time step to construct the initial bond network. According to Jan's answer
 #1 of the Launchpad question, it seems other cohesive-law users do exactly
 the same.
 Then, regarding your suggestion:
 for p in bodyPairs: #user defined list, the collider should provide help,
 not a big deal to implement if not yet available
 i=createInteraction(p.id1,p.id2)
 I think the manual definition of such bodyPairs on the python-side is up
 to now far from the Yade-usage of lot of users / devs... (though I do not
 say it is a reason to keep the current situation)


 Second, regarding damage, I just mentionned damage measurements
 parameters which are just broken bonds numbers. Nothing that enters in the
 constitutive law itself (in case you understood this)..


 I agree it makes sense to at least discuss a possible removal of JCFpm
 law. But probably, this would require another communication channel, more
 efficient than emails, to discuss the ideas about the specific IGeom,
 IPhys, Ig2 and Ip2 functors. And, first of all, someone willing to
 implement it.
 As for me, I do not work anymore with this law, and my first contribution
 to a Law2 extermination in Yade would be
 Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity which I wrote
 myself -- contrary to JCFpm law -- and which is probably, unfortunately,
 much less useful than JCFpm. I swear to do this in the first year I get a
 permanent position


 Jerome



  --
 *From:* Yade-dev [yade-dev-bounces+jerome.duriez=
 ucalgary...@lists.launchpad.net] on behalf of Bruno Chareyre [
 bruno.chare...@3sr-grenoble.fr]
 *Sent:* July 29, 2015 2:24 PM
 *To:* yade-dev@lists.launchpad.net

 *Subject:* Re: [Yade-dev] [Yade-users] [Question #269724]: What are
 particular features of CpmMat model?

   On 29/07/15 17:49, Jerome Duriez wrote:


 * constructing by hand all the interactions of the initial bond
 network (that's what you mean when you say that time integration is not
 needed to detect interactions, I guess ?)

 Yes.

 * computing by hand the corresponding penetrationDepth
 * applying unp = penetrationDepth
 I'm not saying it is difficult / impossible, but hopefully we will agree
 that such kind of things do not usually enter script definitions (or at
 least make script definitions more complex). Whereas a classical step
 execution does it like a charm. What do you think ?

 On a different problem and a few years back I was thinking more or less as
 you think now: I need to simulate isotropic compression + deviatoric
 loading, so let a c++ code do all that: generate the particles, compress
 isotropicaly, decide when to switch to triaxial, output results to text
 files. A single c++ class (the triaxial preprocessor you can still find in
 the GUI) would do all this by just clicking play button.
 At that time there was no functional scripting langage. Now that we have
 one, I find it much more convenient to  write all the above steps one by
 one in a script (and I deprecated TriaxialCompressionEngine). You may think
 it is a pain for me, I have to do every step by hand (50+ lines) while I
 could just click and play.
 Well, it is simply much more flexible.

 The situation is very similar in this initial bond network problem. You
 support having everything planned in advance in some c++ code (so
 everything is decided by clicking the play button or writing O.step()).  I
 claim it should be left to the user, be it at the price of more scripting,
 and in any case it does not justify writing additional
 Material/Ig2/Ip2/Law2 families just for this.

 If you think to it:
 - should the interaction network be based on a constant multiplier applied
 to all sphere radius?
 - should it be based on a fixed distance regardless of individual sphere
 sizes 

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3705: Addition in doc of Omega.engines to state it is = to O.engines in python

[Jan Stránský]

@Bruno: O is defined a a global variable but it is just a convention. If
you continued:

bla = Omega()
bla is O # False
bla == O # False
bla.engines == O.engines # True :-)
# probably some consequence of defining Omega as singleton in C++ (the C++
object is the same but Python object wrapping it not)
...
O = Vector3(0,0,0) # origin of coordinate system # to have desired
nonsense, you have to overwrite O name
...
O.engines = [...] # O.engines? stil works :-D :-D

now you are getting to troubles :-)
Jan


2015-07-23 14:50 GMT+02:00 Bruno Chareyre bruno.chare...@3sr-grenoble.fr:


bla=Omega()
   bla.engines?
   Docstring:  [...] accessed using O.engines
 
  Do you see the problem? Do I really access the engines of bla as
  O.engines?
 For some reason the answer is actually yes, haha.
 But I guess you will get the general idea.
 B



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

___
Mailing list: https://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 1475844] Re: Swap problem in InteractionLoop

[Jan Stránský]

This situation is partly described in [2]. I used it just in a special case:
- spheres with CpmMat
- facets with FrictMat
- Ig2_Facet_Sphere
- Ip2_FrictMat_CpmMat

so Ig2 always order the particles with different shapes in order
Facet-Sphere, so the materials are also ordered FrictMat-CpmMat fitting
perfectly the Ip2 definition :-) this was done correctly by luck, so I
did not have the discussed problem in this case..

If I used CpmMat for facets and FrictMat for spheres, or used CpmMat and
FrictMat for spheres only, I would have had this error..

cheers
Jan


2015-07-23 12:36 GMT+02:00 Bruno Chareyre 1475...@bugs.launchpad.net:

 I don't understand this assert either.
 Just adding more questions:
 -Can the same problem also appear in Ip2_FrictMat_CpmMat_FrictPhys?
 -This one requires that mat1 is Frict and Mat2 is Cpm, how can it be
 always true? [4]

 The good fix would be to let materials be swapped, I don't believe it
 really needs two different functors.

 [4] http://bazaar.launchpad.net/~yade-pkg/yade/git-
 trunk/view/head:/pkg/dem/ConcretePM.cpp#L25

 --
 You received this bug notification because you are subscribed to the bug
 report.
 https://bugs.launchpad.net/bugs/1475844

 Title:
   Swap problem in InteractionLoop

 Status in Yade:
   New

 Bug description:
   When you use two different materials, it might happen that
   IntreactionLoop ends with error [1]. It is because of IPhys stage (see
   also the comment in [1], but in reality Ip2 can by non-symmetric).

   Possible solutions:
   1) define both Ip2_Mat1_Mat2 and Ip2_Mat2_Mat1 (according to [2] maybe
 does not work..)
   2) replace assert [1] (something like   if (swap) {
 I-functorCase.phys=physDispatcher-getFunctor2D(b2-material,b1-material,swap);
 swap=false }). Is the assert necessary at all?
   3) make option 1) somehow automatic (using some macro?)

   Pros and cons:
   1) would mess the source code and documentation a bit, but otherwise I
 think it is ok
   2) would it have some side effects? Is it ok for Law2 stage? etc etc?
   3) maybe the best option if the solution is reasonable

   cheers
   Jan

   [1]
 http://bazaar.launchpad.net/~yade-pkg/yade/git-trunk/view/head:/pkg/common/InteractionLoop.cpp#L116
   [2] https://answers.launchpad.net/yade/+question/269315

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


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

Title:
  Swap problem in InteractionLoop

Status in Yade:
  New

Bug description:
  When you use two different materials, it might happen that
  IntreactionLoop ends with error [1]. It is because of IPhys stage (see
  also the comment in [1], but in reality Ip2 can by non-symmetric).

  Possible solutions:
  1) define both Ip2_Mat1_Mat2 and Ip2_Mat2_Mat1 (according to [2] maybe does 
not work..)
  2) replace assert [1] (something like   if (swap) { 
I-functorCase.phys=physDispatcher-getFunctor2D(b2-material,b1-material,swap);
 swap=false }). Is the assert necessary at all?
  3) make option 1) somehow automatic (using some macro?)

  Pros and cons:
  1) would mess the source code and documentation a bit, but otherwise I think 
it is ok
  2) would it have some side effects? Is it ok for Law2 stage? etc etc?
  3) maybe the best option if the solution is reasonable

  cheers
  Jan

  [1] 
http://bazaar.launchpad.net/~yade-pkg/yade/git-trunk/view/head:/pkg/common/InteractionLoop.cpp#L116
  [2] https://answers.launchpad.net/yade/+question/269315

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1475844/+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 1476159] [NEW] several ForceContainer.addF behaves non-intuitively with permanent=True

[Jan Stránský]

Public bug reported:

Hi all,

consider

O.forces.addF(id,(2,0,0),True)
... # some code, a few steps or whatever
O.forces.addF(id,(4,0,0),True)

what should be the result? Intuitively (according to addF name), I would
expect applied force (6,0,0). However, the permanent force is rewritten
with (4,0,0), so applied force (4,0,0) is the result..

I suggest to split addF to 2 cases:
1) addF without permanent parameter
2) setPermanentForce ()or something similar), substituting 
addF(permanent=True), with the name reflecting more accurately what it really 
does..

any suggestions or comments?
cheers
Jan

** Affects: yade
 Importance: Low
 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/1476159

Title:
  several ForceContainer.addF behaves non-intuitively with
  permanent=True

Status in Yade:
  New

Bug description:
  Hi all,

  consider

  O.forces.addF(id,(2,0,0),True)
  ... # some code, a few steps or whatever
  O.forces.addF(id,(4,0,0),True)

  what should be the result? Intuitively (according to addF name), I
  would expect applied force (6,0,0). However, the permanent force is
  rewritten with (4,0,0), so applied force (4,0,0) is the result..

  I suggest to split addF to 2 cases:
  1) addF without permanent parameter
  2) setPermanentForce ()or something similar), substituting 
addF(permanent=True), with the name reflecting more accurately what it really 
does..

  any suggestions or comments?
  cheers
  Jan

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1476159/+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 1475844] [NEW] Swap problem in InteractionLoop

[Jan Stránský]

Public bug reported:

When you use two different shapes and two different materials, it might
happen that IntreactionLoop ends with error [1]. It is because the
interaction might be swapped in IGeom stage (ok) and in IPhys stage (see
also the comment in [1], but in reality Ip2 can by non-symmetric).

Possible solutions:
1) define both Ip2_Mat1_Mat2 and Ip2_Mat2_Mat1
2) replace assert [1] (something like   if (swap) { 
I-functorCase.phys=physDispatcher-getFunctor2D(b2-material,b1-material,swap);
 swap=false })
3) make option 1) somehow automatic (using some macro?)

Pros and cons:
1) would mess the source code and documentation a bit, but otherwise I think it 
is ok
2) would it have some side effects? Is it ok for Law2 stage? etc etc?
3) maybe the best option if the solution is reasonable

cheers
Jan

[1] 
http://bazaar.launchpad.net/~yade-pkg/yade/git-trunk/view/head:/pkg/common/InteractionLoop.cpp#L116
[2] https://answers.launchpad.net/yade/+question/269315

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

Title:
  Swap problem in InteractionLoop

Status in Yade:
  New

Bug description:
  When you use two different shapes and two different materials, it
  might happen that IntreactionLoop ends with error [1]. It is because
  the interaction might be swapped in IGeom stage (ok) and in IPhys
  stage (see also the comment in [1], but in reality Ip2 can by non-
  symmetric).

  Possible solutions:
  1) define both Ip2_Mat1_Mat2 and Ip2_Mat2_Mat1
  2) replace assert [1] (something like   if (swap) { 
I-functorCase.phys=physDispatcher-getFunctor2D(b2-material,b1-material,swap);
 swap=false })
  3) make option 1) somehow automatic (using some macro?)

  Pros and cons:
  1) would mess the source code and documentation a bit, but otherwise I think 
it is ok
  2) would it have some side effects? Is it ok for Law2 stage? etc etc?
  3) maybe the best option if the solution is reasonable

  cheers
  Jan

  [1] 
http://bazaar.launchpad.net/~yade-pkg/yade/git-trunk/view/head:/pkg/common/InteractionLoop.cpp#L116
  [2] https://answers.launchpad.net/yade/+question/269315

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1475844/+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] Could you please fix warnings in Flow and ConcretePM ?

[Jan Stránský]

The warning in PeriIsoCompressor.xpp should be fixed
Jan


2015-05-09 10:57 GMT+02:00 Bruno Chareyre bruno.chare...@3sr-grenoble.fr:

 It is unsafe to not initialize. Better zero or anything else than nothing,
 since nothing makes the behavior undefined, hence very difficult to debug.
 Jan will tell us what a proper default could be hopefully.
 Bruno

 On 7 May 2015 at 19:03, Janek Kozicki janek_li...@wp.pl wrote:

 Thanks Anton for fixing what you could. I notice that to remove the only
 two last warnings:

 In file included from
 /home/salomea/yade/trunk/pkg/dem/PeriIsoCompressor.cpp:4:0:
 /home/salomea/yade/trunk/pkg/dem/PeriIsoCompressor.hpp: In constructor
 ‘Peri3dController::Peri3dController()’:
 /home/salomea/yade/trunk/pkg/dem/PeriIsoCompressor.hpp:118:1: warning:
 overflow in implicit constant conversion [-Woverflow]
 /home/salomea/yade/trunk/pkg/dem/PeriIsoCompressor.hpp:118:1:
 warning: overflow in implicit constant conversion [-Woverflow]

 we need a following diff:

 diff --git a/pkg/dem/PeriIsoCompressor.hpp b/pkg/dem/PeriIsoCompressor.hpp
 index 94f141f..299d63a 100644
 --- a/pkg/dem/PeriIsoCompressor.hpp
 +++ b/pkg/dem/PeriIsoCompressor.hpp
 @@ -109,8 +109,8 @@ class Peri3dController: public BoundaryController{

 ((Vector6i,ps,Vector6i::Zero(),Attr::readonly,Peri3dController internal
 variable))

 ((Vector6i,pathSizes,Vector6i::Zero(),Attr::readonly,Peri3dController
 internal variable))

 ((Vector6i,pathsCounter,Vector6i::Zero(),Attr::readonly,Peri3dController
 internal variable))
 -   ((int,lenPe,NaN,Attr::readonly,Peri3dController internal
 variable))
 -   ((int,lenPs,NaN,Attr::readonly,Peri3dController internal
 variable))
 +   ((int,lenPe,,Attr::readonly,Peri3dController internal
 variable))
 +   ((int,lenPs,,Attr::readonly,Peri3dController internal
 variable))
 ,
 /*ctor*/


 If you think it's acceptable, then please apply it. `git blame
 PeriIsoCompressor.hpp`
 says we should ask Jan Stránský about this. Maybe instead of NaN put some
 number?
 Or find a legal way to initialize to Nan?

 best regards
 Janek


 Bruno Chareyre said: (by the date of Sun, 3 May 2015 14:48:51 +0200)

  Good idea Janek. Thanks.
  Bruno
 
  On 2 May 2015 at 13:00, Janek Kozicki janek_li...@wp.pl wrote:
 
   Anton Gladky said: (by the date of Sat, 2 May 2015 08:13:46 +0200)
  
I recently raised the level of warnings, so not all of them are
now fixed. Will try to fix it within the next several days.
  
   Thanks, maybe afterwards we could raise the level of warnings even
 more?
   One very useful candidate is `-Wshadow`, because I also lost some
   time trying to find a bug, which was caused by shadowing a variable
   by mistake.
  
   But I see some warnings from eigen due to -Wshadow, I suppose we would
   need to fix those warnings there also.
  
   --
   Janek Kozicki   http://janek.kozicki.pl/
 |
  
   ___
   Mailing list: https://launchpad.net/~yade-dev
   Post to : yade-dev@lists.launchpad.net
   Unsubscribe : https://launchpad.net/~yade-dev
   More help   : https://help.launchpad.net/ListHelp
  
  


 --
 Janek Kozicki   http://janek.kozicki.pl/  |

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



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


___
Mailing list: https://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] Inspecting authors for next doc release

[Jan Stránský]

Hi Bruno,
I committed code from Jan Eliáš twice [1,2]. In both cases, the
documentation is from source code in both cases.
cheers
Jan

[1] http://bazaar.launchpad.net/~yade-pkg/yade/git-trunk/revision/3362.10.49
[2]
http://bazaar.launchpad.net/~yade-pkg/yade/git-trunk/revision/3362.10.291



2015-03-05 12:00 GMT+01:00 Bruno Chareyre bruno.chare...@3sr-grenoble.fr:

 A general comment on git stats: don't try to get more than what they
 really mean, especially when it comes to ranking.
 Running automatic formatting on a 500 lines file will look as 500
 commited lines, for instance. Counting lines is unfair.
 Or one guy will work for months on a project, then send everything
 (plenty lines) in one single commit. Commit count: 1. Counting commits
 is unfair.
 Some obvious junk stats can be avoided (e.g. lines of mesh/data files in
 example folders are ignored [1]), but the numbers are still meaningless
 if one doesn't know what's behind.
 I would keep the authors in alphabetic order after V. Smilauer, like
 before.

 A question for Jan (Stransky): I guess you commited Jan Elias code under
 your name because I don't see him anywhere. Correct?
 Do you remember if there was some related documentation in rst files or
 only documentation in source code?

 Bruno

 [1] grep -E
 '*\.cpp|*\.hpp|*\.rst|*\.cmake|*\.txt|*\.bib|*\.ipp|*\.in|*\.py'



 On 04/03/15 20:29, Bruno Chareyre wrote:
  Hi there,
  1/ I mapped all Author Name e@mail of git in order to have a single
  name for every contributor [1]. Please check if the email adress is the
  one you want to see in the futur version of the documentation (I used
  the one with highest commit count). And please try to use always the
  same name and email, there is sometimes five different names for one
 person.
  2/ I ran some stats between early 2011 (date of last stable
  documentation) and now, the stats are in [2]. They give an idea (not
  100% accurate yet) of the additional authors to include: the last table
  for user manuals, the one just before for reference manual. The first
  table in the page can be used for listing contributors of the code, who
  may not appear as authors of the documentation.
  Cheers
 
  Bruno
 
  [1]
 
 https://github.com/yade/trunk/commit/ed7259b48c180cf01d5d39a635fa17f881bb473e
  [2] https://www.yade-dem.org/wiki/A_couple_tricks_for_stats
 


 --
 ___
 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] [Bug 1420248] [NEW] number minimal of argument for export data

[Jan Stránský]

Hi Alexander,

the problem is hidden in python syntax. The 'attrs' argument should be a
list or tuple. So if you use

export.textExt('../../tmp/data_export_melangeur.txt',format='x_y_z_r_attrs',attrs=('
b.mat.id',)) # notice the comma, making ('b.mat.id',) actually a tuple, ('
b.mat.id') is just one string

it should work

cheers
Jan



2015-02-10 12:37 GMT+01:00 Alex alexandre.gau...@agrosupdijon.fr:

 Public bug reported:

 Hello,


 I encounter an anomaly in the export.textExt () function
 When I give in  parameter That a single argument, I have an execution
 error.
 i have to passed two argument minimum for not have of error

 see example below :


 ===
 EXAMPLE 1 : with error

 ===

 export.textExt('../../tmp/data_export_melangeur.txt',format='x_y_z_r_attrs',attrs=('
 b.mat.id'))

 ===


 Exportation des données en cours...
 ---
 SyntaxError   Traceback (most recent call last)
 /soft/yade/1.12.0/gcc/4.4.7/bin/yade-1.12.0 in module()

 /soft/yade/1.12.0/gcc/4.4.7/bin/yade-1.12.0 in ExportData()
  52 #
  
 export.textExt('../../tmp/data_export_melangeur.txt',format='x_y_z_r_matId',attrs=('b.mat.label'))
  53 #
  
 export.textExt('../../tmp/data_export_melangeur.txt',format='x_y_z_r_attrs',attrs=('b.shape.color','b.state.pos'
 ))
 --- 54
  
 export.textExt('../../tmp/data_export_melangeur.txt',format='x_y_z_r_attrs',attrs=('
 b.mat.id'))
  55
  56 def testcode():

 /soft/yade/1.12.0/gcc/4.4.7/lib64/yade-1.12.0/py/yade/export.pyc in
 textExt(filename, format, comment, mask, attrs)
  56
  
 output+=('%g\t%g\t%g\t%g'%(b.state.pos[0],b.state.pos[1],b.state.pos[2],b.shape.radius))
  57 for cmd in attrs:
 --- 58 v = eval(cmd)
  59 if
 isinstance(v,(int,float)):
  60
  output+='\t%g'%v

 SyntaxError: unexpected EOF while parsing (string, line 1)



 ===
 EXAMPLE 2 : with error

 ===

 export.textExt('../../tmp/data_export_melangeur.txt',format='x_y_z_r_attrs',attrs=('b.shape.color'))

 ===


 Exportation des données en cours...
 ---
 SyntaxError   Traceback (most recent call last)
 /soft/yade/1.12.0/gcc/4.4.7/bin/yade-1.12.0 in module()

 /soft/yade/1.12.0/gcc/4.4.7/bin/yade-1.12.0 in ExportData()
  52 #
  
 export.textExt('../../tmp/data_export_melangeur.txt',format='x_y_z_r_matId',attrs=('b.mat.label'))
  53 #
  
 export.textExt('../../tmp/data_export_melangeur.txt',format='x_y_z_r_attrs',attrs=('b.shape.color','b.state.pos'
 ))
 --- 54
  
 export.textExt('../../tmp/data_export_melangeur.txt',format='x_y_z_r_attrs',attrs=('b.shape.color'))
  55
  56 def testcode():

 /soft/yade/1.12.0/gcc/4.4.7/lib64/yade-1.12.0/py/yade/export.pyc in
 textExt(filename, format, comment, mask, attrs)
  56
  
 output+=('%g\t%g\t%g\t%g'%(b.state.pos[0],b.state.pos[1],b.state.pos[2],b.shape.radius))
  57 for cmd in attrs:
 --- 58 v = eval(cmd)
  59 if
 isinstance(v,(int,float)):
  60
  output+='\t%g'%v

 SyntaxError: unexpected EOF while parsing (string, line 1)



 ===
 EXAMPLE 3,4 and 5 : no error

 ===
 export.textExt('../../tmp/data_export_melangeur.txt',format='x_y_z_r_attrs',attrs=('b.shape.color','b.state.pos'
 ))

 ===

 #format x_y_z_r_attrs
 0.3365530.0248906   -0.835412   0.020.336553
 0.0248906   -0.835412   1   0   1
 -0.318431   -0.174808   -0.780485   0.02-0.318431
  -0.174808   -0.780485   1   0   1
 0.232435-0.145611   -0.799793   0.020.232435
 -0.145611   -0.799793   1   0   1
 0.169229-0.38806-0.784145   0.020.169229
 -0.38806-0.784145   1   0   1
 

[Yade-dev] [Bug 1417080] Re: Clump::updateProperties results in NaNs for non-spherical particles

[Jan Stránský]

** Changed in: yade
   Status: New = Fix Released

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

Title:
  Clump::updateProperties results in NaNs for non-spherical particles

Status in Yet Another Dynamic Engine:
  Fix Released

Bug description:
  According to https://answers.launchpad.net/yade/+question/261529
  Since nobody needed it before, it was ok, but it would be nice to add also 
functionality for non-spherical shapes

  I report it mainly not to forget :-)

  Jan

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1417080/+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 1417080] [NEW] Clump::updateProperties results in NaNs for non-spherical particles

[Jan Stránský]

Public bug reported:

According to https://answers.launchpad.net/yade/+question/261529
Since nobody needed it before, it was ok, but it would be nice to add also 
functionality for non-spherical shapes

I report it mainly not to forget :-)

Jan

** Affects: yade
 Importance: Wishlist
 Assignee: Jan Stránský (honzik)
 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/1417080

Title:
  Clump::updateProperties results in NaNs for non-spherical particles

Status in Yet Another Dynamic Engine:
  New

Bug description:
  According to https://answers.launchpad.net/yade/+question/261529
  Since nobody needed it before, it was ok, but it would be nice to add also 
functionality for non-spherical shapes

  I report it mainly not to forget :-)

  Jan

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1417080/+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 1400075] Re: O.forces.addMove does not work

[Jan Stránský]

Hi Vaclav, yes, NewtonIntegrator is in O.engines by default if you do not
change it..
Jan


2014-12-19 16:57 GMT+01:00 Václav Šmilauer e...@doxos.eu:

 Hi, the code was always working, and still should be, in
 NewtonIntegrator.pp:208 (and 2 other lines for rotations) I read

if (scene-forces.getMoveRotUsed())
 state-pos+=scene-forces.getMove(id);

 It was supposed to impose displacement or rotation change directly, and
 to do it in a way which is thread-safe; changing b.vel may affect other
 computations going on in that timestep, plus it usually supposes that dt
 does not change between steps (not always the case). But I see there is
 only little use for it, and I would have to remember hard what was the
 reason to introduce it back then. There must have been one :)

 @Jan, do you have NewtonIntegrator in engines?

 --
 You received this bug notification because you are subscribed to the bug
 report.
 https://bugs.launchpad.net/bugs/1400075

 Title:
   O.forces.addMove does not work

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   Hi,

   I tried O.forces.addMove to apply displacement to a particle, but the
   method seems not to work..

   b = sphere((0,0,0),1)
   O.bodies.append(b)
   O.forces.addMove(0,(1,0,0))
   print b.state.pos # (0,0,0)
   O.step()
   print b.state.pos # is (0,0,0) again...

   Is this behavior ok, do I do something wrong or is it a bug?

   I use Ubuntu 14.04 and yade  2014-11-08.git-d693417

   Thanks
   Jan

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


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

Title:
  O.forces.addMove does not work

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Hi,

  I tried O.forces.addMove to apply displacement to a particle, but the
  method seems not to work..

  b = sphere((0,0,0),1)
  O.bodies.append(b)
  O.forces.addMove(0,(1,0,0))
  print b.state.pos # (0,0,0)
  O.step()
  print b.state.pos # is (0,0,0) again...

  Is this behavior ok, do I do something wrong or is it a bug?

  I use Ubuntu 14.04 and yade  2014-11-08.git-d693417

  Thanks
  Jan

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1400075/+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 1400075] [NEW] O.forces.addMove does not work

[Jan Stránský]

Public bug reported:

Hi,

I tried O.forces.addMove to apply displacement to a particle, but the
method seems not to work..

b = sphere((0,0,0),1)
O.bodies.append(b)
O.forces.addMove(0,(1,0,0))
print b.state.pos # (0,0,0)
O.step()
print b.state.pos # is (0,0,0) again...

Is this behavior ok, do I do something wrong or is it a bug?

I use Ubuntu 14.04 and yade  2014-11-08.git-d693417

Thanks
Jan

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

Title:
  O.forces.addMove does not work

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Hi,

  I tried O.forces.addMove to apply displacement to a particle, but the
  method seems not to work..

  b = sphere((0,0,0),1)
  O.bodies.append(b)
  O.forces.addMove(0,(1,0,0))
  print b.state.pos # (0,0,0)
  O.step()
  print b.state.pos # is (0,0,0) again...

  Is this behavior ok, do I do something wrong or is it a bug?

  I use Ubuntu 14.04 and yade  2014-11-08.git-d693417

  Thanks
  Jan

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1400075/+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 1380103] [NEW] memory leak?

[Jan Stránský]

Hello,

please always attach a minimal working script reproducing the error.

Thanks
Jan
Dne 11.10.2014 16:40 Sway zhs...@gmail.com napsal(a):

 Public bug reported:

 YADE version:1.11.1
 I simulated a packing with Polyhedra shape recently. When running about
 50,000 steps, a bug occurred casting information as follow:
 Error in `/usr/bin/python': malloc(): memory corruption (fast):
 0x7fc6780762d8
 So give me some hints to find the reason, please.

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

 Title:
   memory leak?

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   YADE version:1.11.1
   I simulated a packing with Polyhedra shape recently. When running about
 50,000 steps, a bug occurred casting information as follow:
   Error in `/usr/bin/python': malloc(): memory corruption (fast):
 0x7fc6780762d8
   So give me some hints to find the reason, please.

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

Title:
  memory leak?

Status in Yet Another Dynamic Engine:
  New

Bug description:
  YADE version:1.11.1
  I simulated a packing with Polyhedra shape recently. When running about 
50,000 steps, a bug occurred casting information as follow:
  Error in `/usr/bin/python': malloc(): memory corruption (fast): 
0x7fc6780762d8
  So give me some hints to find the reason, please.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1380103/+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 1376734] Re: wrong vtk output for boxes

[Jan Stránský]

Hi Christian,

I deleted that output, the problem was that the output is 6 faces of the
box instead of one body, which I did not realized.. fixed in r4180.
cheers
Jan


2014-10-07 8:02 GMT+02:00 Christian Jakob 1376...@bugs.launchpad.net:

 Hi Jan,

 I tested the output for facets, and it is ok. Just boxes vtk output
 seems to be wrong.

 For reproducing add this line at line 111 into examples/triax-tutorial
 /script-session1.py:

 VTKRecorder(iterPeriod=100,recorders=['all'],fileName='/tmp/triax-'),

 Then run the example for at least 100 steps and open /tmp/triax-
 boxes*.vtu with paraview. Click Apply to see the error message.

 Christian

 p.s. i also attached the script

 ** Attachment added: reproduce bug #1376734

 https://bugs.launchpad.net/yade/+bug/1376734/+attachment/4227157/+files/triax-vtk-bug-box.py

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

 Title:
   wrong vtk output for boxes

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   Hi,

   Since some weeks I have problems while open vtk files in paraview.
   When open boxes.vtk I get following error message:

   ERROR: In
 /home/utkarsh/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/VTK/IO/XML/vtkXMLDataReader.cxx,
 line 545
   vtkXMLUnstructuredGridReader (0x5c90990): Cannot read cell data array
 forceVec from PointData in piece 0.  The data array in the element may be
 too short.

   The same message appears for forceLen, torqueVec and torqueLen.
   By deselecting these properties in paraview, vtk file opens without
 error message.

   Maybe there is the same problem with facets, but I do not use them and
 did not check...
   Spheres vtk output is ok.

   I think it has to do with this commit:


 https://github.com/yade/trunk/commit/b1621bcf6c439a7b29b2220bfb1c40b1d5b8f7a6

   Regards,

   Christian

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



** Changed in: yade
   Status: New = Fix Released

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

Title:
  wrong vtk output for boxes

Status in Yet Another Dynamic Engine:
  Fix Released

Bug description:
  Hi,

  Since some weeks I have problems while open vtk files in paraview.
  When open boxes.vtk I get following error message:

  ERROR: In 
/home/utkarsh/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/VTK/IO/XML/vtkXMLDataReader.cxx,
 line 545
  vtkXMLUnstructuredGridReader (0x5c90990): Cannot read cell data array 
forceVec from PointData in piece 0.  The data array in the element may be too 
short.

  The same message appears for forceLen, torqueVec and torqueLen.
  By deselecting these properties in paraview, vtk file opens without error 
message.

  Maybe there is the same problem with facets, but I do not use them and did 
not check...
  Spheres vtk output is ok.

  I think it has to do with this commit:

  https://github.com/yade/trunk/commit/b1621bcf6c439a7b29b2220bfb1c40b1d5b8f7a6

  Regards,

  Christian

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1376734/+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 1376734] [NEW] wrong vtk output for boxes

[Jan Stránský]

Hi Christian,

it really seems like my fault.. could you please attach a simple script
producing vtk with boxes so I (or anybody else) can try it? I would fix it
next week..

Cheers
Jan
Dne 2.10.2014 14:40 Christian Jakob 1376...@bugs.launchpad.net
napsal(a):

 Public bug reported:

 Hi,

 Since some weeks I have problems while open vtk files in paraview.
 When open boxes.vtk I get following error message:

 ERROR: In
 /home/utkarsh/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/VTK/IO/XML/vtkXMLDataReader.cxx,
 line 545
 vtkXMLUnstructuredGridReader (0x5c90990): Cannot read cell data array
 forceVec from PointData in piece 0.  The data array in the element may be
 too short.

 The same message appears for forceLen, torqueVec and torqueLen.
 By deselecting these properties in paraview, vtk file opens without error
 message.

 Maybe there is the same problem with facets, but I do not use them and did
 not check...
 Spheres vtk output is ok.

 I think it has to do with this commit:


 https://github.com/yade/trunk/commit/b1621bcf6c439a7b29b2220bfb1c40b1d5b8f7a6

 Regards,

 Christian

 ** Affects: yade
  Importance: Undecided
  Status: New

 ** Attachment added: open this file in paraview to see the error message

 https://bugs.launchpad.net/bugs/1376734/+attachment/4222402/+files/2-boxes.256.vtu

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

 Title:
   wrong vtk output for boxes

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   Hi,

   Since some weeks I have problems while open vtk files in paraview.
   When open boxes.vtk I get following error message:

   ERROR: In
 /home/utkarsh/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/VTK/IO/XML/vtkXMLDataReader.cxx,
 line 545
   vtkXMLUnstructuredGridReader (0x5c90990): Cannot read cell data array
 forceVec from PointData in piece 0.  The data array in the element may be
 too short.

   The same message appears for forceLen, torqueVec and torqueLen.
   By deselecting these properties in paraview, vtk file opens without
 error message.

   Maybe there is the same problem with facets, but I do not use them and
 did not check...
   Spheres vtk output is ok.

   I think it has to do with this commit:


 https://github.com/yade/trunk/commit/b1621bcf6c439a7b29b2220bfb1c40b1d5b8f7a6

   Regards,

   Christian

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

Title:
  wrong vtk output for boxes

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Hi,

  Since some weeks I have problems while open vtk files in paraview.
  When open boxes.vtk I get following error message:

  ERROR: In 
/home/utkarsh/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/VTK/IO/XML/vtkXMLDataReader.cxx,
 line 545
  vtkXMLUnstructuredGridReader (0x5c90990): Cannot read cell data array 
forceVec from PointData in piece 0.  The data array in the element may be too 
short.

  The same message appears for forceLen, torqueVec and torqueLen.
  By deselecting these properties in paraview, vtk file opens without error 
message.

  Maybe there is the same problem with facets, but I do not use them and did 
not check...
  Spheres vtk output is ok.

  I think it has to do with this commit:

  https://github.com/yade/trunk/commit/b1621bcf6c439a7b29b2220bfb1c40b1d5b8f7a6

  Regards,

  Christian

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1376734/+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 1370736] [NEW] Outdated docs of LawFunctor in programmer's manual

[Jan Stránský]

Public bug reported:

In Programmer's manual, there is still
InteractionContainer::requestErase(id1,id2), while an information about
returning true/false should be there instead (?)

I am not very sure in this area to confirm and correct myself..

cheers
Jan

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

Title:
  Outdated docs of LawFunctor in programmer's manual

Status in Yet Another Dynamic Engine:
  New

Bug description:
  In Programmer's manual, there is still
  InteractionContainer::requestErase(id1,id2), while an information
  about returning true/false should be there instead (?)

  I am not very sure in this area to confirm and correct myself..

  cheers
  Jan

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1370736/+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] Body::groupMask could be unsigned int

[Jan Stránský]

Hi Anton,

thanks for the feedback.




 1) Please, add an option to CMakeLists, it can be a feature probably,
 disabled by default. There are a lot of examples there.


ok, before I will properly test it :-)



 2) [2]
 + bool maskOk(int mask) const {return (mask==0 || (bool)(groupMask 
 mask));}
 + bool maskCompatible(int mask) const { return (bool)(groupMask  mask); }
 +#ifdef BODY_GROUP_MASK_ARBITRARY_PRECISION
 + bool maskOk(const boost::python::long_ mask) const {return (mask==0
 || (bool)(groupMask  mask));}
 + bool maskCompatible(const boost::python::long_ mask) const { return
 (bool)(groupMask  mask); }
 +#endif

 Do you want to have both of these definitions if
 BODY_GROUP_MASK_ARBITRARY_PRECISION
 enabled ?

 [2]
 https://github.com/yade/trunk/commit/15bca1969f43e883bfe9835d4a985a2ead337a77#diff-e6b228e5bbf5122a3adb4478cf4effa2R78


I am soory, I am not sure what exactly is the point here :-) The duplicate
code in maskOk and maskCompatible? int argument is necessary as some other
classes uses ints (like NewtonIntegrator or
collider::avoidSelfInteractionMask), bp::long_ is optionally for body-body
evaluation. Probably I could template it.




 3) [3]
 + namespace bp = boost::python;
 You are there already in a namespace boost, you can just use
 python:: instead of bp::.

 [3 ]
 https://github.com/yade/trunk/commit/15bca1969f43e883bfe9835d4a985a2ead337a77#diff-e6b228e5bbf5122a3adb4478cf4effa2R144


Ok, thanks, I did not pay much attention to namespaces..


The only thing which is missing is automatic conversion from int to
bp::long_, I was not able to make it work..

cheers
Jan
___
Mailing list: https://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] Body::groupMask could be unsigned int

[Jan Stránský]

Hi Anton,
Do you mean to replace boost::python::long_ by groupMask_t?
if BODY_GROUP_MASK_ARBITRARY_PRECISION is defined, both argument types (int
and bp::long_) are needed..
cheers
Jan


2014-06-06 13:07 GMT+02:00 Anton Gladky gladky.an...@gmail.com:

 2014-06-06 10:47 GMT+02:00 Jan Stránský honzik.stran...@gmail.com:
  I am soory, I am not sure what exactly is the point here :-) The
 duplicate
  code in maskOk and maskCompatible? int argument is necessary as some
 other
  classes uses ints (like NewtonIntegrator or
  collider::avoidSelfInteractionMask), bp::long_ is optionally for
 body-body
  evaluation. Probably I could template it.

 From my point of view we should have just one possible typedef for
 groupmask: int or boost,
 depending on the BODY_GROUP_MASK_ARBITRARY_PRECISION flag.

 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

Re: [Yade-dev] Body::groupMask could be unsigned int

[Jan Stránský]

Hi Antom,
I changed my opinion such that using signed types and default value to -1
is the best choice (as -1 = 0b111... in unsigned equivalent, I missed
this feature before). To handle this in python one can use ctypes (c_int
and c_uint) to make the value signed/unsigned)
cheers
Jan





2014-05-26 21:08 GMT+02:00 Anton Gladky gladky.an...@gmail.com:

 Hi Jan,

 I agree with that. The problem is that we use in many parts of code
 the default mask value -1 [1]. All of them should be changed (probably
 also in some if-constructions). But I do not think it is a difficult,
 grep/sed should do thinks well.

 [1]
 https://github.com/yade/trunk/blob/master/pkg/dem/NewtonIntegrator.hpp#L79

 Best regards

 Anton


 2014-05-26 20:54 GMT+02:00 Jan Stránský honzik.stran...@gmail.com:
  Hello,
 
  currently I am running out of size of groupMask (I would need more
 bits), so
  I am planning to introduce optional compilation with some larger type.
  Anyway, even the size is the same, working with the full range of
 unsigned
  int bitmask is much more natural than standard signed int.
 
  Would anybody be against changing the type to unsigned int with default
  value UINT_MAX = 0b1..., i.e. the body would interact with anything
 by
  default?
 
  Thanks for the feedback
  Jan
 
  ___
  Mailing list: https://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] Body::groupMask could be unsigned int

[Jan Stránský]

Hello,

currently I am running out of size of groupMask (I would need more bits),
so I am planning to introduce optional compilation with some larger type.
Anyway, even the size is the same, working with the full range of unsigned
int bitmask is much more natural than standard signed int.

Would anybody be against changing the type to unsigned int with default
value UINT_MAX = 0b1..., i.e. the body would interact with anything by
default?

Thanks for the feedback
Jan
___
Mailing list: https://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 1318513] Re: utils.calm() calms only spheres and clumps

[Jan Stránský]

I left mask parameter for the purpose of slecting bodies to calm and
modified documentation of the function (the original version mentioned,
that the function calms all bodies, which was the source of my confusion).
Thanks for discussion
Jan



2014-05-12 12:06 GMT+02:00 Jan Stránský honzik.stran...@gmail.com:

 Ok, I will think about it and implement something in 2 weeks. If you
 wanted to do something earlier, feel free to modify it.
 cheers
 Jan


 2014-05-12 11:30 GMT+02:00 Anton Gladky 1318...@bugs.launchpad.net:

 Well, we have mask-parameter there, which is also relatively
 flexible. But includeList is also a good idea and will probably
 be even faster.

 Anton


 2014-05-12 11:18 GMT+02:00 Christian Jakob 1318...@bugs.launchpad.net:
  Hi,
 
  I implemented calm() and used it as alternative damping method (e.g.
  when using a small local damping in a sim.).
 
  From this discussion I can see, that an update is needed for this
  method.
 
  An easy way could be to introduce an includeBodyList (or an
 excludeBodyList).
  example:
 
  includeList = []
 
  for b in O.bodies:
if CONDITION:
  includeList.append(b.id)
 
  calm(includeList)

 --
 You received this bug notification because you are subscribed to the bug
 report.
 https://bugs.launchpad.net/bugs/1318513

 Title:
   utils.calm() calms only spheres and clumps

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   Fix is very easy, I just wanted to know opinion of other devs (e.g. if
   there is a reason I missed)

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





** Changed in: yade
   Status: New = Fix Released

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

Title:
  utils.calm() calms only spheres and clumps

Status in Yet Another Dynamic Engine:
  Fix Released

Bug description:
  Fix is very easy, I just wanted to know opinion of other devs (e.g. if
  there is a reason I missed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1318513/+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 1318513] [NEW] utils.calm() calms only spheres and clumps

[Jan Stránský]

Public bug reported:

Fix is very easy, I just wanted to know opinion of other devs (e.g. if
there is a reason I missed)

** Affects: yade
 Importance: Low
 Status: New

** Summary changed:

- utils.caml() calms only spheres and clumps
+ utils.calm() calms only spheres and clumps

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

Title:
  utils.calm() calms only spheres and clumps

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Fix is very easy, I just wanted to know opinion of other devs (e.g. if
  there is a reason I missed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1318513/+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 1318513] Re: utils.calm() calms only spheres and clumps

[Jan Stránský]

Hi Bruno,
this also came to my mind, but one if somebody prescribe a bc for spheres,
current calm function overwrite it anyway.. The function skip non-dynamic
bodies.
Thanks
Jan


2014-05-12 9:58 GMT+02:00 Bruno Chareyre 1318...@bugs.launchpad.net:

 I don't see a real reason to not calm other shapes.
 It may have unpleasant side effects to calm everything, like overwriting
 the velocity defined by the boundary control of rigid boundaries. But if
 this is a big deall the user can define his own calm function.

 --
 You received this bug notification because you are subscribed to the bug
 report.
 https://bugs.launchpad.net/bugs/1318513

 Title:
   utils.calm() calms only spheres and clumps

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   Fix is very easy, I just wanted to know opinion of other devs (e.g. if
   there is a reason I missed)

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


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

Title:
  utils.calm() calms only spheres and clumps

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Fix is very easy, I just wanted to know opinion of other devs (e.g. if
  there is a reason I missed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1318513/+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 1318513] Re: utils.calm() calms only spheres and clumps

[Jan Stránský]

Ok, I will think about it and implement something in 2 weeks. If you wanted
to do something earlier, feel free to modify it.
cheers
Jan


2014-05-12 11:30 GMT+02:00 Anton Gladky 1318...@bugs.launchpad.net:

 Well, we have mask-parameter there, which is also relatively
 flexible. But includeList is also a good idea and will probably
 be even faster.

 Anton


 2014-05-12 11:18 GMT+02:00 Christian Jakob 1318...@bugs.launchpad.net:
  Hi,
 
  I implemented calm() and used it as alternative damping method (e.g.
  when using a small local damping in a sim.).
 
  From this discussion I can see, that an update is needed for this
  method.
 
  An easy way could be to introduce an includeBodyList (or an
 excludeBodyList).
  example:
 
  includeList = []
 
  for b in O.bodies:
if CONDITION:
  includeList.append(b.id)
 
  calm(includeList)

 --
 You received this bug notification because you are subscribed to the bug
 report.
 https://bugs.launchpad.net/bugs/1318513

 Title:
   utils.calm() calms only spheres and clumps

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   Fix is very easy, I just wanted to know opinion of other devs (e.g. if
   there is a reason I missed)

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


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

Title:
  utils.calm() calms only spheres and clumps

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Fix is very easy, I just wanted to know opinion of other devs (e.g. if
  there is a reason I missed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1318513/+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 1300167] Re: (Not) Defining velocities in UniaxialStrainer ?

[Jan Stránský]

Hi Bruno,


 This engine has been introduced before effective integration of python.
 Is it doing something that can't be done with python?


despite this fact, you can just use one line in your python script in
O.engines instead of defining your own function and call it in PyRuuner..
It is true that (according to this thread), it is not maintained for some
time (e.g. directly prescribing displacements), but the functionality is in
general useful..



 Your case with this bug was typical. You could:
 1/ type a few python lines to do exactly what you want, or
 2/ learn how to use an engine, try it, realize that it is not doing what
 you think it would do, find a bug, report, get feedback, start fixing
 Coming soon: commit, push, get feedback again, etc.

 If this engine is removed you will:
 1/ type a few python lines to do exactly what you want
 Less compilation time for us all, less maintainance, less noise on the
 mailing list.


correct, but as more than one person may use it (me for example :-), it
does not matter if it is written in c++ or rewritten to python (somebody
would maintain it, test it, ask questions on mailing lists...)

cheers
Jan

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

Title:
  (Not) Defining velocities in UniaxialStrainer ?

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Hi,

  I have the feeling that there is something wrong with
  UniaxialStrainer where the velocities of the posIds and negIds
  bodies are not defined, and I illustrate it with following examples
  (attached)

  It deals with 2 contacting spheres, with an oblic contact. One sphere is 
moved towards the 2d sphere, and here both normal and tangential relative 
displacements occur. 
  - In testUS.py the moving sphere is moved through UniaxialStrainer
  - Whereas in testUSb.py the movement comes from an initial value of velocity 
(and NewtonIntegrator)

  And, obviously, the two simulations are different (see e.g. the plot
  of fZ sustained by moving sphere). While I would tend to consider
  these two simulations as identical.

  What do you think ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1300167/+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] Yade Workshop in Grenoble

[Jan Stránský]

I hope I will be there too :-)
Jan


2014-02-25 9:51 GMT+01:00 Bruno Chareyre bruno.chare...@hmg.inpg.fr:

 Dear all,

 This message is to announce the

 1st YADE Workshop(*), in Grenoble, july 7 to july 9, 2014.

 The main objective is to gather people interested in DEM-related
 developments, to discuss things like algorithmic issues, performance,
 parallelization, new models and couplings, experiences with various
 softwares, etc.

 Applications of the DEM are not the priority. However, some time may be
 allocated for them in order to have an overview of the current trends on
 this side (maybe half a day, in the form of 15' talks), especially for
 those applications that require new developments.
 The largest part of the workshop will be dedicated to the
 numerical/development aspects. And part of this (maybe the last day) will
 take the form of less formal meetings really focused on the Yade project.

 This workshop should be the opportunity for us all in yade-dev to know
 each other more directly, share ideas, and elaborate plans for the future.
 Occasions for such meetings are really rare, since we are distributed a bit
 everywhere around the world.

 With this email, I wanted to give you at least the dates, since jully is
 approaching already.
 At the moment, I would like to estimate the number of participants from
 yade-dev before opening the annoucement to a larger audience.

 *** If you think you will be able to attend the workshop, could you please
 send me an email? ***

 The registration will be free of charge for yade-dev members (subscribing
 to yade-dev later than today will not count!).
 A more detailed agenda will follow, which will be open for discussion here
 on yade-dev.
 If you have suggestions regarding topics to discuss or special events that
 you would like to see, feel free to suggest.

 With best regards.

 Bruno Chareyre

 (*) Yet Another Discrete Element workshop!


 ___
 Mailing list: https://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 1241817] Re: yade batch mode fails

[Jan Stránský]

Changed error message according to Nolan's suggestion in rev 3748

** Changed in: yade
   Status: New = Fix Released

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

Title:
  yade batch mode fails

Status in Yet Another Dynamic Engine:
  Fix Released

Bug description:
  when I try to run yade in batch mode it always fails, giving the error
  in a log file:

  Welcome to Yade 2013-10-16.git-fe8b27e 
  TCP python prompt on localhost:9000, auth cookie `kasdys'
  Warning: no X rendering available (see 
https://bbs.archlinux.org/viewtopic.php?id=13189)
  XMLRPC info provider on http://localhost:21000
  Running script ../periodic-sphere.py
  Traceback (most recent call last):
File /usr/local/bin/yade-2013-10-16.git-fe8b27e, line 174, in runScript
  execfile(script,globals())
File ../periodic-sphere.py, line 1, in module
  from yade import pack,export,utils,plot,qt
File 
/usr/local/lib/i386-linux-gnu/yade-2013-10-16.git-fe8b27e/py/yade/qt/__init__.py,
 line 3, in module
  if not yade.runtime.hasDisplay: raise ImportError(Connecting to DISPLAY 
at Yade startup failed, unable to activate the qt4 interface.)
  ImportError: Connecting to DISPLAY at Yade startup failed, unable to activate 
the qt4 interface.

  === JOB SUMMARY 
  id  : Row=0,numSpheres=100,REVL=0.636621,Save=1
  status  : 256 (FAILED)
  duration: 00:00:00
  command : YADE_BATCH=initparam.table:2 DISPLAY=  
/usr/local/bin/yade-2013-10-16.git-fe8b27e --threads=1 --nice=10 -x 
../periodic-sphere.py 
../periodic-sphere.py.Row=0,numSpheres=100,REVL=0.636621,Save=1.log 21
  started : Fri Oct 18 16:11:49 2013
  finished: Fri Oct 18 16:11:49 2013

  
---

  I am inline with the github revision
  5aa3f6f4856958a2062a0b8f0558857e86ee8a50 (Oct 16). The suggested
  ArchLinux link is dead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1241817/+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 1241817] [NEW] yade batch mode fails

[Jan Stránský]

Hello Nolan,

try to run yade-batch without GUI, i.e. without
from yade import qt
and let us know
cheers
Jan



2013/10/18 Nolan Dyck nd...@uwo.ca

 Public bug reported:

 when I try to run yade in batch mode it always fails, giving the error
 in a log file:

 Welcome to Yade 2013-10-16.git-fe8b27e
 TCP python prompt on localhost:9000, auth cookie `kasdys'
 Warning: no X rendering available (see
 https://bbs.archlinux.org/viewtopic.php?id=13189)
 XMLRPC info provider on http://localhost:21000
 Running script ../periodic-sphere.py
 Traceback (most recent call last):
   File /usr/local/bin/yade-2013-10-16.git-fe8b27e, line 174, in runScript
 execfile(script,globals())
   File ../periodic-sphere.py, line 1, in module
 from yade import pack,export,utils,plot,qt
   File
 /usr/local/lib/i386-linux-gnu/yade-2013-10-16.git-fe8b27e/py/yade/qt/__init__.py,
 line 3, in module
 if not yade.runtime.hasDisplay: raise ImportError(Connecting to
 DISPLAY at Yade startup failed, unable to activate the qt4 interface.)
 ImportError: Connecting to DISPLAY at Yade startup failed, unable to
 activate the qt4 interface.

 === JOB SUMMARY 
 id  : Row=0,numSpheres=100,REVL=0.636621,Save=1
 status  : 256 (FAILED)
 duration: 00:00:00
 command : YADE_BATCH=initparam.table:2 DISPLAY=
  /usr/local/bin/yade-2013-10-16.git-fe8b27e --threads=1 --nice=10 -x
 ../periodic-sphere.py
 ../periodic-sphere.py.Row=0,numSpheres=100,REVL=0.636621,Save=1.log 21
 started : Fri Oct 18 16:11:49 2013
 finished: Fri Oct 18 16:11:49 2013


 ---

 I am inline with the github revision
 5aa3f6f4856958a2062a0b8f0558857e86ee8a50 (Oct 16). The suggested
 ArchLinux link is dead.

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

 Title:
   yade batch mode fails

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   when I try to run yade in batch mode it always fails, giving the error
   in a log file:

   Welcome to Yade 2013-10-16.git-fe8b27e
   TCP python prompt on localhost:9000, auth cookie `kasdys'
   Warning: no X rendering available (see
 https://bbs.archlinux.org/viewtopic.php?id=13189)
   XMLRPC info provider on http://localhost:21000
   Running script ../periodic-sphere.py
   Traceback (most recent call last):
 File /usr/local/bin/yade-2013-10-16.git-fe8b27e, line 174, in
 runScript
   execfile(script,globals())
 File ../periodic-sphere.py, line 1, in module
   from yade import pack,export,utils,plot,qt
 File
 /usr/local/lib/i386-linux-gnu/yade-2013-10-16.git-fe8b27e/py/yade/qt/__init__.py,
 line 3, in module
   if not yade.runtime.hasDisplay: raise ImportError(Connecting to
 DISPLAY at Yade startup failed, unable to activate the qt4 interface.)
   ImportError: Connecting to DISPLAY at Yade startup failed, unable to
 activate the qt4 interface.

   === JOB SUMMARY 
   id  : Row=0,numSpheres=100,REVL=0.636621,Save=1
   status  : 256 (FAILED)
   duration: 00:00:00
   command : YADE_BATCH=initparam.table:2 DISPLAY=
  /usr/local/bin/yade-2013-10-16.git-fe8b27e --threads=1 --nice=10 -x
 ../periodic-sphere.py
 ../periodic-sphere.py.Row=0,numSpheres=100,REVL=0.636621,Save=1.log 21
   started : Fri Oct 18 16:11:49 2013
   finished: Fri Oct 18 16:11:49 2013


 ---

   I am inline with the github revision
   5aa3f6f4856958a2062a0b8f0558857e86ee8a50 (Oct 16). The suggested
   ArchLinux link is dead.

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

Title:
  yade batch mode fails

Status in Yet Another Dynamic Engine:
  New

Bug description:
  when I try to run yade in batch mode it always fails, giving the error
  in a log file:

  Welcome to Yade 2013-10-16.git-fe8b27e 
  TCP python prompt on localhost:9000, auth cookie `kasdys'
  Warning: no X rendering available (see 
https://bbs.archlinux.org/viewtopic.php?id=13189)
  XMLRPC info provider on http://localhost:21000
  Running script ../periodic-sphere.py
  Traceback (most recent call last):
File /usr/local/bin/yade-2013-10-16.git-fe8b27e, line 174, in runScript
  execfile(script,globals())
File ../periodic-sphere.py, line 1, in module
  from yade import pack,export,utils,plot,qt
File 

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3705: Explicitly link ZLIB-library

[Jan Stránský]

Hi Anton,

I cloned yade from the scratch, but when running cmake, following error
ocure:

CMake Error at
/home/honzik/programs/cmake-2.8.10.2-Linux-i386/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97
(message):
  Could NOT find BZip2 (missing: BZIP2_LIBRARIES BZIP2_INCLUDE_DIR)
Call Stack (most recent call first):

/home/honzik/programs/cmake-2.8.10.2-Linux-i386/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291
(_FPHSA_FAILURE_MESSAGE)

/home/honzik/programs/cmake-2.8.10.2-Linux-i386/share/cmake-2.8/Modules/FindBZip2.cmake:47
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:81 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!

I am using ubuntu 12.04 and have bzip2 package insatlled with apt-get
install.. Do you know where the problem could be?
Thanks
Jan




2013/10/9 nore...@launchpad.net

 
 revno: 3705
 committer: Anton Gladky gladky.an...@gmail.com
 timestamp: Wed 2013-10-09 07:37:48 +0200
 message:
   Explicitly link ZLIB-library

   See https://answers.launchpad.net/yade/+question/237009
 modified:
   CMakeLists.txt


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

 === modified file 'CMakeLists.txt'
 --- CMakeLists.txt  2013-10-08 11:28:19 +
 +++ CMakeLists.txt  2013-10-09 05:37:48 +
 @@ -79,6 +79,7 @@
INCLUDE_DIRECTORIES(${LOKI_INCLUDE_DIR})
  FIND_PACKAGE(Eigen3 REQUIRED)
  FIND_PACKAGE(BZip2 REQUIRED)
 +FIND_PACKAGE(ZLIB REQUIRED)
  #===

  SET(DEFAULT ON CACHE INTERNAL Default value for enabled by default
 options)
 @@ -104,7 +105,8 @@
  ENDIF(EIGEN3_FOUND)
  #===
  INCLUDE_DIRECTORIES(${BZIP2_INCLUDE_DIR})
 -SET(LINKLIBS  ${LINKLIBS};${BZIP2_LIBRARIES};)
 +INCLUDE_DIRECTORIES(${ZLIB_INCLUDE_DIRS})
 +SET(LINKLIBS  ${LINKLIBS};${BZIP2_LIBRARIES};${ZLIB_LIBRARIES};)
  #===
  IF(ENABLE_VTK)
FIND_PACKAGE(VTK COMPONENTS Common)


 ___
 Mailing list: https://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 3705: Explicitly link ZLIB-library

[Jan Stránský]

Hi Anton
with libbz2-dev there is no problem.
Thanks
Jan


2013/10/9 Anton Gladky gladky.an...@gmail.com

 Could you, please, install libbz2-dev and let me know?

 Thanks

 Anton


 2013/10/9 Jan Stránský honzik.stran...@gmail.com:
  Hi Anton,
 
  I cloned yade from the scratch, but when running cmake, following error
  ocure:
 
  CMake Error at
 
 /home/honzik/programs/cmake-2.8.10.2-Linux-i386/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97
  (message):
Could NOT find BZip2 (missing: BZIP2_LIBRARIES BZIP2_INCLUDE_DIR)
  Call Stack (most recent call first):
 
 
 /home/honzik/programs/cmake-2.8.10.2-Linux-i386/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291
  (_FPHSA_FAILURE_MESSAGE)
 
 
 /home/honzik/programs/cmake-2.8.10.2-Linux-i386/share/cmake-2.8/Modules/FindBZip2.cmake:47
  (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:81 (FIND_PACKAGE)
 
 
  -- Configuring incomplete, errors occurred!
 
  I am using ubuntu 12.04 and have bzip2 package insatlled with apt-get
  install.. Do you know where the problem could be?
  Thanks
  Jan

___
Mailing list: https://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] About tetra elements and their contact algorithms usability in deformable tetra elements

[Jan Stránský]

Hello Burak,

the current tetra contact algorithm is implemented by myself, but it was a
bit quick work and I am a bit afraid that there are some cases the
algorithm would not work (ar at least not properly). Anyway I think it is
possible to use it at least as a starter.

If you know contact forces and contact points, it is possible to
interpolate these forces to nodes (tetra's vertices). So what you asked
should be possible.

For the FEM like particles, do you plan to use elastic behavior, or also
some more complicated constitutive law? Recently I did some work of the
same kind, but using an external FEM program.. I will put the information
on wiki in a few days time.

cheers
Jan




2013/9/23 Burak ER burak...@btu.edu.tr

 Dear Yade Developers,

 Salutes again. This time, I just want to know if it is possible to use
 current rigid tetra algorithms in deformable tetrahedral elements. As some
 of you would
 already know it(Especially Mr. Chareyre): I am developing individual
 deformable elements into yade.

 I want to use present contact algorithms that are for rigid tetra
 elements also for deformable tetra elements.I think about applying
 contact force as a surface traction or any other sensible kind of force
 type. Is it possible?

 Thank you in advance.

 Burak ER, M.Sc. Mechanical Engineer

 --
 Research Assistant

 Mechanical Engineering Department

 Bursa Technical University

 Bursa, Turkey




 ___
 Mailing list: https://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] undefined symbol: mpfr_init2

[Jan Stránský]

Hi Bruno and Anton,

thanks for the answers.

@Bruno: I will try it. I am using Polyhedron_3 and Nef_polyherdon_3. As a
kernel I use Exact_predicates_exact_constructions_kernel, I also tried
CartesianCGAL::Gmpz (did not help) and
Exact_predicates_inexact_constructions_kernel (compilation error)..

@Anton: Ubuntu 12.04

Jan
___
Mailing list: https://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] eigen2

[Jan Stránský]

Hello,

according to question #233320, I am correcting the code to compile without
errors with WUAD_PRECISION defined. I touched also some parts, whrer there
is eigen3/eigen2 split. I am using eigen3 (with which I can make all tests
etc.). Before pushing these changes, I would like to ask, If I shoud
recompile and test the code also against eigen2, or if eigen2 is supposed
not to be supported any more.

Thanks
Jan
___
Mailing list: https://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] 0bab9e: midified exporter.VTKExporter for correct interact...

[Jan Stránský]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: 0bab9e93603ecd523946bd17b562073a3b4a67b4
  
https://github.com/yade/trunk/commit/0bab9e93603ecd523946bd17b562073a3b4a67b4
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2013-07-10 (Wed, 10 Jul 2013)

  Changed paths:
M examples/test/vtk-exporter/vtkExporter.py
M py/export.py

  Log Message:
  ---
  midified exporter.VTKExporter for correct interactions export in periodic case



___
Mailing list: https://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] 7cba6c: export.VTKExporter improvement (intaractions expor...

[Jan Stránský]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: 7cba6c516ebf9503a94c303a3854297e7d903d7b
  
https://github.com/yade/trunk/commit/7cba6c516ebf9503a94c303a3854297e7d903d7b
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2013-07-09 (Tue, 09 Jul 2013)

  Changed paths:
M examples/test/vtk-exporter/vtkExporter.py
M lib/base/Math.hpp
M pkg/dem/PeriIsoCompressor.cpp
M pkg/dem/PeriIsoCompressor.hpp
M py/export.py
M py/mathWrap/miniEigen.cpp

  Log Message:
  ---
  export.VTKExporter improvement (intaractions export), SVD matrix 
decomposition in python, Peri3dController improvement (compatibility with 
O.save/O.load)


  Commit: 654a0ec792c9103bee6b9eac27cb165ba629a1ad
  
https://github.com/yade/trunk/commit/654a0ec792c9103bee6b9eac27cb165ba629a1ad
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2013-07-09 (Tue, 09 Jul 2013)

  Changed paths:
M pkg/dem/PeriIsoCompressor.hpp

  Log Message:
  ---
  doc improvement of Peri3dController


  Commit: 7ea207ee8686dfae2480950007f86a4a02ba5271
  
https://github.com/yade/trunk/commit/7ea207ee8686dfae2480950007f86a4a02ba5271
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2013-07-09 (Tue, 09 Jul 2013)

  Changed paths:
M doc/references.bib
A examples/LudingPM.py
M pkg/dem/BubbleMat.hpp
A pkg/dem/LudingPM.cpp
A pkg/dem/LudingPM.hpp
M py/tests/clump.py

  Log Message:
  ---
  Merge branch 'master' of http://github.com/yade/trunk


Compare: https://github.com/yade/trunk/compare/ebb7fec9cfa8...7ea207ee8686
___
Mailing list: https://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/trunk] 7cba6c: export.VTKExporter improvement (intaractions expor...

[Jan Stránský]

Hi Anton,
sorry, I haven't seen these aspects (although they are clear and logical
:-). I hope, that what I added now won't break anything (it is only python
interface). Anyway I will contact Vaclav and add those new features to his
project.
cheers
Jan
___
Mailing list: https://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_CLASS... macros and variables exluded from documentation

[Jan Stránský]

Hello,
is it possible to have a variable in YADE_CLASS_.. macros in ATTRS section,
but not have it in the documentation?
Thanks
Jan
___
Mailing list: https://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] 0d7969: Improved documentation about O.load and O.save, mo...

[Jan Stránský]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: 0d796947ba8b2514ab7bf1aae2fc39961174af1b
  
https://github.com/yade/trunk/commit/0d796947ba8b2514ab7bf1aae2fc39961174af1b
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2013-06-20 (Thu, 20 Jun 2013)

  Changed paths:
M py/wrapper/yadeWrapper.cpp

  Log Message:
  ---
  Improved documentation about O.load and O.save, motivated by question #230900



___
Mailing list: https://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] Facets with forces information in vertices

[Jan Stránský]

Dear Yade developers,

I would like to have information of forces in individual vertices of
facets. It should not be very difficult (class Facet would be changed and
related igeom functors), but I would like to ask, if you prefere to include
it in current Facet class, or if I should create new class for this purpose
(mainly because of igeom functors).

Thanks for opinions
Jan
___
Mailing list: https://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 1175574] Re: spherePacking warning pack.randomDensePack

[Jan Stránský]

Hi Eugen,


Following [1] it is possible to save created packings in a database. This
 way they will be taken from there if the same packing shall be created
 again.
 For using this you need to set 'memoizeDb' to the name (path) of the
 database.
 Obviously [2] this only works for spheresInCell0 that is periodic
 packings. If I understand this point right periodic packings are related to
 simulations with periodic boundary conditions?
 Why is it not possible to reload packings in not periodic simulations?


From the source code, it seems that really only periodic packings are
loaded from database.. anyway, spheresInCell parameter means, that the
initial packing is created using periodic boundary conditions [1], *NOT*
necessarilly usable only in simulations with periodic boundary conditions.
Basicly, the periodic packing packing (cube) is created, than copied in
space to cover all needed volume defined by predicate and particles outside
predicate are deleted (this is for illustration, the actual implementation
may differ..). So you can use it for any simulation. To be more precise,
use randomDensePack for non-periodic simulations (even though
randomDensePack itself uses periodic boundary conditions) and
randomPeriPack for periodic simulations.

HTH
Jan

[1] https://yade-dem.org/doc/user.html#dynamic

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

Title:
  spherePacking warning pack.randomDensePack

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Hi,
  making use of pack.randomDensePack to fill up a predicate gives the following 
warning:

  WARN  /build/buildd/yade-daily-3+3463+44~precise1/pkg/dem/SpherePack.cpp:107 
makeCloud: porosity must be 0, changing it for you. It will be ineffective if 
rMean0.
  WARN  
/build/buildd/yade-daily-3+3463+44~precise1/pkg/dem/TriaxialCompressionEngine.cpp:110
 action: This engine is deprecated, please switch to TriaxialStressController 
if you expect long term support.
  /usr/lib/yade-daily/py/yade/pack.py:288: FutureWarning: The default behavior 
will change; specify returnSpherePack=True for the new behavior, and False to 
get rid of this warning (your code will break in the future, however). The 
returned SpherePack object can be added to the simulation using 
SpherePack.toSimulation()
warnings.warn('The default behavior will change; specify 
returnSpherePack=True for the new behavior, and False to get rid of this 
warning (your code will break in the future, however). The returned SpherePack 
object can be added to the simulation using 
SpherePack.toSimulation()',category=FutureWarning)
   
  Does this method need an update?
This engine is deprecated, please switch to TriaxialStressController if 
you expect long term support.
  the method works as supposed but the warning is annoying.

  I attached a minimum working example this time ;)

  Thanks, Eugen

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1175574/+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 1175574] [NEW] spherePacking warning pack.randomDensePack

[Jan Stránský]

Hi Eugen,

randomDensePack calls TriaxialTest internally [1], which
calls TriaxialCompressionEngine internally [2], which is deprecated. So, as
the warning says, it should be replaced by TriaxialStressController. I have
no time to do it now, but this information may be useful for other people
willing to fix it.
cheers
Jan

[1]
http://bazaar.launchpad.net/~yade-pkg/yade/git-trunk/view/head:/py/pack/pack.py#L462
[2]
http://bazaar.launchpad.net/~yade-pkg/yade/git-trunk/view/head:/pkg/dem/TriaxialTest.cpp#L276

PS: thanks for attached minimal working example, things are much easier
then :-)


2013/5/2 Eugen Kubowsky 1175...@bugs.launchpad.net

 Public bug reported:

 Hi,
 making use of pack.randomDensePack to fill up a predicate gives the
 following warning:

 WARN
  /build/buildd/yade-daily-3+3463+44~precise1/pkg/dem/SpherePack.cpp:107
 makeCloud: porosity must be 0, changing it for you. It will be ineffective
 if rMean0.
 WARN
  
 /build/buildd/yade-daily-3+3463+44~precise1/pkg/dem/TriaxialCompressionEngine.cpp:110
 action: This engine is deprecated, please switch to
 TriaxialStressController if you expect long term support.
 /usr/lib/yade-daily/py/yade/pack.py:288: FutureWarning: The default
 behavior will change; specify returnSpherePack=True for the new behavior,
 and False to get rid of this warning (your code will break in the future,
 however). The returned SpherePack object can be added to the simulation
 using SpherePack.toSimulation()
   warnings.warn('The default behavior will change; specify
 returnSpherePack=True for the new behavior, and False to get rid of this
 warning (your code will break in the future, however). The returned
 SpherePack object can be added to the simulation using
 SpherePack.toSimulation()',category=FutureWarning)

 Does this method need an update?
   This engine is deprecated, please switch to TriaxialStressController if
 you expect long term support.
 the method works as supposed but the warning is annoying.

 I attached a minimum working example this time ;)

 Thanks, Eugen

 ** Affects: yade
  Importance: Undecided
  Status: New

 ** Attachment added: spherePackWarning.py

 https://bugs.launchpad.net/bugs/1175574/+attachment/3662495/+files/spherePackWarning.py

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

 Title:
   spherePacking warning pack.randomDensePack

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   Hi,
   making use of pack.randomDensePack to fill up a predicate gives the
 following warning:

   WARN
  /build/buildd/yade-daily-3+3463+44~precise1/pkg/dem/SpherePack.cpp:107
 makeCloud: porosity must be 0, changing it for you. It will be ineffective
 if rMean0.
   WARN
  
 /build/buildd/yade-daily-3+3463+44~precise1/pkg/dem/TriaxialCompressionEngine.cpp:110
 action: This engine is deprecated, please switch to
 TriaxialStressController if you expect long term support.
   /usr/lib/yade-daily/py/yade/pack.py:288: FutureWarning: The default
 behavior will change; specify returnSpherePack=True for the new behavior,
 and False to get rid of this warning (your code will break in the future,
 however). The returned SpherePack object can be added to the simulation
 using SpherePack.toSimulation()
 warnings.warn('The default behavior will change; specify
 returnSpherePack=True for the new behavior, and False to get rid of this
 warning (your code will break in the future, however). The returned
 SpherePack object can be added to the simulation using
 SpherePack.toSimulation()',category=FutureWarning)

   Does this method need an update?
 This engine is deprecated, please switch to TriaxialStressController
 if you expect long term support.
   the method works as supposed but the warning is annoying.

   I attached a minimum working example this time ;)

   Thanks, Eugen

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

Title:
  spherePacking warning pack.randomDensePack

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Hi,
  making use of pack.randomDensePack to fill up a predicate gives the following 
warning:

  WARN  /build/buildd/yade-daily-3+3463+44~precise1/pkg/dem/SpherePack.cpp:107 
makeCloud: porosity must be 0, changing it for you. It will be ineffective if 
rMean0.
  WARN  
/build/buildd/yade-daily-3+3463+44~precise1/pkg/dem/TriaxialCompressionEngine.cpp:110
 action: This engine is deprecated, please switch to TriaxialStressController 
if you expect long 

Re: [Yade-dev] [Bug 1174749] Re: Controller Engines - Engine count starts at 0 instead of 1

[Jan Stránský]

Ok, sorry, I missed that the bug is related to qt.Contorller, thanks for
the information :-)
Jan


2013/4/30 Eugen Kubowsky 1174...@bugs.launchpad.net

 Hi Jan,
 please have a look at the screenshot I attached.
 I missed referencing it in the bug repot, sorry.
 In ipython you get the right values but in the qt.Controller - Inspect -
 Engines - Engine Drop Down Menu
 you will see something like

 0/6 ForceResetter
 ...
 5/6 NewtonIntegrator


 I think it should be:
 1/6 ForceResetter
 ...
 6/6 NewtonIntegrator

 so the counter before the slash should be index of engine+1.
 But as I said before, it's just a disfigurement.

 greetings,
 Eugen

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

 Title:
   Controller Engines - Engine count starts at 0 instead of 1

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   Hi,
   I've seen a little bug. not critical.
   If you browse the Engines of your simulation the first Engine starts
 with number 0. It should be 1 because the number of engines is defined as
 len(enginelist)+1 seemingly.

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

Title:
  Controller Engines - Engine count starts at 0 instead of 1

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Hi,
  I've seen a little bug. not critical.
  If you browse the Engines of your simulation the first Engine starts with 
number 0. It should be 1 because the number of engines is defined as 
len(enginelist)+1 seemingly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1174749/+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] [yade/trunk] 1bd7c9: added ymport.iges function for reading facets from...

[Jan Stránský]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: 1bd7c9853a110e373f717fca01621a21038f05cd
  
https://github.com/yade/trunk/commit/1bd7c9853a110e373f717fca01621a21038f05cd
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2013-04-24 (Wed, 24 Apr 2013)

  Changed paths:
M py/ymport.py

  Log Message:
  ---
  added ymport.iges function for reading facets from .igs files


  Commit: f989c9afbe9feacaf3199ac29437025b8503d81d
  
https://github.com/yade/trunk/commit/f989c9afbe9feacaf3199ac29437025b8503d81d
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2013-04-24 (Wed, 24 Apr 2013)

  Changed paths:
M doc/sphinx/prog.rst
M py/timing.py
M py/ymport.py

  Log Message:
  ---
  updated timing documentation


  Commit: b815cce852d1a0078c34c29bb0f0a41fbcf0fad8
  
https://github.com/yade/trunk/commit/b815cce852d1a0078c34c29bb0f0a41fbcf0fad8
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2013-04-24 (Wed, 24 Apr 2013)

  Changed paths:
M doc/sphinx/fig/dispatch-loop.svg
M doc/sphinx/formulation.rst
M doc/sphinx/introduction.rst
M doc/sphinx/prog.rst
M doc/sphinx/user.rst
M examples/bulldozer/README
M examples/bulldozer/bulldozer.py
M examples/concrete/README
R examples/concrete/cpm-dem3dof-scgeom.py
R examples/concrete/dem3dof-scgeom.table
M examples/concrete/periodic.py
M examples/concrete/uniax.py
M examples/test/peri3dController_shear.py
M examples/test/peri3dController_triaxialCompression.py
M examples/test/test_Ip2_FrictMat_CpmMat_FrictPhys.py
M pkg/dem/ConcretePM.cpp
M pkg/dem/ConcretePM.hpp
M pkg/dem/VTKRecorder.hpp
M py/eudoxos.py

  Log Message:
  ---
  updated documentation (due to recent changes in Cpm), corrected Cpm related 
examples


Compare: https://github.com/yade/trunk/compare/e9dbeff93c94...b815cce852d1
___
Mailing list: https://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] e9dbef: modification of cpm model, making easier timing in...

[Jan Stránský]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: e9dbeff93c94ce1e38832ad2110ffb5b14950793
  
https://github.com/yade/trunk/commit/e9dbeff93c94ce1e38832ad2110ffb5b14950793
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2013-04-23 (Tue, 23 Apr 2013)

  Changed paths:
M core/Engine.hpp
M core/Functor.hpp
M pkg/common/InteractionLoop.cpp
M pkg/common/InteractionLoop.hpp
M pkg/dem/ConcretePM.cpp
M pkg/dem/ConcretePM.hpp
M pkg/dem/Ig2_Facet_Sphere_ScGeom.cpp
M pkg/dem/Ig2_Sphere_Sphere_ScGeom.cpp
M py/timing.py

  Log Message:
  ---
  modification of cpm model, making easier timing inside InteractionLoop (with 
CMAKE_CXX_FLAGS=-DUSE_TIMING_DELTAS build, no change otherwise)



___
Mailing list: https://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 1166161] [NEW] utils.box() vs. box()

[Jan Stránský]

Hello Christian,
I was not able to reproduce your error.. Is it possible, taht you define
box function or variable in your script before this call? In case you
will not solve the problem, please attach a script, where the error is
reproducable.
Thanks
Jan


2013/4/8 Christian Jakob 1166...@bugs.launchpad.net

 Public bug reported:

 Hi,

 I removed all utils stuff from my scripts, now I got this error:

 O.bodies.append(box(vec1,vec2,fixed=True,material=WallMat))
 TypeError: box() takes at most 1 argument (4 given)

 Is it a bug?

 ... it is working using utils.box() instead of box()

 ** Affects: yade
  Importance: Low
  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/1166161

 Title:
   utils.box() vs. box()

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   Hi,

   I removed all utils stuff from my scripts, now I got this error:

   O.bodies.append(box(vec1,vec2,fixed=True,material=WallMat))
   TypeError: box() takes at most 1 argument (4 given)

   Is it a bug?

   ... it is working using utils.box() instead of box()

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

Title:
  utils.box() vs. box()

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Hi,

  I removed all utils stuff from my scripts, now I got this error:

  O.bodies.append(box(vec1,vec2,fixed=True,material=WallMat))
  TypeError: box() takes at most 1 argument (4 given)

  Is it a bug?

  ... it is working using utils.box() instead of box()

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1166161/+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] wiki does not work

[Jan Stránský]

Hello,
I wanted to modify something on wiki, but whan I click preview or save, I
got
Error 101(net::ERR_CONNECTION_RESET)
It is not only at the moment, but I am getting this error for more than one
week.. Do you know what could be the problem and if it is on my side?
Thanks
Jan
___
Mailing list: https://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 1134422] Re: The version argument to ArgumentParser is deprecated.

[Jan Stránský]

Hello,

in last commit, this bug should be fixed. I removed the deprication warning
reported by Bruno and left old optparse module if argparse is not found,
reported by Christian.
I am sorry for the problems, I did not expect them while using
non-deprecated module instead of the deprecated one :-)

Please try the new version and in case of no troubles, close the bug.
Cheers
Jan


2013/2/28 Jan Stránský honzik.stran...@gmail.com

 The deprication warning is because of arguments of the parser.
 Unfortunately the argparse module is not 100% compatible with optparse. I
 will solve it today.
 Jan
 Dne 27.2.2013 21:25 Bruno Chareyre 1134...@bugs.launchpad.net
 napsal(a):

 Thanks Jan. It is a bit surprising to see a deprecation warning appear
 when an old module is replaced by a new one!

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

 Title:
   The version argument to ArgumentParser is deprecated.

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   What is that? (ubuntu 10.04)

   me: ./yade
   /usr/lib/pymodules/python2.6/argparse.py:1576: DeprecationWarning: The
 version argument to ArgumentParser is deprecated. Please use
 add_argument(..., action='version', version=N, ...) instead
 instead, DeprecationWarning)
   Welcome to Yade 2013-02-26.git-e25a399

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

Title:
  The version argument to ArgumentParser is deprecated.

Status in Yet Another Dynamic Engine:
  New

Bug description:
  What is that? (ubuntu 10.04)

  me: ./yade
  /usr/lib/pymodules/python2.6/argparse.py:1576: DeprecationWarning: The 
version argument to ArgumentParser is deprecated. Please use 
add_argument(..., action='version', version=N, ...) instead
instead, DeprecationWarning)
  Welcome to Yade 2013-02-26.git-e25a399

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1134422/+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] [yade/trunk] 027a4e: modified yade executable, fixing bug 1134422

[Jan Stránský]

Hi Anton,

Bruno could start Yade without problems, he only got deprecation warning
from argparse.ArgumentParser ('version' argument was ok with optparse, but
was depricated in argparse, so now it is deleted)

I agree to delete optparse and leave only argparse, but for a certain time
I would leave both together to prevent situations like Christians's, who
was not able to start Yade at all. Now he would get warning to update
python module.

Jan


2013/2/28 Anton Gladky gladky.an...@gmail.com

 Jan, I do not think, it will fix Bruno's problem.

 I think, we should use argparser, not both, because it is a mess.

 Bruno, can you start yade now?

 Anton


 2013/2/28 Jan Stransky jan.stran...@fsv.cvut.cz:
Branch: refs/heads/master
Home:   https://github.com/yade/trunk
Commit: 027a4e8682620f2b226497301fa5ca555037
 
 https://github.com/yade/trunk/commit/027a4e8682620f2b226497301fa5ca555037
Author: Jan Stransky jan.stran...@fsv.cvut.cz
Date:   2013-02-28 (Thu, 28 Feb 2013)
 
Changed paths:
  M core/main/main.py.in
 
Log Message:
---
modified yade executable, fixing bug 1134422
 
 
 
 
  ___
  Mailing list: https://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] [Bug 1134422] Re: The version argument to ArgumentParser is deprecated.

[Jan Stránský]

Hi guys,

I have changed optparse module in yade executable (which is deprecated for
s long time) to argparse module. I thought, that argparse is present in all
python distributions, but evidently not 100%.

@Christian: sudo apt-get install python-argparse
which was already added to documentation by Anton in one of previous
commits.

@Bruno: I will have a look

sorry for the problems
Jan


2013/2/27 Christian Jakob 1134...@bugs.launchpad.net

 @Bruno: Be lucky, that your yade starts!
 I get:

 Traceback (most recent call last):
   File /home/me/YADE/YADEinstalled/bins/yade-2013-02-27.git-ee85e8a,
 line 38, in module
 import argparse
 ImportError: No module named argparse

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

 Title:
   The version argument to ArgumentParser is deprecated.

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   What is that? (ubuntu 10.04)

   me: ./yade
   /usr/lib/pymodules/python2.6/argparse.py:1576: DeprecationWarning: The
 version argument to ArgumentParser is deprecated. Please use
 add_argument(..., action='version', version=N, ...) instead
 instead, DeprecationWarning)
   Welcome to Yade 2013-02-26.git-e25a399

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

Title:
  The version argument to ArgumentParser is deprecated.

Status in Yet Another Dynamic Engine:
  New

Bug description:
  What is that? (ubuntu 10.04)

  me: ./yade
  /usr/lib/pymodules/python2.6/argparse.py:1576: DeprecationWarning: The 
version argument to ArgumentParser is deprecated. Please use 
add_argument(..., action='version', version=N, ...) instead
instead, DeprecationWarning)
  Welcome to Yade 2013-02-26.git-e25a399

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1134422/+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 1134422] Re: The version argument to ArgumentParser is deprecated.

[Jan Stránský]

The deprication warning is because of arguments of the parser.
Unfortunately the argparse module is not 100% compatible with optparse. I
will solve it today.
Jan
Dne 27.2.2013 21:25 Bruno Chareyre 1134...@bugs.launchpad.net napsal(a):

 Thanks Jan. It is a bit surprising to see a deprecation warning appear
 when an old module is replaced by a new one!

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

 Title:
   The version argument to ArgumentParser is deprecated.

 Status in Yet Another Dynamic Engine:
   New

 Bug description:
   What is that? (ubuntu 10.04)

   me: ./yade
   /usr/lib/pymodules/python2.6/argparse.py:1576: DeprecationWarning: The
 version argument to ArgumentParser is deprecated. Please use
 add_argument(..., action='version', version=N, ...) instead
 instead, DeprecationWarning)
   Welcome to Yade 2013-02-26.git-e25a399

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

Title:
  The version argument to ArgumentParser is deprecated.

Status in Yet Another Dynamic Engine:
  New

Bug description:
  What is that? (ubuntu 10.04)

  me: ./yade
  /usr/lib/pymodules/python2.6/argparse.py:1576: DeprecationWarning: The 
version argument to ArgumentParser is deprecated. Please use 
add_argument(..., action='version', version=N, ...) instead
instead, DeprecationWarning)
  Welcome to Yade 2013-02-26.git-e25a399

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1134422/+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] [yade/trunk] ae3473: minor changes

[Jan Stránský]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: ae347353c1a80b226907607290b4a76ff0a81264
  
https://github.com/yade/trunk/commit/ae347353c1a80b226907607290b4a76ff0a81264
  Author: Jan Stránský honzik.stran...@gmail.com
  Date:   2012-10-15 (Mon, 15 Oct 2012)

  Changed paths:
M py/export.py
M py/utils.py
M py/ymport.py

  Log Message:
  ---
  minor changes



___
Mailing list: https://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] 408552: fixed small bug in export.VTKExporter.exportFacets...

[Jan Stránský]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: 408552950be90c1ebb2a555b62c83f022e61b9cc
  
https://github.com/yade/trunk/commit/408552950be90c1ebb2a555b62c83f022e61b9cc
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2012-09-27 (Thu, 27 Sep 2012)

  Changed paths:
M py/export.py
M py/geom.py
M py/pack/pack.py

  Log Message:
  ---
  fixed small bug in export.VTKExporter.exportFacetsAsMesh
add geom.facetSphere



___
Mailing list: https://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] e3127c: another bug fix of export.VTKExporter.exportFacets...

[Jan Stránský]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: e3127c74003da8d8aaf082a036864b755404286c
  
https://github.com/yade/trunk/commit/e3127c74003da8d8aaf082a036864b755404286c
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2012-09-27 (Thu, 27 Sep 2012)

  Changed paths:
M py/export.py

  Log Message:
  ---
  another bug fix of export.VTKExporter.exportFacetsAsMesh



___
Mailing list: https://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] b855d5: Added Law2_ScGeom_CpmPhys_Cpm class

[Jan Stránský]

  Branch: refs/heads/master
  Home:   https://github.com/yade/trunk
  Commit: b855d5c30af5e3bf0d90a7111cad59724caf90e8
  
https://github.com/yade/trunk/commit/b855d5c30af5e3bf0d90a7111cad59724caf90e8
  Author: Jan Stránský jan.stran...@fsv.cvut.cz
  Date:   2012-08-05 (Sun, 05 Aug 2012)

  Changed paths:
M examples/concrete/periodic.py
M examples/concrete/uniax.py
M examples/test/peri3dController_example1.py
M examples/test/peri3dController_shear.py
M pkg/dem/ConcretePM.cpp
M pkg/dem/ConcretePM.hpp
M pkg/dem/RockPM.hpp

  Log Message:
  ---
  Added Law2_ScGeom_CpmPhys_Cpm class
other modifications of CpmMat related classes



___
Mailing list: https://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/trunk] b855d5: Added Law2_ScGeom_CpmPhys_Cpm class

[Jan Stránský]

 Good one! :)
 Did you make comparisons between the ScGeom and Dem3 functors yet?
 Bruno


Actually I did, and there are a few bugs in Dem3DofGeom, and that's why I
switched to ScGeom :-) bug reports soon..
Jan
___
Mailing list: https://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 1031703] Re: extra value for bodies

[Jan Stránský]

The problem is not how to access the extra variables in python but how to
 implement them in c++.
 For storing arbitrary types, I see at least two ways:
 1/ void pointers + some typecasting
 2/ add template parameters to the class Body


3/ store the string representation of desired variable (as suggested a few
mails above). From my point of view it would be the least effort and for
the same functionality. Example:


Yade [1]: b = utils.sphere((1,2,3),4)

Yade [2]: O.bodies.append(b)
 -  [2]: 0

Yade [3]: a = Vector3(1,2,3)

Yade [4]: b.extra = repr(a)

Yade [5]: b.extra
 -  [5]: 'Vector3(1,2,3)'

Yade [6]: c = eval(b.extra)

Yade [7]: c
 -  [7]: Vector3(1,2,3)

Yade [8]: a + c
 -  [8]: Vector3(2,4,6)


Jan

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

Title:
  extra value for bodies

Status in Yet Another Dynamic Engine:
  New

Bug description:
  Hi,

  It would be very helpful, if there would be an extra value for every
  body. This value can be set by the user. It must be a very fexible
  value (bool, int, float, vector, array, etc.).

  Example:
  I create a clump, which consists of two hardly overlapping spheres and 
sometimes I need the volume of the clump (which is not the sum of the volumes 
of the two spheres in this case). So this could be easily managed by this 
extra value. Where i could set either the volume of the clump as extra value 
to the clump or i could set the volume fractions as extra values to the spheres.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1031703/+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 1031703] Re: extra value for bodies

[Jan Stránský]

2012/8/2 Chareyre 1031...@bugs.launchpad.net

 3/ store the string representation of desired variable

 Yes that one too. I aprooved when I read it but didn't recall it.
 Not sure it would be easier than void pointer though, since it would need
 a lot of typecasting.
 Your example is ok in python but the vector3 can't be used in c++ at this
 point. Getting arbitrary types from a string in c++ is another story.
 I guess Christian has in mind to use e.g. clump volume in some c++
 algorithm (right?), else there is little interest in adding variables to
 bodies.


I was just thinking about using it in python, if it is supposed to be used
in c++, then my solution definitely isn't the best one :-)
Jan
___
Mailing list: https://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 1031703] [NEW] extra value for bodies

[Jan Stránský]

Hello Christian,

sorry if I misunderstood your question, but would you like to achieve this?


Yade [1]: b = utils.sphere((1,1,1),1)

Yade [2]: O.bodies.append(b)
 -  [2]: 0

Yade [3]: b.extra = 4

Yade [4]: b.extra
 -  [4]: 4

Yade [5]: b.extra = Vector3(1,2,3)

Yade [6]: b.extra
 -  [6]: Vector3(1,2,3)


Jan
___
Mailing list: https://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 1031703] [NEW] extra value for bodies

[Jan Stránský]

Ok, if you want to make it serializable with O.save, than it should be in
c++ :-) but I am not sure about an easy way how to implement such flexible
member.. one possibility would be to store it as string and in python set
it with repr and get it with eval function.

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