On 11/29/2012 11:39 AM, Bjarke Dalslet wrote:
On Wednesday, November 28, 2012 4:19:21 PM UTC+1, Robert Cimrman wrote:
Hello,
On 11/28/2012 04:00 PM, Bjarke Dalslet wrote:
Hello SfePy users.
A question:
Is the VariableTimeStepper usable yet? Is there a "proper" way to use it? Are there any examples I have overlooked?
It works, but I am using it only in one of my projects... There are no examples using it in SfePy.
I have tried to manually replace it, i.e.: ###
time_solver.ts=VariableTimeStepper(0.,30.,dt=0.001,step=0.,n_step=30001.)
problem.ts=time_solver.ts.copy() ###
but this throws up problems when using the problem.advance(ts). As far as i can see the ProblemDef.update_time_stepper(ts) and the ts.set_from_ts(ts) functions are not compatible with the VariableTimeStepper subclass, and does not copy the n_step0 and dt variables correctly.
Yes, that is probably the case and should be fixed (could you create a new issue, please?), but see below.
But then again I might just be doing it wrong ;D
Hope that somebody can help me!
I am using it in a following way:
create a VariableTimeStepper instance 'ts' like you did: ts = VariableTimeStepper(...)
problem.ts = ts
make a loop with:
for step, time in ts: ... # call ts.set_time_step() if needed. problem.advance()
So the trick is _not_ to pass the 'ts' into problem.advance().
Could you try that?
Cheers, r.
It doesn't work. In order to actually solve the FEM problem the loop has
to call "make_implicit_step(ts, state, problem, nls_status=None)". This calls problem.time_update(ts) and problem.init_time(ts) which eventually calls VariableTimeStepper.set_from_data() where things get messed up.
Ok, I was too brief in my response. You actually do not need to call make_implicit_step(), but call directly problem.solve(), as follows:
problem.time_update() state = problem.solve()
in the time loop.
But I agree, that it should work also the standard way.
My workaround is to make a subclass of VariableTimeStepper (see attached file) defining a new set_from_data() that makes sure that n_step0 !=1 and that dt is not changed. Obviously it is very crude, but honestly, I don't know how far the timesteppers responsibilities extend, and changing as little as possible seems best.
Forgot the attachment?
I will make a ticket referencing this thread.
Thanks. I will try to fix it. But today I am leaving abroad, so I am not sure when I will be able to get to it.
Once again, thanks for helping!
Thanks for debugging!
r.