UPS Wars 2 - Steel Smelting

[mulark]

THE DATA: https://docs.google.com/spreadsheets/d/ ... sp=sharing


It's time for round 2 of the smelting UPS wars, and this time, the challenge is steel.

Going from ore -> steel is significantly different than just smelting to plates, so I thought it was deserving of its own thread.

Changes from UPS Wars 1:
Void chest mod has been removed in favor of the vanilla infinity-chest.
Submissions will now be handled only as replies to this thread. So called idea stealing is more of idea collaboration in my book. Though I do encourage you to try it yourself before peeking.
Your production target is now 20,000 steel plates per minute. Entries exceeding 20,000 plates per minute will not be awarded additional score. A separate category for 50,000 plates per minute will also be accepted.

Alternate download v1.1: https://drive.google.com/open?id=191N2w ... PcrRdz1UdP

The Basics (shameless copypasta):


Challenge

The concept is simple. The map consists of a giant iron ore patch 300 tiles east of spawn, and a set of void chests 300 tiles west of spawn. You must mine some ore, turn it into plate, then into steel and dump it in the void chest and you need to do it using as little UPS as possible.

Rules

You may not move the ore patch (although you are expected to build on it, its only so big so people can set up multiple outputs if they wish)
you may move the void chests, but not past the hazard concrete at -300 X
avoid using infinity chests inserted straight from smelters, think of them as part of the plate pickup system (they work well as the requesters for a plate pickup station if your doing smelt at base, or plate dropoff if your doing smelt at patch)
You may use as much space as you like (custom mapgen means the unexplored map area will all be empty usable space)
You may use any mods you want to make it, but it must run in vanilla.
The map already has all non infinite research, mining productivity 201 and robot speed 16. you may not increase this further
Your design must be stable for at least 10 hours on the production graph


Changelog:
v1.0: initial
v1.1: disabled pollution

[DaveMcW]

I recommend a couple rule changes to make things easier.

1. You must produce exactly 20k steel plates per minute, there is no score bonus for producing any more.
2. Building and removing infinity chests west of -300X is allowed.

[Aeternus]

What's the rule power-wise? Infinite power cheat provided to invite to go crazy with beacons? (Or just a whopping solar plant/battery farm that does much the same thing?)
Are trains allowed? And is cheating a bit of fuel for one allowed since all you have is ore? Train bulkmoving across ~600 tiles > botwise or beltwise moving across 600 tiles. Single homed 1-1-0 train with a loop at the end could fill the bill for 20k steel in 5 runs.

Seems to me this'll be a pretty basic setup, similar to what I do in my own megaplant for mass steel production:
Beaconed mines set up for full speed dump into provider chests
Those by bot push into smelters for iron. Beaconed for speed, but with production mods. This brings the ratio for smelters iron to steel at 4 to 1 (4.8 iron > 5 required for steel, nearly full utilization), provided they are beaconed for similar speeds. Production in the steel smelters too to produce extra output/reduce required input, which diminishes the required amount of items in, which in turn diminishes UPS.
Deliver output by bot to the void chest. End challenge.

Extra tweaks:
- Stack inserters for moving ore/iron. It'll cut back slightly on the swings they make to move items, and they'll act as minor buffers.
- Yellow inserters to move steel into provider chests. Occasionally these'll pick up 2 or 3 (inserter research) thus reducing the UPS.
- Some inserters could be omitted by having mines feed directly into smelters - but it's probably more efficient to heavily speed beacon both and have some inserters move the ore.

[mulark]

Some clarifications. Infinity chests can be moved any where except closer to the patch you may also have any number of them.

As for a fixed production target, I do like the idea, a target of 20000/min will do, I think. Perhaps 50k/m submissions as well, as it is near the amount needed for 5k spm

Power should be provided with an electric energy interface.

In general if its possible in vanilla, it is allowed.

[DaveMcW]

I was testing a design, and got a huge (25%) variance in performance depending on how long it ran.

It turns out the pollution cloud generates new chunks as it expands. The best way to get consistent performance (and save UPS!) is to explore an area bigger than your pollution cloud can ever grow.

Code: Select all

/c game.player.force.chart(game.player.surface, {{-1600,-2000},{2400,2000}})

In future challenges please turn off pollution!

[mulark]

I've updated the OP to reflect the new design parameters. The map has been updated to v1.1 to disable pollution. The below command can be used to update 1.0 maps to 1.1. Happy Building!

Code: Select all

/c local surface = game.player.surface; for coord in surface.get_chunks() do surface.pollute({coord.x * 32, coord.y * 32}, -10000000) end; game.map_settings.pollution.enabled = false

[mulark]

