<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Dear Santiago,</p>
    <p>you were totally correct! Thank you again</p>
    <p>(Working version attached)</p>
    <p>Michael<br>
      <br>
      <br>
    </p>
    <div class="moz-cite-prefix">On 15.11.19 16:44, Michael Wenske
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:fbe7fad2-f8e1-b0b7-21de-71a3a0f7b527@wwu.de">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Dear Santiago,</p>
      <p>thank you for taking the time! What you suggest comes very
        close to what I tried in my Code example (Option 3: line 128). I
        can indeed create the DiscreteGridFunctionGradient from the
        subspace,<br>
        but for some reason the Adapter will fail!<br>
        <br>
        I append an updated version of the MWE, the adapter will fail to
        instantiate with the DGFGradient made from the subspace (line
        137).<br>
        <br>
        thank you again!</p>
      <p>Michael<br>
        <br>
        <br>
      </p>
      <div class="moz-cite-prefix">On 15.11.19 15:50, Santiago Ospina
        wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CALyMesXjH+EEg-SbkQpv4ehxr+98jAxGcdjB8tUYtARfa8mohg@mail.gmail.com">
        <meta http-equiv="content-type" content="text/html;
          charset=UTF-8">
        <div dir="ltr">
          <div dir="ltr">Hi Michael,</div>
          <div dir="ltr"><br>
          </div>
          <div>Your first approach on extracting the child grid function
            space and using it for the power discrete grid function
            space will definitely not work as you already noticed. The
            reason is that local function spaces have to be created with
            the root tree, in your case, the power grid function space.
            This is because the binding process is only allowed to
            happen in root nodes. Now, there are two approaches to get
            gradients in a grid function out of complex grid function
            space trees. The first one is the one you implemented, that
            is, copying the discrete grid function gradient and get
            explicitly the correct child out of the local function space
            in the evaluate function. The second one is by using a
            subspace grid function space (i.e
            GridFunctionSubSpace<...>). This class overcomes the
            situation mentioned above and allows you to use
            functionalities that expect a root grid function space (e.g.
            LocalFunctionSpace<...> or
            DiscreteGridFunctionGradient<...>). Naturally, the
            second approach should be prefered as it reduces code
            duplication. The following is the way it should be used:<br>
          </div>
          <div><br>
          </div>
          <div style="margin-left:40px">// ...</div>
          <div style="margin-left:40px">template<int comp><br>
          </div>
          <div style="margin-left:40px">using ComponentGFS =
            GridFunctionSubSpace<PowerGFS,TypeTree::TreePath<comp>>;</div>
          <div style="margin-left:40px">// I am not entirely sure on the
            type three path above. If this doesn't work, take a look at
            the type tree docs.</div>
          <div style="margin-left:40px"><br>
          </div>
          <div style="margin-left:40px">ComponentGFS
            comp_gfs(power_gfs);</div>
          <div style="margin-left:40px">DiscreteGridFunctionGradient<ComponentGFS<0>,X>
            dfg_grad_0(comp_gfs,x) ;<br>
          </div>
          <div style="margin-left:40px">// from here on, this should be
            pretty much the same as with the scalar component case.</div>
          <div style="margin-left:40px">// ...<br>
          </div>
          <div><br>
          </div>
          <div>Notice that you still use the same coefficient vector as
            you used to do for the power nodes. This is because the map
            from DOFIndex to ContainerIndex is generated by the leaf
            nodes of local function spaces, therefore, no restriction
            operation nor additional mappings are needed.<br>
          </div>
          <div><br>
          </div>
          <div>Best,<br>
          </div>
          <div>Santiago<br>
          </div>
          <br>
          --------------------------------<br>
          Santiago Ospina De Los Rios<br>
          Interdisciplinary Center for Scientific Computing<br>
          Heidelberg University</div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Fri, Nov 15, 2019 at 2:26
            PM Michael Wenske <<a href="mailto:m_wens01@wwu.de"
              moz-do-not-send="true">m_wens01@wwu.de</a>> wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div bgcolor="#FFFFFF">
              <p>Dear all,</p>
              <p>i managed to do the gradient outputs for the components
                of the PowerGFS<br>
                by writing an aditional discrete Gridfunction which is
                compatible with the adapters.<br>
                I am not sure if it is clean enough to make it into the
                gfs utilities header, but <br>
                for closure I want to report it here. (see attached
                header)<br>
                <br>
                Michael<br>
              </p>
              <div>On 14.11.19 15:36, Michael Wenske wrote:<br>
              </div>
              <blockquote type="cite">
                <pre>Dear wizards,

i am working on a system of one or two (or more) reaction-diffusion
equations. I successfully
refactored my codebase to use the PowerGridfunctionSpace for this
application.
This way I can extend my system to more fields, or fall back to the
simple one-equation case.
I can switch between a PowerGFS of size 1 (one equation), and size 2
(two coupled equations),
and export the results to VTK. So far so good.

Now I want to inspect the gradients of my field(s). In the normal case
without the PowerGFS,
I could make use of the functionality of DiscreteGridFunctionGradient,
and then use the VTK adapter to write the gradient. This is very convenient!

How do I go about this when using a PowerGFS? I fail to get it to work
even for the
one-component PowerGFS. For the two component fields I can use the class
VectorDiscreteGridFunction<..,size>, and force the return types size
with the last
template argument. The class VectorDiscreteGridFunctionGradient does not
seem
to have that option. Here, in the case where the powerGFS has size one, the
Adapters can not convert the one-component Fieldvector to double (I think).

I tried a different route of extracting the sub-GFS-Type from the
PowerGFS and
create a handle on the first components subspace. The idea was to use
use the existing
functionality of the DGF's and adapters on the subGFS, but I also run
into problems.
How would I extract the (smaller) coefficient vector from the larger
PowerGFs one?

I figure that this might be interesting for other applications too,
where the GFS-Tree
might be even more complex than in my case.

I am attaching a minimal working example (dune module) which outputs the
two component fields
sucessfully. The parts where I horribly fail to output the gradients of
the first component are
commented, starting from line 107. I would appreciate any hints or
insights on how to do this.

Am I missing something? What would be the dune way to do this?

build with:
./dune-common/bin/dunecontrol --opts=./dune-powerGFS-output/debug_opts
--only=dune-powerGFS-output all

I am working on dune 2.6

thanks in advance!

Michael

</pre>
                <br>
                <fieldset></fieldset>
                <pre>_______________________________________________
dune-pdelab mailing list
<a href="mailto:dune-pdelab@lists.dune-project.org" target="_blank" moz-do-not-send="true">dune-pdelab@lists.dune-project.org</a>
<a href="https://lists.dune-project.org/mailman/listinfo/dune-pdelab" target="_blank" moz-do-not-send="true">https://lists.dune-project.org/mailman/listinfo/dune-pdelab</a></pre>
              </blockquote>
            </div>
            _______________________________________________<br>
            dune-pdelab mailing list<br>
            <a href="mailto:dune-pdelab@lists.dune-project.org"
              target="_blank" moz-do-not-send="true">dune-pdelab@lists.dune-project.org</a><br>
            <a
              href="https://lists.dune-project.org/mailman/listinfo/dune-pdelab"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.dune-project.org/mailman/listinfo/dune-pdelab</a></blockquote>
        </div>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
dune-pdelab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dune-pdelab@lists.dune-project.org">dune-pdelab@lists.dune-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.dune-project.org/mailman/listinfo/dune-pdelab">https://lists.dune-project.org/mailman/listinfo/dune-pdelab</a></pre>
    </blockquote>
  </body>
</html>