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.
> casts explicit (and maybe tossing in assert() statements to verify my
> "constraints are always real-valued" claim) instead of storing complex
> 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.
> Libmesh-devel mailing list