• Content Count

  • Joined

  • Last visited

Community Reputation

553 Excellent

1 Follower

About wachunga

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @ghkbrewI don't recall what I was doing that lead to small packets moving each second being better than large packets moving slowly. It's one of those "best practices" that I've filed away without remembering where it came from. That said, there are so many interdependencies and variables in a heat exchanger that I don't find it at all surprising that some situations perform opposite to my findings as you're saying. I threw together some examples based off a petroleum boiler since that's an easy example. It's different from sulfur in a sour gas boiler, but it should illustrate the principal. Whether this still holds true for sulfur in a boiler is unknown to me! Crude oil flowing against petroleum. Leftmost is 2.5 kg packets moving each second. Middle is valved at the end so the packets are 10 kg but with a 2.5 kg portion moving each second. Rightmost is one 10 kg packet moving every 4 seconds. Small packets are better, but just slightly. Replaced the crude with igneous. Leftmost is 5 kg packets moving each second. Middle and rightmost are functionally (and experimentally, yay) the same since rail packets can't merge, one 20 kg packet every 4 seconds. Small packets perform slightly better again. All the math for conservation of heat works out properly so I don't think we have to worry much about potential bugs here. EDIT: Was screwing around with a test that is more representative of an actual sour gas boiler. 0.25 kg/s -165C sulfur flowing against 0.758 kg/s 100C sour gas. Left side as 0.25 kg packets every second. Right side as 20 kg packets every 80 seconds. Small packets perform slightly better, going from -165C to 1.2C. Large packets go from -165C to 0.2C. However this difference only translates to 0.1C in the outgoing sour gas, that's pretty meaningless. So I would say go with whatever setup is more convenient or that you find more pleasing for whatever reason. And the save if anyone wants to screw around also: test3.sav
  2. Meters can be set for an amount greater than packet size. You can make a system that sends 357 kg of something and then stops until another 357 kg is requested. The thing is that there isn't much reason to do that and since rails don't have valves, you just see people repurposing the meters as valves. I guess they have more utility in the DLC where there may be a reason to periodically send material to another planetoid on demand. In the base game you would just run another rail/pipe line to whatever and have it always be filled, but in the DLC you are limited by having to share the rail/pipe going through the teleporter or your launcher system. Also I think there are bug reports of meters not reliably sending the amount they are supposed to, which could be another reason why you don't frequently see them being used in their intended function.
  3. The easiest thing is probably to abandon 3.33 kg packets and go with average output. Throttle at the output for one packet every 6 seconds, the exchanger will fill with 20 kg packets but they will move slowly and give an overall flow of 3.33 kg per second. In my experience the heat exchanger doesn't perform as well as with the proper size packets moving per second, but it's not substantially worse and may be good enough for your situation. Test it yourself and see how it plays out. Better would probably be a hybrid approach where you use the splitter to make 10 kg packets and let them out once every 3 seconds. In such a scenario, it's also pretty easy to avoid automation at the output if you so wished. Though automation would allow you to stop output occasionally to keep the exchanger full, since the output is theoretically slightly higher than production or in the case of hiccups. The middle portion of the lower rail represents the heat exchanger section. In order to get perfect 3.33 kg packets you would have to dump the remnant packets out to get picked up again. Alternately you could do some rail spaghetti shenanigans like the above to get 5 3.33 kg packets from the splitter followed by the 3.35 kg remnant packet. Or 2 3.33 kg packets followed by the 3.34 kg remnant by first splitting to 10 kg and then sending to another splitter. But I doubt it's worth the effort to go that far.
  4. Looks like this bug: If so, you can place two mesh tiles stacked directly above the liquid like the last picture in that post. Wolframite so the molten copper doesn't melt them.
  5. Can confirm still a bug in 486708. First 2 screenshots show before condition of 100kg 1409.9C magma/igneous falling into 100kg 409.9C igneous. Last 2 screenshots show magma solidified and incorrectly took temperature of existing debris while igneous fell and combined correctly with existing debris. debris solidification bug.sav
  6. Salt water and brine are so similar I see no reason why one should have a minimum output but not the other. If it is intentional, it would be nice for a dev to pop in and say so. Otherwise we are left thinking they haven't been able to find 5 minutes to fix such a trivial bug in 2 years.
  7. I was screwing around with alternate ways of boiling liquids and I thought I would apply it to this issue to see what happened. Maybe it'll provide some insight. First some background on how I understand things to work so we're on the same page. Contents of buildings behave as debris/ore that are invisible. This includes liquids, bottles are the graphic for liquid in debris form. Debris melts/boils at the material's melting/boiling point and doesn't require the extra 3K that is needed when the solid/liquid comprises a cell. Debris also does not have the 1.5K rebound after phase change. Some buildings are flagged as "sealed" which, AFAICT, prevents the contents from offgassing or changing phase. An interesting quirk occurs with buildings that are not sealed. Liquids that are "transheated", I'll define as above boiling point but below the extra 3K (water @ 374K for example), are stable as a cell or in pipes but will spontaneously boil when placed in an unsealed building. Doing so avoids the 1.5K rebound, which is what I was initially after. Soda fountains are unsealed and the water inside boils when it reaches 372.5K. I wanted to see if boiling water this way triggered the deletion, if so then behavior specific to the vent could be ruled out. Using the equation from a few posts up, I got deletion to occur without a vent. In this configuration of 1000g/s water flow, the deletion is 500g/s or half the flow rate which is what we've seen previously. However, connecting one of the side branches reduces deletion to 250g/s which suggests spreading out the packets from every other to every fourth stops the deletion. Connecting both side branches stops all deletion. I briefly tried adjusting temperatures to restart the deletion with 4 branches but was unable to. Returning to 2 branches restarted the 500g/s deletion. Perhaps alternating flow between multiple vents is an easy way to avoid the bug? And the save for any interested:test.sav
  8. My guess is no deletion would occur and that's what I'm seeing so far in brief testing. I used the @ghkbrew method starting from scratch to achieve deletion with 1 kg/s 96.2C water into a 200C steam covered vent. No deletion when the water was superheated to 200C. Changing back to 96.2C water restarted the deletion. I used this equation where x = water temperature in C, y = steam temperature in C, and z = flow rate in kg/s. z * (99.4 - x) / (y - x) = 2 * (99.4 - 95) / (380 - 95)
  9. It randomly occurred to me that there is maybe a super simple work around to this. Rather than spending a bunch of dev time figuring out what causes the water flow to get into this unstable state, just insulate the vent. Not like insulated pipe, but like how the metal refinery and aquatuner and several other buildings are insulated. Their contents don't engage in temperature exchange with the surroundings. storage.SetDefaultStoredItemModifiers(Storage.StandardInsulatedStorage) My understanding is StandardInsulatedStorage Hides and Seals, if that causes issues then just Insulate? Disclaimer: I am not a professional coder, yada yada yada. And a screenshot showing the phantom contents of a vent exchanging heat: The water enters at 95C and each tick adds ~1C. Maybe the critical steam temperature range is that which cause the 95C "water" to boil after 5 ticks at the same time a new packet of water enters the vent? If it's either 4 or 6 ticks the game deals with it ok? For reference, inside a building the water is treated as debris/bottle and boils at 99.4C and does not need the extra 3C "heat of vaporization" IIRC.
  10. I think we've moved beyond this question, but for completeness it's very reproducible for me just like for you. The few times it has failed might be because I accidentally broke it without knowing. I built a similar contraption without the turbine like @ghkbrew and get the same results. To test if it's the packets or surrounding gas that's being deleted, I placed the vent in hydrogen. Hydrogen amount stayed the same while steam was deleted so I think that points pretty clearly to packets being lost. For a 2 kg/s water flow, the steam deletion was very close to 600 kg over one cycle. As if half the packets are being deleted. To double check this I changed the flow rate to 1 kg/s and adjusted steam temperatures as necessary. Sure enough deletion rate was then 0.5 kg/s or the same every other packet. I guess it could be half the packet amount instead? I also tried the vent in oxygen instead of hydrogen but couldn't find the right temperature. The conductivity of steam and hydrogen are apparently close enough that the temperature for steam works for hydrogen as well. Oxygen is quite different. There might be some utility in finding the critical temperature for other gases, but I don't know if I'm going to bother. It could be an interesting way to avoid the bug though. Remove the vent from the steam chamber and stick some oxygen over it. Good job everybody
  11. I dug into the temperature aspect from my previous post a bit more and I found something I think is compelling. First I adjusted the turbine output water temperature to see if that changed the critical temperatures that enabled the steam deletion. From left to right, the output temps are 95C, 96, 97, 98, and 99. Sure enough the temperature of the steam where deletion would or would not occur changed as well. From left to right, thermium (and steam roughly) are 376.9C (650K), 316.9, 251.9, 186.9, and 125.9. I didn't precisely find the min/max and there is wiggle room, but go too high or low and the deletion stops. Needing to heat the turbine water by 1C more requires roughly 65C more in steam temperature for deletion to occur. Next I blocked one of the turbine ports to see what happened. The necessary temperature deltas all dropped by roughly 1/5 (as you might expect with 1/5 less water flow). The 1.6 kg/s 95C water now only needed roughly 52C hotter steam than the 1.6 kg/s 96C water. And so on for the 97 and 98 water. I stopped looking at the 99 water because it's steam was already bumping into the turbine's minimum 125C to operate. After some head scratching, I think I stumbled upon the important bit. The necessary temperature is at the vent and not where the water boils. The 2kg/s 95C turbine water needs very roughly 377C (again there is quite a bit of wiggle room) steam for deletion to occur. Changing the top or bottom thermium temperatures, and thus the boiling or turbine intake temperatures, does nothing. Changing the middle thermium however, and thus the steam temperature at the vent, stops and starts the deletion. Stopping happens almost instantly when the vent's steam temp changes too much. Restarting is a bit more difficult and took a couple attempts, but I did get it to happen multiple times. If the temperature of the vent cell is somehow important, I would suggest that perhaps the mass is as well. Is the sim using the vent cell mass instead of the boiling cell mass in some calculation or event? Or maybe cells next to the vent in the case of displacements? Is the deletion occurring at that cell for some reason?
  12. Update on some things I've found. Starting from the "TestingGround cycle 14" save @mathmanican posted just above, I simplified it in the interest of removing potential hiccups and extraneous factors. Apologies to those looking at the DLC saves. This shows steam deletion pretty reliably for me, takes just 1/8 of a cycle to see it happening or not. test3.sav I'll let it run until I can see deletion. Then if I pause and frame advance 15 frames and unpause, the deletion stops. I've tried less than 15 and deletion continues, every timed I've done 15 or more the deletion stops. Starting from a fresh load, again I'll let it run until deletion is verified. Then replace the bottom row of 650K thermium with 600K. Once the steam temp drops after a few moments, deletion stops. Restore the 650K thermium and deletion starts again once the steam warms up. I've done a few tests with changing the piping resulting in both the deletion continuing or stopping. No conclusions but I suspect fiddling with the piping sometimes does the same thing as advancing frames, essentially bringing the flow into a stable state.
  13. Popping in to confirm that this save demonstrates steam deletion for me in all 10 turbines. After one cycle, steam was reduced from ~20 kg per tile to ~10 kg per tile. Roughly the same for all 10 turbines. Had to load the save twice for the deletion to occur. First load no deletion. Second load from in game, didn't quit out or anything.