> 
> You know, we could and probably *should* use a similar trick to your
> DG code elsewhere in the library.  Instead of seeing whether element
> vs neighbor sides are conforming via "if (refinement_type == "p")",
> could we test "if (elem->level() == neighbor->level())"?  Then we only
> have to fall back on inverse_map when the particular elem/neighbor
> interface is non-conforming, not when any interface anywhere in the
> mesh might be.  I haven't tested that idea on ex21 yet; would you?

I haven't yet, but I think it's the best option. 

> 
>> In FEBase I added a method that returns the nodes coordinates for reference 
>> frame elements.
>> This method could also be used to speed-up the solution output when using 
>> reference frame finite elements.
>> I did it based on FEBase::on_reference_element()
>> would you please check that everything is correct. This kind of coding is 
>> error-prone and I'm not sure about the PIRAMID5.
> 
> John, double-check me on this:
> 
> I believe the PYRAMID5 in Lorenzo's patch is wrong - the Pyramid5 we
> use, going by both my own hazy memory and by the ::shape() equations
> in fe_lagrange_shape_3D.C, has points 0-3 in the zeta=0 plane, not
> zeta=-1.

Since the PYRAMID5 case is not implemented in FEBase::on_reference_element(),
(looking at the code it seems that Ben has been lazy :->)
I didn't know where to find info about the coordinates. Thanks to you and John
for checking and double-checking.

> 
> Only trouble is, if we make the library depend on this code
> internally, I don't want AMR to break for the less common
> configurations.  So that would mean doing better than a
> libmesh_not_implemented() for InfFE: we'd need to add the InfFE
> entries to FEBase::get_refspace_nodes() and either move side_map up
> the inheritance tree or duplicate it.
> 
> I don't have any time to do that myself right now, though.  And
> otherwise the patch looks good.  So (assuming it passes my app tests,
> and unless anyone has objections) I'm planning to commit things nearly
> as-is, with InfFE as libmesh_not_implemented() and with the PYRAMID5
> case fixed.
> 
> And if anyone wants faster jump error estimators any time soon and has
> more time to play with it, that should soon be low-hanging-fruit.

I hope I'll have some time to improve the error estimators code in the near 
future
and also avoid inverse maps in the solution output using 
FEBase::get_refspace_nodes().
The InfFE stuff is a bit harder for me since I have never used it and at least 
I would need to understand how it works... 

Thanks a lot.
Lorenzo
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to