Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Adrien Delsalle
    @adriendelsalle
    Hi @benbovy , could you please have a look at fastscape-lem/fastscapelib#62 ? It is a big one, and it's preferable to review and merge it before working on flow routing API. Thanks!
    Benoit Bovy
    @benbovy
    I'm on it! It's a big one indeed :-)
    One thing that I'll try is to refactor the fill_sinks functions in sinks.hpp so that those are grid agnostic.
    Adrien Delsalle
    @adriendelsalle
    oh nice !
    I'm starting to implement the flow_graphe API!
    Benoit Bovy
    @benbovy
    Great!
    Adrien Delsalle
    @adriendelsalle
    @benbovy your thoughts about the flow_graph API in the wiki pages describe dynamic polymorphism, which is helpful when you don't know the type at compile time but at runtime
    do you remember why ? is it related to capability to load a computation from a config file, or from the python side?
    Benoit Bovy
    @benbovy
    I think this might be because both flow_router and sink_resolver subclasses may have constructor parameters given at runtime (e.g., multiple_flow_router has parameters for controlling the amount of water flow that is partitioned among the downslope neighbors).
    We should be able to set those parameters from Python, so I think we need to provide instances of those subclasses when creating an instance of flow_graph.
    Adrien Delsalle
    @adriendelsalle
    ok thanks !
    :+1:
    martinRenou
    @martinRenou
    Hello!
    Benoit Bovy
    @benbovy
    Hi @martinRenou !
    martinRenou
    @martinRenou
    Small preview of what's coming to ipygany in the next release:
    Adrien Delsalle
    @adriendelsalle
    woot! looks great :)
    Benoit Bovy
    @benbovy
    This is super cool!!
    martinRenou
    @martinRenou
    log.png
    Added support for log scales as well
    although changing from linear to log or from log to linear seems to be broken on the shaders
    the simulation (and rendering) is made entirely in OpenGL shaders, on a 1000x1000 grid
    Adrien Delsalle
    @adriendelsalle
    :+1:
    Benoit Bovy
    @benbovy
    I find that very cool indeed! Do you think the simulation and/or the rendering are done in real time? I'd love to see something like that to simulate mountain formation (with some realistic textures representing vegetation levels, snow, etc.)
    martinRenou
    @martinRenou
    I suppose everything is run in realtime yes :) I've asked for the source code, but I might not get a positive response.

    I'd love to see something like that to simulate mountain formation (with some realistic textures representing vegetation levels, snow, etc.)

    That would be super cool indeed

    martinRenou
    @martinRenou
    Given the text on the tweet. I understand they have a heightmap for the sand (each "pixel" of the grid has a given sand height). And they compute the height of each pixel given the wind, the previous state, and the neighborpixels. I wonder how accurate their simulation is. But it looks correct at least :)
    Benoit Bovy
    @benbovy
    Yes it looks realistic, although I'm not expert in sand dune dynamics.
    Regarding the formation of mountains, I've been working with someone (Guillaume Cordonnier) who is developing very fast algorithms and scientifically quasi-accurate for such kind of application (e.g., https://team.inria.fr/imagine/sculpting-mountains-interactive-terrain-modeling-based-on-subsurface-geology/)
    (I don't have a link to an animating landscape, unfortunately)
    martinRenou
    @martinRenou
    :+1:
    It might be possible to implement this in shaders and get a very fast implementation of this :)
    Benoit Bovy
    @benbovy
    That would be amazing!
    I'm thinking right now about a terrain texture component for ipygany :-). Something like described here: http://unitytipsandtricks.blogspot.com/2014/07/terrain-texture-splatting-and-threejs.html. One could pick a few built-in textures (or load custom textures) and with some parameters tweak texture splatting.
    martinRenou
    @martinRenou
    Nice! Yeah, that would be a nice addition.
    Benoit Bovy
    @benbovy
    Coupled with something like a sky dome component...
    martinRenou
    @martinRenou
    :+1: I'll open issues to track thoses ideas
    Benoit Bovy
    @benbovy
    :thumbsup:
    Adrien Delsalle
    @adriendelsalle
    Hi @benbovy fastscape-lem/fastscapelib#68 is ready to merge!
    xlia62
    @xlia62
    Hello @benbovy. et al. A quick question. Is it possible to set up precipitation rate for the fastescape python version? Thank you!
    Benoit Bovy
    @benbovy
    Hi @xlia62, sorry for the late reply here. Yes it is possible, you could replace the DrainageArea process by the FlowAccumulator process (https://fastscape.readthedocs.io/en/latest/_api_generated/fastscape.processes.FlowAccumulator.html#fastscape.processes.FlowAccumulator) in which you can provide a value for runoff (if you assume that all rainfall on the land surface is participating to surface runoff). You can also check the orographic precipitation extension to see how we can reuse those components (https://github.com/fastscape-lem/orographic-precipitation/blob/master/orographic_precipitation/fastscape_ext.py).
    xlia62
    @xlia62
    Thank you @benbovy !
    Robert Moucha
    @rbrtmch
    Hi @benbovy, I was looking at using the stratigraphy tracking of reflectors in FastScape (fortranlib) but I noticed that the reflectors are only uplifted and not horizontally advected in the subroutine run_Strati. So, in the case of active margins in a seafloor spreading scenario, this would cause an error in the reflector location over time. Thoughts? Thanks.
    Benoit Bovy
    @benbovy
    Hi @rbrtmch, I've inspected the Fortran source and I'm not sure what's going on, as I see that the Advect subroutine updates the bedrock elevation b, the Strati subroutine reuses b to update the reflectors, and the FastScape_Execute_Stepsubroutine should call Advect before Strati... I rarely use the Fortran library directly, though. I'm rather using the fastscape Python library which has its own StratigraphicHorizons component.
    Robert Moucha
    @rbrtmch
    @benbovy , from what I see the issue is the same in the python version, the horizons are only corrected for vertical motion. As I understand it, the use of b is only to prevent crossovers resulting from vertical and/or horizontal motion. Horizontal advection in both python and fortran version does not advect the horizons horizontally.
    Benoit Bovy
    @benbovy
    Ah yes I guess you are right @rbrtmch, at least regarding the fastscapelib-fortran (and its Python bindings). All active horizons should be advected (as their elevation corresponds to the elevation of the simulated topographic surface), but this is not the case for inactive horizons, which are indeed only uplifted in the subroutine run_Strati. However, in the fastscape library, unless I'm missing something, the elevation of inactive horizons is updated with the bedrock vertical motion, which should include the vertical effect of advection if the HorizontalAdvection process is included in the model.
    Benoit Bovy
    @benbovy
    Thanks for raising this issue. I don't think many users of fastscapelib-fortran(or fastscape) have run simulations with both advection and stratigraphic horizons, which may explain why we've missed it so far.
    Robert Moucha
    @rbrtmch
    Hi @benbovy I'm trying to install the python package from source (I only need the python module fastscapelib-fortran). I had success on my Mac, but not so on Ubuntu 20.04. An error occurred while building with CMake. The install exits with "ERROR: Failed building wheel for fastscapelib-fortran". There is a lot of information to post on here.
    4 replies