[Yade-dev] Website down?

[Robert Caulk]

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

[Yade-dev] Yade short-course for Thermo-Hydro-Mechanical couplings

[Robert Caulk]

Hello Yade users and devs,

You are all invited to a 3-day short-course in Amsterdam, Netherlands on
20/06/22-22/06/22 covering the theory and practical implementation of fluid
and thermal couplings in particulate systems. We have limited space, so
please register early to avoid missing the opportunity. Here is a flier
containing all pertinent information regarding costs and registration
deadlines (link to flier: http://u.pc.cd/rl5otalK). Alternatively, feel
free to contact me directly with any questions you may have.

Cheers,

Robert
___
Mailing list: https://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] R: yade-dev team tomorrow's zoom meeting reminder

[Robert Caulk]

Please everyone, keep in mind you can follow directly the agenda and find
most up to date zoom links on our discord:

https://discord.gg/rku35YXZJd

-rc

On Wed, Nov 10, 2021 at 10:00 AM Katia Boschi 
wrote:

> Dear Janek,
>
>
>
> I would be interested too.
>
> Thank you,
>
>
>
> Katia
>
>
>
> ——
>
> Katia Boschi
>
>
>
> PhD Candidate in Structural, Seismic and Geotechnical Engineering
>
> Department of Civil and Environmental Engineering (DICA)
>
> Politecnico di Milano
>
> Piazza Leonardo da Vinci, 32 - 20133 Milan (IT)
>
> Skype: boschikatia
>
>
>
>
>
> *Da: *Yade-dev  polimi...@lists.launchpad.net> per conto di Deepak Kn <
> deepak.kn1...@gmail.com>
> *Data: *martedì, 9 novembre 2021 20:00
> *A: *Janek Kozicki (yade) 
> *Cc: *yade-dev@lists.launchpad.net 
> *Oggetto: *Re: [Yade-dev] yade-dev team tomorrow's zoom meeting reminder
>
> Hello Janek,
>
>
>
> Just a question, how often do these meetings take place ?
>
>
>
> Thanks and best regards,
>
> Deepak
>
>
>
> On Tue, Nov 2, 2021 at 3:40 PM Janek Kozicki (yade) <
> jkozicki-y...@pg.edu.pl> wrote:
>
> BTW, Klaus, here in Europe just three days ago we have switched to
> winter time. That's one hour shift.
>
>
>
> Janek Kozicki (yade) said: (by the date of Tue, 2 Nov 2021 15:32:27
> +0100)
>
> > Hello everyone,
> >
> > Just a reminder that tomorrow we have a developer zoom meeting at 11:00
> CET.
> >
> > If someone yet uninvited wants to join I hope there's still time to
> > reply to this message to get the zoom link from Klaus.
> >
> > best regards
> > Janek
> >
> > --
> > --
> > Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> > Gdansk University of Technology (Gdansk Tech)
> > Faculty of Applied Physics and Mathematics
> > Department of Theoretical Physics and Quantum Information
> > --
> > http://yade-dem.org/
> > http://pg.edu.pl/jkozicki (click English flag on top right)
>
>
> --
> --
> Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
> Gdansk University of Technology (Gdansk Tech)
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Introducing Yade discord beta

[Robert Caulk]

Hey Yade devs,

A few of us were discussing the *idea of encouraging more collaboration*
among Yade devs and the idea came up to create a central server for
chatting about various topics and exchanging ideas.

Discord seems to be a good candidate for this since we can organize the
server into various topics (i.e. resources, polyhedra, fluid-couplings,
geomechanics etc.) Also, we don't need to install any software to join and
chat (there is a browser-based version)

*The goal of this discord* server is to bring yade devs and users together
in one place to chat freely and openly. If we are lucky, some
collaborations will pop up, if we are unlucky it may just become a landing
spot for new users.

Before we open it to the public, I'd like to invite you yade devs to the
"beta" server.  Come on over and say hey, start testing it out, and provide
feedback. If you have any suggestions for the layout/organization, please
let me know, and I will make sure to incorporate your recommendations.

So, see you over at the yade discord server:

https://discord.gg/kkZ4c3nQtV

Cheers,

Robert
___
Mailing list: https://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 Technical Archive - call for materials

[Robert Caulk]

Hey Yade devs,

Got Yade stuff lying around? Yade Technical Archive (YTA) is looking
for *seminar
presentations*, *papers*, *technical notes*, or* course materials* about
Yade.

Send us your Yade materials and we will:

   - *proofread* it for english,
   - *format* it into the standard YTA latex format,
   - host the file on the Yade website
   - add it to the archive list
   .

By sending these types of Yade materials to YTA, we all strengthen the
foundation of Yade and make it more accessible to more people :-). While at
the same time gaining valuable exposure for our esoteric .

Feel free to send anything you may have!

Cheers,

Robert
___
Mailing list: https://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] [Question #692441]: OpenFOAM YADE coupling iterations

[Robert Caulk]

Question #692441 on Yade changed:
https://answers.launchpad.net/yade/+question/692441

Status: Expired => Needs information

Robert Caulk changed the question status:
Maybe more information can be provided. Changing status.

-- 
You received this question notification because your team Yade
developers is subscribed to the question.

___
Mailing list: https://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] [Question #692441]: OpenFOAM YADE coupling iterations

[Robert Caulk]

Question #692441 on Yade changed:
https://answers.launchpad.net/yade/+question/692441

Robert Caulk posted a new comment:
I guess we would need more clarification of what evidence you are using
to see the difference in "iterations."

However, I am not familiar with openFOAM coupling so I probably cannot
help much more.

-- 
You received this question notification because your team Yade
developers is subscribed to the question.

___
Mailing list: https://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] [Question #692315]: Calculation time definition

[Robert Caulk]

Question #692315 on Yade changed:
https://answers.launchpad.net/yade/+question/692315

Status: Expired => Answered

Robert Caulk changed the question status:
Changing to answered to avoid launchpad janitor. Maybe someone will
answer someday.

-- 
You received this question notification because your team Yade
developers is subscribed to the question.

___
Mailing list: https://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] Joining yade-dev team

[Robert Caulk]

bisectionDecomposition.py is objectively better than
domaindecomposition.py. However, there is still utility in being able to
manually control the subdomains with domaindecomposition.py. And therefore
your corrections are very welcome :-)

On Thu, May 14, 2020 at 6:52 PM Sacha Duverger 
wrote:

> Thank you for welcoming me,
>
> I use domaindecomposition.py because the exemple I tried ([1]) used it.
> It wasn’t up to date with the current version of YADE. Now that you
> mention bisectionDecomposition.py, I’m beginning to think that I should
> have used [2] instead.
>
> [1] :
> https://gitlab.com/yade-dev/trunk/-/blob/master/examples/mpi/testMPI_3D.py
> [2] :
> https://gitlab.com/yade-dev/trunk/-/blob/master/examples/mpi/testMPI_3D_bisection.py
>
>
> On 14 May 2020, at 15:43, Robert Caulk  wrote:
>
> Out of curiosity, why are you using domaindecomposition.py instead of
> bisectionDecomposition.py?
>
> On Thu, May 14, 2020 at 2:39 PM Janek Kozicki (yade) <
> jkozicki-y...@pg.edu.pl> wrote:
>
>> Hi, welcome here! :)
>>
>> Bruno is leading the MPI programming effort, I will let him do the honors
>> ;)
>> BTW, he is in the middle of finishing the docs :)
>>
>> best regards
>> Janek
>>
>>
>> Sacha Duverger said: (by the date of Thu, 14 May 2020 13:39:37 +0200)
>>
>> > Hello,
>> >
>> > I’ve been using YADE since over a year now. I recently tried to use the
>> MPI parallelisation and I believe I found a couple of errors in the
>> py/domaindecomposition.py script.
>> >
>> > Could I join the yade-dev team so I can suggest my corrections? My
>> username on gitlab is @schd .
>> >
>> >
>> > Thank you,
>> >
>> > Sacha Duverger
>> > ___
>> > Mailing list: https://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, PhD. DSc. Arch. Assoc. Prof.
>> Gdańsk University of Technology
>> Faculty of Applied Physics and Mathematics
>> Department of Theoretical Physics and Quantum Information
>> --
>> http://yade-dem.org/
>> http://pg.edu.pl/jkozicki (click English flag on top right)
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Joining yade-dev team

[Robert Caulk]

Out of curiosity, why are you using domaindecomposition.py instead of
bisectionDecomposition.py?

On Thu, May 14, 2020 at 2:39 PM Janek Kozicki (yade) <
jkozicki-y...@pg.edu.pl> wrote:

> Hi, welcome here! :)
>
> Bruno is leading the MPI programming effort, I will let him do the honors
> ;)
> BTW, he is in the middle of finishing the docs :)
>
> best regards
> Janek
>
>
> Sacha Duverger said: (by the date of Thu, 14 May 2020 13:39:37 +0200)
>
> > Hello,
> >
> > I’ve been using YADE since over a year now. I recently tried to use the
> MPI parallelisation and I believe I found a couple of errors in the
> py/domaindecomposition.py script.
> >
> > Could I join the yade-dev team so I can suggest my corrections? My
> username on gitlab is @schd .
> >
> >
> > Thank you,
> >
> > Sacha Duverger
> > ___
> > Mailing list: https://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, PhD. DSc. Arch. Assoc. Prof.
> Gdańsk University of Technology
> Faculty of Applied Physics and Mathematics
> Department of Theoretical Physics and Quantum Information
> --
> http://yade-dem.org/
> http://pg.edu.pl/jkozicki (click English flag on top right)
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Removing trailing white space, yay or nay?

[Robert Caulk]

Hey yade devs,

Lately I’ve been letting my editor automatically remove trailing white
space in the files I’m working on. The benefit to doing this can be
disputed, but it seems most people agree that trailing white space is
undesirable because it can create unwanted commit noise and interfere with
other developers quick keys [1]. A Couple other benign reasons highlighted
in that thread:

   - It takes more storage space than necessary
   - The parser will have to skip an extra character for no good reason
   when compiling
   - Some editors might add an extra blank line when WordWrap is on and the
   trailing space doesn't fit
   - It feels like the cursor is hanging in thin air at the end of a line,
   every step to the right may cause it to either drop or to hover further to
   an unknown extent, it just feels unsteady (like those invisible or
   disappearing blocks that Super Mario used to jump on).


But clearly the first commit on a file where existing trailing white space
is removed is also going to look excessive and polluted [2]...

I will follow the majority opinion in our community on keeping or
progressively doing away with trailing white space. Thoughts?

Cheers,

Robert

[1]
https://softwareengineering.stackexchange.com/questions/121555/why-is-trailing-whitespace-a-big-deal
[2]
https://gitlab.com/yade-dev/trunk/merge_requests/296/diffs?diff_id=59111225_sha=bfa40d9617c0c3f03c5d8eaddfd52d4c075f2781#65534ad2321a960558c286a3a64b1c38fb17f52c
___
Mailing list: https://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] all bugs moved from launchpad to gitlab issues

[Robert Caulk]

Very nice, Janek :-).

Not sure about disabling launchpad bugs. Who “owns” yade launchpad?

Le mar. 5 févr. 2019 à 22:28, Janek Kozicki  a écrit :

> Can we disable reporting new bugs in launchpad interface and redirect
> to gitlab?
>
> Janek Kozicki said: (by the date of Tue, 5 Feb 2019 22:27:27 +0100)
>
> > Hi,
> >
> > I thought we should better migrate because hopping back and forth
> > between gitlab and launchpad while fixing LaTeX pngmath stuff was
> > very inconvenient.
> >
> > I have found this tool:
> >
> > https://github.com/dmi-try/lpgrabber
> >
> > git clone https://github.com/dmi-try/lpgrabber.git
> >
> > It automatically downloaded all bugs into a CSV file from launchpad.
> > gitlab can import CSV files, but without newlines in bug description.
> > So I spent 30minutes copying them back and forth. But still it was a
> > lot faster thanks to automatic import of bug titles.
> >
> > now we should close some issues that were fixed, some of them looong
> time ago ;)
>
> ___
> Mailing list: https://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 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

It’s ok to merge that full commit including flowboundingsphere.

I will make a new merge request with the periodic insertion images.

Le mar. 5 févr. 2019 à 19:15, Janek Kozicki <1814...@bugs.launchpad.net> a
écrit :

> I think rebasing will work now :) Unless Robert will happen to have a
> conflict in lib/triangulation/FlowBoundingSphereLinSolv.ipp which is in
> the first commit in this branch. Let us know!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1814286
>
> Title:
>   Various LaTeX symbols missing in Yade documentation
>
> Status in Yade:
>   New
>
> Bug description:
>   See [1]. Looks like the builder is missing some important LaTeX
>   libraries.
>
>
>   [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/yade/+bug/1814286/+subscriptions
>

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

Alright, I think I figured out the problem. See [1] and the solution
[2]. He adds the latex macros (\def, \let, \newcommand, etc) to his
layout.html. I will try this today and report back :-)


[1]https://github.com/sphinx-doc/sphinx/issues/726
[2]https://github.com/certik/theoretical-physics/pull/62/commits/36c583ddffd9c9375b8ed0971720237a0ef30e36


** Bug watch added: github.com/sphinx-doc/sphinx/issues #726
   https://github.com/sphinx-doc/sphinx/issues/726

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

>>Hmm, this search in Buster indicates that pngmath is still there,
am I missing something?

I guess it exists without support based on this warning thrown by make
doc:

"WARNING: sphinx.ext.pngmath has been deprecated. Please use
sphinx.ext.imgmath instead."

Have you tried replacing \def with \newcommand locally Janek?

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

Strange, I tried reverting that commit [1] and the problem persisted.

[1] https://gitlab.com/yade-dev/trunk/commit/34fb5ffef

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

I am unable to identify the source of the problem. I tried reverting [1]
and [2], but the problem persists. I tried changing delimiters, I tried
replacing \def with \newcommand (despite the fact that we should not
have to, see #12), but the problem persists.

It is worth reiterating that all PDF outputs look perfect.

Ok so I guess I will try these changes by WIP merge request on gitlab
instead of make doc on my own computer.

It would help me if someone could help me further understand exactly how
we "switched" to a new sphinx here. I am on ubuntu 18.04 and my python-
sphinx is the latest version, 1.6.7. Is the new gitlab buildbot using a
newer version compiled from sources? Was the 2018 buildbot using a newer
version too?

[1]https://gitlab.com/yade-dev/trunk/commit/34fb5ffef
[2]https://gitlab.com/yade-dev/trunk/commit/fda92731e3854d09302cf44fa97316875c16d859

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

According to [1], \def and \let should both work fine with mathjax

[1]http://docs.mathjax.org/en/latest/tex.html#tex-commands

I think this has something more to do with the the delimiters [2].
Testing now, will report back.

[2] http://docs.mathjax.org/en/latest/tex.html#defining-tex-macros

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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] Migration to gitlan - moving bugs to issues on gitlab?

[Robert Caulk]

Am I missing a subscription? I’m only receiving these messages once.

Le ven. 1 févr. 2019 à 23:08, Janek Kozicki  a écrit :

> > A mixed option could be to move bugs to gitlab and keep Q on LP, hence
> > separating them even more.
>
> Now I lean towards thinking that this might make some sense.
>
> In last conversation about pngmath and LaTeX symbols each message I
> received twice, and my last one I received four times :(
>
> issues would integrate neatly with the rest of gitlab, would allow to
> mark fixed bugs, etc.
>
> best regards
> Janek
>
>
>
> Bruno Chareyre said: (by the date of Fri, 14 Dec 2018 15:59:14 +0100)
>
> > Thanks for investigations Robert. That's convincing.
> > Mixing bugs and questions does not seem to be a good idea.
> > A mixed option could be to move bugs to gitlab and keep Q on LP, hence
> > separating them even more.
> > Not sure there is any real advantage in doing that, though.
> >
> > Bruno
>
>
>
> 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

[Yade-dev] [Bug 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

Yes, Mathjax seems cleaner. Does it result in better resolution of math
on the web. The old equations used to look grainy with pngmath iirc.

Is there a way to test changes and their effect on the website without
merging to develop branch?

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

Ah, it is probably worth moving away from pngmath. I guess we just need
to rewrite the \defs to accommodate mathjax?

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

Ok, after downloading the artifacts from the build, the PDF is built
perfectly fine.

This must be an issue on the HTML decoding webside, or something like
that.

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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 1814286] Re: Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

In fact, it looks like the compiler is ignoring \defs. For example:

\Dtcr [1] is defined by:

\def\Dtcr{\Dt_{\rm cr}}

Meanwhile other typical latex symbols are printing fine.


https://yade-dev.gitlab.io/trunk/formulation.html#estimation-of-by-wave-propagation-speed

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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 1814286] [NEW] Various LaTeX symbols missing in Yade documentation

[Robert Caulk]

Public bug reported:

See [1]. Looks like the builder is missing some important LaTeX
libraries.


[1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

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

Title:
  Various LaTeX symbols missing in Yade documentation

Status in Yade:
  New

Bug description:
  See [1]. Looks like the builder is missing some important LaTeX
  libraries.

  
  [1] https://yade-dev.gitlab.io/trunk/formulation.html#variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1814286/+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 1814052] Re: Unreproductible simulation (one core, one computer, one script) with a tutorial example

[Robert Caulk]

*In all cases I am executing yade -j1 mwe.py

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

[Yade-dev] [Bug 1814052] Re: Unreproductible simulation (one core, one computer, one script) with a tutorial example

[Robert Caulk]

I am able to reproduce the described behavior using both
makeCloud(seed=1) and regularHexa.

** Attachment added: "plots.zip"
   
https://bugs.launchpad.net/yade/+bug/1814052/+attachment/5234639/+files/plots.zip

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

[Yade-dev] [Bug 1814052] Re: Unreproductible simulation (one core, one computer, one script) with a tutorial example

[Robert Caulk]

I cannot find anywhere in your scripts where you are saving
scenes/packings, loading scenes/packings or resetting the scene.

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

[Yade-dev] [Bug 1814052] Re: Unreproductible simulation (one core, one computer, one script) with a tutorial example

[Robert Caulk]

makeCloud is a random generation of spheres [1]. Use the seed argument
if you want the same packing twice.

[1]https://yade-dem.org/doc/yade.pack.html

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

[Yade-dev] [Bug 1814052] Re: Unreproductible simulation (one core, one computer, one script) with a tutorial example

[Robert Caulk]

Please provide all necessary information to allow a developer to
reproduce your bug. For example, a running script, your method of yade
installation, and exact results that you are observing from said script.

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

[Yade-dev] [Bug 1813550] [NEW] FlowEngine memory leak - 600 Mb/hr

[Robert Caulk]

Public bug reported:

Running examples/oedometer.py with 8000 spheres, flow.useSolver=4 and
tracking RAM usage, I find we have a memory leak of 600 Mb/hr.

examples/oedometer.py with num_spheres=8000:

# -*- coding: utf-8 -*-

from yade import pack

num_spheres=8000# number of spheres
young=1e6
compFricDegree = 3 # initial contact friction during the confining phase
finalFricDegree = 30 # contact friction during the deviatoric loading
mn,mx=Vector3(0,0,0),Vector3(1,1,1) # corners of the initial packing

O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=radians(compFricDegree),density=2600,label='spheres'))
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=0,density=0,label='walls'))
walls=aabbWalls([mn,mx],thickness=0,material='walls')
wallIds=O.bodies.append(walls)

sp=pack.SpherePack()
sp.makeCloud(mn,mx,-1,0.,num_spheres,False, 0.95,seed=1) #"seed" make the 
"random" generation always the same
sp.toSimulation(material='spheres')

triax=TriaxialStressController(
 maxMultiplier=1.+2e4/young, # spheres growing factor (fast growth)
 finalMaxMultiplier=1.+2e3/young, # spheres growing factor (slow growth)
 thickness = 0,
 stressMask = 7,
 max_vel = 0.005,
 internalCompaction=True, # If true the confining pressure is generated by 
growing particles
)

newton=NewtonIntegrator(damping=0.2)

O.engines=[
 ForceResetter(),
 InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()]),
 InteractionLoop(
  [Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
  [Ip2_FrictMat_FrictMat_FrictPhys()],
  [Law2_ScGeom_FrictPhys_CundallStrack()],label="iloop"
 ),
 FlowEngine(dead=1,label="flow"),#introduced as a dead engine for the moment, 
see 2nd section
 
GlobalStiffnessTimeStepper(active=1,timeStepUpdateInterval=100,timestepSafetyCoefficient=0.8),
 triax,
 newton
]

