Skip to content

Causes of slower execution compared to fatscapelib-fortran low-level API #3

@benbovy

Description

@benbovy

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions