Hydrogen Cooling Systems

[asveron]

Can someone point me to a place where I can learn why people choose to use hydrogen to pump into pipes or fill rooms? Also how do they cool the hydrogen in the first place? My first ice biome is slowing melting and it's only a matter of time before I have to use artificial cooling. I've tried searching around a bit but can't find any tutorials. Thanks!

As layman as possible as I might not understand a short technical sounding answer like because the "because of the thermodynamics of it"... 

[Kasuha]

It has greatest heat capacity of all gases. Since both thermal regulator and wheezewort decrease the temperature of processed gas by certain number of degrees, using hydrogen means most removed heat.

It has also very low condensation point so it's safe at all interesting temperatures.

[asveron]

2 hours ago, Kasuha said:

It has greatest heat capacity of all gases. Since both thermal regulator and wheezewort decrease the temperature of processed gas by certain number of degrees, using hydrogen means most removed heat.

It has also very low condensation point so it's safe at all interesting temperatures.

So meaning that if there's cool hydrogen and another hot gass in the same room, the speed of hydrogen warming up will be less than the speed of the other cooling down?

I've googled heat capacity. " the number of heat units needed to raise the temperature of a body by one degree. " So are "heat units" the actual amount of "heat energy" in an object and temperature is just the amount it gives off?

I've also noticed a few other things like people submerging a lot of cooling pipes into water. Does liquids and gass exchange any heat currently? Or does liquid and gass only exchange heat if there's pipes being submerged into it? I'm curious since I would expect water to cool down simply by sitting in a normal temperature room. I thought it was probably enough just to pump hot water into a bigger pool of water since it would cool down fairly fast (at least in real life) anyways. Then I could just cool the air since that should cool the water as well.

[Drach]

everything exchanges heat with anything close enough to it, gasses, liquids, and your buildings/natural tiles. filling a room with snaking pipes and pumping cooled air, or liquids through said pipe will result in the area around it cooling, and the water warming. the only exception at this point would be Neutronium, void tiles, and vacuums (there is no heat transference in a vacuum) . Abyssalite has an incredibly small heat exchange so itsn't useful for for that, but is great to keep in cold/out heat for whatever you make with it.

[Kasuha]

4 hours ago, asveron said:

I've googled heat capacity. " the number of heat units needed to raise the temperature of a body by one degree. " So are "heat units" the actual amount of "heat energy" in an object and temperature is just the amount it gives off?

Heat is energy, expressed in joules. Temperature is certain energy level of the matter.When two materials are in contact with each other, the hotter one loses energy (in joules) and the other gains the same amount of energy. As a result, they both change temperature but the ratio at which that happens depends on heat capacity of each. Because if thing A has twice the heat capacity of thing B, then change of energy X (joules) on A will have half the impact on temperature than on thing B.

[Trego]

5 hours ago, asveron said:

 

I've googled heat capacity. " the number of heat units needed to raise the temperature of a body by one degree. " So are "heat units" the actual amount of "heat energy" in an object and temperature is just the amount it gives off?

 

Minor correction to kasuha's explanation: Hydrogen has the highest specific heat capacity of any gas in the game, not the highest "heat capacity".  specific heat capacity is heat capacity/mass unit.  otherwise all good, but the mass term is quite important.

we see how important it is because the code in the game is missing the mass term in a few places as well, which causes some weird and unrealistic behavior in some situations; hopefully will be fixed soon.

[noisycat]

3 hours ago, Trego said:

we see how important it is because the code in the game is missing the mass term in a few places as well

Any example? I can check it myself in code, just point me to right place

[Kasuha]

43 minutes ago, noisycat said:

Any example? I can check it myself in code, just point me to right place

The place where I believe that happens is heat exchange between pipe and its contents.

[Trego]

On 6/10/2017 at 10:49 AM, rezecib said:

