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 <
[email protected]> 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 <[email protected]> wrote:
>
>> On Thu, Jun 5, 2014 at 3:33 PM, Miguel Angel Salazar de Troya <
>> [email protected]> 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
> [email protected]
>
>
--
*Miguel Angel Salazar de Troya*
Graduate Research Assistant
Department of Mechanical Science and Engineering
University of Illinois at Urbana-Champaign
(217) 550-2360
[email protected]
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
