including tfinal when integrating an orbit

[M1ssing-N0]

Currently, the time of the last sample is (tfinal-tstep) instead of tfinal.
I edited the code to extend the integration until tfinal which may be more intuitive.
I also include more sanity check (e.g., tfinal>tinit) for better quality of life.

[michael-petersen]

Thanks for getting started on this!

I understand that the goal here is a use case where you have finer control to manually change the basis at some larger time step (i.e. sequence several IntegrateOrbits calls together), and right now the effective dt=(tfinal-tinitial)/h results in the orbits not being integrated to have an output at tfinal. Is that right?

Looking through, this will create some breaking changes, so I think we'll definitely want to think about whether this is the best way to implement the goal. We also probably want to have some defaults rather than nullopt, although the catches now will help with that.

[The9Cat]

This is an interesting approach, but we are very reluctant to change the IntegrateOrbits API. As Mike said, it will break existing scripts and applications. It would be better, at this point, to fix the internal step counts to ensure that the last point is tfinal. This was the intent of the code as written. Specifically, the goal of lines 3856-3865 is choose a step size that starts at tinit and ends exactly at tfinal (up to machine precision at least). If that is broken, let's fix that first.

[M1ssing-N0]

Thanks for your comments! I agree that I am making some aggressive changes like introducing nullopt.
The changes I made serve to:

1. Fix the missing output at tfinal (e.g., for tinit=0, tfinal=1, tstep=0.1, it will only integrate from 0 to 0.9), as mentioned by Michael,
2. Provide more consistency and sanity check for better quality of life,
3. Enable simultaneous input of h and nout, which is the reason for introducing optional arguments.
   Maybe I can focus on the first to objectives first? I can revert back the changes to arguments h and nout

[The9Cat]

I apologize that we've left this PR for so long. There are many changes in the proposed patch that modify top-level configuration parameters that will affect way more than the issue at hand. I would very much prefer to address the issue of tfinal directly and open separate PRs or issues for top-level CMake changes and default parameters, please!!

That said, I've boiled down the change request to the attached which I believe should address the issue. At the very least, I propose that we test the following patch and use it or some modification of it to address the core issue.

I've tested it the limiting cases for both positive and negative intervals and it appears to work as expected.

patch.txt

[The9Cat]

@M1ssing-N0 : It would be great if you'd be willing to test this patch and update your branch without the changes to other aspects of the code (i.e. no CMakelists. txt or other default parameter changes).

[The9Cat]

Ooops, sorry, I have a more recent patch. Please use this one.
patch.txt

Here is a link to a branch containing the patch.

[M1ssing-N0]

That's a huge update! The two arguments h and nout can now affect the integration in their own ways.
I downloaded the code and it's working fine. I noticed that h was assigned a new value before the code starts to do the calculations. It's less intuitive but does solve the problem about tfinal.

There seems to be some problem with my PR. I didn't change files other than BiorthBasis.cc and BasisWrappers.cc. Maybe it's a problem with rebasing. I think I can close this PR and it might be better to simply merge the tfinalFix branch.

[The9Cat]

Okay, glad to hear that it works for you and fixed your issue! I agree that this rewritten algorithm is slightly more elaborate.

A few comments on the motivation for this change for completeness:

1. Without specifying nout, the routine gives the user a time series with identical time intervals that exactly matches the full interval with a fixed h. The routine will adjust h slightly to make this so. It seemed cleanest for the user to specify a value of h, tinit & tfinal and get uniform sampling without worrying about matching h to the interval. If the user does match h to the interval, then the user should get what they expect. The use case for this might be DFT, for example. I agree that we could have done this by keeping h fixed except, possibly, for the final interval. But I thought that might surprise some users.
2. The idea behind nout is for the user to specify the number of desired time samples equally spaced, along with a minimum h. The user gets either the same sample as in Case 1, or a smaller value of hthat strides the input interval to achieve nout to samples with a smaller internal step size.

I suppose we could return to the original scheme of having a short last interval. Maybe @michael-petersen has an opinion on this?

@M1ssing-N0 If it's easier. I'm happy to issue a new PR from the tfinalFix branch and link to this one so we don't lose the discussion.