Looking a bit more deeply into the heat transfer code for pipes, I see this function in ConduitTemperatureManager (the code calls pipes Conduits):

  public void SimUpdate(float dt)
  {
    for (int index = 0; index < this.data.Count; ++index)
    {
      ConduitTemperatureManager.Data data1 = this.data[index];
      if ((double) data1.heatCapacity != 0.0)
      {
        StructureTemperatureData data2 = GameComps.StructureTemperatures.GetData(data1.conduitStructureTemperatureHandle);
        float temperature1 = data1.temperature;
        float temperature2 = data2.Temperature;
        float energyFlow = SimUtil.CalculateEnergyFlow(temperature1, data1.thermalConductivity, temperature2, data1.conduitThermalConductivity, this.contentsSurfaceArea * ConduitTemperatureManager.ContentsScaleFactor, 1f);
        float delta_kilojoules = SimUtil.ClampEnergyTransfer(dt, temperature1, data1.heatCapacity, temperature2, data1.conduitHeatCapacity, energyFlow);
        float kilojoules = -delta_kilojoules;
        float num = this.ModifyTemperature(data1.temperature, data1.heatCapacity, data2.Temperature, data1.conduitHeatCapacity, ref kilojoules);
        SimUtil.CheckValidValue(num);
        data1.temperature = num;
        this.data[index] = data1;
        if ((double) num < (double) data1.lowStateTransitionTemperature)
          data2.primaryElement.Trigger(-700727624, (object) null);
        else if ((double) num > (double) data1.highStateTransitionTemperature)
          data2.primaryElement.Trigger(-1152799878, (object) null);
        data2.ModifyEnergy(delta_kilojoules);
      }
    }
  }

ConntentsScaleFactor is a constant of 50, and it looks like contentsSurfaceArea gets passed into the constructor, which is only used in one place, passing in 1. SimUtil.CalculateEnergyFlow makes sense, it's just using a constant thickness of 1m and then the thermal conductivity and temperatures to correctly calculate how much energy flow would pass between. SimUtil.ClampEnergyTransfer, however, seems to have incorrect math, which may actually be responsible for the liquid cooling bug too (I renamed some of the local variables because they were all "num1" and stuff after decompilation):

    public static float ClampEnergyTransfer(float dt, float source_temp, float source_heat_capacity, float dest_temp, float dest_heat_capacity, float max_temp_watts_transferred)
    {
      float max_temp_joules = (float) ((double) max_temp_watts_transferred * (double) dt / 1000.0);
      SimUtil.CheckValidValue(max_temp_joules);
      float min_temp = Math.Min(source_temp, dest_temp);
      float max_temp = Math.Max(source_temp, dest_temp);
      float source_new_temp = source_temp - max_temp_joules / source_heat_capacity;
      float dest_new_temp = dest_temp + max_temp_joules / dest_heat_capacity;
      SimUtil.CheckValidValue(source_new_temp);
      SimUtil.CheckValidValue(dest_new_temp);
      float num4 = Mathf.Clamp(source_new_temp, min_temp, max_temp);
      float num5 = Mathf.Clamp(dest_new_temp, min_temp, max_temp);
      float num6 = Math.Abs(num4 - source_temp);
      float num7 = Math.Abs(num5 - dest_temp);
      float num8 = Math.Min(num6 * source_heat_capacity, num7 * dest_heat_capacity) * ((double) max_temp_watts_transferred >= 0.0 ? 1f : -1f);
      SimUtil.CheckValidValue(num8);
      return num8;
    }

As you can see it calculates a change in temperature of the source and destination, using the intended transfer of energy and the specific heat capacity... but it does this without accounting for the masses of the source and destination. Then for some reason it's clamping this in various ways, probably because doing it without the masses was super buggy, and clamping it made it somewhat reasonable?

 

5 hours ago, noisycat said:

Any example? I can check it myself in code, just point me to right place

As you can see above, the confusion between specific heat capacity and nonspecific heat capacity appears to possibly be popping up in the code, as well as in this thread.  There are functions in the code which properly define Heat Energy Transfer both in terms of specific heat capacity and nonspecific heat capacity, the problem is that other locations in the code call these functions and pass a specific heat value to a nonspecific heat variable, or vice versa.  I'd guess this is happening in other places in the code as well, but so far the only place it's been posted here is in the conduit code, as above.  It's physicists that are to blame for poor naming conventions here, heat capacity = specific heat capacity * mass.   what else looks like this?...momentum = velocity * mass.  Imagine if we called velocity "specific momentum" but hey energy = momentum * mass, so maybe velocity should be double-specific energy, and momentum single-specific energy, and then we'd still have normal energy.  Energy is already a unintuitive and difficult to understand concept as it is, but with various powers of "specific energy" in every equation, physics would be a real treat.  If I were programming ONI, I wouldn't have any functions in terms of "heat capacity", I would simply write out "specific heat * mass" for every instance of heat capacity, that would reduce errors IMO.  Physicists and engineers catch errors like that by checking units on each side, but on the coding side they're just passing floats so it doesn't get caught.

