Very interesting. At this very moment I happen to have 30,000 cores
worth of jobs queued on our supercomputer that match this description!
We have noticed some problems when trying to do mesh refinement
studies for hermites when starting with analytic initial conditions
(like your smooth cross).
We might rerun some of that stuff now.
Derek
Sent from my iPhone
On Feb 2, 2012, at 9:43 AM, Roy Stogner <roystgnr@...> wrote:
>
> A quick warning for those using 2D and/or 3D HERMITE elements:
> there was a bug, now fixed in the svn head, in
> System::project_vector(fptr,gptr,etc), which caused the
> mixed-derivative-based degree of freedom coefficients to be set to
> zero rather than calculated from finite differencing of the gptr
> gradient. Note that this affects the project_vector overload which is
> most commonly used for setting initial conditions, not the overload
> which is used in AMR/C.
>
> The effects of this bug seem to be nearly naked-eye-invisible and to
> rapidly decay in fourth order problems (thankfully; at least 25% of my
> own published work is affected...), but I would still *strongly*
> recommend that anyone using that method with those elements should
> either upgrade to svn or backport the patch to a released libMesh
> version.
>
> My apologies for the error.
> ---
> Roy
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel

A quick warning for those using 2D and/or 3D HERMITE elements:
there was a bug, now fixed in the svn head, in
System::project_vector(fptr,gptr,etc), which caused the
mixed-derivative-based degree of freedom coefficients to be set to
zero rather than calculated from finite differencing of the gptr
gradient. Note that this affects the project_vector overload which is
most commonly used for setting initial conditions, not the overload
which is used in AMR/C.
The effects of this bug seem to be nearly naked-eye-invisible and to
rapidly decay in fourth order problems (thankfully; at least 25% of my
own published work is affected...), but I would still *strongly*
recommend that anyone using that method with those elements should
either upgrade to svn or backport the patch to a released libMesh
version.
My apologies for the error.
---
Roy