GeodynamicWorldBuilder / WorldBuilder

World Builder: An initial conditions generator for geodynamic modeling
GNU Lesser General Public License v2.1
23 stars 28 forks source link

Adding topography as an output #132

Open MFraters opened 5 years ago

MFraters commented 5 years ago

Having a possibility in the GWB to define and output topography would be useful for nummerical models and for other applications (see for example issue #117).

There are in my mind several options this feature could be integrated in the world builder, but I am not sure yet which is the best.

  1. The simplest option is that users define what the topography height on every location on the surface is, completely independent from everything else. This would be easy to implement, but it would become unclear what it actually means to have topography from the GWB perspective and would therefore have to be left up to the software which uses the GWB. I do not think this is an ideal situation.
  2. An other simple option uses the same principle as option 1, but will actively change the 0 depth to the surface of the topography. This would still be relatively easy to implement and would have the benefit of having a strong coupling between the input of the topography and the rest of the model. The downside is that this may lead to unintended topography further down in the model, such as at the 660 phase transition. This could possibly be mitigated by making sure that only features which are actually at the surface are affected by the topography, but even then you would create a thinner lithosphere where there is a mountain, instead of a thicker lithosphere which should be there.
  3. Allowing the features themselves to have a variable thickness, where the topography output reconstructs the elevation above the reference 0 depth. The advantage of this approach is that it can be used/implemented more broadly to allow for variability on the top and bottom of features (for margins for example, see issue #126) and maybe even inside features (variable thickness of layers). The downside is that the lookup will probably be more computationally expensive and be harder to program. An other problem is to find a way to parameterize this in a way which: 3.1. doesn't clutter up input files for users which do not want to use it; 3.2. is easy to use for users which do want to use (parts) of this 3.3 is generic enough to do create complicated and realistic topography, bathymetry and layering inside the models.

Currently I think in the long term it the third options is the one to go for, but it will require some more thought and development to make it into something workable.

MFraters commented 5 years ago

I forgot to mention issue #94 here, which also wants to create a passive margin.

MFraters commented 3 years ago

I think the right way to go is to begin with variable min and max depths. Currently only fixed values are allowed. Instead of that single value, you would instead define a array of objects: [{100e3}] to produce the same results. This would internally expand to [{100e3,[[0,0]]}]. The first number is the depth and the second double array is a list of points with that depth. A more complete example would be: [{100e3,[[10,20],[20,40],[80,60]]},{20e3,[[20,60],[10,30]]}]

The idea of this would be that the depth would be interpolated over multiple points. If there is only one point, that will be use everywhere. If there are multiple, the value (the first number) will be interpolated based on the distance to all the defined points. I currently think this is going to be the cleanest way to implement this. This will be a significant breaking change for the input file and will most likely break all input files. This implementation will however be minimal overhead if you are not interested in the feature, but allow for a huge amount of flexibility in thickness (top and bottom) of plates and for examples layers in plates.

Making a passive margin or a thickened crust would be very easy with this approach. Because there is no connectivity, it may become expensive if a large amount of points are involved. If this would become an issue, a mesh could be generated during initialization, which would make looking up the values a lot faster.

MFraters commented 9 months ago

Given that variable thickness has been implemented in #366, what remains to be done is the following:

  1. create an output property which returns the topography.
  2. compute the topography at a certain location by finding the feature with is on top of all the other ones (depth wise) and then find the depth of the top layer in that location.
  3. This would probably need on option per feature and/or layer to exclude it from the topography computation. This is because you would not want a sticky air to be counted as topography.