[rezecib]

TL;DR: Heat transfer code is better than I thought at first. It takes into account mass for heat capacity. However the major crime of pipes is that they don't take into account the density of the gas passing through (and more generally the game's thermal conductivities are way off for gases since they all reach pressures of around 2kg, but their heat capacities are based on STP, which often has MUCH lower pressures).

@Trego Looking back at the code, I see this:

		result.heatCapacity = contents.mass * element.specificHeatCapacity;
		result.conduitHeatCapacity = data.building.Def.MassForTemperatureModification * element2.specificHeatCapacity;

So both fields being used are non-specific heat capacity, so that's why the non-specific ClampEnergyTransfer is used here. I'm guessing this was just a small optimization to make it so that pipes weren't multiplying it for every packet for every tick, instead just multiplying once on creation of the pipe segment and creation of the gas packet. MassForTemperatureModification, however, is defined as 1/5 the normal mass of the building.

With that knowledge in mind, I went through the code flow a little more carefully, using a better decompiler this time which has more usable variable names.

Step-by-step:

			ConduitTemperatureManager.Data value = this.data[i];
			if (value.heatCapacity != 0f)
			{
				StructureTemperatureData data = GameComps.StructureTemperatures.GetData(value.conduitStructureTemperatureHandle);
				float temperature = value.temperature;
				float temperature2 = data.Temperature;
				float max_watts_transferred = SimUtil.CalculateEnergyFlow(temperature, value.thermalConductivity, temperature2, value.conduitThermalConductivity, this.contentsSurfaceArea * ConduitTemperatureManager.ContentsScaleFactor, 1f);
				float num = SimUtil.ClampEnergyTransfer(dt, temperature, value.heatCapacity, temperature2, value.conduitHeatCapacity, max_watts_transferred);
				float num2 = -num;
				float num3 = this.ModifyTemperature(value.temperature, value.heatCapacity, data.Temperature, value.conduitHeatCapacity, ref num2);
				SimUtil.CheckValidValue(num3);
				value.temperature = num3;
				this.data[i] = value;
				if (num3 < value.lowStateTransitionTemperature)
				{
					data.primaryElement.Trigger(-700727624, null);
				}
				else if (num3 > value.highStateTransitionTemperature)
				{
					data.primaryElement.Trigger(-1152799878, null);
				}
				data.ModifyEnergy(num);
			}

temperature is for the contents, temperature2 is for the pipe segment

max_watts_transferred is using a surface area multiplier of 50, and a ContentsScaleFactor of 1, and a thickness of 1. CalculateEnergyFlow uses the minimum of the two thermal conductivities, which in the case of gas pipes will always be the gas. So with Hydrogen, max_watts_transferred will be 8.4 W per degree of temperature delta.

ClampEnergyTransfer then uses the non-specific heat capacities, although these were produced with kg instead of g, so they have the units of kJ/K. Let's look at ClampEnergyTransfer... (even with the better compiler this one is still full of nums, so I renamed them)

		public static float ClampEnergyTransfer(float dt, float source_temp, float source_heat_capacity, float dest_temp, float dest_heat_capacity, float max_watts_transferred)
		{
			float max_kilojoules_transferred = max_watts_transferred * dt / 1000f;
			SimUtil.CheckValidValue(max_kilojoules_transferred);
			float min = Math.Min(source_temp, dest_temp);
			float max = Math.Max(source_temp, dest_temp);
			float source_target_temp = source_temp - max_kilojoules_transferred / source_heat_capacity;
			float dest_target_temp = dest_temp + max_kilojoules_transferred / dest_heat_capacity;
			SimUtil.CheckValidValue(source_target_temp);
			SimUtil.CheckValidValue(dest_target_temp);
			source_target_temp = Mathf.Clamp(source_target_temp, min, max);
			dest_target_temp = Mathf.Clamp(dest_target_temp, min, max);
			float source_temp_delta = Math.Abs(source_target_temp - source_temp);
			float dest_temp_delta = Math.Abs(dest_target_temp - dest_temp);
			float source_kilojoules_delta = source_temp_delta * source_heat_capacity;
			float dest_kilojoules_delta = dest_temp_delta * dest_heat_capacity;
			float transfer_direction = (max_watts_transferred >= 0f) ? 1f : -1f;
			float transfer_kilojoules = Math.Min(source_kilojoules_delta, dest_kilojoules_delta) * transfer_direction;
			SimUtil.CheckValidValue(transfer_kilojoules);
			return transfer_kilojoules;
		}