triax.goal1=triax.goal2=triax.goal3=-1

while 1:
  O.run(1000, True)
  unb=unbalancedForce()
  if unb<0.001 and abs(-1-triax.meanStress)/1<0.001:
break

setContactFriction(radians(finalFricDegree))

## __   Oedometer section   _

#A. Check bulk modulus of the dry material from load/unload cycles
triax.stressMask=2
triax.goal1=triax.goal3=0

triax.internalCompaction=False
triax.wall_bottom_activated=False
#load
triax.goal2=-11000; O.run(2000,1)
#unload
triax.goal2=-1; O.run(2000,1)
#load
triax.goal2=-11000; O.run(2000,1)
e22=triax.strain[1]
#unload
triax.goal2=-1; O.run(2000,1)

e22=e22-triax.strain[1]
modulus = 1000./abs(e22)

#B. Activate flow engine and set boundary conditions in order to get 
permeability
flow.dead=0
flow.defTolerance=0.3
flow.meshUpdateInterval=200
flow.fluidBulkModulus=2.2e9
flow.useSolver=4
flow.desiredPorosity=0
flow.permeabilityFactor=1
flow.viscosity=10
flow.bndCondIsPressure=[0,0,1,1,0,0]
flow.bndCondValue=[0,0,1,0,0,0]
flow.boundaryUseMaxMin=[0,0,0,0,0,0]
O.dt=0.1e-3
O.dynDt=False

O.run(1,1)
Qin = flow.getBoundaryFlux(2)
Qout = flow.getBoundaryFlux(3)
permeability = abs(Qin)/1.e-4 #size is one, we compute K=V/∇H
print "Qin=",Qin," Qout=",Qout," permeability=",permeability

#C. now the oedometer test, drained at the top, impermeable at the bottom plate
flow.bndCondIsPressure=[0,0,0,1,0,0]
flow.bndCondValue=[0,0,0,0,0,0]
flow.updateTriangulation=True #force remeshing to reflect new BC immediately
newton.damping=0

#we want the theoretical value from Terzaghi's solution
#keep in mind that we are not in an homogeneous material and the small strain
#assumption is not verified => we don't expect perfect match
#there can be also an overshoot of pressure in the very beginning due to 
dynamic effects
Cv=permeability*modulus/1e4
zeroTime=O.time
zeroe22 = - triax.strain[1]
dryFraction=0.05 #the top layer is affected by drainage on a certain depth, we 
account for it here
drye22 = 1000/modulus*dryFraction
wetHeight=1*(1-dryFraction)

def consolidation(Tv): #see your soil mechanics handbook...
 U=1
 for k in range(50):
  M=pi/2*(2*k+1)
  U=U-2/M**2*exp(-M**2*Tv)
 return U

triax.goal2=-11000

from yade import plot

## a function saving variables
def history():
   
plot.addData(e22=-triax.strain[1]-zeroe22,e22_theory=drye22+(1-dryFraction)*consolidation((O.time-zeroTime)*Cv/wetHeight**2)*1000./modulus,t=O.time,p=flow.getPorePressure((0.5,0.1,0.5)),s22=-triax.stress(3)[1]-1)
   
#plot.addData(e22=-triax.strain[1],t=O.time,s22=-triax.stress(2)[1],p=flow.MeasurePorePressure((0.5,0.5,0.5)))

O.engines=O.engines+[PyRunner(iterPeriod=200,command='history()',label='recorder')]
##make nice animations:
#O.engines=O.engines+[PyRunner(iterPeriod=200,command='flow.saveVtk()')]

from yade import plot
plot.plots={'t':('e22','e22_theory',None,'s22','p')}
plot.plot()
O.saveTmp()
O.timingEnabled=1
from yade import timing
print "starting oedometer simulation"
O.run(200,1)
timing.stats()

## Make more steps to see the convergence to the stationnary solution

** Affects: yade

[Yade-dev] [Bug 1813550] Re: FlowEngine memory leak - 600 Mb/hr

[Robert Caulk]

flow.reuseOrdering functionality makes a copy of the factor for
efficient reuse. Algorithm was not freeing unnecessary copies.

Fixed with:

line 173 FLowBoundingSphereLinSolv.ipp:

if (!multithread && factorExists && useSolver==4){
if (getCHOLMODPerfTimings) gettimeofday (, NULL); 
cholmod_l_free_sparse(, );
cholmod_l_free_triplet(, );
if (!reuseOrdering) {
cholmod_l_free_factor(, );
++  cholmod_l_free_factor(, );  <<<++
cholmod_l_finish();
if (getCHOLMODPerfTimings){
gettimeofday (, NULL);
cout << "CHOLMOD Time to finalize 
singlethreaded com " << ((end.tv_sec *100   + end.tv_usec ) - (start.tv_sec 
* 100 + start.tv_usec )) << endl;
}
cholmod_l_start();
}
com.nmethods= 1; // nOrderingMethods; //1;
com.method[0].ordering = CHOLMOD_METIS; // orderingMethod; 
//CHOLMOD_METIS;
factorExists=false; 

}

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

Title:
  FlowEngine memory leak - 600 Mb/hr

Status in Yade:
  Fix Committed

Bug description:
  Running examples/oedometer.py with 8000 spheres, flow.useSolver=4 and
  tracking RAM usage, I find we have a memory leak of 600 Mb/hr.

  examples/oedometer.py with num_spheres=8000:

  # -*- coding: utf-8 -*-

  from yade import pack

  num_spheres=8000# number of spheres
  young=1e6
  compFricDegree = 3 # initial contact friction during the confining phase
  finalFricDegree = 30 # contact friction during the deviatoric loading
  mn,mx=Vector3(0,0,0),Vector3(1,1,1) # corners of the initial packing

  
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=radians(compFricDegree),density=2600,label='spheres'))
  
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=0,density=0,label='walls'))
  walls=aabbWalls([mn,mx],thickness=0,material='walls')
  wallIds=O.bodies.append(walls)

  sp=pack.SpherePack()
  sp.makeCloud(mn,mx,-1,0.,num_spheres,False, 0.95,seed=1) #"seed" make the 
"random" generation always the same
  sp.toSimulation(material='spheres')

  triax=TriaxialStressController(
   maxMultiplier=1.+2e4/young, # spheres growing factor (fast growth)
   finalMaxMultiplier=1.+2e3/young, # spheres growing factor (slow growth)
   thickness = 0,
   stressMask = 7,
   max_vel = 0.005,
   internalCompaction=True, # If true the confining pressure is generated by 
growing particles
  )

  newton=NewtonIntegrator(damping=0.2)

  O.engines=[
   ForceResetter(),
   InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()]),
   InteractionLoop(
    [Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
    [Ip2_FrictMat_FrictMat_FrictPhys()],
    [Law2_ScGeom_FrictPhys_CundallStrack()],label="iloop"
   ),
   FlowEngine(dead=1,label="flow"),#introduced as a dead engine for the moment, 
see 2nd section
   
GlobalStiffnessTimeStepper(active=1,timeStepUpdateInterval=100,timestepSafetyCoefficient=0.8),
   triax,
   newton
  ]

  triax.goal1=triax.goal2=triax.goal3=-1

  while 1:
    O.run(1000, True)
    unb=unbalancedForce()
    if unb<0.001 and abs(-1-triax.meanStress)/1<0.001:
  break

  setContactFriction(radians(finalFricDegree))

  ## __   Oedometer section   _

  #A. Check bulk modulus of the dry material from load/unload cycles
  triax.stressMask=2
  triax.goal1=triax.goal3=0

  triax.internalCompaction=False
  triax.wall_bottom_activated=False
  #load
  triax.goal2=-11000; O.run(2000,1)
  #unload
  triax.goal2=-1; O.run(2000,1)
  #load
  triax.goal2=-11000; O.run(2000,1)
  e22=triax.strain[1]
  #unload
  triax.goal2=-1; O.run(2000,1)

  e22=e22-triax.strain[1]
  modulus = 1000./abs(e22)

  #B. Activate flow engine and set boundary conditions in order to get 
permeability
  flow.dead=0
  flow.defTolerance=0.3
  flow.meshUpdateInterval=200
  flow.fluidBulkModulus=2.2e9
  flow.useSolver=4
  flow.desiredPorosity=0
  flow.permeabilityFactor=1
  flow.viscosity=10
  flow.bndCondIsPressure=[0,0,1,1,0,0]
  flow.bndCondValue=[0,0,1,0,0,0]
  flow.boundaryUseMaxMin=[0,0,0,0,0,0]
  O.dt=0.1e-3
  O.dynDt=False

  O.run(1,1)
  Qin = flow.getBoundaryFlux(2)
  Qout = flow.getBoundaryFlux(3)
  permeability = abs(Qin)/1.e-4 #size is one, we compute K=V/∇H
  print "Qin=",Qin," Qout=",Qout," permeability=",permeability

  #C. now the oedometer test, drained at the top, impermeable at the bottom 
plate
  flow.bndCondIsPressure=[0,0,0,1,0,0]
  flow.bndCondValue=[0,0,0,0,0,0]
  flow.updateTriangulation=True #force remeshing to reflect new BC immediately
  newton.damping=0

  #we want the theoretical value from Terzaghi's solution
  #keep in mind that we are 

Re: [Yade-dev] Trouble building from source on Ubuntu 18.04

[Robert Caulk]

Usually, we direct these types of questions to the Q forum (
https://answers.launchpad.net/yade).

Looking at the cmake warning:

CMake Warning at /usr/share/cmake-3.10/Modules/FindQt4.cmake:620 (message):
  /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib/x86_64-linux-gnu"
  but QtCore could not be found there.  Qt is NOT installed correctly for
the
  target build environment.

I would have to say Qt is NOT installed correctly for your target build
environment :-) Please ensure you have qt installed:

sudo apt-get install python-pyqt5 pyqt5-dev-tools python-pyqt5.qtwebkit

and for Ubuntu 18.04, you need:

sudo apt-get install libqglviewer-dev-qt5

Thank you,

Robert

On Mon, Jan 21, 2019 at 9:17 PM Vasileios Angelidakis (PGR) <
v.angelidak...@newcastle.ac.uk> wrote:

> Hi all,
>
>
> I just upgraded to Ubuntu 18.04 (which in retrospect doesn't feel like a
> good idea) and I have some difficulty building YADE from source. I cite
> below 1. the errors I get during configuring the build files and then 2.
> the errors I get when I try to compile them. Has anyone experienced similar
> problems? I would appreciate any advice on this.
>
>
> Many thanks,
>
>
> Vasileios
>
>
>- *1. Configuration of the compilation files*
>
>
> *b7063391@sage17-drum008:~/myYade/newBuild_21_Jan_19$ cd
> /home/b7063391/myYade/newBuild_21_Jan_19/build
> b7063391@sage17-drum008:~/myYade/newBuild_21_Jan_19/build$ cmake
> -DCMAKE_INSTALL_PREFIX=/home/b7063391/myYade/newBuild_21_Jan_19/install
> /home/b7063391/myYade/newBuild_21_Jan_19/trunk*
> -- The C compiler identification is GNU 7.3.0
> -- The CXX compiler identification is GNU 7.3.0
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found PythonInterp: /usr/bin/python (found version "2.7.15")
> -- Found OpenMP_C: -fopenmp (found version "4.5")
> -- Found OpenMP_CXX: -fopenmp (found version "4.5")
> -- Found OpenMP: TRUE (found version "4.5")
> CMake Warning at /usr/share/cmake-3.10/Modules/FindQt4.cmake:620 (message):
>   /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as
> "/usr/lib/x86_64-linux-gnu"
>   but QtCore could not be found there.  Qt is NOT installed correctly for
> the
>   target build environment.
> Call Stack (most recent call first):
>   CMakeLists.txt:39 (INCLUDE)
>
>
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
> -- Version is set to 2019-01-04.git-f5aa5f7
> -- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so
> -- GTS using gts-config /usr/bin/gts-config
> -- Using GTS from /usr
> -- Found GL2PS: /usr/lib/x86_64-linux-gnu/libgl2ps.so
> -- Found CGAL: /usr/include, /usr/lib/x86_64-linux-gnu/libCGAL.so
> -- Found NumPy: version "1.13.3"
> /usr/lib/python2.7/dist-packages/numpy/core/include
> -- Found Loki: /usr/include
> -- GCC Version >= 4.8. Adding -ftrack-macro-expansion=0
> -- GCC Version >= 4.8. Adding -save-temps
> -- GCC Version >= 4.9. Adding -fstack-protector-strong
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Looking for pthread_create
> -- Looking for pthread_create - not found
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Found Threads: TRUE
> -- Boost version: 1.65.1
> -- Found the following Boost libraries:
> --   python
> --   thread
> --   filesystem
> --   iostreams
> --   regex
> --   serialization
> --   system
> --   date_time
> --   chrono
> --   atomic
> --   Boost_VERSION: 106501
> --   Boost_LIB_VERSION: 1_65_1
> --   Boost_INCLUDE_DIRS: /usr/include
> --   Boost_LIBRARIES: /usr/lib/x86_64-linux-gnu/
> libboost_python.so/usr/lib/x86_64-linux-gnu/libboost_thread.so/usr/lib/x86_64-linux-gnu/libboost_filesystem.so/usr/lib/x86_64-linux-gnu/libboost_iostreams.so/usr/lib/x86_64-linux-gnu/libboost_regex.so/usr/lib/x86_64-linux-gnu/libboost_serialization.so/usr/lib/x86_64-linux-gnu/libboost_system.so/usr/lib/x86_64-linux-gnu/libboost_date_time.so/usr/lib/x86_64-linux-gnu/libboost_chrono.so/usr/lib/x86_64-linux-gnu/libboost_atomic.so/usr/lib/x86_64-linux-gnu/libpthread.so
> -- Found Eigen3: /usr/include/eigen3 (Required is at least version
> "2.91.0")
> -- Found BZip2: /usr/lib/x86_64-linux-gnu/libbz2.so (found version
> "1.0.6")
> -- Looking for BZ2_bzCompressInit
> -- Looking for BZ2_bzCompressInit - found
> -- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11")
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
> version "2.7.15rc1")
> 

Re: [Yade-dev] Potential Blocks and Potential Particles - Documentation

[Robert Caulk]

>>Is there any practical preference between .rst or latex files?

2 more cents:

If you are focused on a practical tutorial/guide, it is really best to
write it in .rst so it can be easily added to the website (and version
controlled as Jerome points out). If, on the other hand, you want to
present some methods, add a couple supporting results, and you want your
work to be citable with google scholar visibility, then a tex file with
Yade Technical Archive is best (and "frozen" as Jerome points out).  If you
prefer the later,  let me know so I can send you the current latex
template.

-rc



On Tue, Jan 22, 2019 at 9:35 AM Jerome Duriez 
wrote:

> > Is there any practical preference between .rst or latex files?
>
>
> In my opinion :
>
> - .rst files, and being somehow part of the doc, as we see it on
> https://yade-dem.org/doc, is much more visible and much easier to
> maintain (by different people, in particular) : it's under git version
> control for instance...
>
> On the other hand, the doc would not survive if it were inflated by new
> additions of sections each time someone proposes new stuff (which is
> otherwise obviously good)..
>
>
> - .tex files and Yade Technical archives make it much more one
> person-specific (for maintenance purposes). In my view, it's like a
> publication : almost frozen for all time.
>
> As a matter of fact we do not have any .tex files under version control
> (at the moment), and, in the way as I see things, it does not work for
> maintenance purposes to have something too deeply related with someone :
> people end up working at different institutions, or on a different
> subject, and they logically end up at some point not being able to
> maintain what they proposed earlier..
>
>
>
> As you see, this will not tremendously help you to make a choice, but I
> wanted to take the opportunity to express some general opinions on the
> subject. Others are welcome..
>
>
> Jérôme
>
> --
> Chargé de Recherche / Research Associate
> Irstea, RECOVER
> 3275 route Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
> +33 (0)4 42 66 99 21
>
> On 21/01/2019 21:31, Vasileios Angelidakis (PGR) wrote:
> >
> > Hi,
> >
> >
> > Regarding the writing of a documentation for the "Potential Particles"
> > and the "Potential Blocks" codes, I am happy to help
> > on a more consistent basis, as I currently use them. Is there any
> > practical preference between .rst or latex files?
> >
> > Chia, I can transcribe your introductory word file and add some
> > "command-to-command" comments.
> >
> >
> > All the best,
> >
> >
> > Vasileios
> > 
> > 
> > *From:* Yade-dev
> >  on
> > behalf of Janek Kozicki 
> > *Sent:* 21 January 2019 20:19:04
> > *To:* Chia Weng Boon
> > *Cc:* Yade developers
> > *Subject:* Re: [Yade-dev] Potential Blocks and Potential Particles -
> > Documentation
> > Hi Boon,
> >
> > awesome! I'm not sure if I need to reply to your address, or only to
> > yade-dev, so to be safe I reply to both now.
> >
> > I did follow your instructions exactly and now all four examples did
> > start and run. But unfortunately they appeared to work incorrectly :(
> >
> > Here's the list of problems I encountered:
> >
> > WedgeYADE.py
> >
> > The scene is empty until I click Display->intrAllWire
> >
> > I am not sure maybe the calculation is going on correctly, but since
> > the shape is not drawn it is very hard to tell.
> >
> > Also the terminal is spammed with messages like KnKsPBLaw.cpp:34
> > go:geom->penetrationDepth=0.00155115; de1->se3.position=-14.8839
> > 8.48539 26.8419; de2->se3.position=-17.682 -6.95829 26.8667;
> >
> > And the messages are so fast that it slows down calculation very fast.
> >
> >
> > cubePBscaled.py
> >
> > The same problem as above also there are extra messages:
> >
> > ../yade:70: DeprecationWarning: dynamic=True is deprecated, use
> > fixed=False instead
> >   print 20*'*'+' UNEXPECTED EXCEPTION WHILE RUNNING TESTS '+20*'*'
> >   print 'WARNING: compiled without OpenMP, -j/--threads/--cores have
> > no effect.'
> >   else: os.environ['OMP_NUM_THREADS']='1'
> >
> > basic.py
> >
> > The sphere does not collide with the box, it goes through.
> >
> >
> > cubePPscaled.py
> >
> > Drawing shapes is a bit slow, so it's hard to tell if it runs
> > correctly. I disabled drawing of shapes, enabled intrAllWire. Ran
> > simulation a bit and it seemed to work.
> > Then I clicked to enable drawing shapes and I got SIGSEGV/SIGABRT
> > handler called; gdb
> >
> >
> > Also I see that your merge request has some lines like "not used"
> > which is confirmed by similar compiler warnings like this one:
> >
> > BlockGen.cpp:326:22: warning: unused variable ‘linecount’
> > [-Wunused-variable]
> > BlockGen.cpp:2670:48: warning: unused variable ‘zlocalA’
> > [-Wunused-variable]
> >
> >
> >
> > best regards
> > Janek
> >
> >
> >
> >
> > Chia Weng Boon said: (by the 

[Yade-dev] [Bug 1810283] Re: Wiki homepage broken

[Robert Caulk]

https://www.yade-dem.org/wiki/Yade works just fine for me. Might've been
on their side as you suggest.

-- 
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 Yade:
  New

Bug description:
  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)

  from within function "SqlBagOStuff::set". Database returned error "1114: The 
table 'yade_objectcache' is full (localhost)".
  ***

  No idea whether it's a problem on wikimedia's, or our side ?

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

[Robert Caulk]

 >> If you asked me it is probably time to move everything (incl. code,
Q, bug tracking etc.)
>> If source code was migrated, same question for bug tracking and answers?

I looked into this. From what I can tell, GitLab only offers issue
tracking, which is analgous to bug tracking on LP. Issue tracking was not
meant to be a Q forum, however, some projects use issue tracking (aka bug
tracking on LP) as a place for community support [1], despite the awkward
interface. GitLab does provide a nice labeling system, so questions or
"support requests" can be filtered as such. But it is likely that Yade
users will become confused since it is not a traditional forum format, they
will simply search through all bugs and questions at once, they will post
without considering the labels, or worse, they will use the wrong labels.
I'm scared of a disorganized mess. What do you guys think? Was it useful to
keep bugs and community questions separate?

If we decide it is preferable to combine bugs (issues) with community
questions, then I vote for an effort to migrate the launchpad Q archives
over to GitLab issues. I looked around and found some apathetic conclusions
regarding Launchpad->GitLab bug migrations [2]. Ultimately, some tools
exist but they will likely need to be retooled. This could be a significant
project, tough to tell...

Given all this information, I lean toward leaving the Q on launchpad.
What is your opinion?

[1]https://gitlab.com/gitlab-org/gitlab-ce/issues/20851
[2]https://gitlab.com/gitlab-org/gitlab-ce/issues/47399

rc

Le mer. 12 déc. 2018 à 07:52, Klaus Thoeni  a
écrit :

> Hi Bruno,
>
> yes, that's right. Dev's should have the rights to do that.
>
> K
>
> On Wed, Dec 12, 2018 at 2:00 AM Bruno Chareyre <
> bruno.chare...@3sr-grenoble.fr> wrote:
>
>>
>>
>> On 12/5/18 7:21 AM, Klaus Thoeni wrote:
>> > I terms of branching, I think this should be kept flexible. I think
>> > branches make sense if you work on major changes. However, I still
>> > think main devs should be able to push directly to the trunk,
>> > obviously with care ;-)
>> I think we need to distinguish two aspects:
>> 1- do we "push" or do we "request-merge"?
>> 2- who is allowed to accept the merge requests?
>>
>> I don't see a real need to use direct push (point 1), one exception is
>> when fixing simple bugs maybe.
>> What you say is more  (I guess) that some devs need enough rights to
>> accept their own MR (point 2). Right?
>>
>> Bruno
>>
>>
>>
>>
>> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Migrating to GitLab

