Re: [Yade-dev] Yade vs. POP

vices//You can read about some of the other codes we've analysed here //https://pop-coe.eu/target-customers/success-stories"/ Is there any volunteer for trying this? It is probably interesting try on both standard desktops and HPC servers. Cheers Bruno On 03/14/2017 03:50 PM, Bruno Char

[Yade-dev] [Bug 1671045] [NEW] Missing reference [Duriez2016]

Public bug reported: The documentation of Ip2_JCFpmMat_JCFpmMat_JCFpmPhys contains a reference [Duriez2016]_ this label does not exist. I found that through the compile warnings. Can you please check Jerome? ** Affects: yade Importance: Undecided Status: New -- You received this

Re: [Yade-dev] new bib entry for yade publications

Done, thanks. And congrats! :) Bruno On 03/08/2017 11:48 AM, Christian Jakob wrote: @phdthesis{Jakob2016, author = {Christian Jakob}, school = {TU Bergakademie Freiberg}, title = {Numerische Modellierung des Verflüssigungsverhaltens von Kippen des Braunkohlenbergbaus beim und nach

[Yade-dev] [Bug 1666339] Re: DFNflow crashes for compiled trunk but not non-optimized debug compiled trunk

Anyway, I'm comiting your fix in the meantime. https://github.com/yade/trunk/commit/1c80962e10d88ead0c3707e449624db7dc0af149 -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1666339 Title: DFNflow

[Yade-dev] [Bug 1666339] Re: DFNflow crashes for compiled trunk but not non-optimized debug compiled trunk

Hi Robert, I was about to commit your fix, then I had another another guess. Could you remove the pass-by-reference for the facet circulator in the function's signature? void DFNFlowEngine::trickPermeability(RTriangulation::Facet_circulator facet, ...) instead of void

[Yade-dev] [Bug 1666339] Re: DFNflow crashes for compiled trunk but not non-optimized debug compiled trunk

Hi, I agree that it sounds like some sort of gcc bug, or maybe a bug in circulators implementation. Two versions of a code doing obviously the same thing but one of them crash, I've seen that before. If I have a chance I'll send you a short "hello world" program with c++/cgal to see if you can

Re: [Yade-dev] [Bug 1666339] Re: DFNflow crashes for compiled trunk but not non-optimized debug compiled trunk

On 02/23/2017 11:24 PM, Robert Caulk wrote: > 195: RTriangulation::Facet_circulator facet1 = > Tri.incident_facets(*edge); > > This is where I believe there may be a problem. facet1 does not appear > to be the address of a facet, instead it appears to be the circulator. The "circulator" is just an

[Yade-dev] [Bug 1666339] Re: DFNflow crashes for compiled trunk but not non-optimized debug compiled trunk

Assignee: (unassigned) => Bruno Chareyre (bruno-chareyre) -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1666339 Title: DFNflow crashes for compiled trunk but not non-optimized debug compiled tr

[Yade-dev] [Bug 1666838] Re: aperiodic randomDensePack huge overlaps and strange behavior

You are speaking of the non-periodic case, aren't you? It seems it is using the pre-processor "TriaxialTest", I can imagine that this old lady is not giving exactly what it was years ago, then maybe the bad results you get. It should not be too difficult to test what the curretn code is doing,

[Yade-dev] [Bug 1663899] Re: SetCohesionNow & setCohesionOnNewContacts /triaxial test

Interesting. There is still more than one difference between the two lines. Could you find which change shows the problem? B -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1663899 Title:

[Yade-dev] [Bug 1663899] Re: SetCohesionNow & setCohesionOnNewContacts /triaxial test

Hi, what you describe in #2 sounds ok, in principle. Since there are many other changes compared to the original script I can't tell if this is really the origin of your problem. You may try to start again from the original script and re-apply each change to see when the problem appears. B --

[Yade-dev] An update on Yade repository

er is still very limited, so _if someone is willing to participate to the package management please let us know_. Happy new year to all yade-user's and yade-dev's! Bruno Chareyre -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +

Re: [Yade-dev] Yade new release is coming

Dear Anton, Thank you very much for this message. I appreciate that your commitment is still significant even after a significant decrease. :) This is (and was) of great help for us all. I will try and go through the open issues, and we will try to fix the builder issues here. Besides, I

Re: [Yade-dev] Using YADE with cloud computing - guide

Dear Robert, It is impressive, I did not expect this to be so easy. Thank you very much for sharing this. If you like the idea of (1) integrating the guide in yade's doc (pdf/html) the question is: what is the type of the source file (doc/tex/...)? If too difficult we can always (2) include a

Re: [Yade-dev] Frequency of documentation update

Hello, Hardware issue here, we will move to a new one. Happy new year Yade-Dev's. :) Bruno On 01/02/2017 08:05 PM, Anton Gladky wrote: Yea, it looks like the buildbot does not build docs and Yade itself. Remi, could you please have a look? Thanks Anton 2017-01-02 19:39 GMT+01:00 Jerome

Re: [Yade-dev] FlowEngine.ipp.in: return values of volumeCell*()

On 11/25/2016 06:46 PM, Jerome Duriez wrote: Hi, In pkg/pfg/FlowEngine.ipp.in, why do volumeCell() return directly a "volume" value [1], whereas other volumeCell*Fictious() functions return the std::abs() of "volume" [2] ? Volume [1] is a signed volume and theoreticaly - at least - the

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3953: Introduce Network::surfaceSolidThroatInPore() for partial solid surfaces per half-throat

rk::surfaceSolidThroatInPore() for partial solid surfaces > per half-throat > > > revno: 3953 > committer: Bruno Chareyre <bruno.chare...@grenoble-inp.fr> > timestamp: Mon 2016-10-24 13:17:04 +0200 > mess

Re: [Yade-dev] [Bug 1628273] Re: Sphere - nonSphere interactions never deleted by Law2_ScGeom_CapillaryPhys_Capillarity

Good one, thanks. The shape test is, I think, ok. The only problem is that it may in fact accept something such as a wall-wall interaction, it would be better to test geometryIndex1 == geometryIndex2 == sphereIndex. Bruno On 17 October 2016 at 18:46, Jérôme Duriez

[Yade-dev] [Bug 1625850] Re: CapillaryTriaxialTest preprocessor broken

** Changed in: yade Status: New => Confirmed ** Changed in: yade Importance: Undecided => Medium -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1625850 Title: CapillaryTriaxialTest

Re: [Yade-dev] [Bug 1625850] Re: CapillaryTriaxialTest preprocessor broken

Hi Jérôme, I do not post on the bug purposely, because this is not a very technical discussion. My suggestion is to keep the bug open until someone will fix. Removing a feature is not a nice way to fix. I believe no interaction loop is not the real problem since it used to work even without this

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3941: revising Potential Blocks to the latest version to run slope analysis

Hello, I didn't see any reply yet. Re-sending in case it has been overlooked. Bruno On 13 October 2016 at 10:38, Bruno Chareyre <bruno.chare...@grenoble-inp.fr> wrote: > Hello Boon, > Could you please help me understand what's going on with clumps? > I see a new "n

Re: [Yade-dev] [Bug 1625850] Re: CapillaryTriaxialTest preprocessor broken

No need to remove, it should work. The bug is real, hiding it will not help. B On 17 October 2016 at 18:54, Jérôme Duriez wrote: > Regarding this bug, I think the CapillaryTriaxialTest preprocessor does > not add much to Yade now (even in a working state), and propose

Re: [Yade-dev] yade and ipython5

A problem in building the doc it seems. Which debian/ubuntu system would be best to try this out? Bruno On 10/12/2016 11:28 PM, Anton Gladky wrote: Hi all, there is definitely a problem with yade and coming ipyhon5 [1]. Has anybody time and wish to let yade work with ipython5? [1]

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3941: revising Potential Blocks to the latest version to run slope analysis

Hello Boon, Could you please help me understand what's going on with clumps? I see a new "nonSpherical" version of updateProperties() (used here [1]) which does not seem to be related to potential blocks specifically. Did you consider possible side effects? Why was the previous

[Yade-dev] [Bug 1628273] Re: Sphere - nonSphere interactions never deleted by Law2_ScGeom_CapillaryPhys_Capillarity

I confirm the bug conceptually (did not reproduce). Call it memory leak... Did you realize that incidentaly or have you seen an anomalous growth of interaction number in a simulation? I wonder how it can be solved without hacks. The notion of multiple physical interactions between two bodies

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3937: Update citing_yade.bib

3-16 8:28 AM *To:* Yade developers *Subject:* [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3937: Update citing_yade.bib revno: 3937 author: Bruno Chareyre <bruno.chare...@grenoble-inp.fr> committer: GitHub <nore...@github.com

Re: [Yade-dev] Compiling dependencies POTENTIAL BLOCKS

Excellent! Congrats for compiling with coinor-* packages. Could you be more specific on the second part? Do you mean that you need those functions and that they are no longer available/doing what they should? Bruno On 09/25/2016 12:04 PM, Chia Weng Boon wrote: Good news! Potential Blocks is

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3932: Friendlier BibTex entries for 2015 doc. To avoid Smilauer and et al in manuscripts

Thank you very much for explanation. Sorry if I've been reverting too hastly. Did you test this "and others" within yade doc and if a few variant bibtex style? Just to be sure it will not produce further jokes. B On 09/23/2016 05:29 PM, Jerome Duriez wrote: Hi Bruno, It is about paper

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3932: Friendlier BibTex entries for 2015 doc. To avoid Smilauer and et al in manuscripts

t seems. How are you compiling? Which bibtex style? Bruno [1] https://www.yade-dem.org/doc/publications.html On 09/23/2016 01:24 PM, Bruno Chareyre wrote: Dumb me! I should read twice. Now I understand the problem Smilauer _and_ et al. Still the solution is not right. We must really display "

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3932: Friendlier BibTex entries for 2015 doc. To avoid Smilauer and et al in manuscripts

Dumb me! I should read twice. Now I understand the problem Smilauer _and_ et al. Still the solution is not right. We must really display "Smilauer et al.". Bibtex experts around? B On 09/23/2016 12:56 PM, Bruno Chareyre wrote: Hi Jérôme, I don't understand this commit. Why do you wan

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3935: Capillary scripts commit (http://www.mail-archive.com/yade-dev@lists.launchpad.net/msg12103.html)...

Great! Thanks. B On 09/21/2016 09:32 PM, nore...@launchpad.net wrote: revno: 3935 committer: jduriez timestamp: Wed 2016-09-21 10:48:23 -0600 message: Capillary scripts commit

[Yade-dev] [Bug 1625850] Re: CapillaryTriaxialTest preprocessor broken

Confirmed with yadedaily. Do you remember the latest commits where changes have been made? Bruno -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1625850 Title: CapillaryTriaxialTest preprocessor

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3932: Friendlier BibTex entries for 2015 doc. To avoid Smilauer and et al in manuscripts

Hi Jérôme, I don't understand this commit. Why do you want to avoid "et al."?? It is a very well accepted convention. Anyway, it is too late to change it, the document has been online for months. It appears with "et al." using the DOI (https://dx.doi.org/10.5281/zenodo.34045), for instance.

Re: [Yade-dev] Regression in ForceResetter?

09/16/2016 07:22 PM, Anton Gladky wrote: I have some thoughts about initial sort. It looks like insertion sort is not especially good if the list is not pre-sorted. For that case it looks like merge sort should work much better. Regagrds Anton 2016-09-16 17:43 GMT+02:00 Bruno Chareyre &l

Re: [Yade-dev] Regression in ForceResetter?

6 09:42 AM, Eulitz, Alexander wrote: Hi Bruno, do you think that the problem exists for a while or when did openMP issues arise? regards Alex *Von:*Yade-dev [mailto:yade-dev-bounces+alexander.eulitz=iwf.tu-berlin...@lists.launchpad.net] *Im Auftrag von *Bruno Chareyre *Gesendet:* F

Re: [Yade-dev] Regression in ForceResetter?

ved by > more elegant way. > > [1] https://github.com/yade/trunk/commit/07940b52ac31597c07d9d98f289131 > 1d7e6d8e0e > > Cheers > > Anton > > > 2016-09-15 19:23 GMT+02:00 Bruno Chareyre <bruno.chare...@3sr-grenoble.fr > >: > > Hello all, > >

[Yade-dev] Regression in ForceResetter?

1400 7174500us 24.39% TOTAL 29415483us 100.00% -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 Email too brief? Here's why! htt

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

at 1:17 AM +0800, "Bruno Chareyre" <bruno.chare...@3sr-grenoble.fr <mailto: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

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

Dear Stefano, that is a very good feedback indeed. You see how beneficial all this is. :) At this point it seems that the right answer to those students was "Yes, it is available". Bruno On 09/06/2016 05:48 PM, Stefano Utili wrote: Dear Bruno, Thank you for your reply. I was at the DEM 7

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

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

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

he sharing of the code easier. Boon *From:* Chia Weng Boon on behalf of Chia Weng Boon <chiaweng.b...@oxfordalumni.org> *Sent:* Sunday, September 4, 2016 11:15:17 PM *To:* Jan Stránský; Bruno Chareyre; stefano utili;

Re: [Yade-dev] TriaxialStressController.externalWork sign

pt of Civil Engineering +1 403 220 7367 *From:* Yade-dev <yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net> on behalf of Bruno Chareyre <bruno.chare...@grenoble-inp.fr> *Sent:* July-28-16 11:06 AM *To:* y

Re: [Yade-dev] TriaxialStressController.externalWork sign

Hi Jérôme, Strictly speaking the doc is right: "Energy provided by boundaries" does not tell if the boundaries provide energy to the sample or to the outside. I agree that it is probably more common to define "external work input" as an input _to_ the sample, yet overall it remains a matter

Re: [Yade-dev] TriaxialStressController.externalWork sign

e University of Calgary, Dpt of Civil Engineering +1 403 220 7367 *From:* Yade-dev <yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net> on behalf of Bruno Chareyre <bruno.chare...@grenoble-inp.

Re: [Yade-dev] Law2_ScGeom_CapillaryPhys_Capillarity code workflow for erased interactions

Thanks Jerome, Fixed here (and a FIXME for the other version): https://github.com/yade/trunk/commit/228c365076879e7133deb66be80f38dadbc3f0d7 Bruno On 23 July 2016 at 00:31, Jerome Duriez wrote: > Hello, > > > Currently Law2_ScGeom_CapillaryPhys_Capillarity may erase

[Yade-dev] [Bug 1596021] Re: O.tags['params'] for 2 batchs and 1 save

Hi Jérôme, O.tags contain whatever you like in terms of named data (e.g. version/date of the script that was used to produce one particular scene). If you see O.tags['params'] as a memory of which parameters were used (it is obviously not the sole purpose) you realize that forgetting history

[Yade-dev] [Bug 1595450] Re: Cannot apply an angular velocity to aspherical objets

For aspherical bodies you must impose the angular momentum instead of the spin. It is true that it can be overlooked big time... One fix could be to update the momentum automatically when the spin is modified. The only overhead-free solution is to improve the documentation though. Bruno -- You

Re: [Yade-dev] ubuntu 14.04 vs. Qt5?

diff-a9ab7d00ca6a2a7ea83f9c204767ae3cR91 and https://github.com/woodem/woo/commit/9cc29d813641bae0f79e0c0ffe653b91ea5bd381 . AFAICT it was fixed in more recentish versions of gcc/glibc again. HTH, Václav 2016-06-13 11:55 GMT+02:00 Bruno Chareyre <bruno.chare...@grenoble-inp.fr>: /usr/include/vtk-6.0

Re: [Yade-dev] ubuntu 14.04 vs. Qt5?

Next problem after switching back to Qt4: /In file included from /usr/include/vtk-6.0/vtkTriangle.h:26:0,// // from /home/3S-LAB/bchareyre/yade/yade-git/trunk/pkg/dem/VTKRecorder.cpp:16,// // from /home/3S-LAB/bchareyre/yade/yade-git/build1404/pkg.11.cpp:7://

Re: [Yade-dev] ubuntu 14.04 vs. Qt5?

-error during first Yade start. Regards Anton 2016-06-13 10:36 GMT+02:00 Bruno Chareyre <bruno.chare...@3sr-grenoble.fr>: Hi, I don't know if a few tips are missing in the doc or if I'm missing something stupid. I was compiling yade on Trusty for the first time and I observed the following thi

[Yade-dev] ubuntu 14.04 vs. Qt5?

4 [INSTALL] libqt5x11extras5-dev:amd64 -- ___ 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/~yad

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

e Duriez, Research Associate University of Calgary, Dpt of Civil Engineering +1 403 220 7367 *From:* Yade-dev <yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net> on behalf of Bruno Chareyre <bruno.ch

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

one else's habits. In the end, do we agree we keep all the interactions in the loop ? Jerome *From:* Yade-dev <yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net> on behalf of Bruno Chareyre <bruno.chare

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3888: Use unordered_map instead of map for MapId2IntrT

Hi Anton, Interesting change, did you benchmark it? I see insertion, deletion, find, all have different costs. Since the number of interaction per body is typically low I wonder how the nominal costs apply. Bruno On 7 June 2016 at 23:46, wrote: >

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1

In [1] it was a good move to remove the periodic barrier. Filtering spheres is another independent question and I don't see a clear reason for that (testing isDynamic was maybe a bit hacky but less restrictive finally). Making split=0 and split=1 return the same thing [2] sounds good, but the

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3874: fabricTensor(): unify the behavior regarding boundary interactions whether split=0 or 1: they are...

On 05/27/2016 05:22 AM, nore...@launchpad.net wrote: revno: 3874 committer: jduriez === modified file 'pkg/dem/Shop_02.cpp' + if(

Re: [Yade-dev] Dynamic bodies and getSpheresVolume()

It makes sense indeed. The dynamic check was probably a loose evaluation of shape, now redundant. Bruno On 05/20/2016 11:30 PM, Jerome Duriez wrote: Hi, getSpheresVolume() currently skips all dynamic bodies before even considering whether they are spheres or not [*]. I think it would you

Re: [Yade-dev] Naming GridConnection

On 05/11/2016 01:52 PM, Klaus Thoeni wrote: I think sooner or later we should get rid of the current ChainedCylinder implementation. Agreed But you are right, the algorithms are slightly different, although it might just the physics (?). I haven't compared the code yet but I added two

[Yade-dev] Naming GridConnection

Hi all, Reading Klaus' answer below I realize that replacing "cylinder" by "grid connection" will not help to intuitively recognize which class can be used to modelize a single cylinder. I wonder how it could be improved. Beyhond renaming GridConnection (still an option), we could make

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

It sounds good to me if the identifier has a meaning. Bruno On 04/19/16 22:13, Anton Gladky wrote: 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

Re: [Yade-dev] fabricTensor() in aperiodic conditions ?

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] moderation of "Michal Nitka"

6:44 - From: Yade developers <nore...@launchpad.net> Reply-To: Yade developers <nore...@launchpad.net> To: Hello Bruno Chareyre, Yade developers has a new message requiring your approval. Subject: Fw: new message Author name: Michal Nitka Author url:

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

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

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

On 17/03/16 17:11, Chia Weng Boon wrote: > 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. You did well. if you have example

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

de.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription > > > ___ > Mailing list: https://launchpad.net/~yade-dev > Post to : yade-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/L

Re: [Yade-dev] Spam on the mailing list

I don't know how launchpad handles spammers, can we ban some accounts on the mailing lists we are managing? I don't think restricting posting rights of everyone but team members is the right way to solve the problem. It has to remain open access IMO. Bruno On 13 February 2016 at 13:25, Anton

Re: [Yade-dev] -DNDEBUG

___ > Mailing list: https://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³

[Yade-dev] -DNDEBUG

january! Still reviewing... -- ___ 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

[Yade-dev] email problem

may have miss, please let me know. Cheers Bruno -- ___ 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

[Yade-dev] [Bug 1533625] [NEW] We can't get total force on clumps

Public bug reported: O.forces.f(clumpId) will always return a null vector with parallel build. Probably simply because there is no forces.sync() after the summary force is computed. Calling forces.sync() all the time for the sole purpose of getting "read rights" on clump force is overkill. We

Re: [Yade-dev] Fwd: New Contact Model for YADE

-Université Laval > Québec, QC, Canada > > ** > > > > Please consider the environment before printing this E-mail. > > > > ___ > Mailing list: https://launchpad.net/~yade-dev > Post to : yade-dev@lists.launchpad.n

Re: [Yade-dev] no X rendering

> [mailto:yade-dev-bounces+alexander.eulitz=iwf.tu-berlin...@lists.launchpad.net] > *Im Auftrag von *Bruno Chareyre > *Gesendet:* Montag, 7. Dezember 2015 15:44 > *An:* Yade Development Group > *Betreff:* [Yade-dev] no X rendering > > > > Hi there, > Today I start yade and I have no X

Re: [Yade-dev] no X rendering

ad, that you solved it, but it is strange behavior. What distribution > do you use? There is some more info in "man xauth". > > Regards > > Anton > > > 2015-12-09 15:21 GMT+01:00 Bruno Chareyre <bruno.chare...@3sr-grenoble.fr>: >> Absolutely correct, tha

Re: [Yade-dev] Move utils for "grid and more" in separate file

On 08/12/15 07:30, Klaus Thoeni wrote: > Hi guys, > > I am about to push the pfacet code (as a Xmas present) but before I wanted to > discuss the following: > > 1) The utils module is massive and I suggest that we move everything related > to cylinder, grids and pfacets in a new file, e.g.

[Yade-dev] no X rendering

https://bbs.archlinux.org/viewtopic.php?id=13189)// / -- ___ 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

Re: [Yade-dev] SoftwareX

See also "where should I publish my software?": http://www.software.ac.uk/resources/guides/which-journals-should-i-publish-my-software On 04/10/15 18:33, Bruno Chareyre wrote: > > > On 4 October 2015 at 18:26, Bruno Chareyre > <bruno.chare...@3sr-grenoble.fr >

Re: [Yade-dev] SoftwareX

helping researchers to deal with their computing tools) and the > journal softwarex (where YADE could be presented ?) > > I could not get it.. > > Jerome > > -- > *From:* Yade-dev [yade-dev-bounces+jerome.duriez= > ucalgary...@lists.launchpad.n

Re: [Yade-dev] SoftwareX

On 4 October 2015 at 18:26, Bruno Chareyre <bruno.chare...@3sr-grenoble.fr> wrote: > http://carver.cs.ua.edu/Papers/Journal/2015/SLR-Science_preprint.pdf > > http://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.1001745 > http://software.ac.uk/so-exactly-what-so

Re: [Yade-dev] SoftwareX

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

Re: [Yade-dev] SoftwareX

I must mention that Jan's note is closely linked, in my brain, to a discussion I had with a developper of Plaxis, who suggested [1] as a relevant link. B [1] https://software-carpentry.org/ On 22 September 2015 at 17:37, Bruno Chareyre < bruno.chare...@3sr-grenoble.fr> wrote: > Very in

Re: [Yade-dev] TesselationWrapper

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 3

[Yade-dev] [Bug 1480173] Re: Yade dependency libopenblas breaks octave

OpenBLAS is an alternative of BLAS, as such it is not strictly necessary, you are right. I guess the yade package could allow different variants, but it would be some more maintainance work. There are so many incompatible combinations when it come to variants of

[Yade-dev] [Bug 1480173] Re: Yade dependency libopenblas breaks octave

Thank you for reporting but this actually not a bug related to yade since the problem is between octave and openblas. Bruno ** Changed in: yade Status: New = Invalid -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade.

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

On 30/07/15 02:49, Bruno Chareyre wrote: It is not far really, this is a theoretical method without a step() : InsertionSortCollider().__call__() bodyPairs=O.interactions with the only problem that for the moment it would hide virtual interactions (hence doesn't work practicaly). Easy to fix

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3709: add function has() to O.interactions to check if (id1, id2) exists + fix doc of O.interactions

On 31/07/15 09:36, Václav Šmilauer wrote: message: add function has() to O.interactions to check if (id1,id2) exists + fix doc of O.interactions You can also call it __contains__ (https://docs.python.org/2/reference/datamodel.html#object.__contains__), and do things like if (0,1) in ...

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

in a specific Ig2, then CohesionMoment could be used I think. Cheers Bruno *From:* Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary...@lists.launchpad.net] on behalf of Bruno Chareyre [bruno.chare...@3sr-grenoble.fr] *Sent

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

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

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

Hi Jérôme, I don't see what you mean, sorry. Setting unp=un is explicitely making current state the equilibrium state, without the need of any additional trick, else please explain why you think it is not enough. Handling modified normals (second specific feature) is the job of Ig2 functor, not

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

in python script. Bruno [1] https://answers.launchpad.net/yade/+question/266828 https://answers.launchpad.net/yade/+question/266828, #4 especially On 29 July 2015 at 03:51, Bruno Chareyre bruno.chare...@3sr-grenoble.fr wrote: Hi Jérôme, I don't see what you mean, sorry. Setting unp=un

[Yade-dev] [Bug 1478470] Re: undefined symbol after Compilation

Hi, Is -1.11.1 really the postfix you defined in the cmake options? I have doubts about that. Also: - which version of the sources do you compile? - what is cmake output? - what OS do you have? I'm closing since I'm nearly sure it is not a bug (or, if it is, a won't fix since we will not fix

Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3707: add a new version of capillary law. (pushed by Caroline)

Hi Jérôme, First of all, this is work in progress (the weirdness of classnames suggests that...) so we will probably not discuss it too much at this point. Short answers, though: I would have a first question on Law2_ScGeom_CapillaryPhys_Capillarity1::intEnergy() / swInterface() /

Re: [Yade-dev] [Bug 1475844] Re: Swap problem in InteractionLoop

Yes, I understand the idea on performance. table[i][j]- is nearly as fast a p-. It makes sense but it is pitty, it was quite a bit of work to implement the cache thing everywhere wasn't it? :) Anyway, it would be interesting to have timings again. B -- You received this bug notification because

[Yade-dev] [Bug 1475844] Re: Swap problem in InteractionLoop

@Vaclav I removed this functor caching, since it does not seem to bring any benefit performance-wise. IIRC the change [1] gave a significant (clearly measurable) speedup. Before the change it was like this: if (noIGfuntor || noIPfunctor) assignIGfunctor(); if (!IGfunctor.go()) continue;

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

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

[Yade-dev] [Bug 1475844] Re: Swap problem in InteractionLoop

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

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

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

[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files

Hi Jerome, It would be a good thing to have scripts generating data in trunk indeed. d is a solution of the ODE integration, not an input variable, that is why you don't find a logic in the increments. uc is an input parameter OTOH. I don't remember in detail how its evolution was defined by I

Re: [Yade-dev] [Bug 1476159] [NEW] several ForceContainer.addF behaves non-intuitively with permanent=True

You are right. I agree with your solution. However I suggest to make addF(id,(2,0,0),True) return error/warning with explicit message (the function changed, please use that one, etc.) instead of just standard python error. It will make transition easier for those who use the current version. Bruno

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

** Changed in: yade Importance: Undecided = Medium ** Changed in: yade Assignee: (unassigned) = Bruno Chareyre (bruno-chareyre) ** Changed in: yade Status: New = Confirmed -- You received this bug notification because you are a member of Yade developers, which is subscribed

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

Public bug reported: Most likely the reason for performance drop reported in [1] dx in the voxel decomposition is minRad/discretization. The problem is when a sphere of radius 1 is member of a clump which aabb has the size 1000 (for instance). Using the minimal discretization=1 gives a number

<    1   2   3   4   5   6   7   8   9   10   >