It first converts the watts into kilojoules that will be transferred on that particular simulation tick. Then it calculates target temperatures for the source and destination using the (non-specific) heat capacities (and the kJ and kg cancel out their factor of 1000 here). Then it clamps to make sure the target temperatures are actually between the min and max temperatures (so they don't overshoot when equalizing). Then it converts into a absolute temperature delta for pipe and contents, converts that to kilojoules, determines the direction of transfer, and finally calculates the kilojoules to transfer (the minimum of the transfer required for each temperature delta), expressed in terms of source (contents) -> target (pipe).

Back in ConduitTemperatureManager, for whatever reason it then flips this kJ transfer to be pipe -> contents, and passes it to ModifyTemperature (heavy renaming and such):

	private float ModifyTemperature(float source_temperature, float source_heat_capacity, float cell_temperature, float cell_heat_capacity, ref float kilojoules)
	{
		if (source_heat_capacity * cell_heat_capacity <= 0f)
		{
			kilojoules = 0f;
			return source_temperature;
		}
		float new_source_temperature = Math.Max(0f, source_temperature + kilojoules / source_heat_capacity);
		if (float.IsInfinity(new_source_temperature) || float.IsNaN(new_source_temperature))
		{
			Output.LogError(new object[]
			{
				"Invalid temperature"
			});
			kilojoules = 0f;
			return source_temperature;
		}
		float new_cell_temperature = Math.Max(0f, cell_temperature - kilojoules / cell_heat_capacity);
		if ((source_temperature - cell_temperature) * (new_source_temperature - new_cell_temperature) < 0f)
		{
			float total_thermal_energy = source_temperature * source_heat_capacity + cell_temperature * cell_heat_capacity;
			float average_temperature = total_thermal_energy / (source_heat_capacity + cell_heat_capacity);
			new_source_temperature = average_temperature;
			kilojoules = (average_temperature - cell_temperature) * cell_heat_capacity;
		}
		return new_source_temperature;
	}

ModifyTemperature then adds the kJ to the contents, and makes sure it doesn't go below absolute zero. Then it subtracts the kJ from the pipe (for some reason it's referring to it as cell here). Finally, it checks if the temperature changes caused them to overshoot (if the deltas between the original temperatures and the new temperatures are not the same sign, then they swapped and that if condition will be negative). In this case, it just takes all the energy of the two, and uses that to calculate a new, fully-equalized temperature.

Going back to ConduitTemperatureManager again, we see that the new content temperature from ModifyTemperature is set into the contents, then it checks for state transitions, and finally it uses the original kJ calculated from ClampEnergyTransfer to ModifyEnergy on the pipe material itself, which I believe respects the adjusted 1/5 thermal mass of the building.

Analysis: For the most part this looks correct, at least in terms of heat capacity. However, I see two potential problems:

1) When checking the temperature equalization case (where the temperatures flip-flop), it only applies the adjusted average temperature to the contents. So the pipe will destroy (if being cooled) or create extra energy (if being heated) because it's not using the adjustment. As for a fix, it seems like it would be more reasonable to pack the special-case equalizing logic into ClampEnergyTransfer instead, which would allow them to remove the extra back-and-forth of temperature to energy in ModifyTemperature. This would probably also make anything else that uses ClampEnergyTransfer more accurate.

