Hi @benbovy. I just noticed that there might be an issue with the boundary conditions in FastScape. I am using 0.1.0beta3

When I run a simple model with a uniform uplift and this type of bc:
'boundary__status': ['core', 'fixed_value','looped', 'looped'],
I get a solution that looks like it should. But if I flip the bc on their side:
'boundary__status': ['looped', 'looped','core', 'fixed_value'],
I get something that does not make any sense...

It looks like there is a bug in where the uplift function is applied in two of the corners: The uplift is imposed but no erosion can take place.

Good solution :

Bad solution:

I noticed some weird differences in behavior when running the exact same notebooks (fastscape-demo) in the same environment, but on different platforms (MacOS, Ubuntu, Binder containers...)

I suspect that this is related to issues with array dtypes that are not properly set.

MarineSedimentTransport has many parameters. I'm wondering what is the percentage of use cases where all of them are needed, or otherwise if there is a number of cases where compaction and/or grain size differentiation (sand/silt) can be turned off.

Depending on this, probably a good idea for more clarity would be to specialize MarineSedimentTransport into a hierarchy of processes with increasing complexity, like it has been done with StreamPowerLaw. This is only a change in API, internally all processes would call the same (most specialized) routine.

Some output variables in a few processes (like flow receivers, etc.) are not set before the 1st run step.

I'm not sure if it makes sense setting a dummy value for those variables in initialize, as I can't think of a case where those are needed elsewhere during initialization. The only annoying thing is that a KeyError is raised when trying to use it in other process classes at this stage.

• define static variables (grid processes, maybe elsewhere like stratigraphic horizons) #14
• index variables (grid processes, maybe elsewhere like stratigraphic horizons) #14
• use multiple groups for some variables #15
• object variables? 04ea2d5
• fix compatibility with dask.distributed -> can't pickle fortran objects #16
  • Avoid using fastscapelib_fortran.fastscapecontext directly -> declare instead all variables that we need (tedious, verbose but at least those are serializable).

Nice to have:

• default values (e.g., SPL "n" and "m" exponents, maybe other parameters) #17
• values validators (ranges, choices, etc.) #17

Hello,

I am trying to start running models with fast scape however when I import fastscape I get a module not found error for the "channel" process file. "fastscapelib_fortran doesn't seem to be recognized. Any help would be appreciated.

See fastscape-lem/fastscapelib-fortran#54

First of all: thanks a lot for this great library!

perhaps the obvious question:
when/how is implementation of the C++ library planned?

I would be very interested in improving some of my models in xsimlab, using fast xtensor-based C++ functions. However, I could not find any examples that use these fucntions in a xsimlab-based context. Is there any version of fastscape that uses the fastscapelib (C++) library, or is there any plan on when the change is to be made?
(from fortran-based to C++ based)

Or otherwise, is there any branch/fork that started using the C++ library

I would be very interested!

Sorry, I didn't see any example of adding a DEM download from other websites as a simulated object. I don't know how to add my DEM to the program if the fastscape supports doing that. I appreciate that someone could help with that. Thanks.

For example, I have a DEM in the file ("E:/PhD/TopoToolbox/TTLEMStudy/ttlem/topotoolbox-master/DEMdata/WulongshanForTTLEM30.tif"), and I try to use it but into failure. I want to find some examples of this problem, but nothing.

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

It might be useful to save drainage area as an model output diagnostic, even though an alternative method (e.g., using non-uniform surface runoff) used for computing flow accumulation.

However, it's difficult (not possible) to use both the DrainageArea process and another FlowAccumulator subclass in the same model.

Drainage area should be thus implemented in FlowAccumulator as an on-demand variable, so that it is available in all FlowAccumulator subclasses.

Hello @benbovy,

I am not sure if this is the right place (or in xsimlab) to raise this issue, but since updating to the new version of fastscapelib-fortran (and fastscape), I cannot run cross-batch jobs, i.e., containing two batch dimensions that I "stack" and "unstack". I keep getting the following message:
ValueError: conflicting multi-index level name VARNAME with dimension VARNAME

I attach a notebook containing a very simple example where the issue arises.

Many thanks for your help
Jean (@jeanbraun)

