[dune-pdelab] Writing subtree of a CompositeGridFunctionSpace to VTK

[Steffen Müthing]

> Am 25.06.2015 um 16:39 schrieb Oliver Sander <sander at igpm.rwth-aachen.de>:
> 
> Hi Christian,
> I will try to do that.  How do I get the equivalent of
> 
>  typedef GridOperator::Traits::Domain V;
> 
> (with the istl backend) directly from the Composite space?
> My MWE will not be very M if I have to keep the GridOperator.

On the current master, you can write

typedef Dune::PDELab::Backend::Vector<GFS,double> V;

the magic of template aliases ;-)

Steffen

> 
> Thanks,
> Oliver
> 
> Am 25.06.2015 um 16:16 schrieb Christian Engwer:
>> Hi Oli,
>> 
>> can please cookup a MWE, which we can use to track down the problem?
>> 
>> Thanks
>> Christian
>> 
>> On Tue, Jun 23, 2015 at 12:46:50PM +0200, Oliver Sander wrote:
>>>>>> As the SubTree is now an object on its own and doesn't exhibit the
>>>>>> VectorGridFunctionSpace tag anymore the transformation doesn't detect
>>>>>> the vector type of your GFS anymore.
>>>>> 
>>>>> Hmm, why should that tag disappear?  On first sight this sounds like a bug to me,
>>>>> but I'm sure in a second you will tell me that there is a good reason for it :-)
>>>> 
>>>> I'm not totally sure how the transformations work in the end, the code
>>>> is quite involved, but the quick answer is if consider
>>>> 
>>>> struct A
>>>> {
>>>> 	typdef X tag;
>>>> };
>>>> 
>>>> and
>>>> 
>>>> template<typename T>
>>>> struct S
>>>> {
>>>> 	A a;
>>>> };
>>>> 
>>>> S<A> will not contain the tag anymore. The TypeTree::ProxyNode is used
>>>> to wrap the actual node and perhaps that is the place where things go wrong.
>>> 
>>> So we need to ask the master.  Steffen, are you there?
>>> 
>>> 
>>>> 
>>>>>> You would have to abjust the
>>>>>> transformations employed when constructing the SubGFS. I'm not sure
>>>>>> how difficult it is. As a work-around you can merge them again in
>>>>>> paraview, using the calculator:
>>>>>> 
>>>>>> Result = iHat * displacement0 + jHat * displacement1 + kHat * displacement2
>>>>> 
>>>>> I'd dislike doing this, but it seems like I have to:  in 3d my overall space has
>>>>> 8 components, and the VTKWriter flat-out refuses to write that.
>>>> 
>>>> I just saw an alternative possibility...
>>>> 
>>>> you can pass a predicate to addSolutionToVTKWriter. the predicate is
>>>> called with a local function space and returns true if the data
>>>> associated with this space should be written. By this you could call
>>>> addSolutionToVTKWriter for the whole GFS and use the predicate to
>>>> filter the subspaces.
>>> 
>>> That sounds good.  Do you have example code that shows how to do this?
>>> 
>>> Thanks,
>>> Oliver
>>> 
>>>> 
>>>> Christian
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20150625/22d255ae/attachment.sig>