2) More importantly, the raw thermal conductivity of the gas is used without any adjustment for pressure. Considering that vacuum has no conductivity, it really should scale with the pressure. A simple gameplay-oriented fix for this would be to use a conductivity of conductivity * massMultiplier, where massMultiplier is something like mass/500g. However, if we want to be reallllly accurate about this...

The thermal conductivity given for hydrogen is for atmospheric pressure, which has a density of about 90 g/m^3. I think cells should be considered to be m^3 (this makes max gas pressure of 1.8kg roughly matches oxygen's density at STP of 1.43 kg/m^3). So instead of using raw thermal conductivities, we should use a specific thermal conductivity. Hydrogen's specific thermal conductivity should be (2.4 J/gK) / (90 g), or 0.027 J/K. When calculating heat transfer, this would then be multiplied by the mass of the gas that's transferring it.

Experiment: I also wanted to do an experiment to make sure I wasn't doing code analysis in a vacuum. So I set up two chambers like this:

The pipes were granite, and initially at 293.15K, and the hydrogen was highly-pressurized in the pump chambers at 100K. One valve was unrestricted, and the other was restricted to 100 g/s. I monitored gas pipe segments as packets entered them and recorded the temperature and compared it to predictions based on the code. The results were pretty close, although the complications of the temperature changing through the initial segment messed things up a little. The results also matched not taking pressure into account with thermal conductivity; although the temperatures of the pipes differed a tiny bit, this was mostly because they were able to warm the smaller packets up faster, reducing the temperature difference and therefore the heat flow.

[asveron]

So water locks only prevent gass leakage but doesn't block temperature?

[Whispershade]

6 hours ago, asveron said:

So water locks only prevent gass leakage but doesn't block temperature?

In terms of things you can construct, only abyssalite tiles really block temperature transfer.  The airlock doors of all varieties are metal and extremely heat conductive. The water in the water lock takes up the temperature as anything else does.

[noisycat]

Wow, I didn't expect such response. Thanks guys, that clears up a lot. I'm going to do some of my own research on the topic when I happen to find some time.

[Sevio]

Well, aside from abyssalite there is one other thing you can use that completely blocks temperature change: A vacuum. If you have an inner hot/cold chamber made of normal tiles, separated by a vacuum from your base, then the only heat transfer can go via the entrance to the chamber. The floor and ceiling of the entrance could be made of abyssalite to minimize that, and a vacuum airlock between the base and the chamber will prevent the doors from leaking heat. Setting that up is no small project so you're better off just using abyssalite for insulated chambers if you can afford it. In either case a vacuum airlock is a good way to minimize heat leaking through the entrance.

[Kasuha]

Thanks for the update. It feels good that I was guessing right about the heat capacity initially, though in the end I decided to trust your original conclusion.

17 hours ago, rezecib said:

1) When checking the temperature equalization case (where the temperatures flip-flop), it only applies the adjusted average temperature to the contents. So the pipe will destroy (if being cooled) or create extra energy (if being heated) because it's not using the adjustment. As for a fix, it seems like it would be more reasonable to pack the special-case equalizing logic into ClampEnergyTransfer instead, which would allow them to remove the extra back-and-forth of temperature to energy in ModifyTemperature. This would probably also make anything else that uses ClampEnergyTransfer more accurate.

ClampEnergyTransfer is wrong as it clamps the transfer on the two masses exchanging their temperatures while it should clamp the transfer on equilibrium temperature. There's even simple and numerically stable closed formula for it that comes out much simpler than the crazy code that's in the routine. I already posted it in the previous discussion of this code.

The fact that actual clamping to equilibrium temperature is made in ModifyTemperature is a performance problem as some calculations are unnecessarily made several times. And the fact that the modified energy transfer is then discarded is major bug. It might be the reason behind the water cooling exploit, too.

17 hours ago, rezecib said:

2) More importantly, the raw thermal conductivity of the gas is used without any adjustment for pressure. Considering that vacuum has no conductivity, it really should scale with the pressure. A simple gameplay-oriented fix for this would be to use a conductivity of conductivity * massMultiplier, where massMultiplier is something like mass/500g. However, if we want to be reallllly accurate about this...

