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

[Claus-Justus Heine]

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?

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

On 14.06.2013 19:35, Claus-Justus Heine wrote:
> Am 29.05.13 16:22, schrieb Claus-Justus Heine:
>> Talking to myself. Ok, the answer seems to be the  RestrictProlongPair
>> class.
>>
>> cj
> 
> Mmmh. That Pair class seems to be a little bit broken, not all methods
> of the interface are defined, and the Entity parameters should be tagged
> as const. Also, seemingly the underlying PairOfInterfaces-class only
> combines references to interfaces (ok, everything else is difficult),
> this, however, is not so obvious when looking at the RestrictProlongPair.
> 
> Actually, I am trying to construct a ResrictProlongTuple from iterating
> the RestrictProlongPair class. I will probably implement that tuple from
> scratch, as the Pair is somewhat broken anyway. What I want to have is
> something like
> 
> RestrictProlongDefaultTuple<T1, T2, T3, ....>
> makeRestrictProlongDefault(T1& DF1, T2& DF2, T3& DF3, ....)
> 
> which I thought I had finished when I realized that the Pair-class was
> broken. I am still a little bit surprised that such a functionality is
> not there already.
> 
> Best regards,
> 
> Claus
> 
> 
>>
>> Am 29.05.13 16:16, schrieb Claus-Justus Heine:
>>> The answer may be naive, but say I have 42 discrete functions, how do I
>>> restrict/prolong their data with the AdaptationManager? The
>>> DefaultRestrictProlong implementation seems to work only on a single
>>> discrete function, and the AdaptationManager only takes one
>>> RestrictProlong object during construction. Of, course, I could take the
>>> code from RestrictProlongDefault and try to code something new, but is
>>> there an exisiting solution?
>>>
>>> Thanks in advance for any answer, best,
>>>
>>> Claus
>>>
>>>
>>
>>
> 
> 


-- 
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