[Robert Caulk]

Hello,

I agree with a migration to GitLab for all the points already mentioned. It
seems the impact on the Yade project can only be positive if I am reading
these emails correctly. I find Anton's review especially compelling - there
is nothing like a glowing recommendation from someone who has used the tool
for two years.

Since I have nothing more to contribute, I might as well point out that
GitHub is now owned by Microsoft, which means we will likely start seeing
some changes to GitHub that stem from shareholder appetite rather than the
open source ideology to which we have become accustomed. GitLab seems to be
the only alternative committed to open source. Does the Yade community want
to continue supporting open source projects or would it rather support
Microsoft's title as the most valuable company in the world?


Cheers,

Robert

On Tue, Dec 4, 2018 at 10:02 AM Luc Sibille 
wrote:

> Hello,
>
> I am rather a user of Yade than a developer. Hence, as a user, I would say
> that one of the possible weakness of Yade is that the release versions may
> not be always very stable, may include some features not always well
> validated (i.e. with some bugs), or may present strong discontinuities
> (from one version to another) in the way to use some features or in the
> computation itself (changing the numerical results).
> To be clear, I am not saying all that is going bad in Yade currently. It
> is a risk, it was not so good at the beginning of Yade but I think there
> have been great improvements with respect to these points since the
> beginning. So things are going in the right direction.
> Nevertheless, always as a user, when I know I am starting a work with Yade
> that will last several months or several years, I take care to keep on my
> computer, for this work, the same version of Yade with the same libraries
> during all the work (to avoid differences in the numerical results which
> could be induced by different versions and also to avoid the (too often)
> updates of the python scripts, but probably I am too lazy).
>
> In conclusion, I think it is important for the community of Yade Users
> (and too still enlarge this community and keep of even improve the
> confidence of users in Yade), to choose the way that will help to get the
> most stable and validated release versions of YADE (but I am not able to
> say which way it should be ;-) ).
>
> Probably, it is already obvious for you but I think important to stress
> this aspect.
>
> Best,
> Luc
>
>
> Le 03/12/2018 à 20:07, Bruno Chareyre a écrit :
>
> Thanks Jerôme, Janek, and Anton, for feedback.
> I'll try and address some questions.
>
> @Jérôme
> The objective of this thread is not to measure available human ressource
> but to use it more efficiently, instead. Recent git activity can provide us
> with example cases but it is not so relevant overall.
>
> *> Would we have new features using gitlab ? I got more and more used to
> github and like it for its commit comments / pull requests / issues. We
> actually barely / > do not use those... ** but maybe this could change in
> the future. Would we have the same on gitlab ? (Yes ?) *
>
> Yes, definitely most features of github have equivalent things in gitlab.
>
> *> I also see there are gtilab versions that require a fee ([1] in your
> email). Are we going to use (for the integration framework) a free version
> ?*
>
> Exactly like github. Not an issue, we use free version in both cases.
>
> *> 1. Regarding the possibility to update trunk from other branchs only:
> this would mean every dev should make a public branch before pushing to
> trunk/master ? *
>
> Everyone should work on a branch then merge, yes (public or not, it
> doesn't matter). It is good practice anyway and I think we need to move in
> this direction with or without gitlab. That's actually what many devs do
> already, see e.g. the yade-mpi branch (
> https://github.com/bchareyre/yade-mpi).
> When pushing to master there is no way to see the revision before
> accepting it. That is, it will be built and uploaded to public repos for
> everyone to download, without control. That would be fine if test coverage
> was approaching 100% but we are probably closer to 10%, it is not a safe
> situation.
> With merge requests revisions can be shown before entering the
> build/release loop.
>
>
> * > I think a more controlled / pre-assessed way of doing things is not be
> possible with our current HR. *
> The current post-assessment approach is not necessarily less time
> consuming and it does not seem to guarantee stability, hence why our HR are
> seeking improvement.
>
> * > **people can not do otherwise than looking closely at things when
> they are directly concerned (which is not always obvious to realize by the
> way).*
>
> A maintainer can't be happy with watching just a short selection of files.
> The whole project needs to be maintained 

[Yade-dev] [Bug 1804621] Re: bodyNumInteractionsHistogram broken

[Robert Caulk]

Thanks Jerome, I guess I did not understand the original proposal to
only change the argument type of bodyNumInteractionsHistogram. Seems to
be a better solution than changing each of the other functions I pointed
out.

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

Bug description:
  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', 
bodyNumInteractionsHistogram(aabbExtrema())
  

  which returns (with trunk version) :

  ArgumentError: Python argument types in
  yade._utils.bodyNumInteractionsHistogram(list)
  did not match C++ signature:
  bodyNumInteractionsHistogram(boost::python::tuple aabb, bool 
contactOnly=False)

  
  because my commit [*] changed the Python return type of aabbExtrema() from 
tuple to list.

  
  Possible (and easiest) fix would be to change all corresponding py::tuple 
aabb from py::list aabb. Agree ? 

  Or do we want this function to deal with Python tuples and not lists
  ?..


  Jérôme

  [*]
  https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1

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

[Robert Caulk]

It seems the only option is to go through and fix these functions
manually. Let's just make sure we find everything that needs to be fixed
before committing the fix. Can you verify the list below and also look
through the trunk to see if there are any other unintended effects?

Looking through trunk/utils.py it seems the following functions need to be 
fixed:
uniaxialTestFeatures()[1]
aabbDim() [2]
plotNumInteractions() [3] 
plotDirections() [4]
avgNumInteractions() [7]

Meanwhile, the flexibility of the python language means that the following 
functions should work before and after the change, right? :
fractionalBox()[5] 
perpindicularArea()[6]

Cheers,

Robert

[*]https://bugs.launchpad.net/yade/+bug/1764424
[1]https://github.com/yade/trunk/blob/720a352989c9b1148cf04022d14ec3da233fe563/py/utils.py#L558
[2]https://github.com/yade/trunk/blob/720a352989c9b1148cf04022d14ec3da233fe563/py/utils.py#L379
[4]https://github.com/yade/trunk/blob/720a352989c9b1148cf04022d14ec3da233fe563/py/utils.py#L448
[3]https://github.com/yade/trunk/blob/720a352989c9b1148cf04022d14ec3da233fe563/py/utils.py#L459
[5]https://github.com/yade/trunk/blob/720a352989c9b1148cf04022d14ec3da233fe563/py/utils.py#L402
[6]https://github.com/yade/trunk/blob/720a352989c9b1148cf04022d14ec3da233fe563/py/utils.py#L393
[7]https://github.com/yade/trunk/blob/720a352989c9b1148cf04022d14ec3da233fe563/py/utils.py#L419

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

Bug description:
  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', 
bodyNumInteractionsHistogram(aabbExtrema())
  

  which returns (with trunk version) :

  ArgumentError: Python argument types in
  yade._utils.bodyNumInteractionsHistogram(list)
  did not match C++ signature:
  bodyNumInteractionsHistogram(boost::python::tuple aabb, bool 
contactOnly=False)

  
  because my commit [*] changed the Python return type of aabbExtrema() from 
tuple to list.

  
  Possible (and easiest) fix would be to change all corresponding py::tuple 
aabb from py::list aabb. Agree ? 

  Or do we want this function to deal with Python tuples and not lists
  ?..


  Jérôme

  [*]
  https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1

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

[Robert Caulk]

Hello Yade devs,

It seems the buildbot's tmp/ directory might be in need of cleaning or
restructuring considering the current error (which is preventing a full
build):

mktemp: failed to create directory via template '/tmp/xvfb-run.XX': Too
many links

Tough to say what the problem really is without access to the buildbot, but
I found this blog post discussing a possible long term fix [1]. I am happy
to troubleshoot more if someone can help me access the buildbot :-)

https://blog.nexcess.net/2012/04/27/mkdir-too-many-links-what-it-is-and-how-to-fix/

Cheers,

Robert
___
Mailing list: https://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] Building Documentation

[Robert Caulk]

I see. Hmm, can you share some of the warnings you notice during
compilation? (especially the "final" one)?

On Mon, Oct 22, 2018 at 11:44 AM Eulitz, Alexander <
alexander.eul...@iwf.tu-berlin.de> wrote:

> Sorry, I indeed did make doc in build folder :(
>
>
>
>
>
> *Von:* Robert Caulk [mailto:rob.ca...@gmail.com]
> *Gesendet:* Montag, 22. Oktober 2018 11:31
> *An:* Eulitz, Alexander
> *Cc:* Yade developers
> *Betreff:* Re: [Yade-dev] Building Documentation
>
>
>
> Yes, so you need to "make doc" inside the build folder instead.
>
>
>
> On Mon, Oct 22, 2018 at 11:21 AM Eulitz, Alexander <
> alexander.eul...@iwf.tu-berlin.de> wrote:
>
> Hi Jerome, hi Robert,
>
> after “make doc” in install folder I end up with the .html files in:
>
> path/to/buildfolder/doc/sphinx/_build/html
>
>
>
> In install/share/doc/yade-version/yade.pdf there is just the yade logo but
> nothing else.
>
> Cheers,
>
> Alex
>
>
>
> *Von:* Yade-dev [mailto:yade-dev-bounces+alexander.eulitz=
> iwf.tu-berlin...@lists.launchpad.net] *Im Auftrag von *Robert Caulk
> *Gesendet:* Montag, 22. Oktober 2018 10:29
> *An:* jerome.dur...@irstea.fr
> *Cc:* Yade developers
> *Betreff:* Re: [Yade-dev] Building Documentation
>
>
>
> Hello Alex and Jerome,
>
>
>
> Just to clarify, you are running make doc from inside your build folder,
> right?
>
>
>
> When I run make doc after running make install, the yade.pdf appears in
> install/share/doc/yade-version/yade.pdf, as described in the yade install
> webpage.
>
>
>
> Cheers,
>
>
>
> Robert
>
>
>
> On Mon, Oct 22, 2018 at 9:45 AM Jerome Duriez 
> wrote:
>
> Hi Alex,
>
> At least, I get the same behavior as you, here.
>
> Cheers,
>
> 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 10/10/2018 18:05, Eulitz, Alexander wrote:
> >
> > Hi,
> >
> > I just tried building the documentation from source according to [1]
> > (just locally for evaluating changes I’d like to make at the doc).
> >
> > The build succeeded with some warnings. Anyway I cant find the
> > documentation in the folder given in the manual:
> >
> > /path/to/installfolder/share/doc/yade-your-version
> >
> > instead I can find it here:
> >
> > /path/to/buildfolder/doc/sphinx/_build/html
> >
> > Is this the usual behaviour?
> >
> > Cheers
> >
> > Alex
> >
> > [1] https://yade-dem.org/doc/installation.html#source-code
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Building Documentation

[Robert Caulk]

Yes, so you need to "make doc" inside the build folder instead.

On Mon, Oct 22, 2018 at 11:21 AM Eulitz, Alexander <
alexander.eul...@iwf.tu-berlin.de> wrote:

> Hi Jerome, hi Robert,
>
> after “make doc” in install folder I end up with the .html files in:
>
> path/to/buildfolder/doc/sphinx/_build/html
>
>
>
> In install/share/doc/yade-version/yade.pdf there is just the yade logo but
> nothing else.
>
> Cheers,
>
> Alex
>
>
>
> *Von:* Yade-dev [mailto:yade-dev-bounces+alexander.eulitz=
> iwf.tu-berlin...@lists.launchpad.net] *Im Auftrag von *Robert Caulk
> *Gesendet:* Montag, 22. Oktober 2018 10:29
> *An:* jerome.dur...@irstea.fr
> *Cc:* Yade developers
> *Betreff:* Re: [Yade-dev] Building Documentation
>
>
>
> Hello Alex and Jerome,
>
>
>
> Just to clarify, you are running make doc from inside your build folder,
> right?
>
>
>
> When I run make doc after running make install, the yade.pdf appears in
> install/share/doc/yade-version/yade.pdf, as described in the yade install
> webpage.
>
>
>
> Cheers,
>
>
>
> Robert
>
>
>
> On Mon, Oct 22, 2018 at 9:45 AM Jerome Duriez 
> wrote:
>
> Hi Alex,
>
> At least, I get the same behavior as you, here.
>
> Cheers,
>
> 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 10/10/2018 18:05, Eulitz, Alexander wrote:
> >
> > Hi,
> >
> > I just tried building the documentation from source according to [1]
> > (just locally for evaluating changes I’d like to make at the doc).
> >
> > The build succeeded with some warnings. Anyway I cant find the
> > documentation in the folder given in the manual:
> >
> > /path/to/installfolder/share/doc/yade-your-version
> >
> > instead I can find it here:
> >
> > /path/to/buildfolder/doc/sphinx/_build/html
> >
> > Is this the usual behaviour?
> >
> > Cheers
> >
> > Alex
> >
> > [1] https://yade-dem.org/doc/installation.html#source-code
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Building Documentation

[Robert Caulk]

Hello Alex and Jerome,

Just to clarify, you are running make doc from inside your build folder,
right?

When I run make doc after running make install, the yade.pdf appears in
install/share/doc/yade-version/yade.pdf, as described in the yade install
webpage.

Cheers,

Robert

On Mon, Oct 22, 2018 at 9:45 AM Jerome Duriez 
wrote:

> Hi Alex,
>
> At least, I get the same behavior as you, here.
>
> Cheers,
>
> 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 10/10/2018 18:05, Eulitz, Alexander wrote:
> >
> > Hi,
> >
> > I just tried building the documentation from source according to [1]
> > (just locally for evaluating changes I’d like to make at the doc).
> >
> > The build succeeded with some warnings. Anyway I cant find the
> > documentation in the folder given in the manual:
> >
> > /path/to/installfolder/share/doc/yade-your-version
> >
> > instead I can find it here:
> >
> > /path/to/buildfolder/doc/sphinx/_build/html
> >
> > Is this the usual behaviour?
> >
> > Cheers
> >
> > Alex
> >
> > [1] https://yade-dem.org/doc/installation.html#source-code
> >
> >
> > ___
> > Mailing list: https://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 1604266] Re: yade not working prpoperly on Ubuntu/Kubuntu 16.04

[Robert Caulk]

Thanks Bruno. I confirm that your patch fixed the problem on my computer
running VM 16.04.

I should point out that in the end, the common denominator of people
running into this problem was that they were all using a virtual
machine.

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

Title:
  yade not working prpoperly on Ubuntu/Kubuntu 16.04

Status in Yade:
  Fix Committed

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

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

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

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

[Yade-dev] [Bug 1790167] Re: JCFPM: "neverErase" modifies the simulated behavior while it should not

[Robert Caulk]

>>
I always get the same curve when running the simulation with the same packing 
(with either neverErase=True or neverErase=False). I don't face the problem you 
mentioned Robert...
>>

Ok, I re-ran your scripts with -j1 (instead of -j6), and sure enough, I
am able to replicate results (neverErase=True and False). Looking back
at the comparison of two replicate runs with -j6, the difference is
almost as staggering as comparing neverErase=True vs
neverErase=False...how could floating point differences add up to almost
3% difference for peak strength?! Also, my curves do not match yours
exactly (they are close though), why? I guess this is a not the bug we
are focused on here...

W.r.t the bug in this thread: is it possible that the interaction
between two particles gets "neverErased" (i.e. shearForce = normalForce
= FnMax=FsMax = 0), but then the particles later regain contact and
"want" to interact frictionally? In this case they but cannot interact
frictionally since we have assigned all the interaction values to 0,
right? In contrast, the neverErase=False case would allow two particles
to lose cohesive contact and later regain frictional contact since the
collider handles interaction disposal and creation, right?

>>
The difference is "minimal" in this case (post peak) but I have other results 
where it is pretty important (even pre peak).
>>

I would say any difference is significant considering we are able to get
perfect replicates. Also, you mention pre peak differences: have you
ever noticed any differences BEFORE a single bond has failed?

Robert

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

Title:
  JCFPM: "neverErase" modifies the simulated behavior while it should
  not

Status in Yade:
  New

Bug description:
  I noticed that running the exact same simulation (with same initial
  packing) gives different behaviors (stress-strain response in, e.g., a
  compression test) when neverErase is True or False. Given the purpose
  of neverErase (keep record of broken contacts, primarily for DFNFlow),
  it should not. The difference can be more or less important depending
  on the situation but it always exists. I could not figure out the
  cause of this yet but it seems that it comes from the treatment of
  broken contacts (obviously).

  Here is a simulation (uniaxial compression) that illustrates the
  problem. Running the same script using the exact same sample (to make
  sure the error does not come from a difference in the packings used)
  with either neverErase=True or neverErase=False produces 2 stress-
  strain curves which deviate at some point during the simulation. I
  made sure that the error is only due to neverErase by running the same
  simulations several times. The curves obtained with neverErase=True
  are always identical, as the curves obtained with neverErase=False.
  For those who would be interested, I also attach a packing  and the
  python script to plot the curves (below the simulation script).

  
  ### yade script ###

  
  from yade import ymport, pack, plot 

   material definition
  def sphereMat(): return 
JCFpmMat(type=1,density=3000,young=1e9,poisson=0.2,tensileStrength=1e6,cohesion=10e6,frictionAngle=radians(30))

  # create the specimen
  #L=0.10
  #D=0.05
  #pred=pack.inCylinder((0,0,0),(0,0,L),D/2.)
  
#O.bodies.append(pack.regularHexa(pred,radius=D/20.,gap=0.,material=sphereMat)) 
  
#O.bodies.append(pack.randomDensePack(pred,radius=D/20.,rRelFuzz=0.4,spheresInCell=1000,memoizeDb='/tmp/gts-triax-packings.sqlite',returnSpherePack=False,color=(0.9,0.8,0.6),material=sphereMat))

   import the specimen
  
O.bodies.append(ymport.text('121_3k.spheres',scale=1.,shift=Vector3(0,0,0),material=sphereMat))

   help define boundary conditions (see utils.uniaxialTestFeatures)
  bb=utils.uniaxialTestFeatures()
  
negIds,posIds,longerAxis,crossSectionArea=bb['negIds'],bb['posIds'],bb['axis'],bb['area']

  # DEM loop + ENGINES DEFINED HERE

  O.engines=[
   ForceResetter(),
  
InsertionSortCollider([Bo1_Sphere_Aabb(aabbEnlargeFactor=1.2,label='Saabb')]),
   InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(interactionDetectionFactor=1.2,label='SSgeom')],

[Ip2_JCFpmMat_JCFpmMat_JCFpmPhys(cohesiveTresholdIteration=1,label='interactionPhys')],

[Law2_ScGeom_JCFpmPhys_JointedCohesiveFrictionalPM(neverErase=False,label='interactionLaw')]
   ),
   
UniaxialStrainer(strainRate=-0.01,axis=longerAxis,asymmetry=0,posIds=posIds,negIds=negIds,crossSectionArea=crossSectionArea,blockDisplacements=1,blockRotations=1,setSpeeds=0,stopStrain=0.1,dead=1,label='strainer'),
   
GlobalStiffnessTimeStepper(active=1,timeStepUpdateInterval=10,timestepSafetyCoefficient=0.8,defaultDt=utils.PWaveTimeStep()),
   NewtonIntegrator(damping=0.4,label='newton'),
   

[Yade-dev] DFNFlow check script and trickPerm uncertainty fix

[Robert Caulk]

Hello,

I am working on a check test for DFNFlow in which I use pressure and
aperture as pass criteria. However, I want this check script to be a
repeatable baseline for DFNFlow, so I'd like to remove/replace the existing
uncertainty associated with tricking permeability. If this change may
affect you, please review the following and reply with your
comments/suggestions.

*Existing problem:*
Currently, DFNFlow tricks facet permeability by using the most recently
visited edge, which means the tricked facet permeability has no physical
basis, in fact, it depends on the order of the C++ for loop.

*Discussed solution:*
Luc, Timos, Bruno, and I discussed this a bit in Aix-en-Provence and
agreed(?) that we should increment the total aperture of a facet for every
broken edge associated with that facet. In other words, if one facet has 2
broken edges, the aperture used to trick facet permeability is the
summation of both apertures (instead of the most recently visited edge
during tickPerm loop). Thus, the aperture incrementation method has some
physical basis and no longer depends on the order of C++ for loop.

If we want/need to keep the uncertain trickPerm method around, let me know
and I will add a flag for you.

*Proposed changes to DFNFlow.cpp [1]:*

DFNFlow.cpp around line 245:

// increment the facet's aperture member:
if (cell1->info().count()[currentFacet.second] < 3){
  cell1->info().count()[currentFacet.second] += 1;
  cell1->info().aperture()[currentFacet.second] += aperture;
  }

// use the incremented facet aperture member to update facet permeability:
cell1->info().kNorm()[currentFacet.second] =
cell2->info().kNorm()[Tri.mirror_index(cell1,currentFacet.second)] =
apertureFactor*pow(cell1->info().aperture()[currentFacet.second],3)/(12*viscosity);

*Status:*
I used this method for creating the DFNFlow check script - the code is
stable and produces repeatable pass criteria.

Cheers,

Robert

[1]https://github.com/yade/trunk/blob/master/pkg/pfv/DFNFlow.cpp
___
Mailing list: https://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 1790167] Re: JCFPM: "neverErase" modifies the simulated behavior while it should not

[Robert Caulk]

I am also curious as to why we see changes in these curves between
replicates (even for neverErase=False), despite our use of a constant
sphere packing...

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

Title:
  JCFPM: "neverErase" modifies the simulated behavior while it should
  not

Status in Yade:
  New

Bug description:
  I noticed that running the exact same simulation (with same initial
  packing) gives different behaviors (stress-strain response in, e.g., a
  compression test) when neverErase is True or False. Given the purpose
  of neverErase (keep record of broken contacts, primarily for DFNFlow),
  it should not. The difference can be more or less important depending
  on the situation but it always exists. I could not figure out the
  cause of this yet but it seems that it comes from the treatment of
  broken contacts (obviously).

  Here is a simulation (uniaxial compression) that illustrates the
  problem. Running the same script using the exact same sample (to make
  sure the error does not come from a difference in the packings used)
  with either neverErase=True or neverErase=False produces 2 stress-
  strain curves which deviate at some point during the simulation. I
  made sure that the error is only due to neverErase by running the same
  simulations several times. The curves obtained with neverErase=True
  are always identical, as the curves obtained with neverErase=False.
  For those who would be interested, I also attach a packing  and the
  python script to plot the curves (below the simulation script).

  
  ### yade script ###

  
  from yade import ymport, pack, plot 

   material definition
  def sphereMat(): return 
JCFpmMat(type=1,density=3000,young=1e9,poisson=0.2,tensileStrength=1e6,cohesion=10e6,frictionAngle=radians(30))

  # create the specimen
  #L=0.10
  #D=0.05
  #pred=pack.inCylinder((0,0,0),(0,0,L),D/2.)
  
#O.bodies.append(pack.regularHexa(pred,radius=D/20.,gap=0.,material=sphereMat)) 
  
#O.bodies.append(pack.randomDensePack(pred,radius=D/20.,rRelFuzz=0.4,spheresInCell=1000,memoizeDb='/tmp/gts-triax-packings.sqlite',returnSpherePack=False,color=(0.9,0.8,0.6),material=sphereMat))

   import the specimen
  
O.bodies.append(ymport.text('121_3k.spheres',scale=1.,shift=Vector3(0,0,0),material=sphereMat))

   help define boundary conditions (see utils.uniaxialTestFeatures)
  bb=utils.uniaxialTestFeatures()
  
negIds,posIds,longerAxis,crossSectionArea=bb['negIds'],bb['posIds'],bb['axis'],bb['area']

  # DEM loop + ENGINES DEFINED HERE

  O.engines=[
   ForceResetter(),
  
InsertionSortCollider([Bo1_Sphere_Aabb(aabbEnlargeFactor=1.2,label='Saabb')]),
   InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(interactionDetectionFactor=1.2,label='SSgeom')],

[Ip2_JCFpmMat_JCFpmMat_JCFpmPhys(cohesiveTresholdIteration=1,label='interactionPhys')],

[Law2_ScGeom_JCFpmPhys_JointedCohesiveFrictionalPM(neverErase=False,label='interactionLaw')]
   ),
   
