yade crashes when opening

Hi Luc,
see http://<email address hidden>/msg08936.html
Jan

2013/7/15 Luc Scholtès <email address hidden>

> New question #232493 on Yade:
> https://answers.launchpad.net/yade/+question/232493
>
> Hello guys,
>
> I just installed latest version of yade (0.80.0-50-ge568cd2) on my brand
> new machine (ubuntu 12.04 precise). Everything ran fine until I tried to
> launch yade from executable. I get this error message:
>
> Welcome to Yade 0.80.0-50-ge568cd2
> Traceback (most recent call last):
> File "./yade-0.80.0-50-ge568cd2", line 112, in <module>
> import yade
> File
> "/media/sdb/yade/sources/git/build//lib/yade0.80.0-50-ge568cd2/py/yade/__init__.py",
> line 58, in <module>
> import boot
> ImportError: /media/sdb/yade/sources/git/build/libcore.so: undefined
> symbol: _ZTI12Serializable
>
> If you have any idea?
>
> Cheers
>
> Luc
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

Thanks Jan but, from this discussion, everything should work with latest yade version, right?

Luc

Hi Luc,
yes, the latest (or one of the latest) git versions should work. Are you
sure that your version is the newest? I am not very familiar with the
version numbering, but according to https://launchpad.net/yade, 0.80 seems
not to be that case (sorry if I missed something).
Jan

2013/7/16 Luc Scholtès <email address hidden>

> Question #232493 on Yade changed:
> https://answers.launchpad.net/yade/+question/232493
>
> Luc Scholtès posted a new comment:
> Thanks Jan but, from this discussion, everything should work with latest
> yade version, right?
>
> Luc
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

Ok, my mistake. Github is very confusing for me...

getting sources using:

clone <email address hidden>:lucScholtes/trunk.git

gives me the error when launching because, it is not the latest version... I must admit that I don't get it but, of course, everything is fine if I use:

git clone <email address hidden>:yade/trunk.git

Yet, I followed what is described here: https://www.yade-dem.org/wiki/Yade_on_github and I don't see why my branch (lucScholtes/trunk.git) is different from the master branch (yade/trunk.git) since I did a "fork" from master branch.... I must be dumb...

Luc

Yes, the plan was to commit some files in the coming days. I will do it using the main branch.

I guess I will know if I am allowed to do so when I will type git commit files, right?

Cheers

Luc

Thanks Bruno Chareyre, that solved my question.

You will know when you will "push". "Commit" is only local.
What do you plan to commit/push btw?

What I have done with pre-existing fracture planes.

Basically, a contact law. This one could actually replace the current cohesiveFrictionalPM has it has the same features plus the possibility to deal with pre-existing fractures (reference to your message regarding contact laws cleaning). Maybe this could actually help me improve the way I implemented it.

I will add an example folder too, so that people could have an idea about how it works with basic scripts. Is there any particular way to commit entire folders?

I plan to add a screenshot or a video as well on wiki to illustrate that.

Hi Luc,

if you plan to push 1-2 commits and that is it for the moment,
you can just "git commit" several (or one) times and then
just git format-patch origin. Than you can send me or somebody else
prepared patches and we will apply it.

Of course, we can surely add you into the Yade-github-griup, so you can
push your changes without us.

Cheers,

Anton

2013/7/17 Luc Scholtès <email address hidden>:
> Question #232493 on Yade changed:
> https://answers.launchpad.net/yade/+question/232493
>
> Luc Scholtès posted a new comment:
> What I have done with pre-existing fracture planes.
>
> Basically, a contact law. This one could actually replace the current
> cohesiveFrictionalPM has it has the same features plus the possibility
> to deal with pre-existing fractures (reference to your message regarding
> contact laws cleaning). Maybe this could actually help me improve the
> way I implemented it.
>
> I will add an example folder too, so that people could have an idea
> about how it works with basic scripts. Is there any particular way to
> commit entire folders?
>
> I plan to add a screenshot or a video as well on wiki to illustrate
> that.
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp

Anton

2013/7/17 Luc Scholtès <email address hidden>:
> Question #232493 on Yade changed:
> https://answers.launchpad.net/yade/+question/232493
>
> Luc Scholtès posted a new comment:
> What I have done with pre-existing fracture planes.
>
> Basically, a contact law. This one could actually replace the current
> cohesiveFrictionalPM has it has the same features plus the possibility
> to deal with pre-existing fractures (reference to your message regarding
> contact laws cleaning). Maybe this could actually help me improve the
> way I implemented it.
>
> I will add an example folder too, so that people could have an idea
> about how it works with basic scripts. Is there any particular way to
> commit entire folders?
>
> I plan to add a screenshot or a video as well on wiki to illustrate
> that.
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp

Ok, so we really have to discuss that Luc.
cohesiveFrictionalPM is a duplicate of Law2_ScGeom6D_CohFrictPhys_CohesionMoment for the most part.
You are about to commit an improved duplicate of a duplicate?... I would really like if we could avoid that.
A few reasons:
- users are lost with so many possibilites;
- lots of unmaintained laws;
- well tested algorithms for contact kinematics (I'm reworking those for a few months now and will commit improvements sometime soon), periodic boundary conditions, etc. are only implemented in a small number of laws since it is painfull to propagate a fix in all existing laws, hence many laws are using poor implementation of contact handling.
- similarly convenience features (e.g. elastic energy and plastic dissipation) are only available for a few laws.

What are the key features of your materials/law that are not present in Law2_ScGeom6D_CohFrictPhys_CohesionMoment?
What would it cost in terms of additional attribute to implement it in the existing classes? I can see it needs the number of broken contacts in material class, if its only that it is not worth a full set of classes I think.

First, please, no new law unless you remove at the same time cohesiveFrictionalPM completely.
Second, even assuming that cohesiveFrictionalPM will be removed, does it really need a new law?

And of course, if it really needs a new law, you would remove cohesiveFrictionalPM at the same time, wouldn't you?

Yes, as I told you, this new law would replace cohesiveFrictionalPM, which is, as you said a duplicate of Law2_ScGeom6D_CohFrictPhys_CohesionMoment for the most part. So I would remove cohesiveFrictionalPM, agreed. BTW, what is the procedure for that matter?

Now, the new law allows to take into account pre-existing fracture planes as I told you. The sort of things describe here:

http://www.sciencedirect.com/science/article/pii/S1365160912000391#.

Nothing really new in terms of contact behaviour (normal, shear adhesion), just a specific way of dealing with the orientation of contacts belonging to pre-existing fractures (and, of course, the initial interparticle distance as the equilibrium distance). A little bit more than number of broken contacts ;)

