[dune-fem] How to restrict/prolong multiple function during grid adaptation

[Claus-Justus Heine]

Hi Tobias,

well, yes, after slight changes the RestrictProlongPair works (but still
would need to be augmented by further methods to meet the interface). I
see the following problem: the Pair only stores references, as it is
base on combined interfaces. This makes it a little bit inconvenient for
chaining more than two functions (better: restrict-prolong instances),
because then you first have to construct the individual RP-instances,
and then you can chain them together by using pairs of pairs (and the
inner pair has also to be constructed separately, i.e. must not be a
copy of a temporary. I have written something similar to the
std::make_tuple stuff which constructs for any number of discrete
functions a tuple based on their default RP-implementations.

Thanks for the comments. Best regards,

Claus

On 20.06.2013 08:42, Tobias Malkmus wrote:
> Hi Claus
> 
> I worked on the local restrict prolong stuff in the last days.
> A tuple of two RPs in the following way works fine for me.
> 
> {
> typedef RestrictProlongDefault< DiscreteFunctionType1 >
> RestrictProlongDefaultType1;
> typedef RestrictProlongDefault< DiscreteFunctionType2 >
> RestrictProlongDefaultType2;
> 
> typedef RestrictProlongPair< RestrictProlongDefaultType1&,
> RestrictProlongDefaultType2& > RestrictProlongDefaultType;
> 
> typedef AdaptationManager< MyGridType, RestrictProlongDefaultType >
> AdaptationManagerType;
> 
> 
> RestrictProlongDefaultType1 rp1( solution1 );
> RestrictProlongDefaultType2 rp2( solution2 );
> 
> RestrictProlongDefaultType rp( rp1, rp2 );
> 
> AdaptationManagerType adop(grid,rp);
> 
> adop.adapt();
> }
> 
> Both functions are restricted and prolongated in the correct way.
> Ok i had to splash some const qualifiers for the EntityTypes in the
> RestrictProlongTuple calls to restrictLocal and prolongLocal, i think
> you will find them ;)
> 
> 
> On 06/19/2013 08:59 PM, Claus-Justus Heine wrote:
>> On-going story. Actually, I begin to wonder: is this a real design flaw,
>> or is just that I am too stupid?
>>
>> I have successfully generated a RestrictProlongTuple (which is simply
>> based on a std::tuple as storage, and does not use that fancy
>> Interface-combination-pair stuff from Dune::Fem)
>>
>> I now get the following error
>>
>> Error: InvalidStateException
>> [AdaptationManager:/home/claus/projects/Math/DUNE/git/dune-fem/dune/fem/space/common/adaptmanager.hh:649]:
>>
>> Only one instance of AdaptationManager allowed per grid instance
>>
>> The plot is as follows: I have a generic ParabolicFemScheme, which
>> implements the ingredients for an "ALBERTA-style" space-time adaptive
>> method and, yes, that one defines an AdaptationManager for this simple
>> one-function setup.
>>
>> Then I derive a more advanced FEM-Scheme from that. This time to
>> simulate the carbonation of concrete. That one needs the
>> CO2-concentration, a pore-volume-fraction and a Ca(OH)2 concentration,
>> and all of them need to be restricted/prolongated during grid adaptation.
>>
>> This is at least not handy. But I cannot imagine that the need to
>> "restrict-prolong" more than one unknown has never occurred before in
>> the Dune::Fem context. Has it not?
> 
> As far as i know Axel Pfeiffer did something on this in his thesis.
> 
>>
>> Is it a real need that this AdaptationManager is a per-grid-singleton?
>>
>> Of course, I could work around by providing the AdaptationManagerType as
>> an additional template-parameter (or use traits ...) to my transient
>> fem-scheme class. But at the very least the current state of
>> restricting/prolongating discrete functions in Dune::Fem appears to be a
>> little bit complicated.
>>
>> What am I doing wrong?
>>
>> Thanks for any comment,
>>
>> best wishes,
>>
>> Claus
> 
> Best Tobias
> 
> 


-- 
Dr. Claus-Justus Heine
Institut für Angewandte Analysis und Simulation
* Numerische Mathematik für Höchstleistungsrechner
Universität Stuttgart

Fon: +49 (0) 711 - 685 65558
Fax: +49 (0) 711 - 685 65507