Hi all,
I will be hiking in Alps from 14. to 24. August, so keep posting your questions/bugreports/patches, I will process the unresolved ones as fast as possible after.
This week is unfortunately an IT infrastructure maintenance week at our university, so I may have problems getting online even before Thursday. It is already very slow.
best wishes, r.
On Tue, Aug 12, 2008 at 12:14 PM, Robert Cimrman robert....@gmail.com wrote:
Hi all,
I will be hiking in Alps from 14. to 24. August, so keep posting your questions/bugreports/patches, I will process the unresolved ones as fast as possible after.
This week is unfortunately an IT infrastructure maintenance week at our university, so I may have problems getting online even before Thursday. It is already very slow.
I'll be answering questions and fixing technical things in the meantime.
Ondrej
That sounds like a really cool trip. Have fun.
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.
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?
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.
Thanks,
Ryan
On Tue, Aug 12, 2008 at 5:14 AM, Robert Cimrman robert....@gmail.com wrote:
Hi all,
I will be hiking in Alps from 14. to 24. August, so keep posting your questions/bugreports/patches, I will process the unresolved ones as fast as possible after.
This week is unfortunately an IT infrastructure maintenance week at our university, so I may have problems getting online even before Thursday. It is already very slow.
best wishes, r.
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.
participants (4)

Ondrej Certik

Robert Cimrman

Robert Cimrman

Ryan Krauss