restructure planetary builder

[sannecottaar]

1. Many of the computations in planetary builder loop over the layers (for gravity, pressure, mass, moment of inertia). The computations for the separate layers could be within the layer class (including a value for the starting value of the integration). This would mean a layer can also be used separately, e.g. currently example_geodynamic_adiabat.py (which produces the input to aspect) is using a layer-type-thing (the mantle), but it uses its own gravity-calculating-function (with a starting gravity value). I think it would be nicer to generalize this more, so layer is an independently usable thing.

2. Currently layer can handle constant or linear temperature. An adiabat would be nice, defined with a T0 at the top of the layer (or T_pot at 0 GPa). Within planet, T0 could be computed from the temperature at the bottom of the previous layer, and potentially a predefined jump across the layer boundary (or the thermal boundary layers). Another potential model would be a geothermal read in from a script that is then interpolated to the depths at which layer is defined.

3. Currently temperature is implemented as a separate layer class. I don't know why we don't have functions within layer that would return or set the temperature of a layer. This would make it easier for people to implement their own function for the temperature of a layer, and potentially include thermal boundary layers or an internal heat source.

[tjhei]

We might be better of discussing over hangout, but:

1. I made the choice to not allow the use of layers independently on purpose and make them "dumb" objects that just contain data. I agree that it is unfortunate that example_geodynamic_adiabat.py basically copies the logic from planet.py. I am not sure if putting all the logic into layer is the best way to go. We could also let the example use planet.py or not?

2. You can define your own kind of layer by deriving from LayerBase and implementing temperature(). One problem is that the layer currently doesn't know anything about other layers.

3. I don't understand. The different temperature are currently implemented as functions inside layer. See 2.

[sannecottaar]

1. Dumb objects that just contain data covers 'the geophysical profile' that we discussed at the end of the December hackathon. Example_geodynamic_adiabat.py would be using planet.py in my scheme. More specifically planet.layer without defining the core though. As Bob has put it, it allows one to work on partial planets.

2./3. I guess this is more of design issue. I might be a flag-leaning person (e.g. in SolidSolution we set the type with a flag). Not too hung up on this. It would be nice if there was an option to input a temperature profile, which is then interpolated to the points in the layer, this would then allow people to hack their own geotherm. Or people should be able to add the non-adiabatic part like this.

One other thing that Bob and I discussed last night is that layers could have set_state like a rock to change the profile. Once a layer is used in a self-consistent planet it would be 'locked' (again I would use a flag for this).

I could code up what we had in mind, but also happy to discuss more on hangouts later (I will be offline while on the train back to Cambridge though).

[tjhei]

2./3. I guess this is more of design issue. I might be a flag-leaning person (e.g. in SolidSolution we set the type with a flag). Not too hung up on this. It would be nice if there was an option to input a temperature profile, which is then interpolated to the points in the layer, this would then allow people to hack their own geotherm. Or people should be able to add the non-adiabatic part like this.

I don't quite understand. One the one hand you don't want separate types/functions but a "flag", which restricts what a user can do. On the other hand you want the user to specify any kind of function as the temperature, which is what I have implemented:

class myFunkySinLayer:
    def __init__(...):
        # ...

    def temperature(self, radius):
        return sin(radius)

[sannecottaar]

Okay, fine. Would be nice to use some geotherm functions in some way though... could be with many separate layers.

On Wed, Mar 29, 2017 at 6:27 PM, Timo Heister notifications@github.com wrote:

2./3. I guess this is more of design issue. I might be a flag-leaning person (e.g. in SolidSolution we set the type with a flag). Not too hung up on this. It would be nice if there was an option to input a temperature profile, which is then interpolated to the points in the layer, this would then allow people to hack their own geotherm. Or people should be able to add the non-adiabatic part like this.

I don't quite understand. One the one hand you don't want separate types/functions but a "flag", which restricts what a user can do. On the other hand you want the user to specify any kind of function as the temperature, which is what I have implemented:

class myFunkySinLayer: def init(...):

...

def temperature(self, radius):
    return sin(radius)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/geodynamics/burnman/issues/285#issuecomment-290162650, or mute the thread https://github.com/notifications/unsubscribe-auth/AGJs2osILyIzFekl4fOJMC9CpbIR3tsUks5rqpSegaJpZM4Mr0OP .

[tjhei]

Agreed. In general, a layer is a very generic thing that one might want to use to represent depth depend data and then:

• use as a layer in a planet
• compute material properties at
• attach additional data columns
• attach funtions that represent properties
• import/export
• visualize

[CaymanUnterborn]

I agree with Sanne, that having a layer create its own temperature profile would be quite useful. Particularly self-consistent adiabats. For stitching layers to make a planet wouldn't a layer just need to know its temperature at its top, and output its temperature at the bottom (for the next layer)?

[tjhei]

I agree with Sanne, that having a layer create its own temperature profile would be quite useful

As I said, this is already supported by the current design.

For stitching layers to make a planet wouldn't a layer just need to know its temperature at its top, and output its temperature at the bottom (for the next layer)?

Yes, which is not possible in an easy way right now and it makes layer be somehow not independent: they either need to know about the layer above or some class like planet needs to communicate this information.

[bobmyhill]

Resolved in #313