UniaxialStrainer(strainRate=-0.01,axis=longerAxis,asymmetry=0,posIds=posIds,negIds=negIds,crossSectionArea=crossSectionArea,blockDisplacements=1,blockRotations=1,setSpeeds=0,stopStrain=0.1,dead=1,label='strainer'),
   
GlobalStiffnessTimeStepper(active=1,timeStepUpdateInterval=10,timestepSafetyCoefficient=0.8,defaultDt=utils.PWaveTimeStep()),
   NewtonIntegrator(damping=0.4,label='newton'),
   PyRunner(iterPeriod=int(100),initRun=True,command='recorder()',label='data'),
  ]

  # RECORDER DEFINED HERE

  def recorder():
  yade.plot.addData({'i':O.iter,
 'eps':strainer.strain,
 'sigma':strainer.avgStress,
 'tc':interactionLaw.nbTensCracks,
 'sc':interactionLaw.nbShearCracks,
 'te':interactionLaw.totalTensCracksE,
 'se':interactionLaw.totalShearCracksE,
 'unbF':utils.unbalancedForce()})
  plot.saveDataTxt('compressionTest_1')

  # PREPROCESSING

   manage interaction detection factor during the first timestep and then 
set default interaction range
  O.step();
  ### initializes the interaction detection factor
  SSgeom.interactionDetectionFactor=-1.
  Saabb.aabbEnlargeFactor=-1.

  # SIMULATION REALLY STARTS HERE
  strainer.dead=0
  O.run(5)


  ### python script ###

  
  # -*- coding: utf-8 -*-
  from pylab import *

  ### processing function
  def store(var,textFile):
  data=loadtxt(textFile,skiprows=1)
  it=[]
  e=[]
  s=[]
  tc=[]
  sc=[]
  uf=[]
  for i in range(0,len(data)):
it.append(float(data[i,1]))
e.append(-float(data[i,0]))
s.append(-float(data[i,4]))
tc.append(float(data[i,5]))
sc.append(float(data[i,2]))
uf.append(float(data[i,7]))
  

[Yade-dev] [Bug 1790167] Re: JCFPM: "neverErase" modifies the simulated behavior while it should not

[Robert Caulk]

> I noticed that running the exact same simulation (with same initial
packing) gives different behaviors

I ran your script multiple times but I am having trouble identifying the
different stress-strain behaviors you mention. What exactly is
different? Is it the post failure part of the curve (I guess it has to
be if neverErase is responsible)? Are my post-failure curves more
consistent than yours [see attached plots]?

> The curves obtained with neverErase=True are always identical

This is not the case when I run your script (or am I missing something?)
[see attached figures].


** Attachment added: "figs.tar.gz"
   
https://bugs.launchpad.net/yade/+bug/1790167/+attachment/5183420/+files/figs.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/1790167

Title:
  JCFPM: "neverErase" modifies the simulated behavior while it should
  not

Status in Yade:
  New

Bug description:
  I noticed that running the exact same simulation (with same initial
  packing) gives different behaviors (stress-strain response in, e.g., a
  compression test) when neverErase is True or False. Given the purpose
  of neverErase (keep record of broken contacts, primarily for DFNFlow),
  it should not. The difference can be more or less important depending
  on the situation but it always exists. I could not figure out the
  cause of this yet but it seems that it comes from the treatment of
  broken contacts (obviously).

  Here is a simulation (uniaxial compression) that illustrates the
  problem. Running the same script using the exact same sample (to make
  sure the error does not come from a difference in the packings used)
  with either neverErase=True or neverErase=False produces 2 stress-
  strain curves which deviate at some point during the simulation. I
  made sure that the error is only due to neverErase by running the same
  simulations several times. The curves obtained with neverErase=True
  are always identical, as the curves obtained with neverErase=False.
  For those who would be interested, I also attach a packing  and the
  python script to plot the curves (below the simulation script).

  
  ### yade script ###

  
  from yade import ymport, pack, plot 

   material definition
  def sphereMat(): return 
JCFpmMat(type=1,density=3000,young=1e9,poisson=0.2,tensileStrength=1e6,cohesion=10e6,frictionAngle=radians(30))

  # create the specimen
  #L=0.10
  #D=0.05
  #pred=pack.inCylinder((0,0,0),(0,0,L),D/2.)
  
#O.bodies.append(pack.regularHexa(pred,radius=D/20.,gap=0.,material=sphereMat)) 
  
#O.bodies.append(pack.randomDensePack(pred,radius=D/20.,rRelFuzz=0.4,spheresInCell=1000,memoizeDb='/tmp/gts-triax-packings.sqlite',returnSpherePack=False,color=(0.9,0.8,0.6),material=sphereMat))

   import the specimen
  
O.bodies.append(ymport.text('121_3k.spheres',scale=1.,shift=Vector3(0,0,0),material=sphereMat))

   help define boundary conditions (see utils.uniaxialTestFeatures)
  bb=utils.uniaxialTestFeatures()
  
negIds,posIds,longerAxis,crossSectionArea=bb['negIds'],bb['posIds'],bb['axis'],bb['area']

  # DEM loop + ENGINES DEFINED HERE

  O.engines=[
   ForceResetter(),
  
InsertionSortCollider([Bo1_Sphere_Aabb(aabbEnlargeFactor=1.2,label='Saabb')]),
   InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(interactionDetectionFactor=1.2,label='SSgeom')],

[Ip2_JCFpmMat_JCFpmMat_JCFpmPhys(cohesiveTresholdIteration=1,label='interactionPhys')],

[Law2_ScGeom_JCFpmPhys_JointedCohesiveFrictionalPM(neverErase=False,label='interactionLaw')]
   ),
   
UniaxialStrainer(strainRate=-0.01,axis=longerAxis,asymmetry=0,posIds=posIds,negIds=negIds,crossSectionArea=crossSectionArea,blockDisplacements=1,blockRotations=1,setSpeeds=0,stopStrain=0.1,dead=1,label='strainer'),
   
GlobalStiffnessTimeStepper(active=1,timeStepUpdateInterval=10,timestepSafetyCoefficient=0.8,defaultDt=utils.PWaveTimeStep()),
   NewtonIntegrator(damping=0.4,label='newton'),
   PyRunner(iterPeriod=int(100),initRun=True,command='recorder()',label='data'),
  ]

  # RECORDER DEFINED HERE

  def recorder():
  yade.plot.addData({'i':O.iter,
 'eps':strainer.strain,
 'sigma':strainer.avgStress,
 'tc':interactionLaw.nbTensCracks,
 'sc':interactionLaw.nbShearCracks,
 'te':interactionLaw.totalTensCracksE,
 'se':interactionLaw.totalShearCracksE,
 'unbF':utils.unbalancedForce()})
  plot.saveDataTxt('compressionTest_1')

  # PREPROCESSING

   manage interaction detection factor during the first timestep and then 
set default interaction range
  O.step();
  ### initializes the interaction detection factor
  SSgeom.interactionDetectionFactor=-1.
  Saabb.aabbEnlargeFactor=-1.

  # 

[Yade-dev] [Bug 1665973] Re: Triaxial Cohesive

[Robert Caulk]

Closing: Seti likely switched from TriaxialCompressionEngine to
TriaxialStressController. This is a bug with the deprecated TCE, so it
is filed as "Won't fix'.

** Changed in: yade
   Status: New => Won't Fix

** Changed in: yade
 Assignee: (unassigned) => Robert Caulk (rcaulk)

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

Title:
  Triaxial Cohesive

Status in Yade:
  Won't Fix

Bug description:
  Hi all,

  I have tried below script:

  https://github.com/yade/trunk/blob/master/examples/test/triax-
  cohesive.py

  When I change
  sigmaIsoCompaction=-150e3,
   sigmaLateralConfinement=-150e3,

  to

  sigmaIsoCompaction=-50e3,
   sigmaLateralConfinement=-50e3,

  I face with below error, can you please advise

  
  
  Traceback (most recent call last):
File "/usr/bin/yade", line 182, in runScript
  execfile(script,globals())
