Re: [Yade-dev] PotentialBlocks & Particles documentation on website?
On 2/6/19 2:30 PM, Janek Kozicki wrote: Of course when Vasileios will write a chapter of documentation in .rst it will be available, but then clicking the references to relevant classes will not work. Question is: how do we solve that? It just needs to turn on that feature either explicitely in pipeline config (cmake PB_enabled=ON) or implicitely by changing the default in CmakeLists.txt. A separate concern, for another discussion is including them into a debian pacakage release, because it will bring some dependencies with it. Which might be difficult to deal with, especially given our bad experience with CGAL. Personally I would prefer that we split yade into more debian packages, based on their dependencies, like: yade-cgal-dep, - parts of yade that depend on CGAL yade-coinor-dep, - parts of yade that depend on coinor i.e. PotentialBlocks yade-escript-dep, - parts of yade that depend on python-escript, i.e. FEMxDEM yade-fft-dep - (future) parts of yade that depend on libfftw (quantum mechanics) I see no real interest in splitting since the problems we will face are exactly the same. If we know how to package yade-cgal-dep properly then we know how package yadedaily (or any yade-stable) with CGAL. There is no difference. If we don't know how to package yade-cgal-dep, then we must turn the feature off in yade as well. More deb packages would help if there were conflicts such that, e.g., coinor and escript couldn't be installed together. I don't think it is the case here. So the only advantage would be to minimize disk usage for installing the basic yade version, not a real issue. The price would be more maintainance and branch management, thus I'm not a big fan. In order to build documentation without implying package dependency a solution could be use "#ifdef YADE_POTENTIAL_BLOCKS" more selectively, i.e. make it guard only the parts of implementation which really depends on external dependencies. Then the interface would be compiled regardless of feature activation. 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
Re: [Yade-dev] all bugs moved from launchpad to gitlab issues
These boards can be pretty useful! https://gitlab.com/yade-dev/trunk/boards/943528 :) Janek Kozicki said: (by the date of Wed, 6 Feb 2019 17:56:58 +0100) > > we need to clean up those issues a bit ;) > > OK, I marked some of them with "maybe close?" have a look and reconsider. -- 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
Re: [Yade-dev] all bugs moved from launchpad to gitlab issues
> we need to clean up those issues a bit ;) OK, I marked some of them with "maybe close?" have a look and reconsider. -- 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
Re: [Yade-dev] Potential Blocks and Potential Particles - brief analysis of the Object Oriented C++ source code
Janek Kozicki said: (by the date of Wed, 6 Feb 2019 13:53:46 +0100) > Hi, I didn't see the reply from Vasileios on the mailing list. I see > it only now in quote in the reply from Boon. I will answer to both. hm. I see your email in the archive: https://lists.launchpad.net/yade-dev/ that must have been some problem with my mail server. Yes, I have found it in spam :( I need to switch away from this wp.pl email server. -- 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
[Yade-dev] PotentialBlocks & Particles documentation on website?
Hi, Vasileios asked a very reasonable question: > Regarding the PB & PP codes, their classes are not included in the Class > reference online, as they are not enabled by default during compilation in the > master branch. Is there a chance for them to be included, so someone who > doesn't want want to dig in the scripts can understand how to use them? I am > currently rewriting the descriptions of the class attributes related to them > and Chia helped a lot by completing many of them during the past weeks in one > of his commits. The thing is, that the online https://yade-dem.org/doc/ class reference compiled by yade is compiled from what classes are available during compilation. So PotentialBlocks are not present in inheritance graphs, and the variables are not documented. Of course when Vasileios will write a chapter of documentation in .rst it will be available, but then clicking the references to relevant classes will not work. Question is: how do we solve that? Note that it is only about documentation on the website. A separate concern, for another discussion is including them into a debian pacakage release, because it will bring some dependencies with it. Which might be difficult to deal with, especially given our bad experience with CGAL. Personally I would prefer that we split yade into more debian packages, based on their dependencies, like: yade-cgal-dep, - parts of yade that depend on CGAL yade-coinor-dep, - parts of yade that depend on coinor i.e. PotentialBlocks yade-escript-dep, - parts of yade that depend on python-escript, i.e. FEMxDEM yade-fft-dep - (future) parts of yade that depend on libfftw (quantum mechanics) however I have no experience with making debian packages, so I wouldn't know how to do that, at least as of today. -- 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
Re: [Yade-dev] all bugs moved from launchpad to gitlab issues
Great, thanks for your support. I wasn't sure if that was a good move. But I wanted to try :) In any case, if we ever need to access old launchpad bugs, we only need to go to https://launchpad.net/yade/+configure-bugtracker and click "launchpad". Then they are all back again. sorry for hundreds of emails about that migration happening :) we need to clean up those issues a bit ;) Janek Bruno Chareyre said: (by the date of Wed, 6 Feb 2019 10:24:54 +0100) > Hi, that was a good move. > And you are crazy. :) > Yes, it seems some bugs are irrelevant. > B > > On 2/5/19 10:27 PM, Janek Kozicki wrote: > > 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 ;) > > > > best regards > > Janek > > > > ___ > > 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 -- 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
Re: [Yade-dev] Potential Blocks and Potential Particles - brief analysis of the Object Oriented C++ source code
Hi, I didn't see the reply from Vasileios on the mailing list. I see it only now in quote in the reply from Boon. I will answer to both. Chia Weng Boon said: (by the date of Mon, 4 Feb 2019 14:55:50 +0800) > I think in the PotentialParticles code, the "vector" parameters in the > shape class can be removed, because they are independent of the block > generation code. Good, this cleaning is a good idea. I prefer that you do this in a WIP: (Work In Progress) branch on gitlab, if possible. > I still think PotentialBlocks and PotentialParticles should be > maintained as separate codes. This is my slight preference. I understand to you are used to how you did write that. However duplicating code is still a source of bugs. What if you suddenly find a bug in some of the duplicated lines and forgot to fix it in the other one? Ok, you won't forget, but what about future users of this code? They will will not even be aware of those duplicated lines that need a parallel fix of the same thing. Try comparing those files with meld. In meld preferences click four checkboxes: Preferences -> Text Filters -> (1) Trim blank lines (2) C++ comment (3) C comment (4) All whitespace Then run: meld ./pkg/dem/KnKsLaw.hpp ./pkg/dem/KnKsPBLaw.hpp meld ./pkg/dem/Ig2_PP_PP_ScGeom.cpp meld ./pkg/common/Gl1_PotentialBlock.cpp ./pkg/common/Gl1_PotentialParticle.cpp meld ./pkg/dem/PotentialParticle2AABB.cpp ./pkg/dem/PotentialBlock2AABB.cpp (maybe there are more and I just missed it) You will see that those files are nearly identical. The only difference is formatting, whitespaces and newlines. This is exactly a place where bugs live and multiply. Would be much better if you derive one class from the other and instead of duplicates call the code in parent class to do the stuff which is the same for both classes. In particular I saw that those functions are nearly identical: ::BrentZeroSurf ::evaluatePB ::getNormal ::getPtOnParticle2 ::customSolve but there are others. > Also, as PotentialParticle runs fine without MOSEK, should we erase > the part calling MOSEK? It is more robust, and it is like a safety > net (but because it is calling an external library, which has > another layer of pre-processing, it is slower). Just curious about > GPL compatibility. I can't use it now because I am not an > academic, and I am using more of PotentialBlocks. It is up to you. > The reason why the physical contact properties were stored in the Shape > file (rather than Material) is because they were originally developed for > rock mechanics problems, where each face will have a different physical > property.The Potential Block contact detection algorithm is compatible with > the block generation algorithm here: > https://www.sciencedirect.com/science/article/pii/S0266352X14002122 ah, I see now. Maybe there is a way to move it to Material somehow. But I see the difficulty now. So that's something to thing about. > On Mon, Jan 28, 2019 at 12:24 AM Vasileios Angelidakis (PGR) < > v.angelidak...@newcastle.ac.uk> wrote: > > > Hi, > > > > > > Janek thanks for the in-depth remarks on the PB (PotentialBlock) & PP > > (PotentialParticle) codes. It will be very useful to have a discussion on > > the matter and try to improve them. you are welcome, please make sure that your reply goes to yade-dev next time. I might have never see it! > > Regarding the compilation warnings that stem from unused variables, I can > > help suppress them by commenting out the unused variables, if Chia can > > verify with me that he does not intend to use any them in the near future. > > For the other warnings, I will track them inside the code and try to > > suppress them as well. I will let you know if I find any difficulties. great. The warnings are cleared now :) > > Personally, I believe that we could unify some classes of the PB & PP, > > since a part of the code is overlapping; although some parts of the codes > > are completely different. Some comments on this -I see Chia just discussed > > some of these matters earlier today-. (Chia please correct me if I have > > misinterpreted something): yes, unification will solve all the problems in code :) > >- The distinction between the two codes, conceptually, is that the > >PotentialBlocks have flat faces with no curvature, while the > >PotentialParticles can have curved faces and look like "cushions" (I > > liked > >that reference!). This curvature of the latter is controlled by the > >parameters "k" and "R" in the PotentialParticle shape class. ok. So this difference appears in some places in code. Make those places into separate functions, and put duplicated code in parent class :) > >Also, the PotentialBlocks code has been developed to incorporate some > >more parameters and to be compatible with the BlockGen code, in which a > >PotentialBlock can be subdivided to more blocks, by intersecting the > >particle with discontinuity planes. ok, good. >
Re: [Yade-dev] all bugs moved from launchpad to gitlab issues
Hi, that was a good move. And you are crazy. :) Yes, it seems some bugs are irrelevant. B On 2/5/19 10:27 PM, Janek Kozicki wrote: 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 ;) best regards Janek ___ 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
