Hi all, and thank you for this work. I have just modified the documentation of *Law2_ScGeom6D_InelastCohFrictPhys_CohesionMoment *and just written that it's under development*. *An article is being written *,* and the documentation will be updated at the same time.
François 2014-05-26 11:06 GMT+02:00 Bruno Chareyre <[email protected]>: > 2/ is very unlikely to happen. More realistic is to translate the table > in *.rst. I was secretely hopping that you would be volunteer for that. :) > Besides, I'm open to suggestions on how to improve. > B > > > > On 26/05/14 10:19, Jérôme Duriez wrote: > > Hi, > > Many thanks to the guy who in fact updated > Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity for me ! I had only > to add the name of the example script... So, I edited my one (or even two) > lines in the wiki page. > > I do not know how much you were serious about your 2/ proposition, Bruno > (this could be a project for a computer science student ?), but let us hope > that this day will come. Otherwise I have no doubt that the destiny of this > page is to be most of the time deprecated. We just had another example with > Law2_ScGeom_ViscElPhys_Basic, with guys that are nevertheless "quite" > involved in Yade... (there is an euphemism there) > > Jérôme > > > Le 23/05/2014 13:21, Bruno Chareyre a écrit : > > Hi Jerome, > Thank you for suggestions. First, I'm glad you recognize that the functors > table is less puzzling than the inheritance diagram (or let's say, they > have different purpose). I saw many situations where users would come with > a very specific question, then we realize that they picked a wrong contact > law (bugged and/or unmaintained, L3 to name one). Frustrating for users, > wasted time for everyone. It was the reason to write this table. > Another possible solution would be to reduce the total number of functors. > For instance eliminate from the source code every law which results at > least partly from code duplication, and/or has no example script, and/or is > not documented, and/or has no known maintainer. > > Now, your message is twofold: 1/ where this content should be, and 2/ what > this content should be. > 1/ If someone could re-type this wiki page in rst format, he would have > his karma increased. The right place to put it is in place of this warning, > which currently links to the wiki page: > https://yade-dem.org/doc/user.html#law2-functor-s > Obviously, writing the table in rst will not escape the need to put > information in two different places: class documentation and user manual > (actually it may be easier to modify a table in a wiki page compared to > rst+github, but still I would like the rst option). So: > > 2/ If someone could write a program that would heuristicaly fill the > columns of the table by browsing bug reports, frequency and authors of > commits to each law, and bibliographic reference mentionned in the class > documentation (warning: references to original papers like Cundall1979 > should not appear in the "publications" column, it needs a semantic > analysis of the docstrings), his karma would not only explode, I would also > pay him. > Before this happens, laws will be orphan until somebody will vouch for > them and update the documentation (thank you for updating > NormalInelasticity, now you know you need to put an example script). > > > Thank you for raising this need for updates. It actually reminded me to > ping Anton and Raphaël for Law2_ScGeom_ViscElPhys_Basic, which still looks > red. > Could you please guys do something? > > Thanks > > Bruno > > > On 23/05/14 10:09, Jérôme Duriez wrote: > > Hi, > > This wiki page makes me puzzled since I stumbled upon it. Is there really > a consensus to consider this page as really usefull, and *efficient* ? > > Surely, it could be useful for new users that discover the diagram of > https://www.yade-dem.org/doc/yade.wrapper.html#lawfunctor... > > But, I tend to answer "no" about the relevance. For me, sphinx doc is the > best interface between users and the code (the best place to put > documentation !) *and the most easy to maintain*. Each change in the > sphinx doc follows the git procedure, with possible control from all > developpers and history. Probably such collaborative work features are also > be possible with the wiki, but why would we sum / mix the tools ? > For example, the authors of the wiki page designated > Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity as orphan and > colored it in red... Sure, it is up to class authors (me, here..) to > correct such things, but I wrote a description, with publications and > example script in (*).*Why should I/we re-type it in the wiki page ?* > > Let us focus on sphinx doc, so that it corresponds to / explains as best > as possible the c++ code. This is already a great challenge, maybe there is > no need to have to maintain wiki pages about the same subjects ? > > Jérôme > > (*) : > https://www.yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity > > > Le 22/05/2014 18:24, Christian Jakob a écrit : > > Hi, > > > I updated the wiki for constitutive laws [1]. > Please check for mistakes and add missing informations (examples, dev. > status, active users, ...). > > I detected a duplicate in law description in [2] and [3], which are > exactly the same. Can someone fix that, please? > > > Regards, > > Christian > > > [1] https://yade-dem.org/wiki/ConstitutiveLaws#Constitutive_laws > [2] > https://yade-dem.org/doc/yade.wrapper.html?highlight=cohesion#yade.wrapper.Law2_ScGeom6D_CohFrictPhys_CohesionMoment > [3] > https://yade-dem.org/doc/yade.wrapper.html?highlight=cohesion#yade.wrapper.Law2_ScGeom6D_InelastCohFrictPhys_CohesionMoment > > > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp > > > -- > Jérôme Duriez > Post-Doctorant UJF > Laboratoire 3SR > Bureau E139 - 04.56.52.86.30 > > > > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp > > > > -- > _______________ > Bruno Chareyre > Associate Professor > ENSE³ - Grenoble INP > Lab. 3SR > BP 53 > 38041 Grenoble cedex 9 > Tél : +33 4 56 52 86 21 > Fax : +33 4 76 82 70 43 > ________________ > > > > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp > > > -- > Jérôme Duriez > Post-Doctorant UJF > Laboratoire 3SR > Bureau E139 - 04.56.52.86.30 > > > > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp > > > > -- > _______________ > Bruno Chareyre > Associate Professor > ENSE³ - Grenoble INP > Lab. 3SR > BP 53 > 38041 Grenoble cedex 9 > Tél : +33 4 56 52 86 21 > Fax : +33 4 76 82 70 43 > ________________ > > > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