File "/home/elaheh/Documents/triaxial/Triaxcoh.py", line 80, in 
  O.reload()
  RuntimeError: Simulation file to load doesn't exist: 
  [[ ^L clears screen, ^U kills line. F12 controller, F11 3d view (use h-key 
for showing help), F10 both, F9 generator, F8 plot. ]]
  [0;34mYade [[1;34m1[0;34m]: [0mERROR 
/build/yade-KKgSmd/yade-1.20.0/core/Omega.cpp:120 run: No 
Omega::simulationLoop? Creating one (please report bug).
  

  The script is as per below:

  
  # encoding: utf-8
  # 2012 ©Bruno Chareyre <bruno.chare...@hmg.inpg.fr>
  # This variant of triax-basic.py shows the usage of cohesive contact laws and 
moments at contacts

  from yade import pack

  sp=pack.SpherePack()
  ## corners of the initial packing
  mn,mx=Vector3(0,0,0),Vector3(10,10,10)

  ## box between mn and mx, avg radius ± ½(20%), 2k spheres
  sp.makeCloud(minCorner=mn,maxCorner=mx,rRelFuzz=.2,num=1000)

  ## create material #0, which will be used as default
  
O.materials.append(CohFrictMat(young=229e6,poisson=0.4,density=2600,frictionAngle=radians(36.5),normalCohesion=1e12,shearCohesion=1e12,momentRotationLaw=True,etaRoll=0.14,label='spheres'))
  
O.materials.append(FrictMat(young=229e6,poisson=.4,frictionAngle=0,density=0,label='frictionlessWalls'))

  
  ## copy spheres from the packing into the scene
  O.bodies.append([sphere(center,rad,material='spheres') for center,rad in sp])
  ## create walls around the packing
  walls=aabbWalls(material='frictionlessWalls')
  wallIds=O.bodies.append(walls)

  triax=TriaxialCompressionEngine(
wall_bottom_id=wallIds[2],
wall_top_id=wallIds[3],
wall_left_id=wallIds[0],
wall_right_id=wallIds[1],
wall_back_id=wallIds[4],
wall_front_id=wallIds[5],
internalCompaction=False,
sigmaIsoCompaction=-50e3,
sigmaLateralConfinement=-50e3,
max_vel=10,
strainRate=0.03,
label="triax"
  )

  O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()]),
InteractionLoop(
#box-sphere interactions will be the simple normal-shear law, 
we use ScGeom for them
[Ig2_Sphere_Sphere_ScGeom6D(),Ig2_Box_Sphere_ScGeom()],
#Boxes will be frictional (FrictMat), so the sphere-box physics 
is FrictMat vs. CohFrictMat, the Ip type will be found via the inheritance tree 
(CohFrictMat is a FrictMat) and will result in FrictPhys interaction physics
#and will result in a FrictPhys

[Ip2_FrictMat_FrictMat_FrictPhys(),Ip2_CohFrictMat_CohFrictMat_CohFrictPhys(label="cohesiveIp")],
#Finally, two different contact laws for sphere-box and 
sphere-sphere

[Law2_ScGeom_FrictPhys_CundallStrack(),Law2_ScGeom6D_CohFrictPhys_CohesionMoment(
useIncrementalForm=True, #useIncrementalForm is turned 
on as we want plasticity on the contact moments
always_use_moment_law=False,  #if we want "rolling" 
friction even if the contact is not cohesive (or cohesion is broken), we will 
have to turn this true somewhere
label='cohesiveLaw')]
),

GlobalStiffnessTimeStepper(active=1,timeStepUpdateInterval=100,timestepSafetyCoefficient=0.5),
triax,

TriaxialStateRecorder(iterPeriod=100,file='100e3,young=229e6,poisson=0.4,density=2600,frictionAngle=radians(36.5),normalCohesion=1e6,shearCohesion=1e6,etaRoll=0.14,'),
NewtonIntegrator(damping=.4)
  ]

  
  from yade import plot
  
O.engines=O.engines[0:5]+[PyRunner(iterPeriod=20,command='history()',label='recorder')]+O.engines[5:7]
  def history():
plot.addData(e11=-O.engines[4].strain[0], e22=-O.engines[4].strain[1], 
e33=-O.engines[4].strain[2],
s11=-O.engines[4].stress(0)[0],
s22=-O.engines[4].stress(2)[1],
s33=-O.engines[4].stress(4)[2],
i

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

[Robert Caulk]

Hey Klaus,

Thanks for taking time to look at this, I’m sorry I missed your first email
about this.

Actually we have not updated DFNflow for CGAL 4.11 yet. The commit is fine,
the key change that is fixing compilation is:

#define DFNFlow

Being commented out.

I will push the change commenting out #define DFNFlow. Cleary it is not
ready to be compiled by default until we make the necessary cgal 4.11
changes.

Cheers,

Robert


Le dim. 20 mai 2018 à 23:18, Klaus Thoeni  a écrit :

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

[Yade-dev] [Bug 1759633] Re: The Code is crashed when there are two balls with same position and radius

[Robert Caulk]

Hello,

Will you please provide a minimal working example to demonstrate this
bug [1]?

Cheers,

Robert

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

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

Title:
  The Code is crashed when there are two balls with same position and
  radius

Status in Yade:
  New

Bug description:
  I just find that if there are two balls with the same position and
  radius and the program is crashed without any information.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1759633/+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 #665387]: Compile error JointedCohesiveFrictionalPM

[Robert Caulk]

Hello William,

There seems to be a deeper issue and the #include  is no more than
a bandaid that helps us narrow down the possible causes. I have a feeling
this might track back to CMakeLists.txt. Do you mind providing the output
of your:

cmake -DCMAKE_INSTALL_PREFIX=../install ../trunk

command?

Cheers,

Robert

On Tue, Mar 13, 2018 at 2:06 AM, William Chèvremont <
william.chevrem...@univ-grenoble-alpes.fr> wrote:

> Thanks Robert, that solved my issue.
>
> Le 12/03/2018 à 18:27, Robert Caulk a écrit :
>
> Hey Will,
>
> Looks like Thomas Chauve is encountering the same issue. I am unable to
> recreate this problem so will one of you please try adding:
>
> #include 
>
> to JointedCohesiveFrictionalpm.hpp and then recompiling?
>
> Thanks!
>
> Robert
>
>
> On Fri, Mar 9, 2018 at 10:51 AM, William Chèvremont <
> william.chevrem...@univ-grenoble-alpes.fr> wrote:
>
>> In fact, for the git rebase, I updade py computer and forget to run this
>> command again. Now fixed.
>>
>> For the compile error, my linux and compiler are following:
>>
>> >$ gcc --version
>> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
>>
>> >$ lsb_release -a
>> LSB Version:core-9.20160110ubuntu5-amd64:c
>> ore-9.20160110ubuntu5-noarch:security-9.20160110ubuntu5-amd6
>> 4:security-9.20160110ubuntu5-noarch
>> Distributor ID: Ubuntu
>> Description:Ubuntu 17.10
>> Release:17.10
>> Codename:   artful
>>
>> I also get the same error on the cluster with this compiler: gcc (Debian
>> 5.4.1-3) 5.4.1 20161019
>>
>> William.
>>
>> Le 09/03/2018 à 18:42, Bruno Chareyre a écrit :
>>
>> This being said I don't think the merge can be the cause of William's
>> compile error.
>> The question is why gcc can't find std::random_device.
>> Just weird.
>> B
>>
>>
>> On 03/09/2018 06:35 PM, Bruno Chareyre wrote:
>>
>> Let us continue the discussion here on yade-dev, William is member.
>> Merge commits are painful, as you suggest Robert it applies the upstream
>> changes on the local trunk then it commits the merged code.
>> In the log it looks like reapplying the same changes, the problem is if
>> it's not reapplying exactly the same thing it can go unnoticed.
>> This is known as "merge bubble" on the git forums.
>>
>> It can be avoided manually or, more simply, by changing the default
>> behavior of git once for all (on a given machine):
>> git config branch.autosetuprebase always
>>
>> Please always consider the above command before any commit to yade trunk.
>>
>> Cheers
>>
>> Bruno
>>
>>
>>
>> On 03/09/2018 06:08 PM, Robert Caulk wrote:
>>
>> Question #665387 on Yade 
>> changed:https://answers.launchpad.net/yade/+question/665387
>>
>> Status: Open => Answered
>>
>> Robert Caulk proposed the following answer:
>> Hello William,
>>
>> Which linux distribution are you running? Which compiler are you using
>> (gcc --version)?
>>
>> As Bruno mentions on yade-dev, your most recent build passes the
>> buildbot [1] - so it may be a local problem. (I think Bruno's message
>> [2] was not posted here as intended. He suggests you join yade-dev list
>> serv [3] and send compiler questions there).
>>
>> Although it seems unlikely - is it possible this has something to do
>> with this unusual merge of master with itself [4]? Is that a merge into
>> your local repository? Perhaps you are you working off a read-only
>> clone? Do you have duplicated commits on your local machine? I can't
>> quite figure out what is going on there, the "merge" seems to simply add
>> commits that are already committed to the repository.
>>
>> Cheers,
>>
>> Robert
>>
>> [1]https://yade-dem.org/buildbot/builders/yade-full/builds/4507
>> [2]https://lists.launchpad.net/yade-dev/msg13755.html
>> [3]https://launchpad.net/~yade-dev
>> [4]https://github.com/yade/trunk/commit/921bb17079fea51385fe620526f9bc48c055918e
>>
>>
>>
>>
>> ___
>> Mailing list: https://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
>>

Re: [Yade-dev] [Yade-users] [Question #665387]: Compile error JointedCohesiveFrictionalPM

[Robert Caulk]

Hey Will,

Looks like Thomas Chauve is encountering the same issue. I am unable to
recreate this problem so will one of you please try adding:

#include 

to JointedCohesiveFrictionalpm.hpp and then recompiling?

Thanks!

Robert


On Fri, Mar 9, 2018 at 10:51 AM, William Chèvremont <
william.chevrem...@univ-grenoble-alpes.fr> wrote:

> In fact, for the git rebase, I updade py computer and forget to run this
> command again. Now fixed.
>
> For the compile error, my linux and compiler are following:
>
> >$ gcc --version
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
>
> >$ lsb_release -a
> LSB Version:core-9.20160110ubuntu5-amd64:
> core-9.20160110ubuntu5-noarch:security-9.20160110ubuntu5-amd64:security-9.
> 20160110ubuntu5-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 17.10
> Release:17.10
> Codename:   artful
>
> I also get the same error on the cluster with this compiler: gcc (Debian
> 5.4.1-3) 5.4.1 20161019
>
> William.
>
> Le 09/03/2018 à 18:42, Bruno Chareyre a écrit :
>
> This being said I don't think the merge can be the cause of William's
> compile error.
> The question is why gcc can't find std::random_device.
> Just weird.
> B
>
>
> On 03/09/2018 06:35 PM, Bruno Chareyre wrote:
>
> Let us continue the discussion here on yade-dev, William is member.
> Merge commits are painful, as you suggest Robert it applies the upstream
> changes on the local trunk then it commits the merged code.
> In the log it looks like reapplying the same changes, the problem is if
> it's not reapplying exactly the same thing it can go unnoticed.
> This is known as "merge bubble" on the git forums.
>
> It can be avoided manually or, more simply, by changing the default
> behavior of git once for all (on a given machine):
> git config branch.autosetuprebase always
>
> Please always consider the above command before any commit to yade trunk.
>
> Cheers
>
> Bruno
>
>
>
> On 03/09/2018 06:08 PM, Robert Caulk wrote:
>
> Question #665387 on Yade 
> changed:https://answers.launchpad.net/yade/+question/665387
>
> Status: Open => Answered
>
> Robert Caulk proposed the following answer:
> Hello William,
>
> Which linux distribution are you running? Which compiler are you using
> (gcc --version)?
>
> As Bruno mentions on yade-dev, your most recent build passes the
> buildbot [1] - so it may be a local problem. (I think Bruno's message
> [2] was not posted here as intended. He suggests you join yade-dev list
> serv [3] and send compiler questions there).
>
> Although it seems unlikely - is it possible this has something to do
> with this unusual merge of master with itself [4]? Is that a merge into
> your local repository? Perhaps you are you working off a read-only
> clone? Do you have duplicated commits on your local machine? I can't
> quite figure out what is going on there, the "merge" seems to simply add
> commits that are already committed to the repository.
>
> Cheers,
>
> Robert
>
> [1]https://yade-dem.org/buildbot/builders/yade-full/builds/4507
> [2]https://lists.launchpad.net/yade-dev/msg13755.html
> [3]https://launchpad.net/~yade-dev
> [4]https://github.com/yade/trunk/commit/921bb17079fea51385fe620526f9bc48c055918e
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] Adding a pdf to the website

[Robert Caulk]

Hello devs,

I noticed the Yade website is hosting some thesis pdf files [1][2], I
assume these are added by ftp. Who has the ftp credentials for adding
additional files? Is there a way to allow other developers ftp access to
the website files?

[1]https://yade-dem.org/w/images/2/27/VanTranTiengThesis.pdf
[2]https://yade-dem.org/publi/PhD_MAURIN_VF.pdf

Best,

Robert
___
Mailing list: https://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] cholmod / GPU integration

[Robert Caulk]

Thank you, Bruno

I had no way of testing this without installing 14.04 specifically for that
problem, so I appreciate you helping me solve it.

*So an obvious solution was to add a #if (CHOLMOD_GPU == 1) before the
useGPU line [1]. *
* It seems to fix the compile problem. Does it seem ok for you?*

Yes, that is OK. I will tweak it a bit to make it more versatile.

*Just to be sure: useSolver=3 will use cholmod through eigen and
useSolver=4 will use cholmod directly. It is correct?*
* Did you compare useSolver=3 and useSolver=4 without gpu? They should be
nearly the same.*

Yes that is correct. I compared flow.useSolver=3  to flow.useSolver=4 using
oedometer.py  (on gpu and cpu). Results are the same. Did you encounter
different results for your comparison?

Best,

Robert

On Fri, Feb 23, 2018 at 7:56 AM Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> wrote:

> Hi Robert,
> Still a small thing to fix following [1] it seems, although it may only
> impact old systems.
> On ubuntu 14.04 with libsuitesparse-dev 1:4.2.1-3ubuntu1 it gives:
> *FlowBoundingSphereLinSolv.ipp:100:6: error: ‘cholmod_common’ has no
> member named ‘useGPU’*
> *  com.useGPU=1; //useGPU;*
>
> On the other hand cmake is returning:
> -- Disabled features: CHOLMOD_GPU
>
> So an obvious solution was to add a #if (CHOLMOD_GPU == 1) before the
> useGPU line [1].
> It seems to fix the compile problem. Does it seem ok for you?
>
> Just to be sure: useSolver=3 will use cholmod through eigen and
> useSolver=4 will use cholmod directly. It is correct?
> Did you compare useSolver=3 and useSolver=4 without gpu? They should be
> nearly the same.
>
> Cheers
>
> Bruno
>
>
> [1] https://github.com/yade/trunk/commit/60342f55f196bce752897b8
> 7ab539a1c2fbf309e
>
> ___
> Mailing list: https://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] Ip2_FrictMat_FrictMat_FrictPhys doc

[Robert Caulk]

Hello Jérôme,

I support clarifying the meaning of particle young in the class reference
as you suggest. There is no doubt that newcomers to DEM and Yade confuse
micro young's modulus with macro young's modulus all the time.

I would vote for clarifying the general doc instead of full removal of
stiffness and normal stiffness section in general doc, I think they provide
good examples of how Yade treats micro stiffness. If we decide to keep the
sections I can look into improving their clarity. But if others think
removal is best, I am not against it :-)

Best,

Robert

On Wed, Feb 21, 2018 at 8:59 AM, Jerome Duriez 
wrote:

> Hi,
>
> After seeing Yet Another Doubts on "young" meaning / 
> Ip2_FrictMat_FrictMat_FrictPhys
> contact model (a PhD student in my institute), I'm proposing to explicitly
> mention the underlying equations in the doc, once for all.
> The corresponding would-be diff appears at the end of the email, you may
> also compare the attached screenshot with https://yade-dem.org/doc/yade.
> wrapper.html#yade.wrapper.Ip2_FrictMat_FrictMat_FrictPhys.
> From the diff, you will see I'm also proposing to remove the "harmonic
> average stiffness" comment, for instance because there actually is a "2"
> factor missing/extra between the comment and the actual code.
>
>
> In the case of the above-mentioned PhD student, confusion also arose
> because of https://yade-dem.org/doc/formulation.html#stiffnesses and
> https://yade-dem.org/doc/formulation.html#normal-stiffness.
> As such, I would also propose to simply remove these two sections from the
> doc.
> From my point of view, they actually are too Ip2-specific to appear in the
> general doc.
>
>
> If necessary, a reference to the (equivalent) 2.2.1 and 2.2.1.1. sections
> from Vaclav's thesis ([Smilauer2010b] reference) could be introduced e.g.
> in Ip2_CpmMat_CpmMat_CpmPhys and Ip2_FrictMat_FrictMat_FrictPhys
> docstrings, to keep track of these comments that could be made concerning
> the Ip2 equations.
>
>
> This email probably is Yet Another non-critical one, but since it deals
> about (the doc of) central pieces of code, and lines probably written by
> Vaclav, I'm opening a possible discussion here before performing the
> changes.
>
>
> Jérôme
>
> PS: next step would be to move https://yade-dem.org/doc/
> formulation.html#strain-evaluation to Ig2 docstrings but I'm not planning
> on it...
>
>
> ** Diff herein proposed for commit **
>
> diff --git a/pkg/dem/FrictPhys.cpp b/pkg/dem/FrictPhys.cpp
> index cb904da..4f8ffe8 100644
> --- a/pkg/dem/FrictPhys.cpp
> +++ b/pkg/dem/FrictPhys.cpp
> @@ -26,9 +26,7 @@ void Ip2_FrictMat_FrictMat_FrictPhys::go( const
> shared_ptr& b1
> Real Va = mat1->poisson;
> Real Vb = mat2->poisson;
>
> -   //harmonic average of the two stiffnesses when (2*Ri*Ei) is the
> stiffness of a contact point on sphere "i"
> Real Kn = 2*Ea*Ra*Eb*Rb/(Ea*Ra+Eb*Rb);
> -   //same for shear stiffness
> Real Ks = 2*Ea*Ra*Va*Eb*Rb*Vb/(Ea*Ra*Va+Eb*Rb*Vb);
>
> Real frictionAngle = (!frictAngle) ? 
> std::min(mat1->frictionAngle,mat2->frictionAngle)
> : (*frictAngle)(mat1->id,mat2->id,mat1->frictionAngle,mat2->
> frictionAngle);
>
> diff --git a/pkg/dem/FrictPhys.hpp b/pkg/dem/FrictPhys.hpp
> index eeb2ef4..12c85ee 100644
> --- a/pkg/dem/FrictPhys.hpp
> +++ b/pkg/dem/FrictPhys.hpp
> @@ -44,7 +44,7 @@ class Ip2_FrictMat_FrictMat_FrictPhys: public
> IPhysFunctor{
> const shared_ptr& b2,
> const shared_ptr& interaction);
> FUNCTOR2D(FrictMat,FrictMat);
> -   
> YADE_CLASS_BASE_DOC_ATTRS(Ip2_FrictMat_FrictMat_FrictPhys,IPhysFunctor,"Create
> a :yref:`FrictPhys` from two :yref:`FrictMats`. The compliance of
> one sphere under point load is defined here as $1/(E.D)$, with $E$ the
> stiffness of the sphere and $D$ its diameter. The compliance of the contact
> itself will be the sum of compliances from each sphere, i.e.
> $1/(E_1.D_1)+1/(E_2.D_2)$ in the general case, or $2/(E.D)$ in the special
> case of equal sizes and equal stiffness. Note that summing compliances
> corresponds to an harmonic average of stiffnesss (as in e.g.
> [Scholtes2009a]_), which is how kn is actually computed in the
> :yref:`Ip2_FrictMat_FrictMat_FrictPhys` functor:\n\n $k_n =
> \\frac{E_1D_1*E_2D_2}{E_1D_1+E_2D_2}=\\frac{k_1*k_2}{k_1+k_2}$, with
> $k_i=E_iD_i$.\n\n The shear stiffness ks of one sphere is defined via the
> material parameter :yref:`ElastMat::poisson`, as ks=poisson*kn, and the
> resulting shear stiffness of the interaction will be also an harmonic
> average. In the case of a contact between a :yref:`ViscElMat` and a
> :yref:`FrictMat`, be sure to set :yref:`FrictMat::young` and
> :yref:`FrictMat::poisson`, otherwise the default value will be used.",
> +   
> YADE_CLASS_BASE_DOC_ATTRS(Ip2_FrictMat_FrictMat_FrictPhys,IPhysFunctor,"Create
> a :yref:`FrictPhys` from two 

Re: [Yade-dev] Odp: Re: Yade for LTS Ubuntu 18.04

[Robert Caulk]

Ok, I pushed the fix for the DEM-PFV-check.py failure. I discovered the
issue was compiler related. GCC 5.4 on ubuntu 16.04 initialized
factorizeOnly to false by default, while GCC 7.2 on ubuntu 18.04 did not do
this. Therefore, the only necessary change ended up being the explicit
initialization of factorizeOnly=false.

My experience compiling, installing, and checking Yade master on Ubuntu
18.04:

   - The library installation requires libqglviewer-dev-*qt5 *instead of
   libqglviewer-dev. Otherwise, the libraries install with the same commands
   as on ubuntu 16.04.
   - Clean build is the same as ubuntu 16.04:
   cmake -DCMAKE_INSTALL_PREFIX=../install ../trunk
   - Clean make/install is the same as 16.04: make -jX install
   - Checks (make check) all pass up until checkPolyhedraCrush.py, where it
   hangs. I see others noticed this issue as well.

In addition to the bug fix, I edited the solvers so flow.useSolvers=3 and 4
can now be used with the default CPU build. I can confirm that
flow.useSolver=4 enables multicore CPU factorization, while
flow.useSolver=3 sticks to 1 core factorization :-).

Cheers,

Robert

On Tue, Feb 13, 2018 at 5:20 AM, Bruno Chareyre <
bruno.chare...@grenoble-inp.fr> wrote:

>
>
> On 02/13/2018 10:12 AM, Robert Caulk wrote:
>
>> I’m running into deeper problems than I expected on this solver bug fix.
>> I need some more time to trouble shoot.
>>
> Let me know, I can also try some things. I have been able at least to
> compile and run cholmod on 18.04 with simple c++ programs.
> I wanted to just replicate a hello-cholmod function inside yade to see if
> the problems come from some specific compilation/link options used for yade
> compilation.
>
> What’s our deadline? I read something about a freeze till March 1st?
>>
> Yes beggining of March IIRC.
>
>
>> Regarding standard gpus for yade: No, suitesparse depends on double
>> precision compute power and standard graphics cards are generally weaker
>> than a multi core cpu for double precision compute.
>>
> I was expecting that, thanks.
>
> That said, I noticed during my testing today that using cholmod directly
>> for cpu solving does seem to re enable multi core factorization (something
>> we used to have before our third party libs stopped playing nicely, right?).
>>
> Indeed, it used to work.
>
>
> Bruno
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Odp: Re: Yade for LTS Ubuntu 18.04

[Robert Caulk]

I’m running into deeper problems than I expected on this solver bug fix. I
need some more time to trouble shoot.

What’s our deadline? I read something about a freeze till March 1st?

Regarding standard gpus for yade: No, suitesparse depends on double
precision compute power and standard graphics cards are generally weaker
than a multi core cpu for double precision compute. That said, I noticed
during my testing today that using cholmod directly for cpu solving does
seem to re enable multi core factorization (something we used to have
before our third party libs stopped playing nicely, right?). So we should
get a bump in cpu performance...after I get this bug worked out.

On Mon, Feb 12, 2018 at 10:51 AM Bruno Chareyre <
bruno.chare...@grenoble-inp.fr> wrote:

> Awesome.
> Years ago we were using cholmod without the eigen interface, it will be a
> revert...
> These cholmod/openblas issues make me nervous (not mentionning other
> attempts with Pardiso and Taucs, which all worked at some point). It still
> did not stabilize after 6+ years.
>
> Do you think the GPU solver has benefits even with a standard graphical
> card, by the way?
> Cheers
>
> Bruno
>
>
>
> On 02/12/2018 06:52 PM, Robert Caulk wrote:
>
> Yes! We should be able to replace the Eigen cholmod interface entirely
> with the existing direct cholmod solver (useSolver=4). Right now the
> #ifdefs are configured for the special GPU build but I will generalize it
> today and commit it so that it can be used without GPU compilation flags.
> Cholmod is smart enough to revert to CPU on its own if GPU is not available.
>
> I will install 18.04, test the solver, and report back with my findings
> today.
>
> Best,
>
> Robert
>
> On Mon, Feb 12, 2018 at 1:22 AM Bruno Chareyre <
> bruno.chare...@grenoble-inp.fr> wrote:
>
>> Thank you very much for help Janek.
>> I confirm that I could compile trunk on ubuntu18 with CGAL, without
>> special steps (not even dpkg, just cmake+make without options).
>> For DEM-PFV-check.py the problem is with the cholmod solver. I'll try and
>> fix that.
>>
>> @Robert, you mentioned that by-passing the eigen interface to use cholmod
>> directly solved issues on your side IIRC.
>> Could you give more hints about that, do you have some candidate code for
>> commit?
>>
>> Cheers
>>
>>
>> Bruno
>>
>>
>> On 02/11/2018 12:33 PM, janek_li...@wp.pl wrote:
>>
>> OK, so I did the initial commit for cgal 4.11, the most importatnt stuff
>> is in the commit message. I will repeat it here in short:
>>
>> 1.  maybe the #ifdefs that I added in
>> lib/triangulation/RegularTriangulation.h are not necessary?
>>
>> 2. the ALPHASHAPES changes inlib/triangulation/Tesselation.h are not
>> related to cgal, but I couldn't compile without this.
>>
>> 3. In checkPolyhedraCrush.py this python line freezes:
>>  O.run(250, True); checkForcesBodies(25.44893, 4)
>>
>> Moreover:
>> 4. with this patch yade is compiling successfully with cgal 4.9 and 4.11.
>>
>> 5. regardless of cgal version (with 4.9 and 4.11) I have this error
>> in DEM-PFV-check.py:
>>
>>   running:  DEM-PFV-check.py
>>   DEM-PFV: unbalanced Qin vs. Qout ( -0.00279199571618  vs.  0.0 )
>>   DEM-PFV: difference in permeability: 27.9199571618  vs. target
>> 0.040399916554
>>   The difference is more, than the critical tolerance!
>>   DEM-PFV: difference in final pressure: 0.0  vs. target  628.314160434
>>   The difference is more, than the critical tolerance!
>>   DEM-PFV: difference in final deformation -0.00430506304298  vs. target
>> -0.00258113045083
>>   The difference is more, than the critical tolerance!
>>   Status: FAILURE!!!
>>
>> Since it does not depend on cgal version, it must be some other library
>> that I have on my workstation. I have here installed devuan ascii, and I
>> only backported cgal 4.11 from devuan ceres. All other libraries are at
>> their default devuan ascii version.
>>
>> 6. Also  yade version is clean, right from github :) Just to make it all
>> clear. However I could not compile yade just by doing the usual
>>
>>   cd .. ; mkdir build ; cd build
>>   cmake -DCMAKE_INSTALL_PREFIX=../install ../trunk -DDEBUG=1 -DCHUNKSIZE=5
>>   time nice -n 20 make install -j 20 ; xmessage "\nFinished\n"
>>
>> I had some boost errors related to the C++11 declytype support, eg. as
>> discussed in:
>> http://www.boost.org/doc/libs/1_66_0/libs/utility/utility.htm
>> At first I was worried that g++ 6.3 is too old. However I found out that
>> I can compile yade 2018-02 

Re: [Yade-dev] Odp: Re: Yade for LTS Ubuntu 18.04

[Robert Caulk]

Yes! We should be able to replace the Eigen cholmod interface entirely with
the existing direct cholmod solver (useSolver=4). Right now the #ifdefs are
configured for the special GPU build but I will generalize it today and
commit it so that it can be used without GPU compilation flags. Cholmod is
smart enough to revert to CPU on its own if GPU is not available.

I will install 18.04, test the solver, and report back with my findings
today.

Best,

Robert

On Mon, Feb 12, 2018 at 1:22 AM Bruno Chareyre <
bruno.chare...@grenoble-inp.fr> wrote:

> Thank you very much for help Janek.
> I confirm that I could compile trunk on ubuntu18 with CGAL, without
> special steps (not even dpkg, just cmake+make without options).
> For DEM-PFV-check.py the problem is with the cholmod solver. I'll try and
> fix that.
>
> @Robert, you mentioned that by-passing the eigen interface to use cholmod
> directly solved issues on your side IIRC.
> Could you give more hints about that, do you have some candidate code for
> commit?
>
> Cheers
>
>
> Bruno
>
>
> On 02/11/2018 12:33 PM, janek_li...@wp.pl wrote:
>
> OK, so I did the initial commit for cgal 4.11, the most importatnt stuff
> is in the commit message. I will repeat it here in short:
>
> 1.  maybe the #ifdefs that I added in
> lib/triangulation/RegularTriangulation.h are not necessary?
>
> 2. the ALPHASHAPES changes inlib/triangulation/Tesselation.h are not
> related to cgal, but I couldn't compile without this.
>
> 3. In checkPolyhedraCrush.py this python line freezes:
>  O.run(250, True); checkForcesBodies(25.44893, 4)
>
> Moreover:
> 4. with this patch yade is compiling successfully with cgal 4.9 and 4.11.
>
> 5. regardless of cgal version (with 4.9 and 4.11) I have this error
> in DEM-PFV-check.py:
>
>   running:  DEM-PFV-check.py
>   DEM-PFV: unbalanced Qin vs. Qout ( -0.00279199571618  vs.  0.0 )
>   DEM-PFV: difference in permeability: 27.9199571618  vs. target
> 0.040399916554
>   The difference is more, than the critical tolerance!
>   DEM-PFV: difference in final pressure: 0.0  vs. target  628.314160434
>   The difference is more, than the critical tolerance!
>   DEM-PFV: difference in final deformation -0.00430506304298  vs. target
> -0.00258113045083
>   The difference is more, than the critical tolerance!
>   Status: FAILURE!!!
>
> Since it does not depend on cgal version, it must be some other library
> that I have on my workstation. I have here installed devuan ascii, and I
> only backported cgal 4.11 from devuan ceres. All other libraries are at
> their default devuan ascii version.
>
> 6. Also  yade version is clean, right from github :) Just to make it all
> clear. However I could not compile yade just by doing the usual
>
>   cd .. ; mkdir build ; cd build
>   cmake -DCMAKE_INSTALL_PREFIX=../install ../trunk -DDEBUG=1 -DCHUNKSIZE=5
>   time nice -n 20 make install -j 20 ; xmessage "\nFinished\n"
>
> I had some boost errors related to the C++11 declytype support, eg. as
> discussed in:
> http://www.boost.org/doc/libs/1_66_0/libs/utility/utility.htm
> At first I was worried that g++ 6.3 is too old. However I found out that I
> can compile yade 2018-02 if I copy the ./debian/ directory from yade
> 2017-01 and do:
>
>time dpkg-buildpackage -rfakeroot -b -j30
>
> So it must not be related to compiler version, but rather to compiler
> flags. And Anton fixed this in debian/ build rules, while my command could
> not make it correctly. I didn't figure this out yet. Last night I was
> simply building yade 2018-02 with debian/ from yade 2017-01 :)
>
> best regards
> Janek
>
>
> Dnia 9 lutego 2018 18:46 Anton Gladky  napisał(a):
>
> Yes, it should be OK.
>
> Anton
>
>
> 2018-02-09 16:06 GMT+01:00 Bruno Chareyre  >:
>
> What is an appropriate system to try this? ubuntu 18.04 beta is ok?
> B
>
>
> On 02/08/2018 07:35 PM, Janek Kozicki (yade-dev) wrote:
>
>
> Hi Anton and Bruno,
>
> I am glad that I can help, and use this opportunity to get back in track
> ;) So I will do this entire Saturday after I get back home on friday night.
>
> Should I work on latest yade trunk?
>
> BTW: I'm writing this from an airport ;)
>
> Best regards,
> Janek
>
> On 8 Feb 2018, 19:10 +0100, Anton Gladky , wrote:
>
>
> Hi Bruno,
>
> CGAL_ 4.11 is the only version now for Debian (testing) [1]
> and upcoming Ubuntu 18.04 [2]. The shipped Yade does
> not support CGAL due to compilation problems.
>
> I am preparing the new Yade upload, but we have a chance
> to patch the Yade within the next two weeks or prepare
> the 2018.02b release with CGAL-support and upload it.
>
> [1] https://tracker.debian.org/pkg/cgal
> [2] https://launchpad.net/ubuntu/+source/cgal
>
> Anton
>
>
> 2018-02-08 18:45 GMT+01:00 Bruno Chareyre
> :
>
>
> Hi Anton,
> Thank you very much.
> I'm not so sure what we are speaking about here.
> Yade 2018.02a is the candidate source code for producing a binary
> 