Vacuum has most importantly zero thermal capacity and with such it has "any" temperature, and "any" thermal conductivity - both are with zero thermal capacity irrelevant in all well built formulas for heat exchange. The pressure argument is questionable. The game does not have any meaningful kind of pressure.

The right question here is, why is heat exchange between pipe and its contents so much slower than heat exchange betwen pipe and the same amount of gas spread over the tile. I don't see the answer in the code you posted. In my humble opinion it should be exactly opposite because the pipe can be assumed to be small, and therefore the distance over which thermal conductivity is applied is much smaller between pipe and its contents than between the pipe and ambient gas.

 

[rezecib]

54 minutes ago, Kasuha said:

The game does not have any meaningful kind of pressure.

It doesn't have pressure exactly, but it does have the concept of different masses of gas on a tile. A denser gas should have greater thermal conductivity, as the non-conductivity of vacuum is what makes gases such poor conductors. Conductivity through a gas is largely about effective collisions, which will increase in a denser gas. In the real world, the scaling is basically linear at low pressures, but at higher pressures the other aspects of conductivity become a factor as well.

56 minutes ago, Kasuha said:

The right question here is, why is heat exchange between pipe and its contents so much slower than heat exchange betwen pipe and the same amount of gas spread over the tile. I don't see the answer in the code you posted. In my humble opinion it should be exactly opposite because the pipe can be assumed to be small, and therefore the distance over which thermal conductivity is applied is much smaller between pipe and its contents than between the pipe and ambient gas.

Maybe I just haven't found it yet, but I believe that is handled in Sim (I see what looks like a handoff to it in StructureTemperatureComponents.SimRegister, which also references the reduced thermal mass for structures). I did check for other things that used ClampEnergyTransfer and its sister functions, but didn't see anything promising. Although I can't figure out why there's a difference, the devs could easily tune it by supplying a different thickness or surface area for pipes into CalculateEnergyFlow (currently using an area of 50m^2 and a thickness of 1m). They could even work in the pressure scaling just for pipes by having ContentsScaleFactor simply be the mass of the packet in kg.

[Trego]

1 hour ago, rezecib said:

It doesn't have pressure exactly, but it does have the concept of different masses of gas on a tile. A denser gas should have greater thermal conductivity, as the non-conductivity of vacuum is what makes gases such poor conductors. Conductivity through a gas is largely about effective collisions, which will increase in a denser gas. In the real world, the scaling is basically linear at low pressures, but at higher pressures the other aspects of conductivity become a factor as well.

 

Pressure as modeled in ONI is arguably closer to pressure in this world than thermodynamics in ONI is to thermodynamics in the real world, so I agree that the game does indeed have a meaningful sort of pressure.

Thanks for clearing up the earlier issue with pipes and mass.

[Allekatrase]

Really awesome explanations in this thread, but mostly pointing at specific heat capacity for why hydrogen is chosen when that's only half the answer.  The other half is thermal conductivity.  Hydrogen has the highest thermal conductivity of any of the gases in the game, at least any of the gases that are in gas form at temperatures that are usually relevant.  This means that it transfers heat the fastest so it's better at heating or cooling things.  The two traits together are complimentary.  High thermal conductivity means you can transfer energy faster and therefore change the temperature in the target faster.  High specific heat means your hydrogen has to transfer more energy before it changes temperature and therefore keeps the difference in temperature higher for longer, and the rate of energy transfer is dependent on that difference.

 

Natural gas has a specific heat of 2.191, which is 91% of the specific heat of hydrogen, but it doesn't do nearly as well because the thermal conductivity is only 0.035.  Hydrogen has a thermal conductivity 4.8 times higher than that.  Technically steam has better characteristics for energy transfer than hydrogen, but typically a colony needs to cool things off, not heat them up and aside from that working with steam is challenging because it's hard to make and use given the relatively low temperatures at which machinery takes overheat damage.

[Trego]

On 6/30/2017 at 0:05 AM, Allekatrase said:

Really awesome explanations in this thread, but mostly pointing at specific heat capacity for why hydrogen is chosen when that's only half the answer.  

It seems more accurate to say that there was one explanation, and then the rest of the thread is in response to OP's second set of questions.

