Property:Extended model description
This is a property of type Text.
"meanderpy" is a Python module that implements a simple numerical model of meandering, the one described by Howard & Knutson in their 1984 paper "Sufficient Conditions for River Meandering: A Simulation Approach" (https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/WR020i011p01659). This is a kinematic model that is based on computing migration rate as the weighted sum of upstream curvatures; flow velocity does not enter the equation. Curvature is transformed into a 'nominal migration rate' through multiplication with a migration rate (or erodibility) constant; in the Howard & Knutson (1984) paper this is a nonlinear relationship based on field observations that suggested a complex link between curvature and migration rate. In the 'meanderpy' module we use a simple linear relationship between the nominal migration rate and curvature, as recent work using time-lapse satellite imagery suggests that high curvatures result in high migration rates (Sylvester et al., 2019). +
--- WHEN USING THIS CODE FOR YOUR RESEARCH, PLEASE CITE: ---<br> Neely, A., Bookhagen B., Burbank, D.W. (2017): An automated knickzone selection algorithm (KZ-Picker) to analyze transient landscapes: Calibration and validation, JGR Earth Surface, doi:10.1002/2017JF004250 available at: http://onlinelibrary.wiley.com/doi/10.1002/2017JF004250/full <br> --- The Matlab-based scripts extract several topometrics at the catchment scale based on log area/log slope and chi plots. Topometrics include: steepness index, theta, steepness index with adjusted theta for each drainage basin, specific stream power, curvature, local relief, and others. Detrended and normalized chi-squared plots are used to identify river knickpoints. Output is written as GeoTIFF files, shapefiles, and CSV files. Additional information, examples, and tutorials are provided on the github page. +
2D marsh evolution model focused on pond dynamics. Channels are static features. Tidal transport is not directly simulated. Includes the effect of man-made ditches (i.e., localized subsidence). It has companion website with pre-loaded simulations to be used by end-users. +
3D cellular model simulating delta evolution in coarse grained river dominated systems (e.g. a gravel fan delta). +
A 2D or 3D model of carbonate sediment production and transport that generates high-frequency platform top auto and allocycles as well as various aspects of large scale platform geomtry +
A Landlab implementation of the Barnes et al. (2014) lake filling & lake routing algorithms, lightly modified and adapted for Landlab by DEJH. This component is designed as a direct replacement for the LakeMapper as existing pre-Aug 2018, and provides a suite of properties to access information about the lakes created each time it is run. Only significant difference is the way the lakes are coded: this component uses the (unique) ID of the outlet node, whereas DepressionFinderAndRouter uses one of the pit node IDs. Note also this component does not offer the lake_codes or display_depression_map options, for essentially this reason. Use lake_map instead for both. It also uses a much more Landlabbian run_one_step() method as its driver, superceding DepressionFinderAndRouter’s map_depressions(). A variety of options is provided. Flow routing is route-to-one in this implementation, but can be either D4 (“steepest”) or D8 on a raster. The surface can be filled to either flat or a very slight downward incline, such that subsequent flow routing will run over the lake surface. This incline is applied at machine precision to minimize the chances of creating false outlets by overfill, and note that the gradient as calculated on such surfaces may still appear to be zero. The filling can either be performed in place, or on a new (water) surface distinct from the original (rock) surface. For efficiency, data structures describing the lakes and their properties are only created, and existing flow direction and flow accumulation fields modified, if those flags are set at instantiation +
A Lithology is a three dimensional representation of material operated on by Landlab components. Material can be removed through erosion or added to through deposition. Rock types can have multiple attributes (e.g. age, erodibility or other parameter values, etc). +
A Python tool for extracting and/or plotting data from the NEXRAD (WSR-88D) Doppler weather radar network operated by the US National Weather Service. This can be used for inputs to models that require a meteorologic component. +
A ``ZoneTaxon`` is composed of members of a lower taxonomic level that each exists within a ``Zone`` object. Taxonomic rank is not considered by this class despite the use of the term, 'speciation', which is used herein to generally describe creation of a child taxon object. All zones of the taxon can be obtained with the attribute, ``zones`` that are the objects that manage the geographic aspect of taxon member populations. The total geographic extent of all populations is depicted by the ``range_mask`` attribute. The zones of a ZoneTaxon instance are created and updated using a ``ZoneController``. At model time steps, the connectivity of zones over time is obtained using attributes of the ``Zone`` object. The evolution of this taxon type is carried out in two stages during a model time step. In the first stage, the zones of the taxon are updated as the result of zone connectivity between the prior and current step in the method, ``_update_zones``. This method is the primary implementation of taxon dispersal and it is called in a stage prior to other evolutionary processes so that all taxa are positioned in their landscape locations prior to the other processes. In the second stage, processes are carried out in methods that are readily expanded or overridden when needed. The primary methods of second stage macroevolution are ``_evaluate_dispersal``, ``_evaluate_speciation``, and ``_evaluate_extinction``. The evaluate dispersal method is intended to modify dispersal conducted in the first stage and it has no effect unless it is expanded or overridden to have an effect. Processes other than those listed above can be called by expanding or overridding the ``_evolve`` method. The taxon is allopatric when it is associated with/exists within multiple zones (signifying multiple member populations). A timer is started when a taxon becomes allopatric. Allopatric speciation occurs once the timer reaches or exceeds the ``time_to_allopatric_speciation`` initialization parameter. If the initialization parameter, ``persists_post_speciation`` is True (default), a child taxon is created in each zone except one zone (the largest by area) that becomes the sole zone of the taxon. If ``persists_post_speciation`` is set to False, a child taxon is created in each and every zone, and the parent no longer occupies any zones, and therefore the parent taxon is no longer extant. Extinction occurs when the taxon is no longer associated with any zones. This occurs when zones in the prior time step do not overlap zones in the current time step, signifying the geographic range of the taxon is no more. A taxon can become no longer extant also when the taxon speciates and ``persists_post_speciation`` is False signifying that the parent taxon has evolved into multiple taxon distinct from the original taxon.
A cellular automaton model for simulating the development of aeolian dune landscapes under the influence of vegetation and biota (parabolic dunes, blowouts, foredunes, nebkha dunes). +
A component to generate a sequence of spatially resolved storms over a grid, following a lightly modified version (see below) of the stochastic methods of Singer & Michaelides, Env Res Lett 12, 104011, 2017, & Singer et al., Geosci. Model Dev., accepted, 10.5194/gmd-2018-86. The method is heavily stochastic, and at the present time is intimately calibrated against the conditions at Walnut Gulch, described in those papers. In particular, assumptions around intensity-duration calibration and orographic rainfall are "burned in" for now, and are not accessible to the user. The various probability distributions supplied to the various run methods default to WG values, but are easily modified. This calibration reflects a US desert southwest "monsoonal" climate, and the component distinguishes (optionally) between two seasons, "monsoonal" and "winter". The intensity-duration relationship is shared between the seasons, and so may prove useful in a variety of storm-dominated contexts. The default is to disable the orographic rainfall functionality of the component. However, if orographic_scenario == 'Singer', the component requires a 'topographic__elevation' field to already exist on the grid at the time of instantiation. The component has two ways of simulating a "year". This choice is controlled by the 'limit' parameter of the yield methods. If limit == 'total_rainfall', the component will continue to run until the total rainfall for the season and/or year exceeds a stochastically generated value. This method is directly comparable to the Singer & Michaelides method, but will almost always result in years which are not one calendar year long, unless the input distributions are very carefully recalibrated for each use case. If limit == 'total_time', the component will terminate a season and/or year once the elapsed time exceeds one year. In this case, the total rainfall will not correspond to the stochastically generated total. You can access the actual total for the last season using the property `(median_)total_rainfall_last_season`. Note that this component cannot simulate the occurrence of more than one storm at the same time. Storms that should be synchronous will instead occur sequentially, with no interstorm time. This limitation means that if enough storms occur in a year that numstorms*mean_storm_duration exceeds one year, the number of simulated storms will saturate. This limitation may be relaxed in the future. The component offers the option to modify the maximum number of storms simulated per year. If you find simulations encountering this limit too often, you may need to raise this limit. Conversely, it could be lowered to reduce memory usage over small grids. However, in increasing the value, beware - the component maintains two limit*nnodes arrays, which will chew through memory if the limit gets too high. The default will happily simulate grids up to around 50 km * 50 km using the default probability distributions.