aquatuner loop pipe blocked

[Olleus]

Can somebody explain this to me?

The top one is from this thread, and works 100% as intended. Hot packets go through the aquatuner, cold packets go around, and the flow is ssmooth and continuous.

The bottom one is exactly the same, except that the overflow is pipe-bridge-pipe rather than pipe-pipe-bridge. But, as you can see, the bottom one doesn't work and sends half the packets around the aquatuner even though they are "hot". This seems to contradict the rule that fluids go into a building pipe intake if there is the option to.

 

 

[mathmanican]

1 hour ago, Olleus said:

Can somebody explain this to me?

Looks like there are two times that the liquid heads up, instead of through the aquatuner. 

1. The first bead that heads up is because it takes 1 sec for the aquatuner to turn on. Also, there is already something in the tuner, as your sensor turned the tuner off.  So the leading bead will not get cooled. 
2. The second bead that heads up is because you have two pipes connecting without a bridge on the output side.  As such, the aquatuner output has to pause to allow a bead to come down, hence it gets backed up for a second. 

Good news, the leading bead changes each time.  Bad news, the second to last bead never swaps location with any other bead, so it will never get cooled. 

[psusi]

Wise words from the ONI hermit.

[Olleus]

31 minutes ago, mathmanican said:

Looks like there are two times that the liquid heads up, instead of through the aquatuner. 

1. The first bead that heads up is because it takes 1 sec for the aquatuner to turn on. Also, there is already something in the tuner, as your sensor turned the tuner off.  So the leading bead will not get cooled. 
2. The second bead that heads up is because you have two pipes connecting without a bridge on the output side.  As such, the aquatuner output has to pause to allow a bead to come down, hence it gets backed up for a second. 

Good news, the leading bead changes each time.  Bad news, the second to last bead never swaps location with any other bead, so it will never get cooled. 

 

Thanks for the reply, but I must admit I don't understand.

1) If there's something in the aquatuner at the start, why doesn't it flow out while the packets are in the radiant pipes? I'm not sure how that aquatuner taking 1 second to turn on causes a problem in the second example but not the first one?

2) Why does the aquatuner outlet have to wait in case 2 but not 1? The time it takes for the detoured packet to rejoin the main loop is exactly the same in both cases.

By the way, I get the same erroneous behaviour in the second example if I have a single packet of liquid going around, or if it's completely full. The packets alternate between going down the correct path, and taking the detour.

[mathmanican]

2 hours ago, Olleus said:

I don't understand.

This junction is your main problem. Liquid come from the right and from above. You are correct that the liquid arrives at both green outflow valves at the same time, but it is impossible for both to flow into the junction at the same time. Your animation shows that the section from the aquatuner output got chosen first (have no clue why, but that's what your animation show), followed by the flow from above. So flow at this junction comes from (1) right (2) top (3) right (4) top (5) right. Each time flow comes from the "top", the aquatuner cannot accept a new packet, and so any new incoming liquid will go up the bypass. This will occur on the 4th bead of liquid (and 6th, 8th, 10th, etc., if you have more.  

To explore it more, open a new game, enable sandbox, fill some pipe segments with different liquids (so it is easy to see the different liquids), and then watch them go. 

I built one with 6 packest, and added the aquatuner. 

• The petro and crude swap spots each time through. This swapping happens because of the 1 sec to turn on issue, as well as the junction giving preference to the flow coming from the aquatuner at the right. 
• The salt water and water always go up (never cool off). This is because of the alternating pipe flow issue at your junction. 
• No liquid remains in the tuner on each pass (I learned something), though this could be because the liquid never got cold enough, not sure.

With only 5 segments of liquid, the first two swap spots as well, and the 4th always goes up (never cooling off).   The junction I started with is your main problem. 

Stuff eventually got stuck, as soon as the thermosensor started activating off and on. (I dropped the temp of the warming bath where the radiant pipes are). 

Eventually the salt water made it out, but the brine (being a single packet) never gets to go through the tuner.  After a bit, the crude and petro (having swapped a bunch of times with the salt) pulled ahead and became a group of 2, with the other three liquids bunching up.  I'm guessing all kinds of weird things will happen if I let this run several cycles, till eventually all 5 liquids are separated by 1 blank spot. Here's where at I'm at after a while. Note that neither the brine nor salt water will ever trigger the tuner to go on, as you have to have two consecutive blobs to trigger it. 

Eventually, the leading 3 blobs separated, and now the two in the lead have no chance EVER to combine with the last 3. 

Seems janky. The junction is the problem.   

[Olleus]

Thanks for taking the time to explain it so carefully! After playing around I get it now. I thought, that the Aquatuner taking 1s to turn on meant that it kept the first packet for 1s before releasing it, not that it refused to accept it.

Essentially, my problem is that I didn't understand how the "good" case work. I see now that the first package in a chain ALWAYS fails to go through the aqua tuner. In example 1, it gets held to the back, which allows the other packets to behave normally. In the example 2, the alternating junction rule means that it back second. This blocks the third from leaving the aquatuner, which blocks the 4th from entering, which causes alternating elements further down the chain to mess up.

This always missing out the first packet seems potentially problematic to me, specially if you turn it on/off often to keep the coolant at a steady temperature. Is it not a big deal in practice? I'm almost tempted to go back to liquid shut off valves, although I always needed a liquid reservoir to make that work smoothly.

[mathmanican]

1 minute ago, Olleus said:

Is it not a big deal in practice?

Depends entirely on what you plan to do. If state changes could happen in your setup, because something sits around for too long, then it is a problem. Realizing that one packet might be sitting somewhere for a long time is the key. Just design with that in mind. 

[TheDeamon]

1 hour ago, Olleus said:

This always missing out the first packet seems potentially problematic to me, specially if you turn it on/off often to keep the coolant at a steady temperature. Is it not a big deal in practice? I'm almost tempted to go back to liquid shut off valves, although I always needed a liquid reservoir to make that work smoothly.

Generally speaking, so long as the loop is properly filled so it is neither over-full, or constantly running with a gap in packets, it should balance out over time. Using Liquid reservoirs as part of the chain can also help in a significant way to balance out the temperature between packets as the Reservoir averages temperatures between everything(of the same type) inside of it and also provides "expansion" capacity for the loop(as one path is shorter than the other).

Easiest and safest build correction is to have the AT output go UP one tile, then left to join up with the output of the liquid bridge rather than simply having it exit to the left. That way, as covered in the first page of this topic, under normal circumstances there should be no way for the AT output(2nd packet) to get to the bridge output before the 1st packet does.

[wachunga]

2 hours ago, mathmanican said:

No liquid remains in the tuner on each pass

It's possible but for liquid to get stuck inside the AT. That's probably what caused the packet separation in your test. The AT holds a packet for a very brief period of time, like 1-2 frames. You can use alt= in debug to see this. If the timings line up such that the following packet disables the AT in that brief window, the packet inside will be trapped. Which creates more problems. Adding a 0.1s buffer seems to be sufficient in preventing this.

Also I would like to clarify that junctions are bad only in combination with using a bridge in the bypass. That creates a path that must be a different length from the AT path and so you get collisions at the junction. You can construct a bypass path with the same length as the AT path using a valve or shutoff and then the junction behaves perfectly.