Hi Ryan,

Ryan Krauss wrote:

That sounds like a really cool trip. Have fun.

thanks!

I am a little nervous that you are leaving and I am not further along on my SciPy paper. I am making progress, but still struggling to understand LinearElasticTerm.

__call__. My main question is that the output of LinearElasticTerm.__call__changes shape depending on whether it was called by assemble_vector or assemble_matrix in evaluate.py. assemble_vector is called by eval_residuals, while assemble_matrix is called by eval_tangent_matrices. Not suprisingly, the output of__call__when called by assemble_vector is a vector (or really one vector per element) and the output when called by assemble_matrix is one matrix per element. The main difference as far as the input to LinearElasticTerm.__call__is concerned is that the first element in args is either a vector or a matrix.

which 'args' do you mean here?

Recall we wish to solve f(u) := A*u = 0

What is being assembled (vector f = A*u or matrix df/du = A) is
decided by the 'diff_var' argument to LinearElasticTerm.**__call__**():

- if it is None, f(u) is returned
- if it is 'u', df/du is returned

Now for terms depending on more unknown variables, e.g. g(u,p), diff_var could attain values None (->vector), 'u' (-> matrix dg/du), or 'p' (-> matrix dg/dp).

I guess I don't have my mind around what is going on inside LinearElasticTerm.

__call__. By the nature of the calculation, does it automatically adapt to have its output match the size of the input vector or matrix, or are there different cases depending on input shapes?

The 'for out, chunk in self.char_fun( chunk_size, shape ):' loop is in
fact a generator, too. It always evaluates f(u) (or its derivatives) for
*_all_* elements in its region (Omega in your case), but returns at most
'chunk_size' at a time.

3 files are attached. sfepy_flow_summary.pdf is a rough draft of trying to summarize the big picture of how my problem flows through the code. axial_rod_sfepy.py is the setup file for my 3D axial rod problem. axial_rod_log.pdf is basically a nicely formatted print out of various steps in the processing of axial_rod_sfepy.py.

sfepy_flow_summary.pdf is ok.

The axial_rod_log.pdf looks nice, too, I like the fact you can generate it automatically. Do you want me to comment it?

Basically, the first time step is a little bit special, as some data need to be initialized, and in linear case, the matrix A is preassembled, as it remains the same for all the time steps. Nothing is solved in the first step - state is given by the initial conditions = all zeros + some Dirichlet BC. (Yeah, it would be easy to support nonzero initial conditions, too, it is just NotImplemted yet)

The other steps just call problem.solve() (solves the system by Newton, in time_step_function()) and problem.advance() (advances the history (u_prev <- u), in solve_evolutionary_op).

r.