I was wondering if someone could please give me some pointers on how to resolve this error. I am running a series of breakthrough curve simulations at constant residence time and column radius with increasing column length (same duration but higher linear velocity). I am scaling the transport parameters with velocity appropriately (film and axial dispersion via correlation). The isotherm and transport parameters were determined fitting of breakthrough curves for the short column. For all simulations the column is being loaded with protein until 7500 s and then washed out with buffer until 10500 s.
I receive the below error after increasing the column length from 2.5 cm to 10 cm. The time integrator error appears to occur when protein loading is completed and the wash begins. I have seen errors with the IDASolve before and fixed it with increasing the max steps in the time integration and relaxing error tolerances. This error is different, however, and I am not sure how to resolve it.
[Error: idasErrorHandler::196] In function ‘IDASolve’ of module ‘IDAS’, error code ‘IDA_ILL_INPUT’:
tout too close to t0 to start integration.
[Error: integrate::1355] IDASolve returned IDA_ILL_INPUT at t = 7500
If someone could point me in the right direction here, it would be much appreciated!
usually this happens when an entry in the user solution times is too close to a section time.
Mind that if you use something like a linspace for creating the solution times, sometimes there are weird floating point issues. So you could play around with that.
To get a more reproducible setup, consider the strategy I developed in CADET-Process (see here):
Create linear space with given resolution (e.g. 1 s, I use np.arange instead of np.linspace here but it’s very similar)
Add sections to solution time vector to make sure every section time is included in the solution times
Sort all entries to be monotonically increasing
Remove duplicates
Check if any diff in the solution times is lower than some cutoff value and remove the corresponding entries (i.e. always keeping the section time and removing the additional solution time that comes from linspace)
I know this sounds kind of tedious but it makes things much more robust for me. And it’s necessary when section boundaries shift a lot like in process optimization.
Finally, there is also a bug in CADET that produces a segfault when one of the user solution times is larger than the last section time. I already proposed a solution (see PR) but I still need to verify that it does not have any side effects.
Thanks Johannes, it seemed that the error was being caused by some floating point issues in the solution times like you mentioned. I fixed this and it seems to have resolved the problem.