Consider longterm moving to a full time vector rather than just specifying extra time elements. In tinyVAST, this is called times. If we move this direction we can soft deprecate extra_time slowly. I'm less considered with this issue, but it's probably easier as a user to worry about specifying a full vector than just the extra time slices. Currently, I'm pretty sure you could just provide a full vector to extra_time and it would ignore time slices that are present in the data, anyways so this mostly about an argument name and how it's described.
Most importantly, remove all the complexity around 'fake' data rows that are added to the end of the real data (with weights of 0) to implement the extra time steps. This seemed like the easiest route initially, but this has proven bug prone and to overly complicate the code base. The extra time slices are only needed in the random effects (spatiotemporal and/or purely time-varying). The data themselves do not need to be touched.
Consider longterm moving to a full time vector rather than just specifying extra time elements. In tinyVAST, this is called
times. If we move this direction we can soft deprecateextra_timeslowly. I'm less considered with this issue, but it's probably easier as a user to worry about specifying a full vector than just the extra time slices. Currently, I'm pretty sure you could just provide a full vector toextra_timeand it would ignore time slices that are present in the data, anyways so this mostly about an argument name and how it's described.Most importantly, remove all the complexity around 'fake' data rows that are added to the end of the real data (with weights of 0) to implement the extra time steps. This seemed like the easiest route initially, but this has proven bug prone and to overly complicate the code base. The extra time slices are only needed in the random effects (spatiotemporal and/or purely time-varying). The data themselves do not need to be touched.