[Yade-dev] Yade related publication?

[Robert Caulk]

Hey Yade Devs,

I am wondering if we have the demand to create a Yade related white paper
publication. The publication would document very Yade specific
functionalities and I imagine some papers might even highlight pieces code.
I think the format would be very flexible, some releases might be 3 pages
with brief summary and figures, while others might be formatted similarly
to a conference paper. In all cases, I think we could maintain a quality
archive by incorporating CrossRef, reviewing the writing/work, and laying
out the documents consistently.

Is it possible for us to set up a conduit for Yade users/devs to release
Yade specific research to the public domain? If so, I'd like to
spearhead the project. If there is some reason why we specifically should
not and cannot do this, please let me know. Otherwise, please take a moment
to read the following questions. If you answer "yes" to either of
these questions, do you mind replying and letting me know? This is my
attempt to gauge interest. If we have none, I will scrap the idea entirely.

   - Do you have any Yade related work that does not fit into a scientific
   journal, but has great value to existing/future Yade users? For example:
   maybe you have some lab notes with figures that exhibit some Yade
   functionality and you'd like to be able to reference this in another
   paper/appendix/supporting material.
   - Do you have a conference/journal paper related to Yade that never
   ended up being published, but you'd like to reference the work?

Best regards,

Robert
___
Mailing list: https://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 1734653] Re: DFN+fluid compressibility not using the correct reference volume

[Robert Caulk]

Ok, I finally got some time to digest this. Thank you for pointing this
out, Bruno, it may have pretty severe impacts on DFNFlow simulations.

In my opinion, we would just *add* the crack volume to the original pore
volume. Let me see if I can explain why I think this:

It seems we need to agree on how the crackArea and crackAperture are
computed for these volume calcs. Each cell is currently associated with a
unique crackArea [1], but I am unsure what the geometry of the current C++
lines represent [2]. I am particularly confused by [3]. I guess I need
someone to translate that for me.

If I were to imagine a plane that represents the crackArea, I would
probably change the existing code to look something like this:

if (calcCrackArea) {
CVector edgeMidPoint = (
ed_it->first->vertex(ed_it->second)->point().point()
+ed_it->first->vertex(ed_it->third)->point.point() ) / 2;
CVector v1 = edgeMidPoint - CellCentre1;
CVector v2 = edgeMidPoint - CellCentre2;
Real halfCrackArea = 0.25*sqrt(std::abs(cross_product(v1,
v2).squared_length()));
cell1->info().crackVol += halfCrackArea*aperture
cell2->info().crackVol += halfCrackArea*aperture;
}


Which would give us a  crack plane that looks like this following poorly
drawn figure:

[image: Inline image 1]

In this scheme, the volume of the crack (crackVol in code above) within a
cell is simply the sum of all halfCrackArea_i*aperture_i where i indexes
the broken edge. Then we can add this volume to the original pore volume.
It's as if we are artificially creating volume space that is not reflected
by the packing geometry. Which is kind of what this all boils down to,
right? Or maybe I am totally lost. If you guys think this is worth testing,
I will implement, test, and report back.

Cheers,

Robert


[1] https://github.com/yade/trunk/blob/master/pkg/pfv/DFNFlow.cpp#L269
[2] https://github.com/yade/trunk/blob/master/pkg/pfv/DFNFlow.cpp#L263
[3] https://github.com/yade/trunk/blob/master/pkg/pfv/DFNFlow.cpp#L266

On Wed, Dec 6, 2017 at 2:52 AM, Bruno Chareyre <1734...@bugs.launchpad.net>
wrote:

> > we should use directly crackAperture*crackArea as Vo in dV/Vo, no?
>
> That's more or less what I wanted to suggest. I can't explain why I wrote
> that strange formula.
> However I also wanted to skip the calculation of crackAperture*crackArea,
> namely because there can be multiple cracks, as you point out.
> So my idea was to store the initial value of the numerical porosity in one
> cell (call it V(t=0)) and to define the cracked volume as the difference
> V(t)-V(t=0). It makes multiple cracks less a problem I think.
>
> However, an obvious problem of this is that it result in a reference
> equal to zero when the crack occurs, and we need to divide by this
> volume... that was the reason to introduce an initial amount of liquid
> via matrixPorosity (could also depend on slotInitialAperture). Just an
> idea anyway. The problem of fluid flow inside an advancing crack tip
> seems fundamentally tough... I can't imagine a perfect answer yet.
>
> Bruno
>
> --
> You received this bug notification because you are a member of Yade
> developers, which is subscribed to Yade.
> https://bugs.launchpad.net/bugs/1734653
>
> Title:
>   DFN+fluid compressibility not using the correct reference volume
>
> Status in Yade:
>   New
>
> Bug description:
>   In the basic PFV scheme the incremental change of density of a pore
>   fluid after a change of pore volume is dependent on dV/Vo where Vo is
>   the reference pore space within a tetrahedral cell [1], i.e.
>   V(tetrahedron)-V(spheres).
>
>   In DFNFlow "V" should reflect the fact that porosity may be mainly due
> to a crack an its opening.
>   Typically V=V(tetrahedron)-opening*area-matrixPorosity.
>   Currently it is using the same formula, hence overestimating the
> compressibility effect (because the DEM porosity is larger than a typical
> rock porosity). What should be the reference "opening" in above formula is
> to be clarified though, it has physical as well as numerical implications.
> Maybe slotInitialAperture is a candidate? Let you DFN people tell what it
> should be.
>
>   Note that the "dV" is less a problem because it is a difference
>   (independent on the choice of the reference volume), so the
>   incompressible scheme is not affected.
>
>   Bruno
>
>   [1]
>   https://github.com/yade/trunk/blob/master/pkg/pfv/FlowEngine.ipp.in#L439
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/yade/+bug/1734653/+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
>


** Attachment added: "IMG_8150.JPG"
   
https://bugs.launchpad.net/bugs/1734653/+attachment/5019427/+files/IMG_8150.JPG

-- 
You received this bug notification because you are a member of Yade
developers, which is 

Re: [Yade-dev] Yade with CGAL 4.11

[Robert Caulk]

Could this be the source of the strange PFV behaviors, Luc?

On Thu, Nov 2, 2017 at 1:22 PM, Anton Gladky  wrote:

> Hi all,
>
> it looks like Yade is not compatible with the new CGAL 4.11 and
> it blocks the upload of new CGAL into the Debian [1].
>
> It would be good if somebody could try to fix this issue.
>
> [1] https://bugs.debian.org/876524
>
> Thanks
>
> Anton
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Compilation issue with cholmod_common.useGPU

[Robert Caulk]

Ya, I guess that would be superior to my solution...I copied the SPH,
Deform, and Liqmigration method of adding a new definition.

On Fri, Sep 29, 2017 at 5:57 AM Bruno Chareyre <bruno.chareyre@grenoble-inp.
fr> wrote:

> #ifdef CHOLMOD_GPU should do the trick, I find it False after cmake.
>
> On 09/28/2017 05:24 PM, Robert Caulk wrote:
>
> Oh yes, I will fix this today. Thank you for pointing this out!
>
> On Thu, Sep 28, 2017 at 1:53 AM Bruno Chareyre <
> bruno.chare...@3sr-grenoble.fr> wrote:
>
>> Hi Robert,
>> It seems there is a version issue with cholmod. I'm guessing the
>> "useGPU" parameter is only in a specific version.
>> Or is it just that my version is way too old?
>> Anyway, we need to indicate the minimal version somewhere doc or
>> (better) set #ifdef guard or something to compile this line optionally.
>> What do you think?
>>
>> FlowBoundingSphereLinSolv.ipp:98:6: error: ‘cholmod_common’ has no
>> member named ‘useGPU’
>>com.useGPU=1; //useGPU;
>>
>> Bruno
>>
>> p.s. Thanks a ton for discovering and implementing this GPU thing!
>>
>>
>> --
>> ___
>> Bruno Chareyre
>> Associate Professor
>> ENSE³ - Grenoble INP
>> Lab. 3SR
>> BP 53
>> 38041 Grenoble cedex 9
>> Tél : +33 4 56 52 86 21 <+33%204%2056%2052%2086%2021>
>> Fax : +33 4 76 82 70 43 <+33%204%2076%2082%2070%2043>
>> 
>>
>> Email too brief?
>> Here's why! http://emailcharter.org
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to : yade-dev@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://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] Compilation issue with cholmod_common.useGPU

[Robert Caulk]

Oh yes, I will fix this today. Thank you for pointing this out!

On Thu, Sep 28, 2017 at 1:53 AM Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> wrote:

> Hi Robert,
> It seems there is a version issue with cholmod. I'm guessing the
> "useGPU" parameter is only in a specific version.
> Or is it just that my version is way too old?
> Anyway, we need to indicate the minimal version somewhere doc or
> (better) set #ifdef guard or something to compile this line optionally.
> What do you think?
>
> FlowBoundingSphereLinSolv.ipp:98:6: error: ‘cholmod_common’ has no
> member named ‘useGPU’
>com.useGPU=1; //useGPU;
>
> Bruno
>
> p.s. Thanks a ton for discovering and implementing this GPU thing!
>
>
> --
> ___
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> Fax : +33 4 76 82 70 43
> 
>
> Email too brief?
> Here's why! http://emailcharter.org
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] buildbot failure in Yade on yade-full

[Robert Caulk]

Does anyone know why the doc keeps failing to build over the past week or
so?

Error:

mktemp: failed to create directory via template
'/tmp/xvfb-run.XX': Too many links


On Sun, Aug 6, 2017 at 6:03 PM,  wrote:

> The Buildbot has detected a failed build on builder yade-full while
> building yade.
> Full details are available at:
>  https://yade-dem.org/buildbot/builders/yade-full/builds/4111
>
> Buildbot URL: https://yade-dem.org/buildbot/
>
> Buildslave for this Build: r0calcul9
>
> Build Reason: scheduler
> Build Source Stamp: [branch master] 7de79168ba184bd805a463da5dc07d
> 28f8c37706
> Blamelist: robcaulk 
>
> BUILD FAILED: failed test test_1 shell_2
>
> sincerely,
>  -The Buildbot
>
>
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] yade on windows 10

[Robert Caulk]

These were my exact thoughts when I read the same news.

I plan to experiment with my new windows 10 computer next week and report
back.

On Thu, Jul 13, 2017 at 11:52 AM, Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr> wrote:

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

Re: [Yade-dev] buildbot failure in Yade on yade-full

[Robert Caulk]

A quick search suggests this is likely due to insufficient RAM + swap. Is
it possible a simple reboot will fix this problem? Does the buildbot reboot
itself?

On Fri, May 12, 2017 at 5:20 AM, Janek Kozicki  wrote:

> Wow, we got:
>
> c++: internal compiler error: Killed (program cc1plus)
>
>
>
> build...@yade-dem.org said: (by the date of Fri, 12 May 2017 02:04:23
> +0200)
>
> > The Buildbot has detected a failed build on builder yade-full while
> building Yade.
> > Full details are available at:
> >  https://yade-dem.org/buildbot/builders/yade-full/builds/3992
> >
> > Buildbot URL: https://yade-dem.org/buildbot/
> >
> > Buildslave for this Build: r0calcul9
> >
> > Build Reason: The Nightly scheduler named 'nightly' triggered this build
> > Build Source Stamp: HEAD
> > Blamelist:
> >
> > BUILD FAILED: failed compile
> >
> > sincerely,
> >  -The Buildbot
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~yade-dev
> > Post to : yade-dev@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~yade-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
> --
> Janek Kozicki   http://janek.kozicki.pl/  |
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] buildbot failure in Yade on yade-full

[Robert Caulk]

Hello Anton,

Thank you, Anton. I agree that yade should be compilable and operational
with any combination of packages. I managed to fix the issue with my recent
commits, based on my testing it should now pass the buildbot.

But my question remains, the LINSOLV package is not compiled or tested by
the buildbot? In other words, I could make a detrimental change to LINSOLV,
but the buildbot would report success?


Best,

Robert

On Tue, May 2, 2017 at 1:38 PM, Anton Gladky <gladky.an...@gmail.com> wrote:

> Hi Robert,
>
> the Yade should work in any combination of enabled features and should
> not fail to compile or to crash. I did not look into your changes, but I
> think
> you need to add a couple of #ifdef guards to make it compilable.
>
> Best regards
>
> Anton
>
>
> 2017-05-02 21:45 GMT+02:00 Robert Caulk <rca...@eng.ucsd.edu>:
> > Ok so after looking into this more I noticed that the buildbot is not
> using
> > the default cmake build. In this case, LINSOLV is disabled on the
> buildbot
> > machine, which is what led to the occurrence of the error on the buildbot
> > but not my desktop.
> >
> > Shouldn't we have the buildbot also testing out compilation of features
> that
> > are considered "default" in addition to a stripped down build? In this
> case,
> > the entire LINSOLV package is not compiled and tested by the buildbot
> after
> > every commit.
> >
> > Best,
> >
> > Robert
> >
> > On Tue, May 2, 2017 at 10:55 AM, Robert Caulk <rca...@eng.ucsd.edu>
> wrote:
> >>
> >> Hey guys,
> >>
> >> So I have an issue I am hoping someone might be able to help me with.
> >> These changes compile perfectly on my desktop [1]. But the buildbot
> catches
> >> an issue that my desktop did not catch [2]. It appears to be an issue
> with
> >> the use of templates inheritance in the flow engine regime, which I
> have now
> >> fixed.  But again, it compiles perfectly fine on my desktop either way.
> So
> >> the only way for me to find out if this is going to pass the buildbot
> is to
> >> push more changes to the trunk? And let's be honest, the likelihood of
> the
> >> buildbot getting upset about something else is high and the last thing
> we
> >> need are pushes to the trunk in the form of compilation
> trial-and-errors.
> >>
> >> So what should I do? Has anyone else encountered this issue where the
> >> trunk compiles fine on their own computer but the buildbot catches a
> >> problem?
> >>
> >> Cheers,
> >>
> >> Robert
> >>
> >>
> >>
> >> [1]https://github.com/yade/trunk/commit/f6970362d9e6e866e8ad
> bc8cbea18e54f677f785
> >>
> >> [2]https://yade-dem.org/buildbot/builders/yade-full/builds/
> 3979/steps/compile/logs/stdio
> >>
> >> On Tue, May 2, 2017 at 9:58 AM, Robert Caulk <rca...@eng.ucsd.edu>
> wrote:
> >>>
> >>> Very sorry, taking care of this now.
> >>>
> >>> On Tue, May 2, 2017 at 10:51 AM, <build...@yade-dem.org> wrote:
> >>>>
> >>>> The Buildbot has detected a failed build on builder yade-full while
> >>>> building yade.
> >>>> Full details are available at:
> >>>>  https://yade-dem.org/buildbot/builders/yade-full/builds/3979
> >>>>
> >>>> Buildbot URL: https://yade-dem.org/buildbot/
> >>>>
> >>>> Buildslave for this Build: r0calcul9
> >>>>
> >>>> Build Reason: scheduler
> >>>> Build Source Stamp: [branch master]
> >>>> f6970362d9e6e866e8adbc8cbea18e54f677f785
> >>>> Blamelist: robcaulk <rob.ca...@gmail.com>
> >>>>
> >>>> BUILD FAILED: failed compile
> >>>>
> >>>> sincerely,
> >>>>  -The Buildbot
> >>>>
> >>>>
> >>>>
> >>>> ___
> >>>> Mailing list: https://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] buildbot failure in Yade on yade-full

