Hi again, Nice words, indeed. Thank you. I will follow your advice :)
But to get back to the topic: Unfortunately, you misunderstood my problem. The issue is with the displacement gradient values stored in "duh" which is computed by deal.II and given as input for the postprocessing tasks to be written. I compared the output of solution gradients "duh" for both codes (my own solid_mechanics code and Thomas' code) using the same implementation for the postprocessor. The fascinating thing is that my code works and it gives correct results in my benchmark since I validated it with another FE program of our own to be 100 % sure. But the code written by Thomas and Timo somehow doesn't give correct duh values. In the first steps both codes agree, but the duh values won't increase according to the loading, only the "yy" component in loading direction increases. This is strange. I am not completely familiar with Thomas' code that's why I posted here. Otherwise debugging my own code is what I do daily. I hope you could explain me what could cause such a behavior in your implementation that deal.II gives different values for duh although the same postprocessor implementation is being used. Is it because of the coupled formulation? Thank you for your help so far. Kind regards, Seyed Ali -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
