Roy Stogner wrote:
>
> Someone (Steffan?) just committed a change turning the constraint
> coefficient types (in the DofConstraintRow typedef and in the generic
> FE compute_C?_constraints functions) from double (which should have
> been Real) and Real into Number.
>
> Is this really necessary? Even if we've got Number defined as
> Complex, all the constraints should still be functions of the
> Real-valued geometric data. I suppose the projection-based
> compute_constraints functions will come up with Numbers for the
> constraint coefficients, but any imaginary components should just be
> floating point error.
>
> I haven't been running with complex numbers enabled, so I'm just
> guessing that this change was prompted by some compiler complaints
> when the new constraint functions tried to downgrade Complexs into
> Reals. If that's the case perhaps we should just be making those
Yep, that was the reason. I agree, there is no need for complex valued
coefficients, and I have just committed some changes (back)
from Number to Real.
Has someone used libmesh for complex valued problems
with non-uniform refinement? I have not, so I did not check
details for the entire constraint functionality for those problems.
Steffen
> casts explicit (and maybe tossing in assert() statements to verify my
> "constraints are always real-valued" claim) instead of storing complex
> coefficients.
> ---
> Roy
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
|