After #1, running a model using the xarray-simlab based, high-level API here might be slightly slower than running the same model using the low-level fatscapelib-fortran API.
This is mainly due to a key difference in design between the xarray-simlab components and the fastscapelib-fortran library:
In fastscapelib-fortran, every process like erosion, uplift or advection is meant to be applied sequentially in a user-defined order. Each related function updates the global state (e.g., topographic surface elevation, bedrock elevation) in place.
The xarray-simlab model components implemented in this package take another approach, where each process yields its own outputs without modifying the global state. After all processes are executed, all outputs are aggregated (e.g., sum all erosion) before updating the state at the end of the time step execution.
Because we reuse the functions implemented in fastscapelib-fortran for the high-level API, there is a lot of duplicate computation and copies that cannot be avoided.
Eventually switching from fastscapelib-fortran to fastscapelib C++ will solve this issue, as the latter is designed more like a library and is more compliant with the second approach explained above. This might even be faster (at the cost of more memory expensive) than using the low-level fatscapelib-fortran API as it would avoid things like:
repetitive b=min(h,b), etot=etot+ht-h, etc. found in subroutines of fastscapelib-fortran
solving advection for h, b and etot in fastscapelib-fortran Advect.f90
After #1, running a model using the xarray-simlab based, high-level API here might be slightly slower than running the same model using the low-level
fatscapelib-fortranAPI.This is mainly due to a key difference in design between the xarray-simlab components and the fastscapelib-fortran library:
In fastscapelib-fortran, every process like erosion, uplift or advection is meant to be applied sequentially in a user-defined order. Each related function updates the global state (e.g., topographic surface elevation, bedrock elevation) in place.
The xarray-simlab model components implemented in this package take another approach, where each process yields its own outputs without modifying the global state. After all processes are executed, all outputs are aggregated (e.g., sum all erosion) before updating the state at the end of the time step execution.
Because we reuse the functions implemented in fastscapelib-fortran for the high-level API, there is a lot of duplicate computation and copies that cannot be avoided.
Eventually switching from fastscapelib-fortran to fastscapelib C++ will solve this issue, as the latter is designed more like a library and is more compliant with the second approach explained above. This might even be faster (at the cost of more memory expensive) than using the low-level
fatscapelib-fortranAPI as it would avoid things like:b=min(h,b),etot=etot+ht-h, etc. found in subroutines of fastscapelib-fortranh,bandetotin fastscapelib-fortranAdvect.f90