-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential bug in elasticity tensor? #156
Comments
The discussion in kimauth/MaterialModels.jl#34 is related to this. If you call |
I think that we just don't utilize in |
yes! I can confirm that the test pass when computing the elasticity tensor as
Many thanks! |
I remember looking into this a long time ago. I don't recall the details but it had something to do with that when you take a derivative w.r.t a symmetric tensor there is some ambiguity. Googling now I find: https://math.stackexchange.com/a/2298251
I don't fully understand the implications of all this though. |
Doesn't matter for this example, but there is a special function |
Actually, that makes this work |
Thanks @fredrikekre and @KristofferC. I can confirm that using |
Joining the party late here, but seeing that this is still open I wanted to attempt giving a final comment that can close this issue. Bonet and Wood's formulas assume all the way that C is symmetric. Doing the derivations without this assumption, I get For any C, this produces that Hence, I think @nilszander's last-mentioned failure is actually the result to be expected. |
Thanks @KnutAM for your comment. But isn't C=trans(F) . F. So to my understanding C is always symmetric. So should I see the minor and major symmetries? |
When deriving the derivatives with a full tensor, no symmetry constraints are accounted for (e.g. we can perturb C_12 without touching C_21). Therefore, we get the result that In Bonet and Wood, however, respecting the symmetry constraints, they derived So there is, even in the theory, a difference in differentiation between being a symmetric tensor per definition and cases when a tensor just happen to have symmetric entries. |
A bit late to the party. The explanation on stack overflow which Kristoffer shared is very theoretic (written from a pure math stand point). Maybe a simpler explanation for people with continuum mechanics background is a paper by Itskov (see [1] below). Still very formal and not simple to read, but maybe it is more approachable to some people. |
Dear developers,
many thanks for this great tool! I just started trying out ferrite and I am impressed by the scope and the simplicity. However, I just stumbled over one question, which might be a potential bug in the computation of the rank-4 elasticity tensor.
I wrote a simple unit test to validate the correctness and used the book of Bonet and Wood as reference (see code below). While for most entries (I,J,K,L) the results match my reference solutions, the ferrite results deviate for certain indices. In particular, the ferrite results seems to be not fully symmetric as they should be according to BonetWood, Equation 6.37. As an example, consider the entry
∂S∂C[1,3,2,3]
. Due to symmetry, this entry should match∂S∂C[1,3,3,2]
. However, in the example stated below, this is not the case. Instead, the results readwhereas the reference solution
D
readsSo it seems as if ferrite "lumps" the two entries to one.
While I don't know whether this will actually cause a problem for hyper-elasticity, it is certainly surprising. Could you help me to understand whether I am using the code correctly?
Many thanks
Nils
The text was updated successfully, but these errors were encountered: