So, I think I am making some progress on trying to understand LinearElasticTerm.__call__, but I have some questions.
First of all, as far as the big picture, it seems like the method (and especially the underlying C function dw_lin_elastic_iso) must implement something like Hooke's law in 3D. But if the __call__ method takes the current state of everything and finds all the element displacements for the current time step, it almost seems like it is doing the entire finite element method. Is either or both of these a good way to think about what the __call__ method does?
What are the input and output of __call__?. It seems like the input is everything that is known at the current time step. The output contains three things. The primary one is out, which for my problem is a 4D array with shape (177, 1, 12, 1). 177 is the number of elements. So, it seems like this is an array that contains 12 parameters per element. Are there 12 d.o.f. for each element? If so, what are they? I guess it makes sense that an element with 4 nodes could have 12 d.o.f., but that would be a redundant way to think about things (obviously the nodes are shared by several elements). So, it seems like it must be 12 element strains. The other two outputs seem straight forward: chunk is a list of element #'s (since I have 177 elements and a chunk size of 100000, it is simply all my elements - i.e. range(177)) and status is always 0. I assume this is a flag for when something goes wrong.
In its current form, my input file (see attached) has only 2 times steps (t=0 and t=1). The only difference between the two is that at t=0 the traction load is 0 and at t=1 the traction load is 0.1.
It seems like the traction load must be part of the fargs that are passed to dw_lin_elastic_iso in the self.function call, but I don't see it. Maybe this is just a problem with what gets printed using Pdb, but is the traction in fargs somewhere?
With two time steps, why is __call__ called 4 times? The first two calls result in out containing all 0's. The third and fourth calls produce non-zero out. The out of the third and fourth calls appear to be different.
I think those are my main questions for now.
On Fri, Aug 1, 2008 at 6:07 AM, Ryan Krauss ryan...@gmail.com wrote:
Cool. Good to know.
On Fri, Aug 1, 2008 at 6:02 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Ryan Krauss wrote:
Thanks for the explanations. Prototyping in Python makes a lot of sense and is far less intimidating .
I can imagine it. The C part developed from what I had scavenged from my previous FE programs.
Just one more note: Term subclasses need just two methods: __init__() and __call__(). The remaining methods you may see are auxiliary, usually serving to avoid typing when further subclassing.