Planet Sirius B a has temperature -273 C

[irigi]

Planet Sirius B a has temperature -273 C, while others further from the star have higher temperatures. I would expect temperature to drop with distance from the star (but of course, presence of the atmosphere can play role too.) But absolute zero temperature is always suspicious number. Is this bug or feature?

[Brianetta]

It might be a bug, or it might just be that our model gives it that temperature. Sirius B is a cold star, so Sirius B a wouldn't get much in the way of heat from it. If the temperature is low enough, it might be rounded down to zero.

[irigi]

It seems to be bug indeed. The planet has greenhouse variable (giving amount of greenhouse effect in range 0-1) bigger than one, 1.57. This causes temperature to be square root of square root of negative number, but for some reason isqrt doesn't complain. I will look at it more closely.

[irigi]

The amount-volatiles variable seems to be blamed.

``` fixed amount_volatiles = fixed(2,1)*rand.Fixed(); if (rand.Int32(3)) amount_volatiles *= mass; // Irigi XXX: why?? // total atmosphere loss if (rand.Fixed() > mass) amount_volatiles = fixed(0); //printf("Amount volatiles: %f\n", amount_volatiles.ToFloat()); // fudge how much of the volatiles are in which state greenhouse = fixed(0); albedo = fixed(0); // CO2 sublimation if (averageTemp > 195) greenhouse += amount_volatiles * fixed(1,3); else albedo += fixed(2,6); // H2O liquid if (averageTemp > 273) greenhouse += amount_volatiles * fixed(1,5); else albedo += fixed(3,6); // H2O boils if (averageTemp > 373) greenhouse += amount_volatiles * fixed(1,3);

I do not understand the second line: Why is amount_volatiles multiplied by planet mass only with certain probability? If greenhouse is in range 0-1, then amount_volatiles should be as well, but then it makes no sense to multiply it by mass..

Btw. the formula for temperature is something like:

T = sqrt(sqrt(power_input/(1-albedo)/(1-greenhouse)))

[Ae-2222]

BTW, I fixed this bug in my temperature fix/system generation branch:) There's a lengthy set of sysgen tweaks as fixing the overflows reduced/eliminated cooler planets.

Don't worry about temp bugs too much:)

The relevant section from my branch:

        fixed amount_volatiles = fixed(2,1)*rand.Fixed(); // this can result in greenhouse > 1 unless clamped later
        if (rand.Int32(3)) amount_volatiles *= mass;
        // total atmosphere loss
        if (rand.Fixed() > mass) amount_volatiles = fixed(0);

        // clamp volatiles so is not greenhouse > 1
        if (amount_volatiles > fixed(1130, 1000)) amount_volatiles = fixed(1130,1000);

        //printf("Amount volatiles: %f\n", amount_volatiles.ToFloat());
        // fudge how much of the volatiles are in which state

        // greenhouse and albedo must be 0 to 1
        // values >= 1 will cause exceptions in temp calcs (div0, sqrt(neg))
        greenhouse = fixed(0);
        albedo = fixed(0);
        // CO2 sublimation

As for the second line Tomm seems to want to increase volatiles for some of the larger terrestrial planets, probably just to tweak things.

[Ae-2222]

Opps you posted while I was typing:)

[Ae-2222]

Glancing through #1692 superficially, Edit: very late at night here, I did the same thing, and will have to reconsider it:) Edit2: (Issue:The range of amount_volatiles is affected. This affects the terrain generation as it affects the assumed range of various sbody properties, and probably the distribution of terrains, as well as anything further down in sysgen/atmospheres that uses these values(m_volatileLiquid,m_volatileIces) - this includes atmos density(=m_volatileGas) which is proportional to amount_volatiles.) Preferably a different clamped variable should just be used for the bits that affect temps to isolate the effects as much as possible.

I like the look of the multi-stage greenhouse thing, which is a new feature.

I don't have the time to consider it in detail, but I will when I get time within the next day or two.

[irigi]

Thanks.. I haven't considered that. I'll think what can be done about not-changing the amount_volatiles. Your solution seems to be better in this aspect - the clamping is enough to solve the bug.

[irigi]

I seems your correction is better. I removed mine not to create a conflict and I kept there the multistaged greenhouse.

[Ae-2222]

Pretty similar, as I used a clamp too..this was a while ago, and then forgot about it:) It meant I had a fresher pair of eyes when I looked at the issue.

Since greenhouse does not affect anything other than temperature, I changed the code to use a different restricted variable to calculate greenhouse. The main issue is the range of other properties being changed and certain code paths in the terrain code potentially never being taken. That's avoided now:)

[irigi]

As for the second line Tomm seems to want to increase volatiles for some of the larger terrestrial planets, probably just to tweak things.

I've been thinking about a meaning of that line and I think that the main reason is that smaller planets exhibit partial atmosphere loss doe to their small mass. If you will be correcting this "imaginary temperature" issue, maybe put it in a comment, if you agree.

[irigi]

@Ae-2222

Now I got yet another idea how we could clamp it "physically". What do you think about this?

if(greenhouse > 0.7f) { // never reach 1, but 1/(1-greenhouse) still grows
    greenhouse *= greenhouse;
    greenhouse *= greenhouse;
    greenhouse = greenhouse / (greenhouse + fixed(32,311));
}

Now if I plot 1/(1-greenhouse) -- the factor used to multiply the temperature, we get

What do you think?

[Ae-2222]

Yep, clamping the dynamic range above 0.7 works..in this case it only goes over slightly though so not sure it's worth the trouble. I just restricted the range by mapping amount volatiles which has a range of 0-2 to 0-1.130.This causes greenhouse to be 0 to a bit less than 1. This was the 'restricted' amount_volatiles variable which I used just for the calculation of greenhouse.

[irigi]

I just restricted the range by mapping amount volatiles which has a range of 0-2 to 0-1.130.This causes greenhouse to be 0 to a bit less than 1.

Unless I'm wrong, amount_volatiles directly translates into m_atmosDensity. If you clamp it, you will never get planet like Venus, with atmospheric density 53. Planets like Venus are, however, probably nothing extraordinary, so it might make sense to increase amount_volatiles significantly and make it more random. Planet like Earth can have subtle atmosphere of amount volatiles = 1, up to ~60, small planets like Mercur should mostly loose their atmospheres completely.

If we want to increase the range of amount volatiles, greenhouse should not go crazy (i.e. for example my correction above could be used.)

Such change would, of course, change the generated universe, so maybe it should be made together with other changes not to change it with every version.

Edit: That greenhouse correction should be tuned to give correct temperature for Venus-like planets.

[irigi]

And if we allow planets with amount volatiles ~60, the gas density should not be one of conditions for life: presence of life causes the atmosphere goes thinner (closer to 1), not vice versa. Something like:

} else if (mass > fixed(1, 15000)) {
    type = SystemBody::TYPE_PLANET_TERRESTRIAL;

    // initial gasses
    fixed amount_volatiles = fixed(80,1)*rand.Fixed();
    // smaller planets lose their atmospheres _quickly_
    if (rand.Int32(3)) amount_volatiles *= Clamp(mass*mass, 0.0, 1.5);
    // total atmosphere loss
    if (rand.Fixed() > mass) amount_volatiles = fixed(0);

    averageTemp = CalcSurfaceTemp(star, averageDistToStar, amount_volatiles);

    // try for life
    int minTemp = CalcSurfaceTemp(star, maxDistToStar, 1.0);
    int maxTemp = CalcSurfaceTemp(star, minDistToStar, 1.0);
    if ((star->type != TYPE_BROWN_DWARF) &&
        (star->type != TYPE_WHITE_DWARF) &&
        (star->type != TYPE_STAR_O) &&
        (minTemp > CELSIUS-10) && (minTemp < CELSIUS+90) &&
        (maxTemp > CELSIUS-10) && (maxTemp < CELSIUS+90) &&
        amountLiquid(1.0, minTemp)) {
        m_life = rand.Fixed();
        amount_volaties = RANDOM AROUND 1
        averageTemp = CalcSurfaceTemp(star, averageDistToStar, amount_volaties)
    } 

    m_volatileGas = amountGas(amount_volatiles, averageTemp)
    m_volatileLiquid = amountLiquid(amount_volatiles, averageTemp)
    m_volatileIces = amountIces(amount_volatiles, averageTemp)

And the code

    // fudge how much of the volatiles are in which state
    greenhouse = fixed(0);
    albedo = fixed(0);
    // CO2 sublimation
    if (averageTemp > 195) greenhouse += amount_volatiles * fixed(1,3);
    else albedo += fixed(2,6);
    // H2O liquid
    if (averageTemp > 273) greenhouse += amount_volatiles * fixed(1,5);
    else albedo += fixed(3,6);
    // H2O boils
    if (averageTemp > 373) greenhouse += amount_volatiles * fixed(1,3);

    if(greenhouse > 0.7f) { // never reach 1, but 1/(1-greenhouse) still grows
        greenhouse *= greenhouse;
        greenhouse *= greenhouse;
        greenhouse = greenhouse / (greenhouse + PROPER_CONSTANT);
    }

could go to CalcSurfaceTemp(star, averageDistToStar, amount_volatiles) - greenhouse and albedo variables are anyway not used anywhere else and can be local variables.

Calculation of gas/liquid/solid proportion should probably have functions of their own:

fixed amountGas(amount_volatiles, averageTemp) {
    return averageTemp / (fixed(100,1) + averageTemp) * amount_volatiles;
}
fixed amountLiquid(amount_volatiles, averageTemp) {
    return (amount_volatiles-amountGas(..)) * (averageTemp / (fixed(50,1) + averageTemp));
}
fixed amountIces(amount_volatiles, averageTemp) {
    return amount_volatiles-amountGas(..)-amountLiquid(..);
}

Sorry for writing code in here like this instead of making pull request for it, but since we are three people editing the same file, I'll rather try to write my ideas for discussion first not to create too many merge conflicts.

[Ae-2222]

Unless I'm wrong, amount_volatiles directly translates into m_atmosDensity. If you clamp it, you will never get planet like Venus, with atmospheric density 53.

I created a separate variable and clamped that, which I then fed into the greenhouse bit:) The rest of the code received the normal amount volatiles variable.

// use reduced range of volatiles so greenhouse < 1
fixed volatiles_proportion = amount_volatiles/fixed(1300,2000);

---

greenhouse and albedo variables are anyway not used anywhere else and can be local variables.

Albedo has a physical meaning (bond albedo) and I've exposed it as well as add automatic temperature calculation in custom systems if the user does not specify.

---

And if we allow planets with amount volatiles ~60, the gas density should not be one of conditions for life: presence of life causes the atmosphere goes thinner (closer to 1), not vice versa.

I think Tomm's reasoning might have been that eventually there might be various conditions that prevent necessary gas / liquid.. such as losing atmosphere due to there being a strong solar wind and too low a gravity well etc.

It's certainly possible to check if a planet is capable of supporting life and then adjust things. Probably this will make balancing the distribution of habitable worlds easier when factions/economies etc. are more developed.

---

Sorry for writing code in here like this instead of making pull request for it

Oh, it's fine:) As long as the relevant people get to see it.

[irigi]

I created a separate variable and clamped that, which I then fed into the greenhouse bit:) The rest of the code received the normal amount volatiles variable.

This is fine, but amount_volatiles still ranges between 0 and two, while in order to produce Venus-like planets, it should be something like 0 to 80.

I wonder, would you please put your fixing branch into github? I was looking for it but couldn't find it. I have several ideas some of which are probably already solved by you, so I was thinking I would send a pull request directly into your branch and you would judge if the correction makes sense or should be done differently.

Thanks!

[Ae-2222]

This is fine, but amount_volatiles still ranges between 0 and two, while in order to produce Venus-like planets, it should be something like 0 to 80.

Oh, I see, yes. Sysgen is very much in a first rough attempt state. Almost everything needs research and detailing.

---

My branch includes the bug fix and the rest is arranging the planets in the system, balancing the distribution of systems of different sizes and testing/integrating the new softfloat library. It's full of multiple versions of temperature and other functions/test code etc. and not really in a state to develop other things. The areas where new functionality has been introduced are PickPlanetType and MakePlanetsAround which are paste binned so you can see the shape of it. There's a lot of tweaking to be done in MakePlanetsAround and it might get re-written a few times depending on what elements are needed for balance.

[irigi]

OK, no problem, I will then probably write my ideas somewhere (to mail conference or issues with feature request) and attend to other features for now. There is no rush.

[Bodasey]

still something to do with that? Just to mention that also actual in-game-data differ from e.g. wikipedia: https://en.wikipedia.org/wiki/Sirius, but i am in doubt if they are good for the gameplay; such systems usually have ejected/burnt/dissolved all the planets once had been formed. No real exoplanet has been confirmed for this system yet.