[Robert Caulk]

Ok so after looking into this more I noticed that the buildbot is not using
the default cmake build. In this case, LINSOLV is disabled on the
buildbot machine, which is what led to the occurrence of the error on the
buildbot but not my desktop.

Shouldn't we have the buildbot also testing out compilation of features
that are considered "default" in addition to a stripped down build? In this
case, the entire LINSOLV package is not compiled and tested by the
buildbot after every commit.

Best,

Robert

On Tue, May 2, 2017 at 10:55 AM, Robert Caulk <rca...@eng.ucsd.edu> wrote:

> Hey guys,
>
> So I have an issue I am hoping someone might be able to help me with.
> These changes compile perfectly on my desktop [1]. But the buildbot catches
> an issue that my desktop did not catch [2]. It appears to be an issue with
> the use of templates inheritance in the flow engine regime, which I have
> now fixed.  But again, it compiles perfectly fine on my desktop either way.
> So the only way for me to find out if this is going to pass the buildbot is
> to push more changes to the trunk? And let's be honest, the likelihood of
> the buildbot getting upset about something else is high and the last thing
> we need are pushes to the trunk in the form of compilation
> trial-and-errors.
>
> So what should I do? Has anyone else encountered this issue where the
> trunk compiles fine on their own computer but the buildbot catches a
> problem?
>
> Cheers,
>
> Robert
>
>
> [1]https://github.com/yade/trunk/commit/f6970362d9e6e866e8adbc8cbea18e
> 54f677f785
> [2]https://yade-dem.org/buildbot/builders/yade-full/
> builds/3979/steps/compile/logs/stdio
>
> On Tue, May 2, 2017 at 9:58 AM, Robert Caulk <rca...@eng.ucsd.edu> wrote:
>
>> Very sorry, taking care of this now.
>>
>> On Tue, May 2, 2017 at 10:51 AM, <build...@yade-dem.org> wrote:
>>
>>> The Buildbot has detected a failed build on builder yade-full while
>>> building yade.
>>> Full details are available at:
>>>  https://yade-dem.org/buildbot/builders/yade-full/builds/3979
>>>
>>> Buildbot URL: https://yade-dem.org/buildbot/
>>>
>>> Buildslave for this Build: r0calcul9
>>>
>>> Build Reason: scheduler
>>> Build Source Stamp: [branch master] f6970362d9e6e866e8adbc8cbea18e
>>> 54f677f785
>>> Blamelist: robcaulk <rob.ca...@gmail.com>
>>>
>>> BUILD FAILED: failed compile
>>>
>>> sincerely,
>>>  -The Buildbot
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://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] buildbot failure in Yade on yade-full

[Robert Caulk]

Hey guys,

So I have an issue I am hoping someone might be able to help me with. These
changes compile perfectly on my desktop [1]. But the buildbot catches an
issue that my desktop did not catch [2]. It appears to be an issue with the
use of templates inheritance in the flow engine regime, which I have now
fixed.  But again, it compiles perfectly fine on my desktop either way. So
the only way for me to find out if this is going to pass the buildbot is to
push more changes to the trunk? And let's be honest, the likelihood of the
buildbot getting upset about something else is high and the last thing we
need are pushes to the trunk in the form of compilation trial-and-errors.

So what should I do? Has anyone else encountered this issue where the trunk
compiles fine on their own computer but the buildbot catches a problem?

Cheers,

Robert


[1]
https://github.com/yade/trunk/commit/f6970362d9e6e866e8adbc8cbea18e54f677f785
[2]
https://yade-dem.org/buildbot/builders/yade-full/builds/3979/steps/compile/logs/stdio

On Tue, May 2, 2017 at 9:58 AM, Robert Caulk <rca...@eng.ucsd.edu> wrote:

> Very sorry, taking care of this now.
>
> On Tue, May 2, 2017 at 10:51 AM, <build...@yade-dem.org> wrote:
>
>> The Buildbot has detected a failed build on builder yade-full while
>> building yade.
>> Full details are available at:
>>  https://yade-dem.org/buildbot/builders/yade-full/builds/3979
>>
>> Buildbot URL: https://yade-dem.org/buildbot/
>>
>> Buildslave for this Build: r0calcul9
>>
>> Build Reason: scheduler
>> Build Source Stamp: [branch master] f6970362d9e6e866e8adbc8cbea18e
>> 54f677f785
>> Blamelist: robcaulk <rob.ca...@gmail.com>
>>
>> BUILD FAILED: failed compile
>>
>> sincerely,
>>  -The Buildbot
>>
>>
>>
>> ___
>> Mailing list: https://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] buildbot failure in Yade on yade-full

[Robert Caulk]

Very sorry, taking care of this now.

On Tue, May 2, 2017 at 10:51 AM,  wrote:

> The Buildbot has detected a failed build on builder yade-full while
> building yade.
> Full details are available at:
>  https://yade-dem.org/buildbot/builders/yade-full/builds/3979
>
> Buildbot URL: https://yade-dem.org/buildbot/
>
> Buildslave for this Build: r0calcul9
>
> Build Reason: scheduler
> Build Source Stamp: [branch master] f6970362d9e6e866e8adbc8cbea18e
> 54f677f785
> Blamelist: robcaulk 
>
> BUILD FAILED: failed compile
>
> sincerely,
>  -The Buildbot
>
>
>
> ___
> Mailing list: https://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 1687355] Re: FlowEngine + compressible flow + multithread does not work

[Robert Caulk]

** Package changed: ubuntu => yade

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

Title:
  FlowEngine + compressible flow + multithread does not work

Status in Yade:
  Fix Committed

Bug description:
  Hello yade community,

  I've noticed that multithread does not work with the compressible flow
  scheme [4]. My debugging points to [1] where we are setting up the
  system of linear equations. For the compressible scheme, we need the
  cell volumes initialized to build our system of linear equations. The
  multithreading option builds a new backgroundSolver and sets the
  system of linear equations[2]. However, the buildTriangulation
  function[3] does not initialize volumes so, so we end up setting up a
  bad system of equations in the backgroundSolver.

  I think the solution is pretty simple, we need to initialize volumes
  in buildTriangulation if compressible flow+multithread are on:

  if (multithread && fluidBulkModulus>0) initializeVolumes(flow);

  I tested this to make sure the results are accurate by comparing
  oedometer.py results produced by  singlethread+compressible mode and
  multithread+compressible. Will this have any negative impacts on other
  flowengines? Or can I go ahead and push this to the trunk?

  Cheers,

  Robert

  
[1]https://github.com/yade/trunk/blob/a3e2b37fea3859a210dd1bddcfed9ab6a5085105/lib/triangulation/FlowBoundingSphereLinSolv.ipp#L205
  
[2]https://github.com/yade/trunk/blob/a3e2b37fea3859a210dd1bddcfed9ab6a5085105/pkg/pfv/FlowEngine.ipp.in#L149
  
[3]https://github.com/yade/trunk/blob/a3e2b37fea3859a210dd1bddcfed9ab6a5085105/pkg/pfv/FlowEngine.ipp.in#L252

  [4]
  mwe.py (multi-threaded oedometer.py with compressible flow on/off to show 
incorrect pressure) :

  
  # -*- coding: utf-8 -*-
  #*
  #  Copyright (C) 2010 by Bruno Chareyre  *
  #  bruno.chareyre_at_grenoble-inp.fr *
  #*
  #  This program is free software; it is licensed under the terms of the  *
  #  GNU General Public License v2 or later. See file LICENSE for details. *
  #*/

  ## Example script for using the DEM-PFV coupling introduced with E. Catalano, 
as reported in:
  ## * [Chareyre2012a] Chareyre, B., Cortis, A., Catalano, E., Barthélemy, E. 
(2012), Pore-scale modeling of viscous flow and induced forces in dense sphere 
packings. Transport in Porous Media (92), pages 473-493. DOI 
10.1007/s11242-011-9915-6
  ## http://dx.doi.org/10.1007/s11242-011-9915-6
  ## * [Catalano2014a] Catalano, E., Chareyre, B., Barthélémy, E. (2013), 
Pore-scale modeling of fluid-particles interaction and emerging poromechanical 
effects. International Journal for Numerical and Analytical Methods in 
Geomechanics. DOI 10.1002/nag.2198
  ## http://arxiv.org/pdf/1304.4895.pdf
  ## Also used in:
  ## * Tong et al.2012 (http://dx.doi.org/10.2516/ogst/2012032)
  ## * Sari et al 2011 
(http://people.3sr-grenoble.fr/users/bchareyre/pubs/SariChareyreCatalanoPhilippeVincens_Particles2011.pdf)

  
  ## The DEM-PFV is applied here to 1D consolidation (oedometer test). The 
example includes the determination of oedometer modulus Ee and permeability K.
  ## The 1D consolidation is simulated as a coupled problem and the analytical 
solution corresponding to the abovementionned Ee and K is used for comparison.
  ## See triax-tutorial/script-session1.py for more detailed explanations of 
the packing generation procedure.

  ## __   First section, similar to 
triax-tutorial/script-session1.py  _
  from yade import pack

  num_spheres=1000# number of spheres
  young=1e6
  compFricDegree = 3 # initial contact friction during the confining phase
  finalFricDegree = 30 # contact friction during the deviatoric loading
  mn,mx=Vector3(0,0,0),Vector3(1,1,1) # corners of the initial packing

  
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=radians(compFricDegree),density=2600,label='spheres'))
  
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=0,density=0,label='walls'))
  walls=aabbWalls([mn,mx],thickness=0,material='walls')
  wallIds=O.bodies.append(walls)

  sp=pack.SpherePack()
  sp.makeCloud(mn,mx,-1,0.,num_spheres,False, 0.95,seed=1) #"seed" make the 
"random" generation always the same
  sp.toSimulation(material='spheres')

  triax=TriaxialStressController(
maxMultiplier=1.+2e4/young, # spheres growing factor (fast growth)
finalMaxMultiplier=1.+2e3/young, # spheres growing factor (slow growth)
thickness = 0,
stressMask = 7,
max_vel = 0.005,
internalCompaction=True, # If true the confining pressure is generated 
by growing particles

[Yade-dev] [Bug 1687355] Re: FlowEngine + compressible flow + multithread does not work

[Robert Caulk]

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

** Project changed: yade => ubuntu

** Changed in: ubuntu
 Assignee: (unassigned) => Robert Caulk (rcaulk)

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

Title:
  FlowEngine + compressible flow + multithread does not work

Status in Ubuntu:
  Fix Committed

Bug description:
  Hello yade community,

  I've noticed that multithread does not work with the compressible flow
  scheme [4]. My debugging points to [1] where we are setting up the
  system of linear equations. For the compressible scheme, we need the
  cell volumes initialized to build our system of linear equations. The
  multithreading option builds a new backgroundSolver and sets the
  system of linear equations[2]. However, the buildTriangulation
  function[3] does not initialize volumes so, so we end up setting up a
  bad system of equations in the backgroundSolver.

  I think the solution is pretty simple, we need to initialize volumes
  in buildTriangulation if compressible flow+multithread are on:

  if (multithread && fluidBulkModulus>0) initializeVolumes(flow);

  I tested this to make sure the results are accurate by comparing
  oedometer.py results produced by  singlethread+compressible mode and
  multithread+compressible. Will this have any negative impacts on other
  flowengines? Or can I go ahead and push this to the trunk?

  Cheers,

  Robert

  
[1]https://github.com/yade/trunk/blob/a3e2b37fea3859a210dd1bddcfed9ab6a5085105/lib/triangulation/FlowBoundingSphereLinSolv.ipp#L205
  
[2]https://github.com/yade/trunk/blob/a3e2b37fea3859a210dd1bddcfed9ab6a5085105/pkg/pfv/FlowEngine.ipp.in#L149
  
[3]https://github.com/yade/trunk/blob/a3e2b37fea3859a210dd1bddcfed9ab6a5085105/pkg/pfv/FlowEngine.ipp.in#L252

  [4]
  mwe.py (multi-threaded oedometer.py with compressible flow on/off to show 
incorrect pressure) :

  
  # -*- coding: utf-8 -*-
  #*
  #  Copyright (C) 2010 by Bruno Chareyre  *
  #  bruno.chareyre_at_grenoble-inp.fr *
  #*
  #  This program is free software; it is licensed under the terms of the  *
  #  GNU General Public License v2 or later. See file LICENSE for details. *
  #*/

  ## Example script for using the DEM-PFV coupling introduced with E. Catalano, 
as reported in:
  ## * [Chareyre2012a] Chareyre, B., Cortis, A., Catalano, E., Barthélemy, E. 
(2012), Pore-scale modeling of viscous flow and induced forces in dense sphere 
packings. Transport in Porous Media (92), pages 473-493. DOI 
10.1007/s11242-011-9915-6
  ## http://dx.doi.org/10.1007/s11242-011-9915-6
  ## * [Catalano2014a] Catalano, E., Chareyre, B., Barthélémy, E. (2013), 
Pore-scale modeling of fluid-particles interaction and emerging poromechanical 
effects. International Journal for Numerical and Analytical Methods in 
Geomechanics. DOI 10.1002/nag.2198
  ## http://arxiv.org/pdf/1304.4895.pdf
  ## Also used in:
  ## * Tong et al.2012 (http://dx.doi.org/10.2516/ogst/2012032)
  ## * Sari et al 2011 
(http://people.3sr-grenoble.fr/users/bchareyre/pubs/SariChareyreCatalanoPhilippeVincens_Particles2011.pdf)

  
  ## The DEM-PFV is applied here to 1D consolidation (oedometer test). The 
example includes the determination of oedometer modulus Ee and permeability K.
  ## The 1D consolidation is simulated as a coupled problem and the analytical 
solution corresponding to the abovementionned Ee and K is used for comparison.
  ## See triax-tutorial/script-session1.py for more detailed explanations of 
the packing generation procedure.

  ## __   First section, similar to 
triax-tutorial/script-session1.py  _
  from yade import pack

  num_spheres=1000# number of spheres
  young=1e6
  compFricDegree = 3 # initial contact friction during the confining phase
  finalFricDegree = 30 # contact friction during the deviatoric loading
  mn,mx=Vector3(0,0,0),Vector3(1,1,1) # corners of the initial packing

  
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=radians(compFricDegree),density=2600,label='spheres'))
  
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=0,density=0,label='walls'))
  walls=aabbWalls([mn,mx],thickness=0,material='walls')
  wallIds=O.bodies.append(walls)

  sp=pack.SpherePack()
  sp.makeCloud(mn,mx,-1,0.,num_spheres,False, 0.95,seed=1) #"seed" make the 
"random" generation always the same
  sp.toSimulation(material='spheres')

  triax=TriaxialStressController(
maxMultiplier=1.+2e4/young, # spheres growing factor (fast growth)
finalMaxMultiplier=1.+2e3/young, # spheres growing fa

[Yade-dev] [Bug 1687355] [NEW] FlowEngine + compressible flow + multithread does not work

[Robert Caulk]

Public bug reported:

Hello yade community,

I've noticed that multithread does not work with the compressible flow
scheme [4]. My debugging points to [1] where we are setting up the
system of linear equations. For the compressible scheme, we need the
cell volumes initialized to build our system of linear equations. The
multithreading option builds a new backgroundSolver and sets the system
of linear equations[2]. However, the buildTriangulation function[3] does
not initialize volumes so, so we end up setting up a bad system of
equations in the backgroundSolver.

I think the solution is pretty simple, we need to initialize volumes in
buildTriangulation if compressible flow+multithread are on:

if (multithread && fluidBulkModulus>0) initializeVolumes(flow);

I tested this to make sure the results are accurate by comparing
oedometer.py results produced by  singlethread+compressible mode and
multithread+compressible. Will this have any negative impacts on other
flowengines? Or can I go ahead and push this to the trunk?

Cheers,

Robert

[1]https://github.com/yade/trunk/blob/a3e2b37fea3859a210dd1bddcfed9ab6a5085105/lib/triangulation/FlowBoundingSphereLinSolv.ipp#L205
[2]https://github.com/yade/trunk/blob/a3e2b37fea3859a210dd1bddcfed9ab6a5085105/pkg/pfv/FlowEngine.ipp.in#L149
[3]https://github.com/yade/trunk/blob/a3e2b37fea3859a210dd1bddcfed9ab6a5085105/pkg/pfv/FlowEngine.ipp.in#L252

[4]
mwe.py (multi-threaded oedometer.py with compressible flow on/off to show 
incorrect pressure) :


# -*- coding: utf-8 -*-
#*
#  Copyright (C) 2010 by Bruno Chareyre  *
#  bruno.chareyre_at_grenoble-inp.fr *
#*
#  This program is free software; it is licensed under the terms of the  *
#  GNU General Public License v2 or later. See file LICENSE for details. *
#*/

## Example script for using the DEM-PFV coupling introduced with E. Catalano, 
as reported in:
## * [Chareyre2012a] Chareyre, B., Cortis, A., Catalano, E., Barthélemy, E. 
(2012), Pore-scale modeling of viscous flow and induced forces in dense sphere 
packings. Transport in Porous Media (92), pages 473-493. DOI 
10.1007/s11242-011-9915-6
## http://dx.doi.org/10.1007/s11242-011-9915-6
## * [Catalano2014a] Catalano, E., Chareyre, B., Barthélémy, E. (2013), 
Pore-scale modeling of fluid-particles interaction and emerging poromechanical 
effects. International Journal for Numerical and Analytical Methods in 
Geomechanics. DOI 10.1002/nag.2198
## http://arxiv.org/pdf/1304.4895.pdf
## Also used in:
## * Tong et al.2012 (http://dx.doi.org/10.2516/ogst/2012032)
## * Sari et al 2011 
(http://people.3sr-grenoble.fr/users/bchareyre/pubs/SariChareyreCatalanoPhilippeVincens_Particles2011.pdf)


## The DEM-PFV is applied here to 1D consolidation (oedometer test). The 
example includes the determination of oedometer modulus Ee and permeability K.
## The 1D consolidation is simulated as a coupled problem and the analytical 
solution corresponding to the abovementionned Ee and K is used for comparison.
## See triax-tutorial/script-session1.py for more detailed explanations of the 
packing generation procedure.

## __   First section, similar to triax-tutorial/script-session1.py 
 _
from yade import pack

num_spheres=1000# number of spheres
young=1e6
compFricDegree = 3 # initial contact friction during the confining phase
finalFricDegree = 30 # contact friction during the deviatoric loading
mn,mx=Vector3(0,0,0),Vector3(1,1,1) # corners of the initial packing

O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=radians(compFricDegree),density=2600,label='spheres'))
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=0,density=0,label='walls'))
walls=aabbWalls([mn,mx],thickness=0,material='walls')
wallIds=O.bodies.append(walls)

sp=pack.SpherePack()
sp.makeCloud(mn,mx,-1,0.,num_spheres,False, 0.95,seed=1) #"seed" make the 
"random" generation always the same
sp.toSimulation(material='spheres')

triax=TriaxialStressController(
maxMultiplier=1.+2e4/young, # spheres growing factor (fast growth)
finalMaxMultiplier=1.+2e3/young, # spheres growing factor (slow growth)
thickness = 0,
stressMask = 7,
max_vel = 0.005,
internalCompaction=True, # If true the confining pressure is generated 
by growing particles
)

