Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Roy Stogner <roystgnr@ic...>  20060426 21:08:53

On Wed, 26 Apr 2006, Steffen Petersen wrote: > I just tried to clean up some shape function files > and code the Bernstein shapes in a more generic way > (including arbitrary orders for quadrilaterals). > Although I have adapted the corresponding fe_ElemType.C > (i.e. the n_dofs functions), > I got this error for p > 6 > > ERROR: unsigned char too small to hold Elem::_p_level! > Recompile with Elem:_p_level set to something bigger! > [0] /home/mubsp/tmp/libmesh/include/geom/elem.h, line 1325, compiled Apr 21 > 2006 at 12:21:08 > > For different element types, the order seems to be > fixed at different levels. Can you perhaps give > me a quick hint? Because no element type can support arbitrarily high p (in fact, floating point and matrix conditioning seem to kill us around p = 11), I've put a max_order function in the FEInterface code to tell the DoFMap just how high each element can go. If the base polynomial degree + the p_level elevation exceeds this max order, the DoFMap bumps the p_level down again. This obviously isn't a complete solution (if p refinement is impossible, 99% of the time you'd prefer h refinement to nothing) but it's a start. The problem comes in when the base polynomial degree exceeds that max_order even with p_level() == 0  then the DofMap tries to drop the p_level to 1 (which casts turn into 2^32  1 or so) and the p_level() function freaks. I put an assert in dof_map.C this morning to prevent that misleading error message from cropping up; should I add a more informative error message to dof_map.C to take its place? Oh, and to summarize all the rambling: In src/fe/fe_interface.C, edit the FEInterface::max_order() function at the bottom of the file to return a higher number for the BERNSTEIN/QUAD* case.  Roy 