yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

Concerning the license of CGAL, I'm still waiting an answer from 
developpers of CGAL, but I'm a bit pessimistic after reading the text 
below.
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, ...)

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.


--

_______________
Chareyre Bruno
Maître de Conférences

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________