I was able to run the mesh refinement for just one processor, it seems to
work fine. However, when I run it with two processors, I get this error:
Assertion `coarse->parent()' failed.
[1] src/error_estimation/uniform_refinement_estimator.C, line 545, compiled
Jun 10 2014 at 14:35:08
The code snippet for that line is:
for (; elem_it != elem_end; ++elem_it)
{
// e is necessarily an active element on the local processor
const Elem* elem = *elem_it;
// Find the element id for the corresponding coarse grid
element
const Elem* coarse = elem;
dof_id_type e_id = coarse->id();
while (e_id >= max_coarse_elem_id)
{
libmesh_assert (coarse->parent());
coarse = coarse->parent();
e_id = coarse->id();
}
...
Could you help me out with what the code is doing here? I am struggling
figuring out how to debug a program in parallel. I ask the question to see
if you guys could help me in the mean time. What is the element "id" ? What
is its purpose? Any idea why it is failing? I haven't introduced any
modification in the mesh or elem data structures. Thanks in advance.
Miguel
On Mon, Jun 9, 2014 at 12:48 PM, Miguel Angel Salazar de Troya <
[email protected]> wrote:
> More problems with the extension of the refinement to the FE LAGRANGE_VEC.
> The class UniformRefinementEstimator::_estimate_error only accepts FEBase
> types (around line 484 in uniform_refinement_estimator.C), I'll have to
> check the other kind of refinements. Then it creates the corresponding
> shape functions and gradient of shape functions that are only for
> non-vectors FEType.family 's. I was thinking I could do something similar
> to what I did before:
>
> - Create the FEAbstract AutoPtr instead of FEBase
> - Create pointers to both vector<Real> phi and vector<RealGradient> phi,
> same with dphi.
> - Create the conditional and downcast to either case (FEBase or
> FEVectorBase) and populate the shape functions and their gradients.
> - Use the shape functions in another conditional because phi[i][qp] is a
> vector for LAGRANGE_VEC not a scalar.
> - Clean up the memory.
>
> My question is, are there alternatives? I've read here,
> http://thewayofc.blogspot.com/2007/09/alternative-ways-to-implement-downcasts.html
> , that dynamic_cast is pretty slow and maybe a different design approach
> might be more efficient. So far, I was using this downcasting:
>
> AutoPtr<FEBase> feCasted = AutoPtr<FEBase>(dynamic_cast<
> FEBase*>(fe.get()));
>
> Are there alternatives? Thanks in advance.
>
>
>
> On Fri, Jun 6, 2014 at 1:49 PM, Miguel Angel Salazar de Troya <
> [email protected]> wrote:
>
>> I think I solved it by using the raw pointer AutoPtr has:
>>
>> AutoPtr<FEBase> feCasted =
>> AutoPtr<FEBase>(dynamic_cast<FEBase*>(fe.get()));
>>
>> I will test if it works.
>>
>>
>> On Fri, Jun 6, 2014 at 11:59 AM, Miguel Angel Salazar de Troya <
>> [email protected]> wrote:
>>
>>> 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]
>>>
>>>
>>
>>
>> --
>> *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]
>
>
--
*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]
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
