Search the Community
Showing results for tags 'math'.
Found 3 results
Hello there! I have seen quite the countless number of those Hydrogen generators being highly inefficient and all, so I decided to perform a test and do a little bit of math for the sake of science and exploration! yay. The devices used and their outputs and inputs are listed below: Electrolyzer: 112g/s of Hydrogen generated. 888g/s of Oxygen generated. 120W of Power consumed. 1kg/s of Water consumed. Hydrogen Generator: 100g/s of Hydrogen consumed. 800W of Power generated. Gas Filter: 120W of Power consumed. Gas Pump: 240W of Power consumed. 500g/s of Gas pumped. Sum of components: Power Generated: 320W Oxygen Generated: 888g/s Hydrogen Generated: 12g/s Gas left in chamber: 500g/s Water consumed: 1kg/s With that list out of the way, we can finally talk about the findings. We have a net power generation of 320W, which is 80% of the power generation of a dupe wheel. Though smaller, it's a passive amount of power created. In terms of water consumption, it is consuming the same water as would 3.33 Algae Terrarium. It's pretty damn efficient! What's more, you ask? It provides your colony with 888g/s of oxygen generated. That's enough to feed 8 dupes at most (or, approximately 4 if you have 3 mealwood plants for each dupe -don't quote me on this one though). However, that's under ideal conditions. How do you imitate that? With the set-up shown below. Additionally, you can simply place a single gas permeable tile at the bottom pannel to allow pressure to diffuse the oxygen outwards into your base. Doing so ensures you get the full capacity of the 888g/s of oxygen generated. Hydrogen floats to the top of the tiny room, which then almost guarantees your hydrogen generator to recieve the 112g/s of hydrogen generated. In this case, the hydrogen generator will always be topped off at all times. Have two of them, and you can generate twice as much oxygen, and twice as much power for only the net loss of the same water consumption as 6.66 algae terrarium. Unfortunately, there seems to be a bug where the hydrogen generator does not produce any power, even when completely filled with the hydrogen it so requires.
enhander23 posted a topic in [Oxygen Not Included] - Suggestions and FeedbackTL;DR Implement Pressure Field by adding contamination level (CL) as a property to fluids and using the Ideal Gas Law Implement Fluid Dynamics by using conservation of momentum equations along with the added Pressure Field Implement Mass Transport by using the Fluid Dynamics and CL property This gives us: No more cells of miniscule amount of material (i.e. 10g of contaminated O2 sitting in a cell surrounded by cells of 1000g O2) Less weird water physics (contaminated water falls into body of clean water, weird splash physics) Allows for system where you can transport dug solids (i.e. copper ore, dirt, etc.) via the liquid piping system Proper diffusion of gases (CO2 and O2 will behave more realistically) No more gas pump not in air (since the vacuum created by the pump should draw surrounding gas in more sharply) So after giving it some thought, I think I may have a solution to the problem of sweeping, and the apparent (at least on this forum) problem of the fluid dynamics being unintuitive (fluids not mixing, strange physics). It is not a clean solution by any means, but seeing as the game is still alpha, implementing this may make changes much easier in the future. Fair warning: there is pretty heavy math/physics in this solution. In this post, the term fluids refers to both gases and liquids Problem Sweeping is annoying, generally boring, and takes up a lot of time. Currently, the game is a race to pseudo-equilibrium before you run out of vital resources. The most common problems are that you run out of water, you run out of electricity fuel, and you run out of sand. Sweeping takes up time that you could be using to build up your base, and this delays the point at which you reach a pseudo-equilibrium base. Fluid mixing is not intuitive. When polluted water enters a body of clean water (or vice-versa), you get a very weird splashing dynamic where the liquid can rise unexpectedly. Additionally, the fact that each cell is finite means that fluids not being able to mix leaves you with weird pockets of gas where you have an extremely small quantity of one gas, surrounded by large quantities of the continuum gas (i.e. <100g of contaminated oxygen surrounded by blocks of 1000g of clean oxygen) Fluid diffusion is not intuitive. It is fairly well known that fluids tend to travel from areas of high pressure to areas of low pressure, but this is not the exact case with ONI. This flaw is most obvious with the gas pumps, where there should be a sharp decrease in gas pressure in the vicinity of the pump, causing other gases to flow towards it. Currently I don't believe this is how it works, although I haven't quite tested this empirically. Proposed Solution As mentioned in another post, I think that ONI already uses some kind of finite element analysis (FEA) in order to simulate its fluid and heat dynamics. It makes sense, as ONI is already split into finite elements (the cells). This makes it very easy to implement a simple FEA system to take care of the fluid/heat dynamics. However, FEA can be computationally demanding. This solution will likely increase the processing demand of the game, but will include some potential simplifications for reducing this load. Pressure The first thing that needs to be done (if it isn't already) is to implement a pressure system and overlay, at least for gases. The implementation of this would allow players to easily predict how gases in their base will flow, as right now it is somewhat of a mystery (O2 rises and CO2 falls generally, but not always). For this, we can actually just ignore a lot of the fluid dynamics and just use the Ideal Gas Law: PV = nRT This implementation is actually quite simple, but robust for our purposes. The volume of each cell is already fixed, so V is actually a constant here. R is the gas constant, which is also fixed (and can be tuned for the purposes of game balance). The only variables left to calculate the pressure of a cell are n, which is the moles of gas, and T, which is the temperature of the cell. Utilizing n actually benefits us a lot, because it solves some of the problems with fluid mixing. For the purposes of ONI, we can say that polluted oxygen is actually clean oxygen, with some contaminant solute mixed in. While you can use CO2 as a "contaminant", this would greatly complicate the problem. It would be much easier to say that the contaminant is slime, or something similar. While it doesn't really make sense that gas is going to carry a solid solute, it doesn't really break the immersion of the game and so we can use this as an easy solution. By doing this, we can now utilize the gas and solute density to calculate a realistic-feeling gas pressure. To do this, we need to introduce a contamination level parameter, which can be measured as a percentage (i.e. this cell of oxygen is 40% contaminated). This affords us several benefits: Currently, having a drop of contaminated water enter a pool of clean water creates this tiny little cell of contaminated water, which feels unintuitive. If you put one drop of sewage into a swimming pool, it doesn't stay put. It spreads. By using a contamination level, mass diffusion will become much easier to do later, and it makes the game more intuitive. With the temperature update, buildings take damage when you feed them the wrong fluid. However, this doesn't make much sense: again, if you have a single drop of contaminated water enter a large body of clean water and then pump it to your shower, the shower shouldn't break from that one drop of contaminated water. It would make much more sense that the shower takes damage proportional to the contamination level of the water you're pumping in (i.e. 10% contamination deals a very small amount of damage, 80% almost breaks it). To prevent the continuous breaking problem (as can be observed right now with coal generators overheating), you can set a minimum threshold of contamination for the building to take damage (i.e. <5% contamination deals no damage to buildings). So now that we have a contamination level parameter, we can calculate the pressure of the gas. The moles of gas in the cell is then calculated by finding the moles of gas and the moles of the solute, and then adding them together: n (total) = m(gas)/MM(gas) + m(gas)*CL/MM(contaminant) Where n is the total moles of material in the cell, m is the mass, CL is the contamination level expressed as a number (i.e. 0.4 for 40%), and MM is the molar mass of the material. To simplify this further, you could just say that the CL directly increases the moles by a certain number. Utilizing T also benefits us, as it makes sense for a heated gas to exert more pressure on its surroundings. It could be very useful, for example, to heat the area around your gas outlets so that they diffuse faster (due to the larger gas pressure created in the vicinity). With these two paramters, you can then calculate the gas pressure as: P = nRT/V This leads us to the next part: the Navier-Stokes Equations Fluid Diffusion (Mass Transport) This section is going to be pretty heavy on the math/physics, but all of it would be back end, so really no one has to deal with it (except the devs). It involves the following differential equations: Fick's 1st and 2nd Laws of Diffusion The Navier-Stokes Equations When combined, these equations allow us to model the fluid and solute flow fields. Normally, this requires quite intensive computing power since even simplifying the PDEs to ODEs doesn't always make them solvable. However, by using scaling analysis, you can simplify the problems to a couple of tunable constants and a system of 2D-ODEs. This makes the system much easier to solve, although it is still somewhat intensive. I'm going to skip the math on this one (I could explain but it would make this much longer than it needs to be and doesn't really add anything except math), but I'm going to summarize what these equations will give us: Tunable dimensionless parameters. You can look them up: Da, Pe_M, Re. These parameters are basically what you change to affect the diffusion of solutes and the flow rates. Because changing them does not change the equations themselves, they make it very easy to balance the game numbers-wise. The parameters are calculated based on material constants and certain scenario constants (Reasonably) accurate fluid diffusion. Using the pressure field, in addition to the material constants, gas can now be modeled to flow more realistically. Using this method, you should not longer have cells that have miniscule masses that last for very long; a cell of 1000g of oxygen beside a cell of 10g of oxygen should now diffuse very quickly to evenly distribute the gases. (Reasonably) accurate mass transport. Using our newly found fluid flow model, you can add Fick's Laws of Diffusion to properly diffuse contamination. 1 drop of contaminated liquid should now properly diffuse through a body of clean water. Likewise, contaminated oxygen should diffuse itself throughout the air system. You could allow different kinds of gases to mix in this way; you would just have to combine their partial pressures to factor that into the pressure field, and then the Navier-Stokes equation automatically accounts for fluid weights through its gravity term. This means that gases should properly rise and fall as needed. For implementation, there are several things that would have to be done to simplify the math. First, you want to treat all of the fluids as incompressible. This removes an entire term from some of the equations and often simplifies them significantly. Secondly, you want to make sure that you have no slip boundaries between the fluids and solids in the game. This means that any wall or undug tile does not move with the fluid; it stays put, and the fluid acts accordingly. So now we have the math and physics, it's time to move onto the last part: Finite Element Analysis Finite Element Analysis So now we have equations that describe the flux of material between cells. All that's left to do is calculate this for every cell. Yup, as you guessed that is a metric f***-ton of math. But, such is the cost of having a realistic simulation. Of course, Klei doesn't have to go the full 9 yards with this, but solving their systems first in COMSOL might give them better insight into how their systems should behave, so that they can find ways to make their systems act more realistically. Sweeping So you might be thinking, "but enhander, how does this solve sweeping problems?". Well, once we have mass transport in fluids, it isn't too far of a stretch to allow our mined materials to be solubilized in water. In this way, we could potentially transport materials through our already-existing piping systems. Conclusion By adding these fluid dynamic models, we can solve a lot of the problems with unrealistic and unintuitive gas and liquid behavior. It also gives us a way to deal with sweeping which can be an issue when you are trying to explore.
EuedeAdodooedoe posted a topic in [Don't Starve Together] General DiscussionSo, while it's still seemingly not worth the trouble, I thought I'd do some math for those who do want them sweet crowns for good, fancy head gear. The math is actually a bit convoluted... If you start with "n" amount of thulecite, then the math per time you use up a construction amulet would go about like this: n - 2 (this is where you craft a construction amulet, which takes away 2 of your existing thulecite), n - 5 (this is where you craft a thulecite suit and a deconstruction staff, both using the amulet, which results in loss of 40% from the construction amulet, aka 0.4 green gems), n + 1 (this is where you first deconstruct a thulecite suit, gaining +6 thulecite, in total equating to 1 more than you had before. The following is just a continued process of constructing and deconstructing thulecite suits via construction amulets and deconstruction staff respectively, until...), n - 2, n + 4, n + 1, n + 7, n + 4, n + 10 (construction amulet breaks, deconstruction staff stays at 20%. Total green gems used up for this process = 1.8, which gives 10 thulecite more than you had initially, aka n + 10). Now, the question I brought up to myself is whether it's worth/more efficient to use a construction amulet in order to craft thulecite crowns. To determine this, I needed to find out the total amount of green gems used in order to create a certain amount of thulecite crowns. 10 thulecite normally equates to 2.5 thulecite crowns. With a construction amulet, with its thulecite included, you could craft 4 crowns for an extra 0.8 green gems used up. So, it's 2.5 crowns for 1.8 green gems, or, 4 crowns for 2.6 green gems... Seems like both are pretty close, if not the same, right? Well, lets try and get the crown amount to be the same for both equations in order to determine how much of them each use up the green gems for the same amount if thulecite crowns as each other. Lets scale the numbers up a bit first though by like, say, 10 times, so we get 25 crowns for 18 gems and 40 crowns for 26 gems. Then lets divide the crowns' amount to equate the same amount, so 25/5 = 5, 40/8 = 5. The same must then be applied for their respective gem amount and with that we will get an answer for this question: 18/5 = 3.6 26/8 = 3.25 Well then... If my math is correct, then it is slightly more efficient to use construction amulets for crafting thulecite crowns. Hope this is useful for somebody out there when crafting those sweet sweet crowns, in case you've been crafting them without an amulet this entire time ^^