Title *

SummaryCode sketches and ideas for modeling watersheds

Description *Data Model Requirements¶ 1. a data model that allows for the transport of schemas as well as data 2. support for geometry and geometric representation of objects and space 3. support for describing the relationships between things 4. support for arbitrary metadata 5. support for provenance; so that authors of content can be used to filter spam 6. support for filtering content by an extended trust network Objects¶ 1. prototypes 2. uid 3. permissions 4. schemas 1. agents 2. agent api to query, split join? 1. geometry 2. points in 3 space 3. lines 4. polygons 5. boxes 6. circles 7. polyhedra 8. spheres 9. potentially visible sets? { may be helpful as an optimization } 1. appearance 2. color 3. texture 4. illumination 1. constraints 2. groupings 3. collision hulls and planes 4. friction 5. static computed voxel volumes with extended metadata { pollution, light... } 6. classic rigid body constraints; joint limits and the like 7. parametric relationships { a tree of height x shall have branches all over } 8. rule based scoring constraints { trees fail to grow under water } 9. algorithmic linear constraints { certain pollution levels affect salmon } Primitive Types¶ class Vec3 { float x,y,z; } class Geometry { private Array vertices; private Array polyhedra; } class Volume { public Vec3 position; public Vec3 size; public Vec3 min; public Vec3 max; double radius; } interface Agent { public void update(); public void version(); } class Physical { public Geometry geometry; public Volume volume; public Agent agent; } Prototypes¶ class Environment extends Physical { public void update() { // defining things like sunlight, evaporation, rain, // diurnal cycle, tide cycle, seasonal cycles, interglacial cycles // the burden of evalution should probably be on the agents rather than this. // defines time; iterating forward by desired time // defines diurnal cycle // defines solar radiation // defines seasonal cycles // defines tide cycles // defines interglacial cycles // probably has public accessor methods } public float solar_radiation { } public float } class Ground extends Physical { public void update() { // probably defined as a digital elevation model // this would have to be a simplified model; perhaps not doing erosion? } } class River extends Physical { public void update_environment() { // a discovery tool handles this... // Checks it for solar information to do evaporation, rainfall, freezing // Binds to all ground objects; uses slope and the the like // sets a pile of its own state variables // this would have to query the local environment for factors such as // wind velocity, sunlight and sunlight direction, rain, slope, rockyness // and the like in order to compute changes to its temperature and // oxygenation levels and the like. // // one challenge with a river is that it may need to be simulated as a // cellular automata in order to do stream flow and the like in detail. // a coarse model may do for now. // // ultimately it has to interact with the ground to do volumetric erosion. } } class river_soil_handler { // i could have handlers that handle the interaction between kinds of things // in this way a river could be a fairly simple thing // however are there ways that things intersect that is not just pairwise? // a river interacts with solar influences that also depend on wind... // if i made the solar module sensitive to weather then evaporation off the river might 'just work'? } class water_solar { // visit all points on surface of water <- this can be optimized away; so that the pure mathematical relation below remains // get mean solar at this point // evaporation at this point is a function of solar at this point // surface_temperature at this point is a function of solar at this point // } class water { // issues // water could fully evaporate... and new bodies of water can form... // also geography could change leading to new water pools... // so... a cellular model could add up water over it and try dissipate it; or fail to and thus allow build up. // same is true for tree cover; it can expand or contract or the like; or be holed... // so ... // are polyhedra just a form of cellular automata? // i want some way to coarsely aggregate and consolidate and define phenomena... // how can i say that something basically covers a swatch? can i indicate its granular composition over that swatch? // should i have polyhedra that also have a bitmap coverage or some kind of density gradient? // in which case water or plantcover etc is global? // and solar impact computes angle of sun at a given angle? modulated by cover at an angle? // would solar have a bitmap too? for its interaction at that point? // and if so are we dealing with a large number of overlapping bitmaps? } collection water_group { // grouping would be very convenient water_solar { evaporation { reduce water as a function of temperature } condensation { add water as a function of temperature } } water_soil { erosion { erode soil as a function of water volume and velocity at this point creating soil suspensions } deposition { deposit soil as a function of suspension } } water_movement { carry water and soil suspensions forward at volume and velocity note that we may have to evaluate the entire system from top left to bottom right otherwise we may not be effectively computing overlapping water volumes etc maybe we need a sparse matrix approach too and maybe the polyhedral model is only good to setup initial conditions so i guess we print into a cellular automata but there is a question of scoring these things; how can we report a river has dried; not moved? and as well, how about simulation of complex oil systems; like extraction, refining, usage and impacts? do we also have some point objects or polyhedral objects co-existing in this landscape? } } An example Scene¶ Geometry environment_geometry { name { environment_geometry } vertices { 0,0,0, 100,0,0, 100,100,0, 0,100,0 } polyhedra { 0,1,2, 2,3,0 } } Environment { Geometry { environment_geometry } } Geometry ground_geometry { vertices { 0,0,0, 100,0,0, 100,100,0, 0,100,0 } polyhedra { 0,1,2, 2,3,0 } } Ground { Geometry { ground_geometry } } Geometry river_geometry { vertices { 0,0,0, 100,0,0, 100,100,0, 0,100,0 } polyhedra { 0,1,2, 2,3,0 } } River { Geometry { river_geometry } } The Simulator Engine¶ Note it may be possible to avoid using a cellular automata in favor of objects. All intersecting volumes are defined by relationships and we can visit each relationship once per time slice. The relationships can apply wind as a whole to say river parts or the like. On the other hand it may be harder to grow volumes past their initial bounds and some kind of cellular automata model may be easier. One can imagine a simulation core like so: interface solar { getset_temperature(point) getset_wind(point) getset_humidity(point) } class water { getset_behavior_at_point() } class relation_water_solar { evaluate(x,y,time) { cell = cells[x][y] cell.evaporation = cell.temperature * cell.wind * time; cell.water = cell.water - cell.evaporation; cell.water = some function of cell.slope; cell.aquifer = some function of water; cell.erosion ... cell.temperature = ... cell.wind = can affect nearby cells too... } } main() { for all points { for all relationships { we arrange all of the cells by type in an n-deep array and then all the algorithms visit all the cells } } }