I understand your concerns but I am not sure I could implement this particular new feature into Law2_ScGeom6D_CohFrictPhys_CohesionMoment. What I can insure though, is that I will try to keep the files updated in regards to the new features you mentionned (contact handling, PBC, etc...).

Luc

I just tried to "git push" a commit (add a new reference for testing commit) but get this message:

ERROR: Permission to yade/trunk.git denied to lucScholtes.
fatal: The remote end hung up unexpectedly

Could you help me on that one please?

Luc

Back to this.
Equilibrium distance is also present in Law*CohesionMoment (LCM) through "unp", so the only difference left is the normal (good thing to integrate this, btw).
In fact the question is not wether the behavior is very different or not. It is only a matter of how much additional data is needed in IP/IG. Adding hundreds of functions and data to a functor will never hurt in terms of performance. OTOH, adding a lot of data in interactions for an optional feature is not good as it would increase memory usage for everyone.
So if you need, let's say, only a pointer to a fracture plane in each interaction, it is not a big deal to integrate what you need in LCM.
The only limit of this reasoning is that reading a 2000+ line source file is painful. We have to balance the different aspects.

If you find that there is a real reason for a new class, then there is still an alternative to plain duplicate. You could inherit form LCM and write only the parts of the code that are modified. Some code blocks that are the same (e.g. computing moments, if it applies) could be moved to separate functions in LCM, so that your action() would use them unmodified.
The advantage of this is that you automatically get features like elastic energy, graphical display of the interactions, etc. Anything available for LCM will be also available for your law. Also you would not have to track the changes in LCM to duplicate them in the other law (which is really boring in the long run and generates a lot of noise).

B

Thanks for inputs Bruno.

As a first alternative, because it would be easier both in terms of time and coding, I would say that I would like to commit my new class as I received several demands for it. It would replace the old Cohesive frictionalPM of course if you can explain me how to delete it. In addition, I would like to commit a directory with examples so that people would be able to use it as it is. I guess I can do it by myself but Anton suggested that I may send the folder to one of you...

What do you think?

Luc

As I understand, you have already "push-rights". Feel free
to do it, but, please, double-check, what you commit.

Thanks.

Anton

2013/7/22 Luc Scholtès <email address hidden>:
> Question #232493 on Yade changed:
> https://answers.launchpad.net/yade/+question/232493
>
> Luc Scholtès posted a new comment:
> Thanks for inputs Bruno.
>
> As a first alternative, because it would be easier both in terms of time
> and coding, I would say that I would like to commit my new class as I
> received several demands for it. It would replace the old Cohesive
> frictionalPM of course if you can explain me how to delete it. In
> addition, I would like to commit a directory with examples so that
> people would be able to use it as it is. I guess I can do it by myself
> but Anton suggested that I may send the folder to one of you...
>
> What do you think?
>
> Luc
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp

I agree that making it available for people is the priority, but please don't take it as a "one shot" operation. Clean integration is the key to long term viability.

google("git remove file"):
http://stackoverflow.com/questions/11121352/how-to-remove-files-from-the-github-repository

I'm guessing google("git add directory"), will work as well. :)

"git add ."

is enough to add/remove files
afaik

"gitt add" without any option might be a bit dangerous as it adds all files
it finds in the working tree (if I understand the documentation correctly),
including e,g built documentation in yade/doc/sphinx directory.. I
personally prefer a bit more writing but much safer commands like "git add
thisfile.*pp; git rm thatfile.py".
Jan

2013/7/22 Christian Jakob <email address hidden>

> Question #232493 on Yade changed:
> https://answers.launchpad.net/yade/+question/232493
>
> Christian Jakob posted a new comment:
> "git add ."
>
> is enough to add/remove files
> afaik
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

i am always using "git add ."
i see no problem, since one does not change other things in the code, that are not wanted to commit ...

Of course, basically you are right. But in the case of building sphinx
documentation in yade/doc/sphinx directory, "git add ." would include the
built documentation to the commit (??), which is not desired.. I just
wanted to point out this fact, which might be unwanted side effect in some
cases..
Jan

2013/7/22 Christian Jakob <email address hidden>

> Question #232493 on Yade changed:
> https://answers.launchpad.net/yade/+question/232493
>
> Christian Jakob posted a new comment:
> i am always using "git add ."
> i see no problem, since one does not change other things in the code, that
> are not wanted to commit ...
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

right jan, thats why i build doc i an extra folder

I really support Jan's suggestion.
I usually instruct everyone to type only "git add file1" and "git commit file1". Never trust the default.
I usually have many "file.cpp~" here and there (automatic backup), kdevelop can also modify or create a few files.
Not mentioning people who build in the source dir...
If we suggest "add ." and "commit -a" to everyone, problems frequency will increase. :)