Re: [Libmesh-users] LAGRANGE_VEC and mesh refinement

[Miguel A. S. de T. <sal...@gm...>]

I'm having problems doing the downcasting. I create the FEAbstract as:

AutoPtr<FEAbstract> fe (FEAbstract::build(dim,base_fe_type));

and then when I am inside of the conditional when FEType is not LAGRANGE or
LAGRANGE_VEC, I downcast:

AutoPtr<FEBase> feCasted = (AutoPtr<FEBase>)fe;

but I get this compilation error

./include/libmesh/auto_ptr.h: In instantiation of
'libMesh::AutoPtr<Tp>::AutoPtr(libMesh::AutoPtr<Tp1>&) [with Tp1 =
libMesh::FEAbstract; Tp = libMesh::FEGenericBase<double>]':
src/systems/system_projection.C:932:82:   required from here
./include/libmesh/auto_ptr.h:148:23: error: invalid conversion from
'libMesh::AutoPtr<libMesh::FEAbstract>::element_type* {aka
libMesh::FEAbstract*}' to 'libMesh::FEGenericBase<double>*' [-fpermissive]
     : _ptr(a.release()) {}

If FEGenericBase<Real> (i.e. FEBase) is a child of FEAbstract, I should be
able to do the downcast right? I am not sure if the AutoPtr is getting in
the middle.



On Fri, Jun 6, 2014 at 10:30 AM, Miguel Angel Salazar de Troya <
sal...@gm...> wrote:

> I think I understood it. I'm going to try to implement it. Thanks.
>
>
> On Thu, Jun 5, 2014 at 5:06 PM, Paul T. Bauman <ptb...@gm...> wrote:
>
>> On Thu, Jun 5, 2014 at 3:33 PM, Miguel Angel Salazar de Troya <
>> sal...@gm...> wrote:
>>
>>> Thanks for your response. I am trying to modify the
>>> ProjectVector::operator() function to be able to handle the LAGRANGE_VEC.
>>> One of the first things this function does is this (line 782 at
>>> system_projection.C )
>>>
>>> AutoPtr<FEBase> fe (FEBase::build(dim, base_fe_type))
>>>
>>> This function does not handle the fe_type.family LAGRANGE_VEC, I would
>>> have
>>> to call:
>>>
>>> AutoPtr<FEVectorBase> fe (FEVectorBase::build(dim, base_fe_type));
>>>
>>> as John pointed out. How could I handle both cases without a conditional?
>>> That's the first thing I tried,
>>
>>
>> There's a couple of different paths I see here. Because this code
>> actually does different things based on whether the element is LAGRANGE or
>> not and I've thrown you into the deep end of the pool and are uncomfortable
>> with templates, I'll make the following suggestion and the other developers
>> can trump/suggest alternatives:
>>
>> - Introduce an FEAbstract AutoPtr instead of FEBase
>> - make phi_values, etc. (AutoPtr?) pointers instead of references
>> - if the FEType is not LAGRANGE_VEC, downcast to the FEType and then
>> allocate (new) and populate the phi_values, etc. structures (they aren't
>> used in the LAGRANGE case)
>> - update the conditional to check for LAGRANGE and LAGRANGE_VEC
>> - update the LAGRANGE part to handle LAGRANGE_VEC (only very few, if any
>> changes).
>> - Clean up the memory for phi_values, etc.
>>
>> This will take care of the LAGRANGE_VEC case and doesn't obfuscate future
>> enhancements that'll be need for NEDELEC_ONE, etc, I think.
>>
>> Make sense?
>>
>> Thanks for taking a crack at this.
>>
>> Best,
>>
>> Paul
>>
>>
>
>
> --
> *Miguel Angel Salazar de Troya*
>
> Graduate Research Assistant
> Department of Mechanical Science and Engineering
> University of Illinois at Urbana-Champaign
> (217) 550-2360
> sal...@il...
>
>


-- 
*Miguel Angel Salazar de Troya*
Graduate Research Assistant
Department of Mechanical Science and Engineering
University of Illinois at Urbana-Champaign
(217) 550-2360
sal...@il...