newton=NewtonIntegrator(damping=0.2)

O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_FrictPhys()],
[Law2_ScGeom_FrictPhys_CundallStrack()],label="iloop"
),

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

[Robert Caulk]

This explains why I am not encountering this issue with the 16.04 LTS
server version.

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

Title:
  yade not working prpoperly on Ubuntu/Kubuntu 16.04

Status in Yade:
  New

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

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

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

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

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

[Robert Caulk]

Hey Bruno,

The compiler does not let me compile if I remove the pass-by-reference
as you suggest.

I have yet to run into another issue w.r.t this bug, so we can stick
with the "magic" fix for now :-). Thank you for the assistance and for
committing the fix.

Best,

Robert

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

Status in Yade:
  Fix Committed

Bug description:
  Distro: Xenial 16.04LTS
  Yade Version: yade-2017-0207.git-11c276f
  Compilation: default compilation with debug flags and '#define DFNFLOW' 
uncommented in DFNFlow.cpp

  
  Summary:

  DFNFlowEngine crashes for compiled yade-2017-0207.git-11c276f sources.
  The segmentation fault also occurs for a debug compiled version and
  yields the attached core dump. Interestingly, the DFNFlowEngine does
  not crash for a non-optimized debug compilation of the same sources.

  
  Description of failure:

  According to the core dump, the failure can be traced back to
  DFNFlow.cpp:176, where it is checking if the cell is inifinite
  (although I have also had it fail at the permeability assignment
  directly below line 176 for a modified version of DFNflow.cpp).

   DFNFlow.cpp:

   176: if ( Tri.is_infinite(cell1) || Tri.is_infinite(cell2)) cerr<<"Infinite 
cell found intrickPermeability, should be handled somehow, maybe"<info().kNorm()[facet->second]=cell2->info().kNorm()[Tri.mirror_index(cell1,
 facet- >second)] = pow((aperture+residualAperture),3)/(12*viscosity);

  I am unsure why this line is causing a crash in the optimized-debug
  compiled code, but not the non-optimized-debug compiled code.

  My optimized-debug compiled executable is simply built with the flag
  -DDEBUG=ON. My non-optimized debug compiled code uses an edited
  CMakeLists.txt to avoid optimization:

  IF(CMAKE_COMPILER_IS_GNUCC)
SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0")
SET(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -O0")
  ENDIF(CMAKE_COMPILER_IS_GNUCC)

  The attached zip contains:
mwe.py  // input script 
liteSpecimen2mm.spheres  // packing file
jointSurf.stl  // stl for smooth joint
coreDump2.txt  // core dump after executing mwe.py with optimized debug 
compiled yade

  Any assistance with this bug is greatly appreciated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1666339/+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 1665973] Re: Triaxial Cohesive

[Robert Caulk]

Is there a reason you are trying to use TriaxialCompressionEngine
instead of TriaxialStressController? TCE is deprecated.

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

Title:
  Triaxial Cohesive

Status in Yade:
  New

Bug description:
  Hi all,

  I have tried below script:

  https://github.com/yade/trunk/blob/master/examples/test/triax-
  cohesive.py

  When I change
  sigmaIsoCompaction=-150e3,
   sigmaLateralConfinement=-150e3,

  to

  sigmaIsoCompaction=-50e3,
   sigmaLateralConfinement=-50e3,

  I face with below error, can you please advise

  
  
  Traceback (most recent call last):
File "/usr/bin/yade", line 182, in runScript
  execfile(script,globals())
File "/home/elaheh/Documents/triaxial/Triaxcoh.py", line 80, in 
  O.reload()
  RuntimeError: Simulation file to load doesn't exist: 
  [[ ^L clears screen, ^U kills line. F12 controller, F11 3d view (use h-key 
for showing help), F10 both, F9 generator, F8 plot. ]]
  [0;34mYade [[1;34m1[0;34m]: [0mERROR 
/build/yade-KKgSmd/yade-1.20.0/core/Omega.cpp:120 run: No 
Omega::simulationLoop? Creating one (please report bug).
  

  The script is as per below:

  
  # encoding: utf-8
  # 2012 ©Bruno Chareyre 
  # This variant of triax-basic.py shows the usage of cohesive contact laws and 
moments at contacts

  from yade import pack

  sp=pack.SpherePack()
  ## corners of the initial packing
  mn,mx=Vector3(0,0,0),Vector3(10,10,10)

  ## box between mn and mx, avg radius ± ½(20%), 2k spheres
  sp.makeCloud(minCorner=mn,maxCorner=mx,rRelFuzz=.2,num=1000)

  ## create material #0, which will be used as default
  
O.materials.append(CohFrictMat(young=229e6,poisson=0.4,density=2600,frictionAngle=radians(36.5),normalCohesion=1e12,shearCohesion=1e12,momentRotationLaw=True,etaRoll=0.14,label='spheres'))
  
O.materials.append(FrictMat(young=229e6,poisson=.4,frictionAngle=0,density=0,label='frictionlessWalls'))

  
  ## copy spheres from the packing into the scene
  O.bodies.append([sphere(center,rad,material='spheres') for center,rad in sp])
  ## create walls around the packing
  walls=aabbWalls(material='frictionlessWalls')
  wallIds=O.bodies.append(walls)

  triax=TriaxialCompressionEngine(
wall_bottom_id=wallIds[2],
wall_top_id=wallIds[3],
wall_left_id=wallIds[0],
wall_right_id=wallIds[1],
wall_back_id=wallIds[4],
wall_front_id=wallIds[5],
internalCompaction=False,
sigmaIsoCompaction=-50e3,
sigmaLateralConfinement=-50e3,
max_vel=10,
strainRate=0.03,
label="triax"
  )

  O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()]),
InteractionLoop(
#box-sphere interactions will be the simple normal-shear law, 
we use ScGeom for them
[Ig2_Sphere_Sphere_ScGeom6D(),Ig2_Box_Sphere_ScGeom()],
#Boxes will be frictional (FrictMat), so the sphere-box physics 
is FrictMat vs. CohFrictMat, the Ip type will be found via the inheritance tree 
(CohFrictMat is a FrictMat) and will result in FrictPhys interaction physics
#and will result in a FrictPhys

[Ip2_FrictMat_FrictMat_FrictPhys(),Ip2_CohFrictMat_CohFrictMat_CohFrictPhys(label="cohesiveIp")],
#Finally, two different contact laws for sphere-box and 
sphere-sphere

[Law2_ScGeom_FrictPhys_CundallStrack(),Law2_ScGeom6D_CohFrictPhys_CohesionMoment(
useIncrementalForm=True, #useIncrementalForm is turned 
on as we want plasticity on the contact moments
always_use_moment_law=False,  #if we want "rolling" 
friction even if the contact is not cohesive (or cohesion is broken), we will 
have to turn this true somewhere
label='cohesiveLaw')]
),

GlobalStiffnessTimeStepper(active=1,timeStepUpdateInterval=100,timestepSafetyCoefficient=0.5),
triax,

TriaxialStateRecorder(iterPeriod=100,file='100e3,young=229e6,poisson=0.4,density=2600,frictionAngle=radians(36.5),normalCohesion=1e6,shearCohesion=1e6,etaRoll=0.14,'),
NewtonIntegrator(damping=.4)
  ]

  
  from yade import plot
  
O.engines=O.engines[0:5]+[PyRunner(iterPeriod=20,command='history()',label='recorder')]+O.engines[5:7]
  def history():
plot.addData(e11=-O.engines[4].strain[0], e22=-O.engines[4].strain[1], 
e33=-O.engines[4].strain[2],
s11=-O.engines[4].stress(0)[0],
s22=-O.engines[4].stress(2)[1],
s33=-O.engines[4].stress(4)[2],
i=O.iter)

  
#plot.plots={'i':(('e11',"bo"),('e22',"ro"),('e33',"go"),None,('s11',"bx"),('s22',"rx"),('s33',"gx"))}
  plot.plots={'e22':'s22'}
  plot.plot()

  print "computing, be patient..."
  #First run without moment and without 

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

[Robert Caulk]

First, thank you Bruno for the tips and please excuse my developing
understanding of C++, CGAL, and YADE source.

>If your idea was correct the current code would not work at all, you
>need to include in the picture the fact that this same code actually
>works for us without problem.
I should mention that the attached mwe.py is my attempt at creating the most 
basic DFNflow model possible by avoiding any special cases that may extend 
beyond the original functionality. Since you mention that this code does work 
fine for you guys, it is possible that my input script contains an error. 

Bug update:

>Could you output more data on the crashing facet? Which are the vertices
>connected to it, etc. It may ring a bell about which special case need
>to be handled differently.
The crash occurs no matter which facet is currently being used to declare cell1 
and cell2. Based on my debugging, the crash occurs even when the facet maps to 
nonfictitious cells. The problem occurs in the declaration of cell1 (which 
should simply grab the cellhandle of the facet using "facet->first"). Instead, 
it is declaring some junky values within cell1 despite facet1 pointing to a 
perfectly normal cell. Once the junky cellhandle is passed to CGAL, it throws 
the error.

So I've managed to fix the problem by dereferencing the circulator to
obtain the facet, and then grabbing the cellhandle from the facet
directly [1]. It appears to do exactly what the original code is doing,
but in a more verbose manner. However, cell1 is no longer filled with
junk values and I am no longer getting a segmentation fault.

Obviously, this is strange since the original code was already working
for other people, but this fix suggests that it should not be. Since
I've already associated this bug with the compiler optimization level,
it might be possible that my compiler is optimizing the code differently
than it was intended to when this was written in 2014. Also, I will
continue to investigate my input script for possible mistakes.


[1] void DFNFlowEngine::trickPermeability(RTriangulation::Facet_circulator& 
facet, Real aperture, Real residualAperture)
{
const RTriangulation::Facet& currentFacet = *facet;  // seems verbose 
but facet->first was declaring a junk cell and crashing program
const RTriangulation& Tri = 
solver->T[solver->currentTes].Triangulation();
const CellHandle& cell1 = currentFacet.first;
const CellHandle& cell2 = 
currentFacet.first->neighbor(currentFacet.second);
if ( Tri.is_infinite(cell1) || Tri.is_infinite(cell2)) cerr<<"Infinite cell 
found in trickPermeability, should be handled somehow, maybe"<info().kNorm()[currentFacet.second]=cell2->info().kNorm()[Tri.mirror_index(cell1,
 currentFacet.second)] = pow((aperture+residualAperture),3)/

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

Status in Yade:
  New

Bug description:
  Distro: Xenial 16.04LTS
  Yade Version: yade-2017-0207.git-11c276f
  Compilation: default compilation with debug flags and '#define DFNFLOW' 
uncommented in DFNFlow.cpp

  
  Summary:

  DFNFlowEngine crashes for compiled yade-2017-0207.git-11c276f sources.
  The segmentation fault also occurs for a debug compiled version and
  yields the attached core dump. Interestingly, the DFNFlowEngine does
  not crash for a non-optimized debug compilation of the same sources.

  
  Description of failure:

  According to the core dump, the failure can be traced back to
  DFNFlow.cpp:176, where it is checking if the cell is inifinite
  (although I have also had it fail at the permeability assignment
  directly below line 176 for a modified version of DFNflow.cpp).

   DFNFlow.cpp:

   176: if ( Tri.is_infinite(cell1) || Tri.is_infinite(cell2)) cerr<<"Infinite 
cell found intrickPermeability, should be handled somehow, maybe"<info().kNorm()[facet->second]=cell2->info().kNorm()[Tri.mirror_index(cell1,
 facet- >second)] = pow((aperture+residualAperture),3)/(12*viscosity);

  I am unsure why this line is causing a crash in the optimized-debug
  compiled code, but not the non-optimized-debug compiled code.

  My optimized-debug compiled executable is simply built with the flag
  -DDEBUG=ON. My non-optimized debug compiled code uses an edited
  CMakeLists.txt to avoid optimization:

  IF(CMAKE_COMPILER_IS_GNUCC)
SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0")
SET(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -O0")
  ENDIF(CMAKE_COMPILER_IS_GNUCC)

  The attached zip contains:
mwe.py  // input script 
liteSpecimen2mm.spheres  // packing file
jointSurf.stl  // stl for smooth joint
coreDump2.txt  // core dump after executing mwe.py with optimized debug 
compiled yade

  Any assistance with this bug is greatly appreciated.

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

[Robert Caulk]

I've narrowed it down to the cell1 and cell2 declarations. These objects
are not playing nicely with CGAL's is_infinite, mirror_index, and
neighbor functions.

Here is my working theory:

The cell1 and cell2 handles originate down at the facet_circulator on
line 195 where an arbitrary facet is defined by dereferencing the edge
of interest.

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.
Am I right to say that in this case *facet1 is the facet that we are
interested in using [1]? If so, we should be able to change lines 174
and 175 to:

const CellHandle& cell1 = *facet->first;
const CellHandle& cell2 = *facet->first->neighbor(*facet->second);

But of course, the compiler says this is an invalid initialization of
reference.

[1] http://doc.cgal.org/latest/Circulator/index.html

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

Status in Yade:
  New

Bug description:
  Distro: Xenial 16.04LTS
  Yade Version: yade-2017-0207.git-11c276f
  Compilation: default compilation with debug flags and '#define DFNFLOW' 
uncommented in DFNFlow.cpp

  
  Summary:

  DFNFlowEngine crashes for compiled yade-2017-0207.git-11c276f sources.
  The segmentation fault also occurs for a debug compiled version and
  yields the attached core dump. Interestingly, the DFNFlowEngine does
  not crash for a non-optimized debug compilation of the same sources.

  
  Description of failure:

  According to the core dump, the failure can be traced back to
  DFNFlow.cpp:176, where it is checking if the cell is inifinite
  (although I have also had it fail at the permeability assignment
  directly below line 176 for a modified version of DFNflow.cpp).

   DFNFlow.cpp:

   176: if ( Tri.is_infinite(cell1) || Tri.is_infinite(cell2)) cerr<<"Infinite 
cell found intrickPermeability, should be handled somehow, maybe"<info().kNorm()[facet->second]=cell2->info().kNorm()[Tri.mirror_index(cell1,
 facet- >second)] = pow((aperture+residualAperture),3)/(12*viscosity);

  I am unsure why this line is causing a crash in the optimized-debug
  compiled code, but not the non-optimized-debug compiled code.

  My optimized-debug compiled executable is simply built with the flag
  -DDEBUG=ON. My non-optimized debug compiled code uses an edited
  CMakeLists.txt to avoid optimization:

  IF(CMAKE_COMPILER_IS_GNUCC)
SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0")
SET(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -O0")
  ENDIF(CMAKE_COMPILER_IS_GNUCC)

  The attached zip contains:
mwe.py  // input script 
liteSpecimen2mm.spheres  // packing file
jointSurf.stl  // stl for smooth joint
coreDump2.txt  // core dump after executing mwe.py with optimized debug 
compiled yade

  Any assistance with this bug is greatly appreciated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1666339/+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 1666339] [NEW] DFNflow crashes for compiled trunk but not non-optimized debug compiled trunk

[Robert Caulk]

Public bug reported:

Distro: Xenial 16.04LTS
Yade Version: yade-2017-0207.git-11c276f
Compilation: default compilation with debug flags and '#define DFNFLOW' 
uncommented in DFNFlow.cpp


Summary:

DFNFlowEngine crashes for compiled yade-2017-0207.git-11c276f sources.
The segmentation fault also occurs for a debug compiled version and
yields the attached core dump. Interestingly, the DFNFlowEngine does not
crash for a non-optimized debug compilation of the same sources.


Description of failure:

According to the core dump, the failure can be traced back to
DFNFlow.cpp:176, where it is checking if the cell is inifinite (although
I have also had it fail at the permeability assignment directly below
line 176 for a modified version of DFNflow.cpp).

 DFNFlow.cpp:

 176: if ( Tri.is_infinite(cell1) || Tri.is_infinite(cell2)) cerr<<"Infinite 
cell found intrickPermeability, should be handled somehow, maybe"<info().kNorm()[facet->second]=cell2->info().kNorm()[Tri.mirror_index(cell1,
 facet- >second)] = pow((aperture+residualAperture),3)/(12*viscosity);

I am unsure why this line is causing a crash in the optimized-debug
compiled code, but not the non-optimized-debug compiled code.

My optimized-debug compiled executable is simply built with the flag
-DDEBUG=ON. My non-optimized debug compiled code uses an edited
CMakeLists.txt to avoid optimization:

IF(CMAKE_COMPILER_IS_GNUCC)
  SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0")
  SET(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -O0")
ENDIF(CMAKE_COMPILER_IS_GNUCC)

The attached zip contains:
  mwe.py  // input script 
  liteSpecimen2mm.spheres  // packing file
  jointSurf.stl  // stl for smooth joint
  coreDump2.txt  // core dump after executing mwe.py with optimized debug 
compiled yade

Any assistance with this bug is greatly appreciated.

** Affects: yade
 Importance: Undecided
 Status: New

** Attachment added: "trunkTest.zip"
   
https://bugs.launchpad.net/bugs/1666339/+attachment/4822988/+files/trunkTest.zip

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

Status in Yade:
  New

Bug description:
  Distro: Xenial 16.04LTS
  Yade Version: yade-2017-0207.git-11c276f
  Compilation: default compilation with debug flags and '#define DFNFLOW' 
uncommented in DFNFlow.cpp

  
  Summary:

  DFNFlowEngine crashes for compiled yade-2017-0207.git-11c276f sources.
  The segmentation fault also occurs for a debug compiled version and
  yields the attached core dump. Interestingly, the DFNFlowEngine does
  not crash for a non-optimized debug compilation of the same sources.

  
  Description of failure:

  According to the core dump, the failure can be traced back to
  DFNFlow.cpp:176, where it is checking if the cell is inifinite
  (although I have also had it fail at the permeability assignment
  directly below line 176 for a modified version of DFNflow.cpp).

   DFNFlow.cpp:

   176: if ( Tri.is_infinite(cell1) || Tri.is_infinite(cell2)) cerr<<"Infinite 
cell found intrickPermeability, should be handled somehow, maybe"<info().kNorm()[facet->second]=cell2->info().kNorm()[Tri.mirror_index(cell1,
 facet- >second)] = pow((aperture+residualAperture),3)/(12*viscosity);

  I am unsure why this line is causing a crash in the optimized-debug
  compiled code, but not the non-optimized-debug compiled code.

  My optimized-debug compiled executable is simply built with the flag
  -DDEBUG=ON. My non-optimized debug compiled code uses an edited
  CMakeLists.txt to avoid optimization:

  IF(CMAKE_COMPILER_IS_GNUCC)
SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0")
SET(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -O0")
  ENDIF(CMAKE_COMPILER_IS_GNUCC)

  The attached zip contains:
mwe.py  // input script 
liteSpecimen2mm.spheres  // packing file
jointSurf.stl  // stl for smooth joint
coreDump2.txt  // core dump after executing mwe.py with optimized debug 
compiled yade

  Any assistance with this bug is greatly appreciated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1666339/+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] Using YADE with cloud computing - guide

[Robert Caulk]

Thanks for the reply Anton,

Ok, I will wait for some other devs to share opinions on which venue is
best for this type of guide.

Best,

Robert

On Sun, Jan 1, 2017 at 1:31 PM, Anton Gladky <gladky.an...@gmail.com> wrote:

> Hi Robert,
>
> thanks for sharing this information with us! It can be really
> useful for somebody. There are three opportunities to attach
> your guide:
>  - place it on Yade's wiki
>  - integrate it into the Yade`s official documentation (into the source
> code)
>  - publish it somewhere and add the link into the the Yade`s documentation.
>
> It is better to ask an opinion of other Yade`s developers, how to
> proceed with it.
>
> Best regards
>
> Anton
>
>
> 2016-12-29 18:35 GMT+01:00 Robert Caulk <rca...@eng.ucsd.edu>:
> > Dear YADE devs,
> >
> > I recently spent some time getting YADE running on Amazon's EC2. It pairs
> > surprisingly well with YADE, so I figured I should put together some
> > documentation that helps other YADE users set it up.
> >
> > I've attached the guide because I am unsure where else to post it. If you
> > would like the latex source code for the guide, let me know and I can
> send
> > it over.
> >
> > Best,
> >
> > Robert
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp