Public bug reported:
Hi there,
Since bugs report get a lot of attention these days :-) let me add
another one:
###
from yade import plot
plot.addData(x = 1 , y = 5)
plot.plots = {'x':'y'}
plot.plot()
plot.plot()
###
gives error messages (pointing to
Back to normal, indeed... Closing, thanks Robert.
** Changed in: yade
Status: New => Invalid
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1810283
Title:
Wiki homepage broken
Status in
Public bug reported:
For the record, https://www.yade-dem.org/wiki/Yade currently just
outputs here:
***
Database error
>From Yade
A database query syntax error has occurred. This may indicate a bug in the
software. The last attempted database query was:
(SQL query hidden)
The fact is py/pack/_packPredicates.cpp defines aabb() functions for
predicates that still return tuples (not lists, as I proposed). I do not
think this would necessarily conflict with the use of list in
aabbExtrema(), but I still can not say I know all of _packPredicates.cpp
Then, in terms of a
For the record, I'm herein attaching a patch that would make
aabbExtrema() back to a tuple, cancelling the effects of commits 1db13fb
( = [*] in the bug report) and 7c60d78 ( = more recent commit mentioned
in #2)
As of now, I do not think this patch should be applied, see other
comments regarding
I'll try to avoid exaggeration here. My commit [1] was about a Shop /
utils function, maybe not exactly a bottom layer of yade (at least, not
in my opinion).
As illustrated by the present bug and the launchpad question, [1] could
be problematic in case of Python code (hardcoded in trunk or in
See commit
https://github.com/yade/trunk/commit/7c60d78bd9badfa174fb79a82af7b119abf81d5d.
It fixes the example in the above and the related Launchpad question (I
guess, since there was no MWE therein ;-) ).
There are also several uses of aabb tuple stuff in
/py/pack/_packPredicates.cpp which is
** Changed in: yade
Assignee: (unassigned) => Jérôme Duriez (jduriez)
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1804621
Title:
bodyNumInteractionsHistogram broken
Status in Yade:
Public bug reported:
See https://answers.launchpad.net/yade/+question/676284 and:
#
O.bodies.append(sphere((0,0,0),1,dynamic=False))
O.bodies.append(sphere((0,0,1.9),1,dynamic=False))
O.step()
print 'BodyNumInteractions Histogram',
Public bug reported:
Doc [*] mentions a not-existing strainStress attribute, instead of goal.
For the record and later fix (unless someone does it before me)
[*] https://yade-
dem.org/doc/yade.wrapper.html#yade.wrapper.PeriTriaxController
** Affects: yade
Importance: Undecided
Initial MeasureCapStress problem fixed in commit 68b0557.
The possible use of e.g. boost::python::extract during Engine::action()
(see the link in #3) remains to be explored, as far as I'm concerned.
** Changed in: yade
Status: New => Fix Released
--
You received this bug notification
For the record, see also https://www.mail-archive.com/yade-
d...@lists.launchpad.net/msg13223.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
I have numpy 1.11.0 actually
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1774065
Title:
doctests fail with numpy 1.14
Status in Yade:
New
Status in Debian:
Confirmed
Bug description:
I do not confirm it:
jerome.duriez@AXP17003:~$ yadedaily
Welcome to Yade 2018.02b-1270674828~xenial
TCP python prompt on localhost:9000, auth cookie `dckayu'
XMLRPC info provider on http://localhost:21000
[[ ^L clears screen, ^U kills line. F12 controller, F11 3d view (use h-key for
showing
Fixed in
https://github.com/yade/trunk/commit/87144ecc6964ceac3995928198f62c3982a5b15f,
thanks for feedback Anton.
** 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.
Public bug reported:
Hi,
The https://yade-dem.org/doc/prog.html#debian-packaging-instructions
section seems to me obsolete.
1.
For sure, all links in
https://yade-dem.org/doc/prog.html#prepare-source-package are broken. They
actually direct to some trunk folder which has been first moved [1],
See also https://bugs.launchpad.net/yade/+bug/1455621, comment #1 at
least ?
** Changed in: yade
Status: New => Confirmed
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1378717
Title:
For comment #1 at least, see also
https://bugs.launchpad.net/yade/+bug/1378717 ?
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1455621
Title:
documentation bug: getting class name fails
Status
Hi,
If it now works while it used not to, I think we can say it's fixed ;-)
A recently updated yadedaily should indeed reflect the above-mentioned commit
https://github.com/yade/trunk/commit/bd1089e77eae83c41c4ce0c60873e1e234ba9c89
(the compilation problems I mentioned in #3 are solved now ---
For playing with source code, you may refer to https://yade-
dem.org/doc/installation.html#source-code for source code download and
compilation (i.e. YADE installation), then the Programmer's manual https
://yade-dem.org/doc/prog.html.
--
You received this bug notification because you are a
Thanks, I could reproduce the crash with this script.
Solution
The change [1] should fix your problems. Obviously you need to update
your yade version to enjoy this change.
In terms of package versions, I do not know when this change will be
reflected in yadedaily, considering in
** Changed in: yade
Assignee: (unassigned) => Jérôme Duriez (jduriez)
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1767601
Title:
segmentation fault after erasing some particles
Sta
Hi,
Thank you very much Bruno for the links and hints, I understand there
probably is some bad practice here (see 3.).
1.
However, I'm quite sure the crash is just caused by the following line
"boost::python::tuple extrema = Shop::aabbExtrema();" [1]
I thus suspect incorrect Python/C++
** Summary changed:
- MeasureCapStress-caused segmentation fault (boost::python)
+ Segfaults with boost::python::tuple during simulation loop
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1764424
Hi,
I launched this script with Yade 2018-04-19.git-79b2edb.
I got the repeated output of "porosity X" with the porosity X-value soon
getting negativ, and then decreasing againt until ~ -1e100, then I
stopped manually the simulation.
I did not get any segmentation fault. Could you clarify the
** 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/1764753
Title:
CohesiveTriaxialTest preprocessor segfaults
Status in Yade:
Fix Released
Fixed in
https://github.com/yade/trunk/commit/12ed7b43ebfe25d5566950dce2d0e489519359c1.
Thanks
** Changed in: yade
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
Actually, I think the present bug is the same as the newly reported
https://bugs.launchpad.net/yade/+bug/1764753
Out of 4 FileGenerator, we have
- two conforming the "new" (though years old) InteractionLoop
definition, and that run: TriaxialTest and SimpleShear
- two not conforming this
See common symptoms (and common cause as well as common fix possibility
?) at https://bugs.launchpad.net/yade/+bug/1625850.
Discussing further therein
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
Public bug reported:
Hi,
I get "core dumped" crashes using CohesiveTriaxialTest preprocessor
(FileGenerator) with:
Crashing script
simu = CohesiveTriaxialTest(numberOfGrains=4)
simu.generate('simu.yade')
O.load('simu.yade')
O.step()
(or just using the "Generate" part
Hi,
It's true using the "wrong code" I got an infinite (it seems) number of
"ValueError: cannot convert float NaN to integer" even when running just
one iteration.
Is it what you call "code is crashed" ?
If yes, could you please try to shorten your script ? (for this behavior to
occur do we
Public bug reported:
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
Thank you Bruno for comments. I may come back on the naming convention
in relation with inheritance later on, in the mean time I fixed 4. at
least (not related with inheritance discussion) in
https://github.com/yade/trunk/commit/ddb86b587cb500bb5ff141bd802dbb579cca3fb1
and won't touch the rest.
Public bug reported:
Hello,
I have few questions regarding the doc of chained cylinders classes and
such.
1. It seems to me the doc ("doc" string of YADE_CLASS_BASE_DOC_*) of
Law2_ChCylGeom6D_CohFrictPhys_CohesionMoment [1] and
Law2_CylScGeom_FrictPhys_CundallStrack [2] may deserve some
Sorry about that, this label has been renamed at one point. It is now
fixed
https://github.com/yade/trunk/commit/d3c524c4fbd0fc8406df5b5463ef2236297f198c
** Changed in: yade
Status: New => Fix Released
** Changed in: yade
Status: Fix Released => Fix Committed
--
You received this
It turns out yadedaily is older than I thought.. I still confirm this is
just yade-version related, the "Welcome to Yade 2016.06a-24" suggesting
that this yadedaily is the same as 2016.06a you initially considered..
I do not have a clear understanding of the update frequence of yadedaily
(and
Indeed, with the latest capillary files, you have to use some yade
version younger than end of last September (which is not your case now).
You could either directly pull the last trunk (see "working with source
code" in [*]), or use packaged "yadedaily" which should most probably
work as well.
Note your issue may also be related with the capillary files you're using. The
capillary source code has been updated together with capillary files end of
September, 2016.
You have to use compatible yade version and capillary files.
--
You received this bug notification because you are a
Hello,
I can not reproduce the bug: I've tried this example [*] (since it is a
file from "examples" folder, you may just refer directly to it, so that
we're sure it has not been altered) with two recent versions (2016-10-31
.git-1b22b1a and the last one 2016-12-20.git-54c46f3) and did not get
any
Hopefully solved by following commit
https://github.com/yade/trunk/commit/dd0b300d3d75ac5b3f3a701cec135d966343c922
** 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.
Somewhat similar to another proposed bug [*]. We decided the other
situation was just a feature, applying same treatment here
[*] https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg12040.html
** Changed in: yade
Status: New => Invalid
--
You received this bug notification
(I'm answering here to http://www.mail-archive.com/yade-
d...@lists.launchpad.net/msg12167.html that does not appear on the bug
webpage ?)
>From my point of view, I do not propose at all to hide a bug.
My understanding of the situation is that CapillaryTriaxialTest
preprocessor had not been
Regarding this bug, I think the CapillaryTriaxialTest preprocessor does not add
much to Yade now (even in a working state), and propose to remove
CapillaryTriaxialTest.*pp from the code.
Either using git rm, or adding #ifdef DEPREC_CODE (I vote for the former)
Agree ?
--
You received this bug
Hi,
Just to give some figures about this bug:
Random examples of triaxial simulations (with 2 spherical particles and 6
boxes) show here ~ 45% of sphere-wall interactions that are useless at the end
of the simulation. Ie ~ 3% of the (real) interactions total number.
I think checking for
We realized it thanks to a colleague who was working on interaction
data, as exported in a text file. However we did not quantify it
precisely yet (and I'm now away from office for a couple of weeks)
--
You received this bug notification because you are a member of Yade
developers, which is
Public bug reported:
Hi,
Let say one performs simulation with
Law2_ScGeom_CapillaryPhys_Capillarity and
Law2_ScGeom_FrictPhys_CundallStrack.neverErase = 1 (in order to keep
menisci between separated particles)
In such case, interactions between sphere and non spherical particles
(e.g.
They are 2 years old:
https://github.com/yade/trunk/commits/master/pkg/dem/CapillaryTriaxialTest.hpp
https://github.com/yade/trunk/commits/master/pkg/dem/CapillaryTriaxialTest.cpp
As for myself, in particular, I never touched them (except for the
stress sign convention thing).
I think this
Public bug reported:
Hi,
When using either yadedaily or the latest (as of today) trunk version,
CapillaryTriaxialTest preprocessor crashes at the first iteration. The
backtrace obtained from a debug version of trunk is attached.
I'm at the moment playing with capillary code before commit
Public bug reported:
Hello,
It seems the pack.gtsSurfaceBestFitOBB() function is broken in recent
YADE versions. Just type the following (using a gts file present in the
sources) in your YADE terminal:
**
import gts
surface=gts.read(open('parallellepiped.gts')) # the
Thanks everyone.
** Changed in: yade
Status: New => Invalid
--
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:
Indeed, that's another point of view.. Mine would be that
O.tags['params'] is deeply related with the batch parameters rather than
anything else. I'll wait a couple of days and then mark the bug as
invalid if I'm the only one thinking that way.
(In fact, the solution you're proposing would not
** Attachment added: "first.py"
https://bugs.launchpad.net/yade/+bug/1596021/+attachment/4689846/+files/first.py
--
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']
Public bug reported:
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,
** Attachment added: "second.py"
https://bugs.launchpad.net/yade/+bug/1596021/+attachment/4689854/+files/second.py
--
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:
** Attachment added: "first.table"
https://bugs.launchpad.net/yade/+bug/1596021/+attachment/4689855/+files/first.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:
** 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:
Public bug reported:
Hello,
See the attached files to launch in batch mode
yade-batch test.table test.py
As suggested by the title, you will see that using O.reset() prevents
accessing subsequently O.tags['params']
Reporting so that we may decide if this a bug or not. At least, it let
crash
To be sure I got you (and you got me):
In the files, this distance does have a well defined set of values: with
e.g. (I'm taking random figures) 600 lines at d = cst = 0, then 500
lines at d = cst = 1e-4, then 400 lines at d = cst = 5e-3.
Up to now, I would not be able to obtain such precise set
Hi,
I'm finally working on open source scripts to regenerate capillary files from
scratch. Hopefully, there will be a commit in a couple of months.
In Luc Scholtes' capillary files, the d* values were not linearly spaced, as
the attached figure shows it (it shows the increment between two
PPS: the same question holds more or less for the uc* values
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1440887
Title:
Buggy data in capillary files
Status in Yade:
Fix Released
Bug
** Attachment added: Current uc* values (MATLAB .fig version)
https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4430666/+files/ucValuesOldCorr.fig
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
The current uc* values distribution, for the record
** Attachment added: Current uc* values
https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4430665/+files/ucValuesOldCorr.eps
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to
Ok, it is in fact quite clear for what concerns uc*
(sorry for the possible spam, the record is sometimes also for me)
** Attachment added: Current uc* values with analytical fit
https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4430714/+files/ucValuesOldCorr.eps
--
You received
Ok. Last question/remark before I upload the corrected files :
in M(r=10), there is a bunch of missing uc* values in some cases. For
dist* = 0 and 1e-4, considered uc* values jump from 1350 to 11000. This
being said, trends in all values changes (according to uc*) do not show
anything chocking,
Ok, so my opinion is that there is no junk force values in the files.
Then, force(uc*) curves have nothing to reveal.
However, there are junk volume / delta2 values (for some dist*), that
get obvious on volume(uc*), or delta2(uc*), curves. See Figure ... bug
attachments
In the end, I think
Hi Vaclav,
No, and I do not have this code myself.
What I have is a MATLAB code I used to modify the very first version of the
capillary files (I'm attaching). Luc Scholtes provided me these very first
version of the files.
I guess he is the only one, if any, who may have the code to generate
I do not know if I could take care of re-generating new files, but I am
personly anyway curious about your script, if you agree to provide it
(would also help to assess the required work amount).
Fresh new files being generated or not, we agree to put now capillary
files inside sources (in an
** Attachment added: MATLAB file to plot capillary files (see first lines as
doc)
https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4367949/+files/plotCapFiles.m
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
Assignee: Jérôme Duriez (jduriez)
Status: New
** Attachment added: prob.txt
https://bugs.launchpad.net/bugs/1440887/+attachment/4367946/+files/prob.txt
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https
** Attachment added: Figure to illustrate vol* values problems (current
capillary files)
https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4367947/+files/ratio2probV.eps
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
** Attachment added: Figure to illustrate delta2 value problems (current
capillary files)
https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4367948/+files/ratio1_1probDelta.eps
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to
Hi,
From my point of view this is not a bug. It is a (useful, I would say)
feature introduced recently to let understand that the defined
simulation will run outside the validity range of capillary files. See
http://www.mail-archive.com/yade-dev@lists.launchpad.net/msg10889.html
and next
Hopefully fixed in
https://github.com/yade/trunk/commit/d81ac93b9383a2ab01a75809d72826c62ee91b7c
and previous commit
** 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.
Ok, thank you.
For the DEM-PFV check I thought the minus sign was the big difference. Now I'm
realizing it is normal : I did not see before that the test was on Qin + Qout,
instead of Qin - Qout.
For the 1e-4 difference, I get for the same test the INFO message More than
60\% of cpu time in
I copy paste below some part of the build/CMakeCache.txt (also attached
as a whole). I guess that's what you wanted. And indeed the same
discrepancy in Q (with the same INFO message) appears for another
version without any change in sign convention
//No help, variable specified on the command
** Attachment added: CMakeCache.txt
https://bugs.launchpad.net/yade/+bug/1381282/+attachment/4263137/+files/CMakeCache.txt
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1381282
Title:
Sign
Hi,
I'm trying to change this sign convention. I have currently a check test
failure in DEM-PFV-check.py :
DEM-PFV: unbalanced Qin vs. Qout ( -4.07196227268e-06 vs.
4.07179270687e-06 )
Obvioulsy, the sign convention in triaxial engines seems to have an influence
on calculations in
Public bug reported:
Hi,
When used as stress or strain rates, sign convention of goal1/2/3
attributes of TriaxialStressController engine seem to me as not
consistent.
Positive values for stress goals correspond indeed to compression, whereas
positive values for goal strain rates involve
Do not know exactly what happened, this was my first archive creation, with
Archive Manager... I created another archive, directly with tar (command
line).
The wiki seems currently down (This site is experiencing technical
difficulties), I' attaching here in the meantime.
--
You received
** Attachment added: CapillaryFiles.tar.gz
https://bugs.launchpad.net/yade/+bug/1376047/+attachment/4228610/+files/CapillaryFiles.tar.gz
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1376047
For info, I uploaded a new version of this file. https://www.yade-
dem.org/wiki/File:CapillaryJune2012.tar.gz
** 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.
Ok Luc, thanks. The value in this first line is indeed used in the
computations, and has to be edited (to correspond to the intended
ratio), isn't it ?
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
Public bug reported:
Hi,
In the capillary files, I guess the first line correspond to the radii
ratio (r = Rmax / Rmin), and should correspond to the r-value in the
title of the different files. Am I right ?
Because, for r = 1.1 ; 1.25 and 1.5, this is not the case, the first
line always
Quite useful, indeed... All is modified, now !
Le 21/08/2014 19:55, Bruno Chareyre a écrit :
On 21/08/14 17:38, Jérôme Duriez wrote:
but grepping the source code of all wiki pages is out of my
competences at the moment...
https://yade-dem.org/wiki/Special:WhatLinksHere/Yade_on_github
-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
--
Jérôme Duriez
Post-Doctorant UJF
Laboratoire 3SR
Bureau E139 - 04.56.52.86.30
___
Mailing list: https
to redirect readers to the new page.
Bruno
On 21/08/14 10:21, Jérôme Duriez wrote:
Ok.
May we (I) suppress the wiki content ?
Le 20/08/2014 20:04, Bruno Chareyre a écrit :
This is great Jerome!
The link should also be updated in the programmer's manual [1].
You could grep Yade_on_github
Le 16/07/2014 19:58, Bruno Chareyre a écrit :
Yade must be be consistent and the convention for strain/stress is
traction positive. If python says -1 then paraview should also say -1,
not +1.
I'm learning it... For me there was still different conventions among
the different contact laws, with
@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
--
Jérôme Duriez
Post-Doctorant UJF
Laboratoire 3SR
Bureau E139 - 04.56.52.86.30
___
Mailing list: https://launchpad.net/~yade-dev
Post
(466-530) could fit in maybe 10 lines,
which will be a lot easier to browse and read.
Bruno
On 16/07/14 13:47, Jérôme Duriez wrote:
Question #251712 on Yade changed:
https://answers.launchpad.net/yade/+question/251712
Jérôme Duriez posted a new comment:
Hi,
See
https://github.com/yade/trunk
Le 16/07/2014 18:07, Anton Gladky a écrit :
2014-07-16 18:04 GMT+02:00 Jérôme Duriez jerome.dur...@3sr-grenoble.fr:
For 4, I get your idea, but at the moment I do not know how to store
matrices in vtkDoubleArray... I even have the feeling, according to
vtkDoubleArray.h
/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
--
Jérôme Duriez
Post-Doctorant UJF
Laboratoire 3SR
Bureau E139 - 04.56.52.86.30
___
Mailing list: https
).
Thank you for raising this need for updates. It actually reminded me
to ping Anton and Raphaël for Law2_ScGeom_ViscElPhys_Basic, which
still looks red.
Could you please guys do something?
Thanks
Bruno
On 23/05/14 10:09, Jérôme Duriez wrote:
Hi,
This wiki page makes me puzzled since I
/ is very unlikely to happen. More realistic is to translate the
table in *.rst. I was secretely hopping that you would be volunteer
for that. :)
Besides, I'm open to suggestions on how to improve.
B
On 26/05/14 10:19, Jérôme Duriez wrote:
Hi,
Many thanks to the guy who in fact updated
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
--
Jérôme Duriez
Post-Doctorant UJF
Laboratoire 3SR
Bureau E139 - 04.56.52.86.30
Hello,
Le 08/05/2014 16:37, Matthias Frank a écrit :
yadedaily gravityLoading.py
Welcome to Yade 1.07.0-180-788bc5d~trusty
TCP python prompt on localhost:9000, auth cookie `uyacke'
XMLRPC info provider on http://localhost:21000
Running script gravityLoading.py
Traceback (most recent call last):
Maybe the previous fix is incomplete : efficient for initial situation,
but not for contacts created during simulation ? (see l.513-514). Will
try to investigate more
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
Hi
I'm attaching a new version of InsertionSortCollider that could solve
this bug.
At least, it solves https://answers.launchpad.net/yade/+question/246392
(I have now 9 sphere-box interactions in any case !!!). I think that the
problem was caused by the wrap of bound extents inside cells. I
: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
--
Jérôme Duriez
Post-Doctorant UJF
Laboratoire 3SR
Bureau E139 - 04.56.52.86.30
I just tried, and in fact no...The compilation is successfull on my PC.
Le 28/03/2014 12:14, Bruno Chareyre a écrit :
I can't reproduce the compile error on my PC. This is weird.
When you compile, Jerome, does it give an error?
B
On 27/03/14 17:07, Jérôme Duriez wrote:
Hi,
I got this mail
Hi,
I got this mail after a little commit, I'm on the blamelist :-(
But the errors concern apparently (see the full details)
lib/triangulation/PeriodicFlow.hpp:
that I normally did not modify (which seems to be confirmed by
1 - 100 of 124 matches
Mail list logo
