[dune-functions] Documentation

[Carsten Gräser]

Hi Oliver,

Am 21.09.2015 um 13:32 schrieb Oliver Sander:
> 
>> Before adding detailed documentation for this and before
>> starting to advertise this I'd like to know if these
>> additions/changes are OK for you.
> I think that in any case we still need a general disclaimer stating
> something like
> "this is a technology preview -- no API is fixed yet -- may eat your cat
> -- follow the mailinglist"
sure.

>>> Finally, I have also started to write prose explaining how the stokes-taylorhood.cc example
>>> works. I wrote that for the book, and it actually describes a separate implementation
>>> which uses MultiTypeBlockMatrices for the linear algebra.  If I find the time I may
>>> factor out that text into a separate document and upload it to dune-functions itself.
>> It would be very nice, if you could add this example to
>> dune-functions. I'd really like to have A and B working
>> for this and I have the impression that it mostly is,
>> once you add support for multi-type containers to the
>> HierarchicVectorWrapper or provide an alternative wrapper.
>> But in some places I'm not sure.
> This is where I am currently stuck.  I'd like to handle the VTK output
> in the way it is done in stokes-taylorhood.cc.
> But there, the expression
>  
>   Functions::hierarchicVector(x)
> 
> shows up, and in my case x is a MultiTypeBlockVector.  To be honest I
> didn't try it yet, but I suppose
> I need to generalize hierarchicVector to also function with a MTBVector?
Or you must provide a wrapper which does the same for your
MTBVector. That's not to complicated, you only need to provide

 *.resize(SizeInfo);
 *.operator[](MultiIndex);
 *.operator[](MultiIndex) const;

I'd not think of supporting it in the general mapper now.
The dynamic->static transition will be rather complicated
to get right (assuming that it's posssible at leats).

But even if you have the wrapper I'm not sure if the machinary
will work. That's what I'd like to test.

Best,
Carsten

> 
> Best,
> Oliver
> 
> 
>>
>> The reason for this is, that these A and B are a good
>> indicator if the interface is rich enough/usable in
>> such cases. If you can't implement A and B, we may
>> have to adjust the interface. And this should be done
>> as soon as possible.
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20150921/e8abb360/attachment.sig>