Bit of 'digging' into the stratigraphy #47
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is not meant to ever be merged, but rather to prompt a discussion about what we should do regarding stratigraphy recording (this grew out of efforts to close #43).
'old' method
The original DeltaRCM stratigraphy process involved initializing a 3D array and populating it over time with sand fraction values using a 2D array
sand_frac
and the vertical locations to be recorded were assigned using another 2D arraytopz
. The stratigraphy array was updated every timestep after sediment routing was completed. This implementation was carried over to relauzon's python DeltaRCM which was the genesis for what is now pyDeltaRCM_WMT.'new' method
I suspect, that when the code was being updated and improved, this initialization of a full 3D array and writing to it every timestep was identified as a real processing bottleneck. Which is why the current method carefully initializes smaller sparse arrays to hold the strata sand content and depth that are only written to and extended at timesteps that are output (intervals of
save_dt
). In this 'new' method, the sand fractions and depth of sand is maintained throughout the simulation, and a 'final' stratigraphy can be back calculated usingstrat_preprocess.py
(added in this PR astools.strata_postprocess
) to cross-cut between the sand fraction arrays and the strata depth arrays to get at a final saved stratigraphy.comparing the two
This jump from the original implementation to the "new" or "sparse" one does save a lot of computational time. But, how do we know if it is accurate? That is why I put together this PR to resurrect the 'old' method and directly compare it to the new one. A direct comparison of the stratigraphy output via these two methods shows us that that are not in-fact identical (image). Fortunately, the strata bits of code are very much independent from the rest of the model, so this inconsistency can be explored in isolation (topography and discharge remain the same).
So this is kinda the status of how the model handles stratigraphy. I am still thinking through what the 'best' path forward needs to be so that we are as confident as we can be in the pyDeltaRCM stratigraphy that is modeled. Suggestions, comments and ideas are appreciated.