Oh yeah - here the file is...

Have a nice trip!

On Thursday, November 29, 2012 12:30:19 PM UTC+1, Robert Cimrman wrote:
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:
>>
>> 1. create a VariableTimeStepper instance 'ts' like you did:
>>      ts = VariableTimeStepper(...)
>> 2. problem.ts = ts
>> 3. 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.