yade-dev team mailing list archive

[Václav Šmilauer <eudoxos@xxxxxxxx>]

> What I don't understand is that even CGAL seems to have license issues, 
> based on the bolded paragraph, since CGAL code and examples are linked 
> to GPL libraries (lapack, geomview, Qt, boost, taucs, ...)
lapack is public domain (IIRC), boost has its own quite liberal license,
not sure about the others. Eh, for MicroMacroAnalyser, I think the best
would be write a special function that could be called from python, but
also called from the engine, if you need that data periodically. Will
get in more detail tomorrow. Cheers, V.
> 
> Bruno
> 
> Q Public License (QPL), Version 1.0 
> <http://doc.trolltech.com/3.0/license.html>
> 
>     This is a non-copyleft free software license which is incompatible
>     with the GNU GPL. It also causes major practical inconvenience,
>     because modified sources can only be distributed as patches.
> 
>     We recommend that you avoid using the QPL for anything that you
>     write, and use QPL-covered software packages only when absolutely
>     necessary. However, this avoidance no longer applies to Qt itself,
>     since Qt is now also released under the GNU GPL.
> 
>     *_ Since the QPL is incompatible with the GNU GPL, you cannot take a
>     GPL-covered program and QPL-covered program and link them together,
>     no matter how._*
> 
>     However, if you have written a program that uses QPL-covered library
>     (called FOO), and you want to release your program under the GNU
>     GPL, you can easily do that. You can resolve the conflict /for your
>     program/ by adding a notice like this to it:
> 
>       As a special exception, you have permission to link this program
>       with the FOO library and distribute executables, as long as you
>       follow the requirements of the GNU GPL in regard to all of the
>       software in the executable aside from FOO.
>         
> 
>     You can do this, legally, if you are the copyright holder for the
>     program. Add it in the source files, after the notice that says the
>     program is covered by the GNU GPL.
> 
> 
> (from free software foundation website : 
> http://www.fsf.org/licensing/licenses/index_html/view?searchterm=qpl)
> 
> 
> 
> 
> 
> Bruno Chareyre a écrit :
> > Hello
> >
> > I'm thinking to how MicroMacroAnalyzer (MMA) could be modified in 
> > order to be used in a more versatile way (partly because Vaçlav told 
> > me he could use that - still true?).
> >
> > Currently, if you put MicroMacro engine in your simulation, 
> > MMA::action() will (in short) :
> > - scan bodies and build a regular(*) triangulation of the spheres each 
> > N iterations;
> > - compute the average strain in each tetrahedron and assign it to 
> > grains (so that the "strain" of one grain is a sum over adjacent 
> > tetrahedra), based on the dispacements of particules on the interval 
> > [n,n+N].
> > - save the state of the sample in a text file (with a specific 
> > convention), so that strains can be recomputed later (out of yade) 
> > with different interval sizes (like [n,n+2N], [n,n+3N], etc.)
> > - write local strains, porosity, fabric tensor, and other 
> > micromechanical quantities in txt files too.
> >
> > Problems :
> > - This engine is doing always the same thing, you can't change what it 
> > does if you don't modify the code and recompile. It is a pitty, since 
> > many geometrical functions available in lib/Triangulation could be 
> > usefull as well (e.g. computing the dual Voronoi graph).
> > - If you want to access to quantities like porosity at the scale of 
> > tetrahedra, you have no way to do that in yade, because you need to 
> > access the CGAL structure using the concepts of cell_iterators, 
> > edge_iterators,... which are not defined in yade.
> >
> > So, I'm wondering how to improve that, and I hesitate between 2 
> > approaches :
> >
> > a) enrich the interface of TesselationWrapper or MicroMacro, so that 
> > instead of just "MM::action()", many members could be accessed via 
> > python, and different things can be computed on demand, and returned 
> > in a standard format.  e.g. for the porosity in a cell of the 
> > triangulation, there could something like :
> >
> > pair<int [4], Real porosity> MMAnalyzer::porosityInNextCell (void);// 
> > usage : while (porosity!=-1) porosity = porosityInNextCell().second;
> >
> >
> > b) expose and make full usage of all typedefs defined in def_types.h. 
> > In that case, no need for interface any more, the full lists of edges, 
> > cells, or facets can be visited, but the user need to learn how to use 
> > CGAL and/or my triangulation classes before doing anything. Example :
> >
> > for (finite_cell_iterator cell=MMA->triangulation->finite_cells_begin; 
> > cell != MMA->triangulation->finite_cells_end; cell++)
> > {
> >      porosity = MMA::Porosity(cell);
> >      if (cell->vertex(2)->id == x) do something;//etc.
> > }
> >
> > I created a draft wiki page about this : 
> > https://yade-dem.org/index.php/Triangulation
> >
> > Bruno
> >
> >
> > (*) Regular is for weighted points (center + radius), while the usual 
> > Delaunay is for points. It can make a big difference (and Delaunay can 
> > give stupid result) when radii are not all the same.
> >
> 
>