Screenshot_20180322_191115.png (544.81 KiB) Viewed 14302 times

After a little delay, I have my first submission.

This design uses direct insertion to achieve quite a respectable score.

I've also started the results spreadsheet: https://docs.google.com/spreadsheets/d/ ... sp=sharing
Eventually I'll create a summary, if we get enough submissions, the raw data will go on a second sheet.

[quyxkh]

That's a whole lot better performance than I'd expected from anything with belts, kudos.

Here's a fairly straight port of my copper-smelting design from the previous challenge, it avoids the two extra inserter swings per handful that intermediate belt entails and gets ~10% better performance on my rig.

quyxkh.steel.clocked.20k.zip

(4.8 MiB) Downloaded 255 times

[DaveMcW]

Here is my 9 beacon direct-to-train design.

Compared to quyxkh it gains 1 beacon at the cost of 2x train movement, and ends up 4% slower.

UPS Wars 2 - DaveMcW.zip

(4.63 MiB) Downloaded 237 times

[mulark]

Results have been uploaded.

One thing I've been thinking about is how reliable are these kind of small scale results when taken to the max at megabase scale. It's entirely conceivable that what bottlenecks a system at these small scale changes at a larger scale. I ran a small test on my personal megabase and my first submission to this thread to see if that was the case. In this test, I ran my memory at both 1866MHz and 2000MHz which is around a 7% uplift in frequency. This overclock carried a 1.7% uplift on my submission to this thread, but a 4.4% uplift on my personal megabase. Indeed it appears that as you scale up memory speed becomes more important. I suppose the question then becomes, how do we accurately test to capture this behavior in the future?

[quyxkh]

I call what you're talking about cache-packing. I gather graphics guys call it "tiling", numerics guys call it "blocking", it's all about getting temporal locality on anything referenced multiple times so the odds of paying just the cache-hit price for the access go (hopefully way) up. You're seeing the cost difference between cache and main memory access for the misses provoked by your working set -- that difference is so high these days main memory is best regarded as a network or i/o device when it's time to pay attention. A 7% main memory speed boost got you a 4.4% large-working-set performance boost and a 1.7% small-working-set performance boost is exactly what you'd expect to see when the small working set fits mostly in cache and the engine's well optimized so the large working set is accessed with some brainpower guiding the sequencing.

I don't think you _do_ test to capture this for in-game designs. Cache packing depends on your actual cache layout, the relative costs, everything. Any drama in the results will be specific to the system and the workload -- i.e. in this context pretty much a crapshoot -- and if the effects are significant on any particular system they will also change significantly when the design gets embedded in a real map.

[quyxkh]

It occurred to me that holding clocked inserters idle for a fifth the payoff might be enough to cross a line, and so it proved. The unclocked version of my first map gets another 7% or so, delivering 21.6 steel plates / cpu ms on my rig vs 18.5 for mulark's and 19.6 for DaveMcW's.

quyxkh.steel.unclocked.20k.zip

(5.04 MiB) Downloaded 243 times

[DaveMcW]

I optimized my 9 beacon design from 12 trains down to 6, but it still fails to beat quyxkh.

UPS Wars 2 - DaveMcW 2.zip

(3.99 MiB) Downloaded 200 times

[mulark]

An idea I had was to use an explicit train schedule instead of naming every station the same thing and dynamically turning off the stations like in quxykh's.

This design is a complete copy paste of quxykh's except for the stations. Unsurprisingly performance is almost identical. In fact it is so close I took this opportunity to rerun all the previous submissions on the latest current version 0.16.36 as well as a refresh on all the OS updates that could have changed the balance of performance since the thread began. With these considerations in mind I'm proud to once again claim the performance crown using my totally original design by a whopping 5 effective UPS or a commanding lead of 0.11%!

On a more serious note, I've been thinking of ways to more effectively gauge the performance of the vanilla game as well as any potential shortcomings of current testing. One area that I think could be improved is in our test map. Our current map consists of one franken lab scenario that generates vanilla terrain if you go too far out, ported to 0.16 with a singular giant ore patch east of spawn. Lets outline some pros and cons to this method.

Pro:
The map file size is small. Faster times saving and sharing designs.
Consistency. There is one clear objective and all participants are competing on a level playing field.

Con:
A single fixed size ore patch. The vanilla game's ore patches are nowhere near as large as this patch. This leads to potential overfitting of test designs. For instance a more compact design has the same train distance penalty as one filling the entire patch. Ore in the vanilla game is infinite and this test map may exclude the bulkiest designs that would otherwise succeed in the vanilla game.
Adaptability. This map is pretty much only usable for a single resource production challenge. For instance a hypothetical green circuit or oil processing UPS wars would require an entirely new map or significant changes to the current one.