`
import numpy as np
import xsimlab as xs
import xarray as xr

from fastscape.models import basic_model

ds_in = xs.create_setup(
model=basic_model,
clocks={'time':np.linspace(0,10e7,101)},
input_vars={
'grid__shape': [101,101],
'grid__length': [10e3,10e3],
'boundary__status': 'fixed_value',
'uplift__rate': ('U', [1e-4,1e-3]),
'spl__k_coef': ('K', [1e-6,1e-5]),
'spl__area_exp': 0.4,
'spl__slope_exp': 1,
'spl__tol_rel': 0.0001,
'spl__tol_abs': 0.0001,
'spl__max_iter': 100,
'diffusion__diffusivity': 1e-3,
'init_topography__seed': None,
},
output_vars={'topography__elevation': 'time'}
)

import zarr
zgroup = zarr.group("Test.zarr", overwrite=True)

with basic_model, xs.monitoring.ProgressBar():
ds_out = ds_in.stack(batch=['U','K']).xsimlab.run(check_dims='transpose',store=zgroup, batch_dim='batch', parallel=True, scheduler='processes').unstack('batch')
`

Hello,

I am receiving an error when trying to run the tutorial for the basic model. I have loaded the demo environment as per the instructions in the readme.md file and have not modified any of the code.

`out_ds = in_ds.xsimlab.run(model=basic_model)

​

out_ds

ValueError Traceback (most recent call last)
in
----> 1 out_ds = in_ds.xsimlab.run(model=basic_model)
2
3 out_ds

~/.conda/envs/fastscape-demo/lib/python3.7/site-packages/xsimlab/xr_accessor.py in run(self, model, safe_mode)
484 driver = XarraySimulationDriver(self._ds, model, store, output_store)
485
--> 486 return driver.run_model()
487
488 def run_multi(self):

~/.conda/envs/fastscape-demo/lib/python3.7/site-packages/xsimlab/drivers.py in run_model(self)
297
298 """
--> 299 ds_init, ds_gby_steps = self._get_runtime_datasets()
300
301 runtime_context = RuntimeContext(

~/.conda/envs/fastscape-demo/lib/python3.7/site-packages/xsimlab/drivers.py in _get_runtime_datasets(self)
279
280 ds_all_steps = (self.dataset.drop(ds_init.data_vars.keys(),
--> 281 errors='ignore')
282 .isel({mclock_dim: slice(0, -1)})
283 .assign(step_data_vars))

~/.conda/envs/fastscape-demo/lib/python3.7/site-packages/xarray/core/dataset.py in drop(self, labels, dim, errors, **labels_kwargs)
3641 stacklevel=2,
3642 )
-> 3643 return self.drop_sel(labels, errors=errors)
3644
3645 def drop_sel(self, labels=None, *, errors="raise", **labels_kwargs):

~/.conda/envs/fastscape-demo/lib/python3.7/site-packages/xarray/core/dataset.py in drop_sel(self, labels, errors, **labels_kwargs)
3687 raise ValueError('errors must be either "raise" or "ignore"')
3688
-> 3689 labels = either_dict_or_kwargs(labels, labels_kwargs, "drop")
3690
3691 ds = self

~/.conda/envs/fastscape-demo/lib/python3.7/site-packages/xarray/core/utils.py in either_dict_or_kwargs(pos_kwargs, kw_kwargs, func_name)
255 if not is_dict_like(pos_kwargs):
256 raise ValueError(
--> 257 "the first argument to .%s must be a dictionary" % func_name
258 )
259 if kw_kwargs:

ValueError: the first argument to .drop must be a dictionary`

It is currently computed as the product of total lengths along this x and y axes, which doesn't account of the "outer" area delineated by nodes (cell centers) and cell edges. It should be cell area times the total number of grid nodes.

This is a common initial setup.

It may be possible to encapsulate a model run to dynamically create a steady state topography, maybe with some (configurable) resolution downgrade for speed-up. It might also be possible to leverage the dimensionless uplift/stream-power/diffusion relationship to adapt to the grid scale and to set a height scale.

Add a module or subpackage landlab_bridge that contains landlab component classes converted to xarray-simlab process classes and/or inversely.

Hello @benbovy. I have encountered an issue with fastscape where it complains about a depreciated numpy integer type on line 93 of flow.py. I believe np.int should be replaced by int as done everywhere else in the process. I managed to solve it by downgrading the version of numpy and xarray I use to 1.23.5 and 2022.3.0 but I am not sure if this is what fixed the problem. I hope this helps. Jean