[Dune] Update of the official Homepage / dunedesign.png

[Andreas Dedner]

Hi.

There are 2 things I do not like and one I do:
+ keeping it simple and not naming dune-common and dune-geometry works
   quite well (there both really rather technical as you said and not
   much use to any one on there own).
- It looks to me in this picture as if both the core modules and the
   the discretization modules can both not be used without some external
   library module. But it is possible to build
   application without an external module and even without
   using fem or pdelab. I would to have that information in the picture
   if possible.
- I would like to have fem and pdelab more prominent and not side by
   side with grid modules. That was what I quite liked about Christroph's
   original design suggestion.

I tried to change the figure accordingly.

In my picture I am missing that the external modules could be build on 
top of fem or pdelab - one could use a "L-shaped domain" for that of 
course but it did not seems necessary for me.

 From my point of view there are now more than enough suggestions 
around... so do we vote on this or how do we decide?
Andreas

PS:
I never quite understood why there were diamonds and small points on
the top for the applications so I thought one could use the points to 
represent grid modules - but perhaps I missed some underlying idea 
concerning the points and diamonds...

On 09/06/11 17:46, Jö Fahlke wrote:
> Here is a proposal by Markus and me.  We tried to make it simple while still
> showing the most essential features, i.e.
>
>   * the features provided by the core, i.e. a basic selection of grids, as well
>     as local functions and same linear algebra, represented by dune-grid,
>     dune-localfunctions and dune-istl respektively,
>
>   * that more grids can be provided by external modules,
>
>   * that at least two discretization modules exist, naming them explicitly to
>     endorse them,
>
>   * that further external library modules can be written using the core
>     modules, the discretization modules and possibly extra grid modules,
>
>   * and finally that all of this can be used by applications.
>
> We deliberately left some things out to unclutter the diagramm, namely
>
>   * dune-common, since it is mostly a technical detail,
>
>   * discretization modules beyond the two endorsed ones,
>
>   * names of particular extra grid modules and for external library modules,
>     there are simply too many and no particular reason to endorse any of them
>     over the others,
>
>   * names for applications.
>
> Am Thu,  9. Jun 2011, 02:24:12 +0200 schrieb Christian Engwer:
>> In general I prefer design over completeness. I prefer the simplicity
>> of A and would also prefer to have the application visually separated,
>> like in my original diagram. I might be less accurate (but this mainly
>> depends on the interpretation), but looks more appealing.
>
> I hope we uncluttered the diagram enough to appeal to your sense of simplicity
> :)  Our diagram is also not really accurate in a technical sense but we hope
> it catches the spirit.
>
> Grüße,
> Jö.
>
>
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dunedesignC.png
Type: image/png
Size: 38183 bytes
Desc: not available
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20110610/9952b00e/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dunedesignC.svg
Type: image/svg+xml
Size: 25579 bytes
Desc: not available
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20110610/9952b00e/attachment.svg>