Mapping rework experimentation

[Samuel-amap]

Alternate (and possibly more promising, or could with more changes lead to a more promising) approach to multitimestep : a softdependencynode computes its timestep-mapped outputs directly into its status. This meshes better with the current mapping implementation, and avoids other redundancies. More discussions to come.

[github-actions]

Benchmark Results (Julia v1.10)

Time benchmarks

	main	b632253...	main / b632253...
bench_linux/PBP	14.8 ± 2.1 ms	14.9 ± 2.1 ms	0.994 ± 0.2
bench_linux/PBP_multiple_timesteps_MT	0.234 ± 0.0019 s	0.234 ± 0.0017 s	1 ± 0.011
bench_linux/PBP_multiple_timesteps_ST	0.245 ± 0.00093 s	0.242 ± 0.0012 s	1.01 ± 0.0063
bench_linux/PSE	4.36 ± 0.58 s	4.78 ± 0.58 s	0.911 ± 0.16
bench_linux/XPalm_convert_outputs	0.757 ± 0.0078 s	0.747 ± 0.0075 s	1.01 ± 0.015
bench_linux/XPalm_run	0.0174 ± 0.0096 h	0.0183 ± 0.0093 h	0.95 ± 0.71
bench_linux/XPalm_setup	17.2 ± 2.7 ms	17.5 ± 2.4 ms	0.978 ± 0.2
time_to_load	2 ± 0.012 s	2.02 ± 0.014 s	0.991 ± 0.0089

Memory benchmarks

	main	b632253...	main / b632253...
bench_linux/PBP	0.0913 M allocs: 6.16 MB	0.0921 M allocs: 6.27 MB	0.983
bench_linux/PBP_multiple_timesteps_MT	3.46 M allocs: 0.714 GB	3.46 M allocs: 0.714 GB	1
bench_linux/PBP_multiple_timesteps_ST	3.32 M allocs: 0.217 GB	3.32 M allocs: 0.217 GB	1
bench_linux/PSE	0.0496 G allocs: 2.31 GB	0.05 G allocs: 2.39 GB	0.968
bench_linux/XPalm_convert_outputs	6.59 M allocs: 0.436 GB	6.59 M allocs: 0.436 GB	1
bench_linux/XPalm_run	0.572 G allocs: 28.9 GB	0.574 G allocs: 30.1 GB	0.96
bench_linux/XPalm_setup	0.168 M allocs: 9.16 MB	0.168 M allocs: 9.17 MB	0.999
time_to_load	0.153 k allocs: 14.5 kB	0.153 k allocs: 14.5 kB	1

[Samuel-amap]

The Multi-timestep prototype branch is mostly functional -but still needs to be tested on a complex real-world model mapping to better guide remaining development priorities.

The advantages of the current approach over the first one :

• Not much extra work for the user
• Not too intrusive in terms of codebase changes
• Compatible with the current scale mapping approach (unless some ugly corner-case shows up…) without hacking special cases in
• Plays nicer with potential future features (linking specific subsets of nodes of different parts of the MTG together) than the previous approach

Here are the current limitations :

• The API can probably be improved
• PreviousTimestep interaction with timestep mapping needs to be more thoroughly tested
• One of the bigger limitations is that one can’t yet map a variable to a variable with the same name at a different timestep at the same scale. This is a constraint that could possibly be lifted by introducing a more complex Status structure, a sort of 'MultiTimestepStatus', containing a Status object per timestep the model interacts with. This could allow using the same name in different timesteps at the same scale and scale-map to the proper variable at the proper timestep without conflicts, but hasn’t been prototyped.
• Error checking is limited with the current approach, it would take a bit of work to add some more powerful user error checks
• Tests are limited in coverage
• I haven't tested add_organ! changes
• Status vector model generation hasn’t been tested with varying timesteps. I am pretty sure if a model has a status vector and is at/maps to a different timestep something will break.

Other remaining tasks :

• No work done on the ModelList version
• Weather interpolation
• Test type promotion on timestep-mapped variables
• Potential slight performance change in the PSE linux benchmark, worth investigating.
• In fact, I hadn't thought of adding a new multi-timestep benchmark, but I should have.
• Handling rational timestep ratios, not just integers (might not be necessary)
• Documentation and doctests haven’t been updated yet (less point if the API isn’t stable yet)
• There is some likely remaining type instability with the reduce aggregation data, which might affect performance. Runtime-dispatch in general needs to be investigated on the XPalm side, in any case, there may be some lingering issues, from what some summary profiling seems to indicate.

Other comments :

• MultiScaleModel should probably be renamed to MappedModel, or something along those lines, since it isn't strictly used for multi-scale purposes anymore.
• The current way of outputting timestep-mapped variables is to output them at every timestep. A little space is wasted, and no filtering utilities are provided atm.