fixed time stepping is not using the DT parameter

[cekees]

instead, it's using what's in tnList. Reported by @srobertp. We should have two fixed time step modes:

1. step exactly over intervals in tnList (FixedStepSimple)
2. step exactly over intervals of DT (or whatever fixed step the system step controller decides after analyzing all the model step controllers) (FixedStep)

[srobertp]

@cekees You had sent me a message saying

I confirmed that Sequential_FixedStep, etc. is taking the step size from the first interval in tnList rather than using DT, as you saw. After that step, however, it's constant, so you could do something like [0,DT,1.0,2.0,3.0] for small DT, and it will take steps at size DT but (after the first step) only save at the larger steps. I'll raise that as a proteus issue though. It should force steps of DT regardless of what's in tnList.

I have experimented with this and it still sticks to the elements of tnList. I am not observing the constant-ness of it after the first step.

[cekees]

OK, if you could commit your files to a branch on proteus-ps with the case where it sticks to the elements of tnList, I'll take a look at it.

[srobertp]

• SHA: 14d4e83993f1e80a6ec0fd04696368adcbe2c339
• User/Repository@SHA: srobertp/proteus-ps@14d4e83993f1e80a6ec0fd04696368adcbe2c339

has that case in branch tnListIssueExample of https://github.com/erdc-cm/proteus-ps/

I guess it is not possible to link directly to that branch from a separate github repository, that I can see.

[cekees]

Thanks. My mistake, I forgot that I had switched the systemStepControllerType to just the minimum step chosen by the model stepControllers (and leave those set to FixedStep). Here is the diff showing what to change

-systemStepControllerType = Sequential_FixedStep # uses DT set in _n.py files
+systemStepControllerType = Sequential_MinModelStep # uses DT set in _n.py files

[srobertp]

Ok, this works well and maintains the DT as set in our _n files only if DT divides the values in tnList evenly. In my case, I was printing out at [0, 0.25, 0.5, 0.75,..., 9.75, 10.0] but my DT was set to 0.1, so that it is actually solving at times [ 0.0, 0.1, 0,175, 0.25] then continues with DT = 0.075 until it needs to adjust again to hit the next step [0.325, 0.4, 0.45, 0.5] after which it is DT = 0.05 . Now that 0.05 divides each plotting interval nicely it continues with that till the end of the simulation using DT = 0.05.

Moral of the story, this hack works for a fixed DT only if that DT divides the intervals for outputting.

[cekees]

That sounds right. Will have to think about desired behavior here. Interpolation or returning the value at the nearest time step are the only options that seem reasonable to me. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: srobertpSent: Monday, June 15, 2015 5:35 PMTo: erdc-cm/proteusReply To: erdc-cm/proteusCc: Chris KeesSubject: Re: [proteus] fixed time stepping is not using the DT parameter (#258)Ok, this works well and maintains the DT set if DT divides the values in tnList evenly. In my case, I was printing out at [0, 0.25, 0.5, 0.75,..., 9.75, 10.0] but my DT was set to 0.1, so that it is actually solving at times [ 0.0, 0.1, 0,175, 0.25] then continues with DT = 0.075 until it needs to adjust again to hit the next step [0.325, 0.4, 0.45, 0.5] after which it is DT = 0.05 . Now that 0.05 divides each plotting interval nicely it continues with that till the end of the simulation using DT = 0.05.

Moral of the story, this hack works for a fixed DT only if that DT divides the intervals for outputting.

—Reply to this email directly or view it on GitHub.

[adimako]

@cekees @tridelat, this should be closed I guess. @tridelat can you check if there are any other issues with constant timestepping.