To best achieve our goals let's look at each of the map generation settings. I will share my arguments and reasoning for each setting, however I am open to discussion and feedback.
First tab: Basic settings
Most of the settings here control background dials for the other tabs. The only relevant ones here are the map size in width and height variables. As the vanilla game is infinite, at least one of these settings should be infinite. However, I propose that we impose a fixed height to the map. Our current testing involves extracting ore from the right side of the map and delivering products to the left. Having infinite height just serves to muddy the results. A fixed height focuses the challenge. The height should be large enough to encompass any potential builds, thus I propose a height of 2000.

Second tab: Resource tab
The most difficult and subjective settings and we need to quantify them. Right off the bat we can set the richness of all resources to Very Good, as there is no real downside. The other two settings are truly the most difficult. In my opinion the ideal patch rewards longer trains and more wagons. Of course a greater number of patches that are near to each other lowers the tedium of exploring new chunks and setting up outposts. But in the vanilla game raising the frequency settings lowers the patch size silently. The RSO mod allows for highly tuned ore generation settings and we can use them to our advantage. With RSO it's possible to create very big patches very often, which I personally believe would be best for our test map. It's also possible to set an obscene richness multiplier. However I recognize this is not vanilla. Thus I believe we are left with 3 options. 1: release with RSO tuned settings, which allows infinite expansion by participants, then, right before testing remove it. 2: use RSO and generate a _large_ area, then convert back to vanilla before releasing to test. 3: use vanilla ore generation at some level like low ore frequency, very big patches.

Third tab: Terrain settings
Low hanging fruit: turn off cliffs, trees, and biters. All these things add to the tedium of testing, and all are disableable right here in vanilla. Only trees are technically required.
Starting area: irrelevant without biters.
That leaves water: water covers over ore in generation, thus maximizing this resource is not ideal. However it still is required in substantial quantity for things we may want to test in the future. Proposed: frequency very low. Size medium. Allows larger lakes, but also big continents.

Fourth tab: Advanced settings
The one stop shop to ending pollution. The main uses for pollution in the ultra late game (which this testing is meant to simulate) are to 1: trigger biters, 2: damage trees, and 3: lag out your map view when the overlay is on. None of these things are relevant tidbits to test (and the map thing isn't testable with our method).

Further, our map should have all research completed, with mining productivity and worker robot speed increased further still. I propose mining productivity of 1000 and worker robots speed of 30. These values are open to feedback.

Finally, I like the idea of using fixed production targets, where no additional score is awarded for exceeding the target. Choosing what rate to target is another matter. Based on this testing, I feel 20,000 steel per minute is too small. The difference between the top two players is less than 0.01 avg ms/t. This works out to around the 2k SPM need. So I said to myself, what is the highest conceivable need? Why yes it's 50,000 SPM . So from now on, all future tests will require the required amount for 50,000 SPM of that resource. Just kidding! I think this could stand to be in the 5K-10K SPM need range, depending on the particular resource.


Well anyways this went on about as long as I expected, which is still too long. So I await your feedback.

[TBTerra2]

Its great to see someone else start to run another UPS wars. sorry about suddenly disappearing from the first wars, but real world stuff happened that kinda took me out of action.

as for the changes made from the first wars:

• Adding a fixed production target with no bonus for going over, is a great idea as scoring vastly different sized designs was a pain
• The new 50K target is promising as it will force people to not use entirely on patch smelting(you might be able to smelt to plates on patch, but you're then going to need to make the steel somewhere else). I was always anoyed that all the big entries for the first wars were entirely on patch smelting

With regards to the research level suggestions for future wars. I think we should look at what is typical for a 5kspm base (the 15 robot speed, 200 mining was kinda arbitrary when I made it up for the first wars)

[mulark]

I have spent a lot of time benching various things outside the forum, and what I've found is that in order to accurately gauge how a design will perform at megabase scale, it needs to be scaled to megabase scale. To me, this means scaling designs to target a maximum to 200 UPS or less effective. Like for red science I settled on 300k red packs a minute. But for green packs 180k a minute works. For me, every design must start at the raw resource, then mined and processed up to the targeted item.
If designs are scalable to for instance 2400 output of an item, it is easy to copy them for as many times as required.

As for research level, I'm inclined to allow the player to set it to any level they desire (maybe top cap it at 10k or so?). The reason for this is that I've found you actually lose performance when you go higher than ~1855 mining prod (assuming 2 miners no modules) when mining on to belt. I haven't found if there was negative performance scaling for other mining techniques yet (mining into furnace or cargo wagon). But for those the optimal mining productivity is most certainly different. If we defined a specific productivity that all designs must use, it could unfairly harm some designs.