Also, although I agree that thermal conductivity is important, currently, it's important to note that currently heat transfer in pipes is incredibly slow.  If that were ever changed, then thermal conductivity would be correspondingly less important for cooling media for use within pipes.  The whole situation is quite complex, so to say that the thermal conductivity is half the answer seems to be an overestimation on your part.  Your response to Kasuha's post completely forgets about the low dew point of hydrogen...that's half the answer you've forgotten , the specific heat is the other missing half, and the situation with the buggy pipe heat transfer mechanics is the other other missing half, the high TC is the original missing half, the surprising pleasing color of hydrogen is the nouveau missing half, the easy availibility of hydrogen in quantity as a waste product from electrolyzers is the practical missing half.

[Coolthulhu]

Specific heat is important here because of wheezeworts and regulators. Wheezeworts are limited in number and regulators consume power per packet cooled, not heat moved.

Hydrogen just happened to be the best at everything, making it a total no-brainer choice. I hope it will change one day and we'll use high dew point gases for vapor-compression cooling, high pressure * thermal conductivity fluids for heat exchange and so on. Not just hydrogen and CO2.

[Allekatrase]

2 hours ago, Trego said:

It seems more accurate to say that there was one explanation, and then the rest of the thread is in response to OP's second set of questions.

Also, although I agree that thermal conductivity is important, currently, it's important to note that currently heat transfer in pipes is incredibly slow.  If that were ever changed, then thermal conductivity would be correspondingly less important for cooling media for use within pipes.  The whole situation is quite complex, so to say that the thermal conductivity is half the answer seems to be an overestimation on your part.  Your response to Kasuha's post completely forgets about the low dew point of hydrogen...that's half the answer you've forgotten , the specific heat is the other missing half, and the situation with the buggy pipe heat transfer mechanics is the other other missing half, the high TC is the original missing half, the surprising pleasing color of hydrogen is the nouveau missing half, the easy availibility of hydrogen in quantity as a waste product from electrolyzers is the practical missing half.

You make good points.  The way pipes transfer heat shouldn't really be relevant since it applies equally to all gases, unless it doesn't use thermal conductivity of the gas in the pipe at all for the calculation.  You are completely correct about the dew point, though.  That's a big factor, especially where you're trying to liquefy or solidify other things that are normally gases.

 

Anyway, as Coolthulhu just said, hydrogen is the best at everything involving heating or cooling systems and that's why it's used.

[Whispershade]

I think it was revealed in the code that only lower conductivity is considered for the exchange of temperature while specific heat capacities are multiplied, yes?

If I am remembering correctly, then this somewhat mitigates the value of super high conductivity.

[Allekatrase]

True, but it depends on what materials are involved.  Basically all solids and liquids have higher thermal conductivity than any of the gases, so the limiting factor is the gas you're using.  If you're trying to cool another type of gas then the other gas is going to be the limiting factor.

[Trego]

14 hours ago, Coolthulhu said:

Specific heat is important here because of wheezeworts and regulators. Wheezeworts are limited in number and regulators consume power per packet cooled, not heat moved.

Hydrogen just happened to be the best at everything, making it a total no-brainer choice. I hope it will change one day and we'll use high dew point gases for vapor-compression cooling, high pressure * thermal conductivity fluids for heat exchange and so on. Not just hydrogen and CO2.

Well, hydrogen is a good coolant IRL because of the low molar mass right, which is what gives it such a high specific heat etc I believe, which then is exacerbated by ONI modeling pressure based solely on mass, which then makes hydrogen look even better, I think...and then them not including hydrogen's greatest drawback (the Hindenburg drawback).  We're still waiting for the high temperature update, which would be a natural time to introduce flammability drawbacks for a couple of our gases that should be able to turn a base into an inferno.

[Coolthulhu]

7 minutes ago, Trego said:

not including hydrogen's greatest drawback (the Hindenburg drawback).  We're still waiting for the high temperature update, which would be a natural time to introduce flammability drawbacks for a couple of our gases that should be able to turn a base into an inferno.

It's not a big drawback for fully enclosed systems with tightly controlled temperatures, like ones encountered in the game. Unless the flammability skipped the requirement for oxygen.

But then, drawbacks like that don't really work - they hurt new players, but experienced players quickly learn to work around them with minimum effort.