text:
Complete immersion of servers in dielectric mineral oil has recently become a promising technique for minimizing cooling energy consumption in data centers. However, a lack of sufficient published data and long-term documentation of oil immersion cooling performance make most data center operators hesitant to apply these approaches to their mission critical facilities. In this study, a single server was fully submerged horizontally in mineral oil. Experiments were conducted to observe the effects of varying the volumetric flow rate and oil inlet temperature on thermal performance and power consumption of the server. Specifically, temperature measurements of the central processing units (CPUs), motherboard (MB) components, and bulk fluid were recorded at steady-state conditions. These results provide an initial bounding envelope of environmental conditions suitable for an oil immersion data center. Comparing with results from baseline tests performed with traditional air cooling, the technology shows a 34.4% reduction in the thermal resistance of the system. Overall, the cooling loop was able to achieve partial power usage effectiveness (pPUECooling) values as low as 1.03. This server level study provides a preview of possible facility energy savings by utilizing high temperature, low flow rate oil for cooling. A discussion on additional opportunities for optimization of information technology (IT) hardware and implementation of oil cooling is also included.

## Introduction

Continually increasing demand for information technology (IT) applications and services has provided sustained growth and interest in data centers. The large amounts of energy consumed by data center facilities have placed a significant emphasis on the energy efficiency of the building’s overall operation. One area of importance is the cooling energy required. Data center cooling is in place to maintain and control safe operating temperatures for the IT equipment they house. Traditional approaches to cooling data centers use air as the primary cooling medium. Heat rejected from IT hardware is absorbed by the air and either rejected to the outside ambient, mixed with incoming fresh air, or cooled through refrigeration processes. These techniques are matured fields and well documented with safe environmental conditions established by ASHRAE TC 9.9 [1]. However, with continuing increases in heat densities of electronic components and densities at the rack level rising, we may be approaching the limits of air cooling, especially for high power racks and as such, alternatives methods are sought.

Both direct and indirect forms of liquid cooling offer many advantages over conventional air cooling such as higher heat capacities and lower transport energy requirements. Indirect methods using water as a cooling medium through cold plates or rear door heat exchangers demonstrate the benefits of a liquid cooling strategy [2,3]. Water cooling may also allow increased efficiency through use of higher temperature fluids and possible use of waste heat for other applications [4]. Cold plates have been a long standing method of bringing water cooling to high powered devices as with the thermal conduction module of the early 1980s [5]. Even today, there is continued interest in such applications and making this old approach more dynamic for the constantly changing requirements of next-generation components [6]. However, in most applications, the use of cold plates still requires air cooling for a portion of the components within servers. Significant developments have been made to bring water cooling to a complete cooling solution (i.e., remove 100% of the IT heat) for even the most powerful super computers [7]. Although additional piping infrastructure required within the server may increase the costs and system complexity of this technology, the cost per performance may still be equal or better than alternatives. Ample data and guidelines for implementing water cooled data center environments are available by sources such as ASHRAE TC 9.9 [8].

Direct immersion of electronic equipment offers a singular cooling solution in which the entirety of a server may be cooled by a single medium. This may provide simplicity and ease in planning and implementation of a total solution. A legacy approach to full liquid immersion cooling is using dielectric fluorocarbon refrigerants in pool boiling application. These fluids are extremely good electrical insulators and have moderate thermal characteristics [9]. Additionally, their low boiling points make them suitable for two-phase flow applications capable of removing large heat densities [10,11]. These high heat transfer rates can be further enhanced though special coatings that increase boiling rates [12,13]. However, there are additional challenges to this technology, with cost as one of the possible concerns that are still to be overcome before it will see wide application. Current research in this area seeks to best select fluids for these purposes [14].

Compared to air, many mineral oils have a heat capacity roughly 1200 times greater. The increased thermal properties, along with their dielectric nature, make mineral oils a possible alternative for data center applications. Mineral oils have long been used as heat transfer fluids with especially large adoption in power delivery applications such as high voltage transformers [15]. The performance of transformer oils as heat transfer fluids may be significantly improved with the addition of nanoparticles, as recently shown in Ref. [16]. A small fraction (<0.100% by weight) of diamond nanoparticles added to mineral oil were shown to increase the thermal conductivity of the base fluid by 40–70% while having minimal detrimental impact to flow properties such as viscosity.

When considering oil immersion as a possible cooling technology for data centers, it is observed that there is limited literature. Recent media attention has provided general power usage effectiveness (PUE) values [17,18], but the details of the operation are absent. Prucnal [19] provides a helpful overview of general operating benefits of oil-based data centers, mentioning the possibility to use facility chilled water up to 30 °C compared to 7–13 °C for traditional air-based systems. A fairly extensive account is provided by Patterson and Best [20], which showed a 36% improvement in thermal resistance of an oil immersion system compared to an air-cooled counterpart with no adverse mechanical effects. Additionally, this work showed successful cooling with oil inlet temperatures up to 43 °C and cooling PUEs in the 1.02–1.03 range. However, no discussion regarding the volume flow rates used was provided. With only limited data available, a large knowledge gap remains in the industry regarding environmental requirements to operate an oil immersion cooling facility.

The primary goal of this study is to establish general operating conditions, in terms of volumetric flow rate per server and oil inlet temperature, which can be expected for safe operation of servers in an oil immersion cooling configuration. For this work, an Intel-based Open Compute server, Fig. 1, was experimentally tested and characterized. Initially, the server was operated in the standard air-cooled configuration with internal server fans to establish baseline operating performance and component temperatures. Next, the server was removed from its standard chassis and placed in an insulated acrylic container and submerged in white mineral oil. Data were recorded for the duration of testing; however, only steady-state data are reported here with some comments made regarding transient performance. Although the complete experimental setup is not entirely reflective of an actual data center facility implementation in fully built-out conditions, the data provides strong evidence to support continued research in this area.

Fig. 1
Fig. 1
Close modal

## Experimental Setup and Procedures

### Air Testing Setup.

To establish a baseline for comparison, the server is initially tested in the standard air-cooled configuration as shown in Fig. 1. Detailed descriptions of the Intel-based Open Compute server design can be found in Refs. [21] and [22]. The server motherboard (MB) contains two CPUs each with a rated thermal design power of 95 W. These components represent the primary heat sources in the system and are cooled by two extruded aluminum heat sinks. The key features, which enable efficient air cooling, are four 60 × 60 × 25.4 mm fans and an air duct that directs air flow over the temperature critical components (i.e., processors and memory). The internal server fans are controlled by a fan speed control algorithm native to the server. This fan speed control operates by adjusting the fan speeds using pulse width modulation (PWM) to achieve a target CPU die temperature. In this manner, the fan speeds and die temperatures typically oscillate with some over- and under-shoot of a targeted value. An average value over the duration of the test cycle is reported. To test the server in the standard configuration, it is allowed to draw air from the ambient laboratory environment for cooling. A synthetic computing workload is applied and internal monitoring tools are used for data collection, as discussed in the Results and Discussion section.

### Oil Testing Setup.

The oil immersion test setup used in the present investigation consists of the following major components as shown in Fig. 2 and discussed in the following. A single Intel-based Open Compute server motherboard and power supply unit (PSU) are placed horizontally in an immersion tank. Some modifications are made to the server to enable testing in the container available and to enable operation in oil. The server motherboard and PSU printed circuit boards are removed from their respective metal chasses to reduce their size to fit in the test container available. In addition, the air duct is removed and the internal server fans of both the server and PSU are disconnected and removed. The hard disk drive (HDD), incapable of operating when submerged, is placed outside the tank although other options exist to leave the HDD intact. The HDD is cooled by natural convection only and represents a small portion of the total IT heat load that is not removed by oil (approximately 3.5%). Of additional note, the grease-based thermal interface materials applied on the CPUs and chipset are kept in place for the duration of testing. Some sources suggest that oils and greases conflict and may cause the thermal grease to dissolve leading to contamination of the oil and possible fouling in the system. However, in the authors’ background study, this information was merely anecdotal and was not followed for the present experiments.

Fig. 2
Fig. 2
Close modal

The tank is made of one-half inch thick acrylic of inner dimensions 45.7 × 36.8 × 19.1 cm (18.0 × 14.5 × 7.5 in) and is wrapped in 2.54 cm (1.0 in) thick insulation. A total of four 1.27 cm (0.5 in) diameter ports are tapped into the container, two serving as inlets to the tank and two as outlets. The inlet and outlet ports are strategically placed with ball valves to allow for the impact of flow patterns through the system to be studied. One set of inlet and outlet is directly in-line with the center of the base of the CPU heat sinks. When only these two ports are open, it will likely represent the best case cooling scenario for the system since the highest velocity flow is directed straight across the CPU heat sinks. The second inlet/outlet port pair is in-line with the power supply unit, removed from the main motherboard components. It is predicted that this flow configuration will prompt higher component temperatures (especially CPUs) since their cooling will be primarily induced by bulk fluid motion. These two flow configurations are used independently during testing and are termed “MB flow path” and “PSU flow path,” respectively, as shown in Fig. 3. The rationale behind pursuing the PSU flow path is to investigate the system configuration where the inlet flow is confined to directed flow over the secondary heat sources, and the underlying heat transfer mode is a conduction dominated bulk transfer mode.

Fig. 3
Fig. 3
Close modal

A small magnetically driven centrifugal pump with a 12 V direct current (DC) brushless motor located on the outlet side of the tank circulates fluid through the system. A DC power supply delivers a constant voltage signal to the pump. The voltage delivered and current drawn by the pump are logged by a workstation in 2 s intervals. The pump is equipped with a four-pin connector, which enables pulse width modulation for speed control from 1300 to 4500 rpm. A function generator is used to control the speed of the pump to achieve the desired volumetric flow rate to the inlet of the tank.

Heat is rejected from the oil to the laboratory environment via two 240 mm radiators constructed of two-pass, single row brass tubes with louvered copper fins. Each radiator is equipped with two 120 mm 12 V DC brushless motor fans. A DC power supply delivers a constant voltage signal to the fans. The voltage delivered and current drawn by the fans are logged by the workstation. The fans are equipped with four-pin connectors, which enable PWM speed control from 1650 to 5100 rpm. A function generator is used to control the speed of the fans to achieve the desired inlet temperature to the tank containing the server.

An Omega FLMH-1402AL in-line flow meter is used to record the volumetric flow rate of the oil. The flow meter has a scale accuracy of ±4%. The meter is rated for oils with a specific gravity of 0.873. This leads to a correction factor of 1.0% for the oil used in the current system. The flow meter is placed midway between the outlet and inlet sections of the immersion tank. As this is an analog device, it is visually monitored throughout a given test, with the values at the conclusion of the test reported. Although mineral oils have relatively high volumetric expansion rates (β = 0.0007 1/K), it is assumed that the volumetric flow rate is conserved from the point of flow measurement to inlet of the immersion tank. In actual testing, the fans on the second radiator in the loop were not needed to maintain inlet temperatures and it is assumed that temperature change between flow meter and tank inlet is minimal and any resulting change in density is negligible.

An Omega Universal Serial Bus data logger is used to record the laboratory ambient air conditions in 1 min intervals with an accuracy of ±1.0 °C.

The oil inlet temperature of the tank is measured using T-type thermocouples placed in the stream of the flow, 25 mm (1 in) upstream of the inlet ports to the tank. These thermocouples have an accuracy of ±0.5 °C and are used to maintain the tank inlet temperature to within ±0.5 °C of the desired value. Similar thermocouples are 25 mm (1 in) downstream of the outlet ports to measure the temperature difference of the oil across the server.

The material specifications of the technical grade white mineral oil are given in Table 1. In total, 11.4 L (3 gal) of oil are used to fill the system (tank, radiators, and tubing). This allows the tank to be filled to a height of 6.99 cm (2.75 in), completely submerging the server to just above the top of the extruded heat sinks. This leaves an air column height of 12.1 cm (4.75 in) between the top free surface of the oil and the lid of the container. The system piping consists of 1.27 cm (0.5 in) inner diameter vinyl tubing covered with 1.27 cm (0.5 in) foam insulation. This size tubing allows the system to maintain low velocity, laminar flow, reducing system pressure losses.

Table 1

Mineral oil physical properties

 Specific gravity 0.8555 Density 0.8493 g/cm3 Kinematic viscosity <16.02 mm2/s ASTM D445 Kinematic viscosity temperature 40 °C
 Specific gravity 0.8555 Density 0.8493 g/cm3 Kinematic viscosity <16.02 mm2/s ASTM D445 Kinematic viscosity temperature 40 °C

T-type thermocouples are attached with epoxy to the surface of 11 components across the motherboard. The components monitored represent a range of component types (chipsets, voltage regulators (VRDs), dual in line memory module (DIMM) chips) to provide a survey of the thermal performance of the two cooling methods being tested. Of these components, the voltage regulators have the most sensitive thermal requirements, with a maximum safe operating temperature of 85 °C. If VRDs exceed this limit, they begin to throttle and degrade the overall compute performance of the system. Thermocouples are also placed in three bulk fluid locations, as well as in two locations in the air gap above the oil to help establish when steady-state conditions are reached. These thermocouples have error limits of ±1.0 °C and are connected to a data acquisition system, which records their values in 5 s intervals.

The total server power consumption is measured using a Yokogawa CW121 power meter by connecting voltage and current clamps to the incoming power feed to the server. Power consumption data are recorded in 5 s intervals and logged on the workstation.

### Compute Load Generation and Data Collection.

To generate a computational workload on the server, a synthetic load generation program is employed. The lookbusy software tool allows users to set predefined CPU, memory, I/O, and networking utilization targets [23]. For this study, a workload of 75% CPU utilization with 20% memory allocation is used as design conditions. This level of workload represents high activity that would be desired in operational service and generates near maximum heat output for the server. The native Linux operating system monitoring tools mpstat and free are used to record CPU and memory utilization levels, respectively. An internal diagnostic tool provided by the motherboard manufacturer reports data from dynamic temperature sensor sensors in the processors, as well as, rpm readings from Hall sensors in the internal server fans.

The primary heat-generating components and main driver for optimizing thermal management in the particular server under study are the CPUs. As such, CPU die temperature is the main metric of concern for this study; however, understanding and monitoring of other motherboard components is important to the overall health of the server system.

### Test Procedure.

The system oil was set to a desired inlet volumetric flow rate via speed control of the pump. By adjusting the speed of the radiator fans, a desired oil inlet temperature could be achieved. This process was typically iterative, and required several adjustments to achieve steady-state conditions. The values reported here are averages over the course of at least 1 h of steady-state conditions, which is defined as within ±0.1 lpm and ±0.5 °C of the targeted volumetric flow rate and oil inlet temperature, respectively. Since typical real-time workloads in data centers are not constant over long durations, the values presented here may represent worst-case conditions given the transient times required to achieve steady-state. Figure 4 shows the temperature of several variables over the course of a test. These temperatures are the oil MB inlet temperature, which was a defining parameter of the test case, MB outlet temperature, temperature in the bulk fluid at a location in the vicinity of the center of the motherboard at a depth of about 2.54 cm (1 in) from the free surface of the oil, and temperature of the air gap between the top surface of the oil and the lid of the test container. It can be seen that the time to reach steady-state values can take 30 min or more depending on the initial condition. Average steady-state values over a period of at least 1 h are reported here forth.

Fig. 4
Fig. 4
Close modal

The test range studied included oil inlet temperatures from 30 °C to 50 °C, in increments of 5 °C. The volumetric flow rate is varied from 0.5 lpm to 2.5 lpm in increments of 0.5 lpm. However, at 30 °C and 35 °C inlet temperature, a flow rate of 2.5 lpm was not achievable because the oil viscosity caused the pressure drop through the system to be prohibitively high, as will be discussed. The results/data points corresponding to higher flow rates at 30 °C and 35 °C inlet temperature have been left blank, as will be apparent in the Results and Discussion section.

## Results and Discussion

### Air-Cooled Baseline Results.

The results of the preliminary air-cooled testing are used to establish typical operating temperatures of the server. Table 2 lists the average temperature of four components during steady-state conditions after three repeated trials at the design compute conditions. Data recorded showed that all three of these runs occurred with an ambient inlet temperature of 25 °C ± 1.0 °C. These components are the CPU0 die temperature, the input/output hub (IOH) chip, a memory chip on the dual in line memory module, and a voltage regulator device located directly behind CPU1. These four components represent a variety of component types and spaced around the motherboard. The CPU0 die temperature of 74.0 °C can be used as a basis for comparison in the oil cooled results. This serves to represent an upper limit of desirable operating temperature for the CPUs. As a point of reference, the average power consumption of the server (IT components + internal server fans) during this testing was 222.4 W. Roughly 4 W, or less than 2% of this power, can be attributed to the fans required for cooling.

Table 2

Baseline temperature results of air-cooled testing

ComponentRun #1 (°C)Run #2 (°C)Run #3 (°C)Average (°C)
CPU074.173.973.974.0
IOH50.850.650.850.8
DIMM 1-B31.631.731.631.6
CPU1 VRD270.770.670.870.7
ComponentRun #1 (°C)Run #2 (°C)Run #3 (°C)Average (°C)
CPU074.173.973.974.0
IOH50.850.650.850.8
DIMM 1-B31.631.731.631.6
CPU1 VRD270.770.670.870.7

### Varying Oil Flow Rate and Inlet Temperature.

The resulting CPU die temperatures over the range of test conditions when using the MB flow path of the oil immersion setup are shown in Fig. 5. Ambient laboratory conditions were observed to be 25 °C ± 1.0 °C throughout the study. Quadratic curve fits are used to show the trends for increasing volumetric flow rates at given oil inlet temperatures. As should be expected, increasing the inlet flow rate at a given inlet temperature results in decreasing die temperatures. Increasing the flow rate from 0.5 lpm to 1.0 lpm produced the most significant impact on die temperature, resulting in a roughly 4.9 °C reduction when the inlet temperature was 30 °C. Figure 5 shows that increasing flow rate beyond 1.5 lpm begins to have diminishing returns, wherein the increase in pumping power does not correspond to a significant reduction of die temperature for the inlet temperatures studied. Using the 74.0 °C die temperature from the air cooling results as a benchmark; it seems feasible to use a range of these operating conditions to safely cool the server. All studied flow rates at inlet temperatures of 30 °C, 35 °C, and 40 °C provide suitable operating conditions. When the inlet temperature reaches 45 °C, flow rates beyond 1.5 lpm are needed to maintain CPU temperatures below the 74.0 °C threshold.

Fig. 5
Fig. 5
Close modal

When the PSU flow path was utilized, in which only the PSU inlet and outlet ports were open, resulting CPU temperatures were higher for given flow rates and inlet temperatures as seen in Fig. 6. These higher temperatures were to be expected, since the flow of oil across the CPU heat sinks is not directly focused from the container inlet as in the MB flow path case. Figure 6 also uses quadratic curve fits to highlight the trends with increasing flow rate; however, some of these trends are fairly linear. For example, at an inlet temperature of 35 °C, each 0.5 lpm increase in flow rate from 0.5 lpm to 2.0 lpm results in a roughly 2.3 °C reduction in CPU die temperature.

Fig. 6
Fig. 6
Close modal

Using the PSU flow path, inlet flow rate and inlet temperature conditions that result in 74.0 °C die temperature or less are greatly reduced. Here, flow rates of 1.0 lpm and above are needed at 35 °C inlet temperatures and flow rates of 2.0 lpm and above are needed at 40 °C inlet temperatures. These results indicate that ducting of flow over key components is of importance in an oil cooling system. Although the fluid velocities are low through heat sinks, bulk fluid motion of the system does not provide the same cooling performance as directed flow, particularly at lower flow rates.

### Partial Power Usage Effectiveness and System Power Consumption.

Power usage effectiveness has been widely adopted and used throughout as the standard efficiency metric for data centers. PUE, originated by Belady and others, determines data center efficiency by taking the total facility power consumed divided by IT load (useful work of the data center) [24]. Detailed description and development of the term can be found in Ref. [25]. Partial PUE (pPUE) metrics can be developed to understand efficiency of specific subsystems and subsets of the data center. pPUE of cooling systems can be expressed as follows:
(1)

Equation (1) represents the efficiency of just the cooling system. For the present test setup, the entire cooling loop may be thought of as representing a “complete” data center loop in which the heat rejected by the IT equipment is eventually rejected to an ambient air of 25 °C (77 °F) from the air-cooled radiators to the laboratory environment. The caveats to this assumption are discussed in the Additional Discussion section. The cooling energy is the sum of the power drawn by the centrifugal pump and radiator fans. Table 3 compiles the pPUECooling values obtained at the various conditions studied for the MB flow path case. Over the range of conditions studied, pPUECooling values as low as 1.027 are achievable; however, this does not necessarily coincide with the minimum total system power operating point. In the range of desired CPU temperatures (i.e., CPU0 DT < 74 °C), pPUECooling values range from 1.036 to 1.170. Similar values can be seen in Table 4 for the PSU flow path case.

Table 3

pPUECooling values at given tested operating conditions with the MB flow path

Oil inlet temperature (°C)

MB flow path
3035404550
Flow rate (lpm)0.51.0551.0361.0411.0301.027
1.01.0861.0511.0581.0391.035
1.51.1241.0681.0791.0531.046
2.01.1701.0881.1021.0721.059
2.51.1291.0951.075

Oil inlet temperature (°C)

MB flow path
3035404550
Flow rate (lpm)0.51.0551.0361.0411.0301.027
1.01.0861.0511.0581.0391.035
1.51.1241.0681.0791.0531.046
2.01.1701.0881.1021.0721.059
2.51.1291.0951.075
Table 4

pPUECooling values at given tested operating conditions with the PSU flow path

Oil inlet temperature (°C)

PSU flow path
3035404550
Flow rate (lpm)0.51.0561.0401.0371.027
1.01.0751.0581.0511.0381.035
1.51.0971.0801.0681.0531.047
2.01.1061.0871.0751.059
2.51.1091.1011.070

Oil inlet temperature (°C)

PSU flow path
3035404550
Flow rate (lpm)0.51.0561.0401.0371.027
1.01.0751.0581.0511.0381.035
1.51.0971.0801.0681.0531.047
2.01.1061.0871.0751.059
2.51.1091.1011.070

Although server power consumption was recorded for the air-cooled baseline test, this datum does not lend itself to pPUECooling calculations. Rough extrapolations as to the energy required by a computer room air conditioner-based or economizer-based system to achieve the 25 °C inlet air temperature would need to be made and are beyond the scope of the present work.

These results can be expanded to begin to understand efficiency of an oil immersion system at different ambient conditions. A maximum system approach temperature can be developed by taking the difference between the oil outlet temperature and ambient laboratory temperature. In this case, the oil outlet temperature is calculated using the measured inlet temperature plus the temperature rise, ΔT, across the server using the standard steady-flow thermal energy equation
$q=m˙cpΔT$
(2)

where q is the measured IT power, $cp$ is the oil’s specific heat, and $m˙$ is the mass flow rate, taken as the product of the oil’s density and measured system volume flow rate. The relation between the maximum system approach and system efficiency, shown in Fig. 7, is fit with an exponential curve as can be expected in heat exchanger analysis. These results are helpful to system designers to begin estimating the system efficiency over expanded ambient conditions. This cannot replace a detailed energy flow model of a facility but serves as a starting point for reference designs.

Fig. 7
Fig. 7
Close modal

PUE and pPUECooling alone do not provide a complete picture of the energy efficiency of a data center cooling scheme. With the goal of minimizing total facility power for a data center, all components’ energy consumption must be considered holistically. Figure 8 shows a surface plot of the minimization of total power consumption for the system for the MB flow path case. This includes the power to the server (IT load), the power consumed by the pump, and the power drawn by the radiator fans. It can be seen that the minimum power draw for the system occurs at 40 °C (104 °F) inlet temperature and 0.5 lpm flow rate. At this point, the CPU die temperature is 74.1 °C, just above the targeted upper limit. Although the best pPUECooling value occurred at an inlet flow rate of 0.5 lpm and 50 °C inlet temperature, the total system power at this point was 2% higher and had a CPU0 die temperature of 83.4 °C.

Fig. 8
Fig. 8
Close modal

The somewhat conflicting results of pPUECooling and total system power can best be understood by analyzing the individual system components (IT, pump, and fans). The general trends are as follows:

• IT power increases nonlinearly with CPU die temperature (and all component temperatures in general) due to leakage current effects in silicon devices. This trend is roughly quadratic as shown in Fig. 9, which shows the relation between CPU0 die temperature, the input/output hub, and one of CPU1’s VRDs with the total server power from the data collected in the MB Flow Path cases. All three of these components have similar trends with total server power. This is not a complete relation since the total server power depends on power consumption and leakage of all components on the MB and PSU, but it does provide a rough estimate of the general behavior. For example, increasing the CPU0 die temperature from 60 °C to 70 °C results in a roughly 2.3 W increase in total server power. Increasing the die temperature from 70 °C to 80 °C results in a 4.7 W increase in power consumption. There is certainly incentive to operate the server at lower component temperatures for this reason; however, it must be complimented with the rest of the system.

• It is known that the viscosity of oils vary with temperature. This has a direct impact on the system pressure and hence, pumping power required of the system. A standard correlation relating viscosity and temperature for transformer oils (similar to the light mineral oil used in this study) is given in Ref. [15] as
$μ=C1* Exp[2797.3T+273.2]$
(3)
where μ is the dynamic viscosity in centipoise, T is the temperature in  °C, and C1 is a coefficient for scaling (a value of 0.0013573 is provided in the reference for transformer oil). The interdependence of viscosity with Reynolds number (Re), Reynolds number with friction factor (f), and friction factor with pressure drop (Δp) for laminar flow [26,27]
$μ∝1Re∝f∝Δp$
(4)
should eventually manifest itself in the pumping power of the system by the relation
$Ppump=Δp*V˙$
(5)
where $V˙$ is the volumetric flow rate. Figure 10 shows suitable agreement with the pumping power required to maintain 1.0 lpm of flow rate in the immersion system for the MB flow path and the viscosity trend predicted by Eq. (3). Over the range of inlet temperatures studied, a 43.5% reduction in viscosity is predicted and an average reduction in pumping power of 42.6% is observed for a given flow rate.

Looking at the pumping power over the range of temperatures and flow rates studied, as in Fig. 11, it is easy to see that there is ample incentive to operate at higher temperatures. The curves in Fig. 11 are fit with cubic trend lines which should be expected from the pump affinity laws, which state that pump power is proportional to the cube of the impeller or shaft speed [28]. As stated earlier, increasing flow rate beyond 1.5 lpm did not correspond to a significant reduction of component temperatures while operating at oil inlet temperatures beyond 45 °C necessitates flow rates more than 1.5 lpm to maintain safe operating temperatures. In Fig. 12, for oil flow rates less than 1.5 lpm, the competing trends of nonlinear decrease in pumping power and nonlinear increase in IT power as oil temperature increases can be observed. These trends observed indicate a design opportunity in achieving an operating point with minimum power requirement.

For all cases studied, the flow is distinctly laminar, well below the transition regime. At the lower end, with a flow rate of 0.5 lpm and oil temperature of 30 °C, the Reynolds number within the system piping is ∼50. At the other extreme, with a flow rate of 2.5 lpm and oil temperature of 50 °C, the Reynolds number is ∼440. These values will become substantially lower as the flow enters the larger volume of the tank and flows across the server.

• At oil inlet temperatures of 35 °C and above, the radiator fans operate at idle speeds. At these low speeds, the radiator fans consume <1.2% of the total system power. Their impact on pPUECooling values over the operating conditions is relatively constant.

Fig. 9
Fig. 9
Close modal
Fig. 10
Fig. 10
Close modal
Fig. 11
Fig. 11
Close modal
Fig. 12
Fig. 12
Close modal

Understanding these interrelated trends of system components is central to selecting the optimal operating conditions for an oil immersion cooled system. The results presented here for the MB flow path and PSU flow path cases provide some initial bounding operating conditions for an oil cooled system. Since the MB flow path can be considered a “better” case scenario for the cooling, it can utilize higher temperature fluids and lower flow rates.

### Comparison to Air-Cooled Baseline Results.

Although a direct comparison of PUE is not possible between the air-cooled baseline tests and the oil immersion results, other performance parameters may be used. Thermal resistance to heat transfer between a device and coolant is given by
$Rth=Td−Tcq$
(6)

where Td is the device temperature, Tc is the incoming coolant temperature, and q is the heat dissipated by the device. In this way, a comparison between oil and air can be made by focusing on the critical device temperature, the CPU, and the server’s inlet coolant temperature divided by the total IT power of the system. From the air-cooled baseline tests, air provides a thermal resistance of 0.224 °C/W. Over all oil cases studied, oil provided a thermal resistance ranging from 0.128 to 0.175 °C/W, with an average resistance of 0.147 °C/W. This average value is a 34.4% improvement over the baseline air cooling case. This improved performance is consistent with the results reported in Ref. [20].

Comparisons of surface temperature measurements show improvements in thermal performance across all components on the motherboard. Table 5 compares the rise in surface temperature of components, Td, over the inlet coolant temperature, Tc, with a lower value being better. The air results are taken from baseline tests and oil results are the average temperature rise over all the MB flow path test conditions. The most significant improvements are seen across all voltage regulating devices for the CPUs, which are critical for power delivery to the CPUs. In all conditions, including 50 °C oil inlet temperature at a flow rate of 0.5 lpm, the VRDs exhibited lower surface temperatures than in the air-cooled baseline case. From a thermal reliability perspective, this is significant.

Table 5

Thermal performance comparison of motherboard component surface temperatures

ΔT = Td − Tc
ComponentAir (baseline)Oil (average)Percent reduction (%)
IOH26.918.730.5
DIMM1 VRD8.14.643.2
DIMM 1-A20.916.421.5
DIMM 1-B8.24.150.0
CPU1 VRD143.76.385.6
CPU1 VRD243.83.891.3
CPU0 VRD343.64.190.6
CPU0 VRD440.17.381.8
DIMM 0-A6.54.235.4
DIMM 0-B16.615.19.0
DIMM0 VRD7.24.438.9

ΔT = Td − Tc
ComponentAir (baseline)Oil (average)Percent reduction (%)
IOH26.918.730.5
DIMM1 VRD8.14.643.2
DIMM 1-A20.916.421.5
DIMM 1-B8.24.150.0
CPU1 VRD143.76.385.6
CPU1 VRD243.83.891.3
CPU0 VRD343.64.190.6
CPU0 VRD440.17.381.8
DIMM 0-A6.54.235.4
DIMM 0-B16.615.19.0
DIMM0 VRD7.24.438.9

### Additional Discussion.

The initial results of this study are helpful in establishing a range of flow requirements that can be expected on per server or per Watt basis for a data center oil cooling strategy. These figures may be helpful in design of a larger system and provide relative sizing requirements for pumps, heat exchangers, and system pressure drop. Other than using temperature difference across the server (ΔT) for the design criteria, which may be difficult to determine, these results establish flow requirements based on component temperatures, namely CPU, which are the critical elements of the system.

The efficiency values (pPUECooling) presented earlier are unique to the system being tested. Certain simplifications and modifications were required for laboratory testing that may not be in place in an actual data center implementation. A fully built oil immersion data center may contain additional heat exchanges (i.e., oil-to-water, water-to-air) before final rejection of heat to the environment. The additional exchanges and piping will require increased cooling energy consumption. However, larger components (pumps, fans, etc.) are generally more efficient than geometrically similar, smaller components. Because of these counteracting efficiency factors, the results here are expected to be indicative of what may be seen at larger scales.

As discussed in Ref. [21], this Open Compute server was strategically designed and optimized for air cooling. Many of the design aspects are beneficial in oil cooling, but it is expected that further optimization for oil cooling can be achieved. For example, the heat sinks may be better designed for oil flow conditions as fin efficiencies in liquid and air are markedly different. This modification may be especially helpful in the PSU flow path case in which heat transfer is mainly from bulk fluid motion. Modifications to the current system, such as the removal of the air duct and PSU chassis, present material savings that may not be achievable in standard air-cooled server designs.

Further enhancements to the system’s performance may be gained by more prudent selection of the oil used. Additional oil types such as vegetable oils and other mineral oils may provide better heat transfer and fluid characteristics compared to the white mineral oil used for this study. In general, there are a wide range of topics that can be explored to better understand this promising cooling technique.

## Conclusion

The purpose of this work was to establish the general operating trends that may be seen in an oil immersion cooled data center setup. By operating a single server fully immersed in mineral oil and varying volumetric flow rate and oil inlet temperature, bounding environmental operating conditions were established. From these results, it is possible to utilize oil inlet temperatures up to 45 °C for cooling. pPUECooling values ranging from 1.03 to 1.17 were achieved in the current experimental setup. Comparison with baseline air cooling tests showed 34.4% reduction in the thermal resistance of the system and significant reduction in the temperature difference between component surfaces and the inlet coolant. Improvements to system and hardware design may increase the efficiency and potential for use of oil cooling in data centers. Future work in this area could include optimizing heat sinks for oil cooling, constructing a larger experimental setup to understand how efficiency scales with size, understanding dynamic loading effects of IT equipment in mineral oil, exhaustive reliability studies, and understanding servicing challenges present in an oil immersed data center.

## Funding Data

• National Science Foundation (Grant No. 1134821).

## Nomenclature

• $cp$ =

specific heat

•
• f =

friction factor

•
• $m˙$ =

mass flow rate

•
• $Ppump$ =

pumping power

•
• q =

total server power dissipated

•
• $Rth$ =

thermal resistance

•
• Re =

Reynolds number

•
• $Tc$ =

coolant inlet temperature

•
• $Td$ =

device temperature

•
• $V¯$ =

volumetric flow rate

•
• $Δp$ =

pressure drop

•
• $ΔT$ =

temperature difference across server

•
• $μ$ =

dynamic viscosity

## References

1.
ASHRAE TC 9.9
,
2015
, Thermal Guidelines for Data Processing Environments, 4th ed., ASHRAE Datacom Series, ASHRAE, Atlanta, GA.
2.
Alkharabsheh
,
S.
,
Fernandes
,
J.
,
Gebrehiwot
,
B.
,
Agonafer
,
D.
,
Ghose
,
K.
,
Ortega
,
A.
,
Joshi
,
Y.
, and
Sammakia
,
B.
,
2015
, “
A Brief Overview of Recent Developments in Thermal Management in Data Centers
,”
ASME J. Electron. Packag.
,
137
(
4
), p.
040801
.
3.
Ellsworth
,
M. J.
, Jr.
, and
Iyengar
,
M. K.
,
2009
, “
Energy Efficiency Analyses and Comparison of Air and Water Cooled High Performance Servers
,”
ASME
Paper No. InterPACK2009-89248.
4.
Carbó
,
A.
,
Oró
,
E.
,
Salom
,
J.
,
Canuto
,
M.
,
Macías
,
M.
, and
Guitart
,
J.
,
2016
, “
Experimental and Numerical Analysis for Potential Heat Reuse in Liquid Cooled Data Centres
,”
Energy Convers. Manage.
,
112
, pp.
135
145
.
5.
Chu
,
R. C.
,
Hwang
,
U. P.
, and
Simons
,
R. E.
,
1982
, “
Conduction Cooling for an LSI Package: A One-Dimensional Approach
,”
IBM J. Res. Dev.
,
26
(
1
), pp.
45
54
.
6.
Fernandes
,
J.
,
Ghalambor
,
S.
,
Docca
,
A.
,
Aldham
,
C.
,
Agonafer
,
D.
,
Chenelly
,
E.
,
Chan
,
B.
, and
Ellsworth
,
M.
, Jr.
,
2013
, “
Combining Computational Fluid Dynamics (CFD) and Flow Network Modeling (FNM) Design of a Multi-Chip Module (MCM) Cold Plate
,”
ASME
Paper No. IPACK2013-73294.
7.
Ovaska
,
S. J.
,
Dragseth
,
R. E.
, and
Hanssen
,
S. A.
,
2016
, “
Direct-to-Chip Liquid Cooling for Reducing Power Consumption in a Subarctic Supercomputer Centre
,”
Int. J. High Perform. Comput. Networking
,
9
(
3
), pp.
242
249
.
8.
ASHRAE TC 9.9
,
2011
, “
2011 Thermal Guidelines for Liquid Cooled Data Processing Environments
,” ASHRAE, Atlanta, GA.
9.
Incropera
,
F. P.
,
1999
,
Liquid Cooling of Electronic Devices by Single-Phase Convection
,
Wiley-Interscience Publication
,
New York
.
10.
Anderson
,
T. M.
, and
Mudawar
,
I.
,
1989
, “
Microelectronic Cooling by Enhanced Pool Boiling of a Dielectric Fluorocarbon Liquid
,”
ASME J. Heat Transfer
,
111
(
3
), pp.
752
759
.
11.
Tuma
,
P.
,
2010
, “
The Merits of Open Bath Immersion Cooling of Datacom Equipment
,”
26th Annual IEEE Semiconductor Thermal Measurement and Management Symposium
(
SEMI-THERM
), Santa Clara, CA, Feb. 21–25, pp.
123
131
.
12.
Arik
,
M.
,
2007
, “
Enhancement of Pool Boiling Critical Heat Flux in Dielectric Liquids by Microporous Coatings
,”
Int. J. Heat Mass Transfer
,
50
(5–6), pp.
997
1009
.
13.
El-Genk
,
M. S.
,
2012
, “
Immersion Cooling Nucleate Boiling of High Power Computer Chips
,”
Energy Convers. Manage.
,
53
(
1
), pp.
205
218
.
14.
Warrier
,
P.
,
Sathyanarayana
,
A.
,
Patil
,
D. V.
,
France
,
S.
,
Joshi
,
Y.
, and
Teja
,
A. S.
,
2012
, “
Novel Heat Transfer Fluids for Direct Immersion Phase Change Cooling of Electronic Systems
,”
Int. J. Heat Mass Transfer
,
55
(13–14), pp.
3379
3385
.
15.
Pierce
,
L. W.
,
1992
, “
An Investigation of the Thermal Performance of an Oil Filled Transformer Winding
,”
IEEE Trans. Power Delivery
,
7
(
3
), pp.
1347
1358
.
16.
Taha-Tijerina
,
J. J.
,
Narayana
,
T.
,
Tiwary
,
C. S.
,
Lozano
,
K.
,
Chipara
,
M.
, and
Ajayan
,
P. M.
,
2014
, “
Nanodiamond-Based Thermal Fluids
,”
ACS Appl. Mater. Interfaces
,
6
(
7
), pp.
4778
4785
.
17.
Jones
,
P.
,
2012
, “
Data Center Dynamics
,” Data Center Dynamics Ltd., London, accessed Nov. 15, 2013, http://www.datacenterdynamics.com/focus/archive/2012/09/intel-says-liquid-and-servers-do-mix
18.
Fulton
,
S.
, III
,
2017
, “
Data Center Knowledge
,” Data Center Knowledge, San Francisco, CA, accessed June 2, 2017, http://www.datacenterknowledge.com/archives/2017/05/01/data-center-cooling-how-practical-is-dunking-servers-in-oil/
19.
Prucnal
,
D.
,
2013
, “
Doing More With Less: Cooling Computers With Oil Pays Off
,”
Next Wave
,
20
(
2
), pp.
20
29
.http://www.grcooling.com/wp-content/uploads/2015/06/NSA-The-Next-Wave.pdf
20.
Patterson
,
M.
, and
Best
,
C.
,
2012
, “
Oil Immersion Cooling and Reductions In Data Center Energy Use
,”
ASHRAE Summer Conference
, San Antonio, TX, June 23–27.
21.
Frachtenberg
,
E.
,
Heydari
,
A.
,
Li
,
H.
,
Michael
,
A.
,
Na
,
J.
,
Nisbet
,
A.
, and
Sarti
,
P.
,
2011
, “
High-Efficiency Server Design
,”
International Conference for High Performance Computing
, Networking, Storage, and Analysis (
SC
), Seattle, WA, Nov. 12–18, pp. 1–11.
22.
Li
,
H.
, and
Michael
,
A.
,
2011
, “
Intel Motherboard Hardware v1.0
,” Open Compute Project, accessed Nov. 22, 2013, http://www.opencompute.org/projects/intel-motherboard/
23.
Carraway
,
D.
,
2013
, “
Lookbusy: A Synthetic Load Generator
,” Look Busy, accessed Aug. 18, 2017, http://www.devin.com/lookbusy
24.
The Green Grid
,
2008
, “
The Green Grid Data Center Power Efficiency Metrics: PUE and DCiE
,” The Green Grid Administration, Beaverton, OR, White Paper No.
6
.http://www.premiersolutionsco.com/wp-content/uploads/TGG_Data_Center_Power_Efficiency_Metrics_PUE_and_DCiE.pdf
25.
The Green Grid
,
2012
, “
PUE™: A Comprehensive Examination of the Metric
,” The Green Grid Administration, Beaverton, OR, White Paper No.
49
.https://datacenters.lbl.gov/sites/all/files/WP49-PUE%20A%20Comprehensive%20Examination%20of%20the%20Metric_v6.pdf
26.
Godfrey
,
D.
, and
Herguth
,
W. R.
,
1996
, Physical and Chemical Properties of Industrial Mineral Oils Affecting Lubrication—Parts 1–5,
Society of Tribologists and Lubrication Engineers
, Park Ridge, IL.
27.
Eiland
,
R.
,
Fernandes
,
J.
,
Vallejo
,
M.
,
Agonafer
,
D.
, and
Mulay
,
V.
,
2014
, “
Flow Rate and Inlet Temperature Considerations for Direct Immersion of a Single Server in Mineral Oil
,” IEEE Intersociety Conference on Thermal and Thermomechanical Phenomena in Electronic Systems (
ITherm
), Orlando, FL, May 27–30, pp.
706
714
.
28.
White
,
F. M.
,
2011
,
Fluid Mechanics
, 7th ed.,
McGraw-Hill
,
New York
.


text:
# zoj 2406 Specialized Four-Digit Numbers

+关注继续查看
Specialized Four-Digit Numbers
Time Limit: 2 Seconds      Memory Limit: 65536 KB

Find and list all four-digit numbers in decimal notation that have the property that the sum of its four digits equals the sum of its digits when represented in hexadecimal (base 16) notation and also equals the sum of its digits when represented in duodecimal (base 12) notation.

For example, the number 2991 has the sum of (decimal) digits 2+9+9+1 = 21. Since 2991 = 1*1728 + 8*144 + 9*12 + 3, its duodecimal representation is 189312, and these digits also sum up to 21. But in hexadecimal 2991 is BAF16, and 11+10+15 = 36, so 2991 should be rejected by your program.

The next number (2992), however, has digits that sum to 22 in all three representations (including BB016), so 2992 should be on the listed output. (We don't want decimal numbers with fewer than four digits - excluding leading zeroes - so that 2992 is the first correct answer.)

Input

There is no input for this problem.

Output

Your output is to be 2992 and all larger four-digit numbers that satisfy the requirements (in strictly increasing order), each on a separate line with no leading or trailing blanks, ending with a new-line character. There are to be no blank lines in the output. The first few lines of the output are shown below.

Sample Input

There is no input for this problem.

Sample Output

2992
2993
2994
2995
2996
2997
2998
2999

（1）题意很简单，就是求各种进制下数字之和相等的四位数。16进制和12进制求解过程就是分解成因子的形式计算，先求出能组成这些数字的因子的所有情况，然后组合求出每个因子的系数返回相加之和即可。

#include <stdio.h>

int i;
int base_duo[4] = {1,12,144,1728};
int base_hex[4] = {1,16,256,4096};

//得到12进制的数字之和
int get_sum_duo(int num)
{
int ex[4]={0},sum=0;
for(i=3;i>=0;i--)
{

if(num>=base_duo[i])
{
num -= base_duo[i];
ex[i]++;
i++;
}
}
for(i=0;i<4;i++)
sum+=ex[i];
return sum;
}

//得到16进制的数字之和
int get_sum_hex(int num)
{
int ex[4]={0},sum=0;
for(i=3;i>=0;i--)
{
if(num>=base_hex[i])
{
num -= base_hex[i];
ex[i]++;
i++;
}
}
for(i=0;i<4;i++)
sum+=ex[i];
return sum;
}
//得到10进制之和
int get_sum(int num)
{
int sum=0;
while(num>0)
{
sum += num%10;
num /=10;
}
return sum;
}

int main()
{
int j,tem;
for(j=2992;j<10000;j++)
{
tem = get_sum(j);
if(get_sum_duo(j)==tem&&get_sum_hex(j)==tem)
printf("%d\n",j);
}
return 0;
}

HDU-1061，Rightmost Digit（快速幂）
HDU-1061，Rightmost Digit（快速幂）
0 0
poj 2406 Power Strings【KMP】

506 0
zoj 3690 Choosing number

566 0
poj 1150 The Last Non-zero Digit

538 0
+关注

format: plain


text:
# Nonstationary Generalized TASEP in KPZ and Jamming Regimes

@article{Derbyshev2020NonstationaryGT,
title={Nonstationary Generalized TASEP in KPZ and Jamming Regimes},
author={A. E. Derbyshev and A. M. Povolotsky},
journal={Journal of Statistical Physics},
year={2020},
volume={185}
}
• Published 1 December 2020
• Physics
• Journal of Statistical Physics
We study the model of the totally asymmetric exclusion process with generalized update, which compared to the usual totally asymmetric exclusion process, has an additional parameter enhancing clustering of particles. We derive the exact multiparticle distributions of distances travelled by particles on the infinite lattice for two types of initial conditions: step and alternating ones. Two different scaling limits of the exact formulas are studied. Under the first scaling associated to Kardar…

## References

SHOWING 1-10 OF 82 REFERENCES

• Mathematics
Communications in Mathematical Physics
• 2019
We investigate a rich new class of exactly solvable particle systems generalizing the Totally Asymmetric Simple Exclusion Process (TASEP). Our particle systems can be thought of as new exactly
• Physics
Physical review. E, Statistical, nonlinear, and soft matter physics
• 2015
A crossover parameter is identified and the large deviation function for particle current is derived, which interpolates between the case considered by Derrida-Lebowitz and a single-particle diffusion.
We consider the $q$-Hahn TASEP which is a three-parameter family of discrete time interacting particle systems. The particles jump to the right independently according to a certain $q$-Binomial
• Mathematics
• 2008
In this paper we obtain general integral formulas for probabilities in the asymmetric simple exclusion process (ASEP) on the integer lattice $${\mathbb{Z}}$$ with nearest neighbor hopping rates p to
• Mathematics
• 2012
We study the joint exit probabilities of particles in the totally asymmetric simple exclusion process (TASEP) from space–time sets of a given form. We extend previous results on the space–time
• Mathematics
• 2010
The totally asymmetric simple exclusion process (TASEP) on\input amssym ${\Bbb Z}$ with the Bernoulli‐ρ measure as an initial condition, 0 < ρ < 1, is stationary. It is known that along the
Brownian motion is a continuum scaling limit for a wide class of random processes, and there has been great success in developing a theory for its properties (such as distribution functions or
• Mathematics
Probability Theory and Related Fields
• 2018
We consider the q-totally asymmetric simple exclusion process (q-TASEP) in the stationary regime and study the fluctuation of the position of a particle. We first observe that the problem can be
• Mathematics
Physical review. E
• 2016
A quadratic algebra is constructed and an analytic expression for the finite-size pair correlation function is obtained in the limit of irreversible aggregation p[over ̃]→1, when the stationary configurations contain just one cluster.
• Computer Science
• 2007
In this paper the totally asymmetric simple exclusion process is considered, a model in the KPZ universality class, and its one‐point distribution is a new interpolation between GOE and GUE edge distributions.


text:
# Homotopy Type Theory pushout (changes)

Showing changes from revision #2 to #3: Added | Removed | Changed

## Idea

Many constructions in homotopy theory are special cases of pushouts. Although when being defined sometimes it may be clearer to define the construction as a seperate higher inductive type and then later on prove it is equivalent? to the pushout definition.

## Definition

The (homotopy) pushout of a span $A \xleftarrow{f} C \xrightarrow{g} B$ is the higher inductive type  A \sqcup_{C} \sqcup^{C}_{f ; g} B generated (or by:$A \sqcup^C B$) generated by:

• a function  inl : A \to A \sqcup_{C} \sqcup^{C} B
• a function  inr : B \to A \sqcup_{C} \sqcup^{C} B
• for each $c:C$ a path $glue(c) : inl (f (c)) = inr (g( c))$


text:
## Monday, June 02, 2008

### Java to Scala - Smaller Inheritance hierarchies with Structural Typing

I was going through a not-so-recent Java code base that contained the following structure for modeling the employee hierarchy of an organization. This looks quite representative of idiomatic Java being used to model a polymorphic hierarchy for designing a payroll generation application.

public interface Salaried {  int salary();}public class Employee implements Salaried {  //..  //.. other methods  @Override  public int salary() {    // implementation  }}public class WageWorker implements Salaried {  //..  //.. other methods  @Override  public int salary() {    // implementation  }}public class Contractor implements Salaried {  //..  //.. other methods  @Override  public int salary() {    // implementation  }}

And the payroll generation class (simplified for brevity ..) that actually needs the subtype polymorphism between the various concrete implementations of the Salaried interface.

public class Payroll {  public int makeSalarySheet(List<Salaried> emps) {    int total = 0;    for(Salaried s : emps) {      total += s.salary();    }    return total;  }}

While implementing in Java, have you ever wondered whether using public inheritance is the best approach to model such a scenario ? After all, in the above class hierarchy, the classes Employee, WageWorker and Contractor does not have *anything* in common except the fact that all of them are salaried persons and that subtype polymorphism has to be modeled *only* for the purpose of generating paysheets for all of them through a single API. In other words, we are coupling the entire class hierarchy through a compile time static relationship only for the purpose of unifying a single commonality in behavior.

Public inheritance has frequently been under fire, mainly because of the coupling that it induces between the base and the derived classes. Experts say Inheritance breaks Encapsulation and also regards it as the second strongest relationship between classes (only next to friend classes of C++). Interface driven programming has its advantages in promoting loose coupling between the contracts that it exposes and their concrete implementations. But interfaces in Java also pose problems when it comes to evolution of an API - once an interface is published, it is not possible to make any changes without breaking client code. No wonder we find design patterns like The Extension Object or strict guidelines for evolution of abstractions being enforced in big projects like Eclipse.

Finer Grained Polymorphism

Structural typing offers the ability to reduce the scope of polymorphism only over the subset of behaviors that need to be common between the classes. Just as in duck typing, commonality in abstractions does not mean that they belong to one common type; but only the fact that they respond to a common set of messages. Scala offers the benefit of both the worlds through its implementation of structural typing - a compile time checked duck typing. Hence we have a nice solution to unify certain behaviors of otherwise unrelated classes. The entire class hierarchy need not be related through static compile time subtyping relationship in order to be processed polymorphically over a certain set of behaviors. As an example, I tried modeling the above application using Scala's structural typing ..

case class Employee(id: Int) { def salary: Int = //.. }case class DailyWorker(id: Int) { def salary: Int = //.. }case class Contractor(id: Int) { def salary: Int = //.. }class Payroll {  def makeSalarySheet(emps: List[{ def salary: Int }]) = {    (0 /: emps)(_ + _.salary)  }}val l = List[{ def salary: Int }](DailyWorker(1), Employee(2), Employee(1), Contractor(9))val p = new Payrollprintln(p.makeSalarySheet(l))

The commonality in behavior between the above classes is through the method salary and is only used in the method makeSalarySheet for generating the payroll. We can generalize this commonality into an anonymous type that implements a method having the same signature. All classes that implement a method salary returning an Int are said to be structurally conformant to this anonymous type { def salary: Int }. And of course we can use this anonymous type as a generic parameter to a Scala List. In the above snippet we define makeSalarySheet accept such a List as parameter, which will include all types of workers defined above.

Actually it gets better than this with Scala. Suppose in the above model, the name salary is not meaningful for DailyWorkers and the standard business terminology for their earnings is called wage. Hence let us assume that for the DailyWorker, the class is defined as ..

case class DailyWorker(id: Int) { def wage: Int = //.. }

Obviously the above scheme will not work now, and the unfortunate DailyWorker falls out of the closure of all types that qualify for payroll generation.

In Scala we can use implicit conversion - I call it the Smart Adapter Pattern .. we define a conversion function that automatically converts wage into salary and instructs the compiler to adapt the wage method to the salary method ..

case class Salaried(salary: Int)implicit def wageToSalary(in: {def wage: Int}) = Salaried(in.wage)

makeSalarySheet api now changes accordingly to process a List of objects that either implement an Int returning salary method or can be implicitly converted to one with the same contract. This is indicated by <% and is known as a view bound in Scala. Here is the implementation of the class Payroll that incorporates this modification ..

class Payroll {  def makeSalarySheet[T <% { def salary: Int }](emps: List[T]) = {    (0 /: emps)(_ + _.salary)  }}

Of course the rest of the program remains the same since all conversions and implicit magic takes place with the compiler .. and we can still process all objects polymorphically even with a different method name for DailyWorker. Here is the complete source ..

case class Employee(id: Int) { def salary: Int = //.. }case class DailyWorker(id: Int) { def salary: Int = //.. }case class Contractor(id: Int) { def wage: Int = //.. }case class Salaried(salary: Int)implicit def wageToSalary(in: {def wage: Int}) = Salaried(in.wage)class Payroll {  def makeSalarySheet[T <% { def salary: Int }](emps: List[T]) = {    (0 /: emps)(_ + _.salary)  }}val l = List[{ def salary: Int }](DailyWorker(1), Employee(2), Employee(1), Contractor(9))val p = new Payrollprintln(p.makeSalarySheet(l))

With structural typing, we can afford to be more conservative with public inheritance. Inheritance should be used *only* to model true subtype relationship between classes (aka LSP). Inheritance definitely has lots of uses, we only need to use our judgement not to misuse it. It is a strong relationship and, as the experts say, always try to implement the least strong relationship that correctly models your problem domain.

Alaz said...

I've caught the whole idea, many thanks for the post, but there is some discrepancy in your last sample: what's the idea of declaring makeSalarySheet with view bound, while you make an implicit conversion of Contractor to Salaried in the List instantiation already -- as far as I understand the List already contains Salaried...

gambistics said...

I think you are not quite precise. You are talking about implementing an interface as if it was inheritance which it isn't.

Implementing an interface is like a marker. You specify that you adhere to a specific contract identified by the name and the package of the interface.

If you use structural subtyping you rely on a contract as well: That the implementing class has the method of the specified type and has the right semantics.

But: An interface and the contained type themselves don't specify the contract alone. The contract is made up from the interface specification in the programming language AND the written documentation which furtherly defines the expected semantics. And then it's given a name within a namespace.

If you implement the interface you explicitly say that you have understood what the interface (the contract) is about.

What you are proposing (which btw is exactly the same with duck typing) is omitting the namespace from a contract and solely relying on the types and the name of a method as a contract. That might be the right thing in smaller environments since there probably won't be any naming conflicts. In the large it probably will break sooner or later.
(For example if some consumer of your objects expects different semantics from their method salary:Int)

To sum up: interfaces and structural subtyping have the same purpose but different extents.

Interfaces are (hopefully) immutable and embedded in a namespace uniquely identifiable while structural subtyping only scratches the surface of a specification.

And the responsibilities are shifted: Implementors of interfaces have to make sure their implementation adheres to the documented interface semantics when implementing but the implementations are free to be used in that sense afterwards (as a perfectly valid example of the mentioned LSP btw). If you use structural subtyping you have to check the semantics when calling a consumer. So the consumer has to be documented to include some information what type of objects it expects.

Debasish said...

@gambistics: I fully agree with what u say and have never doubted the benefits of using interfaces and subtype polymorphism. But structural types allow implementing a level of polymorphism at a much lower granularity than the entire type hierarchy. I can say that Employee, Contractor and WageWorker do not have a common contract as far as the types are concerned. They are only related by the commonality that each of them needs to implement a method salary() that returns an Int (or a conversion thereof). This definitely can lead to accidental conformity with other unrelated types that implement the method with the same signature. But in Java we have lots of instances where there has been a plethora of interface explosion just for the sake of implementing fine grained commonality between otherwise unrelated classes. Structural typing provides a nice work around for such cases.
And u r right - this is nothing but duck typing. And for Scala it is statically checked duck typing.

Cedric said...

Hi Debasish,

In my experience, structural typing looks cute on the outside but doesn't scale when the type you are describing becomes more complex. Very quickly, you find yourself with a lot of repetition in your code which makes it 1) harder to read and 2) better captured in an interface or a trait that will convey the intent in a much more meaningful manner than a loose list of methods and properties.

More details here: http://beust.com/weblog/archives/000476.html

--
Cedric

Cedric said...

About your previous comment: actually, I see things from the opposite direction. Structural typing allows accidental matches from objects that do not necessarily conform to the contract you are expecting. Implementing an interface by accident is, on the other hand, extremely unlikely.

I don't see any problems with an explosion of interfaces. If they allow the developer to describe the problem space more accurately, then more power to both producers and consumers of that code. This is actually a direction that has intrigued me for a while, which I called "Quantum Software Design" a few years ago (http://beust.com/weblog/archives/000312.html) and that Rickard explores in much more depth under the name "Composite Oriented Programming" in his framework Qi4j (http://www.qi4j.org/).

Debasish said...

@cedric: Hi Cedric -
Thanks for visiting my blog!

I know you r a big proponent of interface based programming. However, sometimes I feel that people tend to overuse interfaces in Java. Like the example that I have mentioned in my post, the employee types do not have anything in common except the salary part. Do u think it is still better to model them based on a common supertype because of the fact that all of them get paid through a common interface ? Don't u feel that we r trying to couple them at a much bigger level through subtype polymorphism than the commonality that they deserve ? And that, for this case structural typing implements the level of polymorphism at a much smaller level, the method level, which they actually are, rather than the entire type level.

What do u think ?

Cedric said...

Hi Debasish,

I've been an avid reader of your blog for a while, today is just one of the few times where I disagree with some of your points :-)

Of course, interfaces can be abused, but I really don't think that the number of methods should be the deciding factor in the decision to use one, which is what you seem to imply here ("it's just one method, it's not worth introducing an interface for this"). I am absolutely fine with the idea of introducing an interface that only contains one method as long as it makes semantic sense. I much prefer to read ConvertibleToXml than looking inside a structural type for a method toXml() which might explain what this type is for. Or not. And if you expand this structural type to more than one method, it becomes extremely hard to justify its existence at all.

Also, to echo a point made above: to me, interfaces define contracts much more than they define a common subtype, so I don't see them increasing heavy coupling as much as you do (quite the opposite, actually).

My biggest gripe with structural typing remains the blatant violation of the DRY principle. Imagine three methods accepting the same structural type made of three methods or properties, and you are now facing code that is painfully redundant, needlessly verbose and that is screaming to your face "refactor me!".

Anyway, good stuff, keep it up!

--
Cedric

Daniel said...

You can actually do a little better than forcing the existing of a Salaried class:

implicit def wageToSalary(in: {def wage: Int}) = new {
def salary = in.wage
}

With respect to the suitability of structural types, I agree that this is probably a bad example. In this particular case, I would have used a superclass or trait instead of going with an anonymous interface (structural type).

On the flip side, I disagree that structural typing has no place in good OO design. There was a situation I ran into recently where structural typing saved a huge mess of contrived inheritance, making my life just that much easier. I'll agree that it's not a silver bullet, but it's still a nice tool to keep in your back pocket for when you really need it.

Debasish said...

Hi Cedric / Daniel -

I am not claiming that structural typing is a substitute for public inheritance or interface based programming in Java. But I think it addresses one of the weaknesses of Java type systems. In Java you have to statically bind a class to an interface in order to use the contract. In a way this is good since it enforces a discipline in how abstractions evolve. But it also robs us of the flexibility to adapt classes dynamically to an existing hierarchy based on methods that they implement. In the example that I have posted in the blog, if I had to adapt some employees from other systems that *do* not implement the specific Salaried interface (and I do not have access to that source code as well), there is no way in Java that I can treat them polymorphically in my paysheet generation routine. And structural typing offers an alternative towards this.

What do u think ?

gambistics said...

I would say, it changes not much.

In the most general case structural typing is as statically bound to the specific consumer as interfaces are bound to some implementation.

If you code your consumer(Payroll) you tailor it to fit onto a specific class(e.g. Employee). That more classes have {def salary:Int} defined with the right semantics is just coincidence. (The ruby guys would probably object because they say it would be the obvious thing, but obviousness and intuition are tricky things to come up with concrete decisions)
For other classes(DailyWorker) you need the adapter pattern which is the same situation you would be in if you had used interfaces.

While being somewhat critized I think adaptation is a natural pattern: First you have the Employee classes, then you have a consumer which needs a specific aspect of it. Then you have to think about how each Employee class is salaried ie fits these aspects.
You can then change the Employee and implement the interface - if you can change the source - or you use adaptation as the glue to make it work.

Tom said...

I look at nominal typing (interfaces) as having implicit namespacing that structural typing usually lacks. Folks are looking at adding explicit namespaces to structural typing in both ECMAScript and Ruby to get around the can-be-troublesome lack of namespaces there today. But by the time you get that far, I think the simple "I implement this interface" takes less manual work.

Daniel said...

Neither JavaScript nor Ruby have structural typing since the concept is by definition a figment of a static type system. There's no point in explicitly structurally typed code when using a dynamic type system.

Structural typing *is* less restrictive than nominal typing with interfaces, this is both part of its power and its curse. On the one hand, you cannot restrict the parameters to a certain inheritance hierarchy. But on the other hand, you also cannot use types which would satisfy the requirements (a properly implemented salary:Int method), but which don't implement the all-knowing interface.

In the end, they're two different (but similar) tools which each have their place. I'll admit that structural typing coupled with implicit conversions does indeed make the adapter pattern far less bulky, something I think we can all appreciate.

Tom said...

Duck typing vs. structural typing are equivalent for the concerns of my comment.

David R. MacIver said...

I'm not sure where the impression that structural types require repetition is coming from. They do if you don't have type aliasing... but not having type aliasing *already* causes too much repetition.

In Scala:

type Salaried = { def salary : Int }

Now I can use Salaried exactly like I could the original interface, but it refers to the structural type rather than requiring people to use an interface. Clearly you should be doing this any time you find yourself repeating the same structural type more than once.

david said...

@Daniel

You said, that this is a bad example and that structural typing is a tool as well as nominal typing. Can you give an example of when to use which tool? Are there any rules that I can apply of when to use which tool (except of "it depends")?

TheDet said...

Are there any rules that I can apply of when to use which tool (except of "it depends")?

Well, reading the article and the comments, I would come up with another perspective, I missed so far: Scoping.

Especially considering the term David R. MacIver provided:

type Salaried = { def salary: Int }

combined with the implicit conversion gives me a notion of "usable in local scope".

So the usage of structural typing seems to be comparable to using (named but private or even anonymous) inner classes.

Regarding that, we could ponder some statements which could lead to advices (no "rules"):

1.) Do I have access to the classes I want to cast into a contract?

If no, there's no chance to adorn them with an 'implements interface' expression, and applying the adapter pattern is the only solution.

The Java to Scala migration example is bad in so far that all classes were from ground up under control and had already a named interface implemented in Java.

So it is a good example for structural typing, but a bad example for when to use it.

2.) Does the contract reflect an essential concept in the problem domain?

Well, if you write an application e.g. for the HR or finance department, 'salaried' would perhaps indeed be a domain concept, so it should be visible as explicit type or contract.

3.) Is the contract OTOH only driven by implementation issues, then we could consider structural typing.

Here the question is: Is it published as part of an API?

Then it should be a named interface <=> an explicit contract.

Is it OTOH restricted to a local scope (assume makeSalarySheet being a private method only), then introducing an explicitly declared and namespaced interface type may indeed be oversized.

A structural type plus implicit conversion could be the better solution here.

Anonymous said...

Does Scala support recursvie structural types?

There's a paper that describes the Whiteoak language (http://whiteoak.sourceforge.net) which claims that recursive structural types are not allowed in Scala. Wonder what's the reason for this limitation?

Debasish said...

I think u can have structural recursion in Scala. Luc Duponcheel had a few posts explaining this .. http://lucdup.blogspot.com/2008/04/home_18.html

How would you compare structural typing against consumer-implemented wrapper classes for predefined types that implement consumer-specified interfaces? Is structural typing more elegant than wrapping classes? Or are the two effectively the same?

deamon said...

The Zen of Python says "explicit is better than implicit" and I think it is a good practise to use interfaces explicitly (traits / super classes) instead of using them implicitly like with structural typing.

The only real advantage of structural typing is the possibility to use existing classes with common methods like implementations of a certain interface.

I tried to summarize the arguments of this discussion in the Scala Forum.

Stephan.Schmidt said...

I've read the post now two years later. I think you've cheated with some points.

The evolution problem of Java interfaces still applies. If you ever only need one method on which Payroll depends, then your Java interface also only needs on method. If the interface needs more methods, most probalby because of the Payroll, then evidently you depend on more than one and all the workers need to change also.

The momentum is:

Java:
1. Payroll needs more methods


text:
# Lesson 3

Representing Exponential Growth

### Problem 1

Which expression is equal to $$4^0 \boldcdot 4^2$$?

A:

0

B:

1

C:

16

D:

64

### Solution

For access, consult one of our IM Certified Partners.

### Problem 2

Select all expressions are equivalent to $$3^{8}$$.

A:

$$8^3$$

B:

$$\frac{3^{10}}{3^2}$$

C:

$$3 \boldcdot 8$$

D:

$$\left(3^4\right)^2$$

E:

$$\left(3\boldcdot 3\right)^4$$

F:

$$\frac{1}{3^{\text-8}}$$

### Solution

For access, consult one of our IM Certified Partners.

(From Unit 5, Lesson 1.)

### Problem 3

A bee population is measured each week and the results are plotted on the graph.

1. What is the bee population when it is first measured?
2. Is the bee population growing by the same factor each week? Explain how you know.
3. What is an equation that models the bee population, $$b$$, $$w$$ weeks after it is first measured?

### Solution

For access, consult one of our IM Certified Partners.

### Problem 4

A bond is initially bought for $250. It doubles in value every decade. 1. Complete the table. 2. How many decades does it take before the bond is worth more than$10,000?
3. Write an equation relating $$v$$, the value of the bond, to $$d$$, the number of decades since the bond was bought.
bond is bought
dollar value
of bond
0
1
2
3
$$d$$

### Solution

For access, consult one of our IM Certified Partners.

### Problem 5

A sea turtle population $$p$$ is modeled by the equation $$p = 400 \boldcdot \left(\frac{5}{4}\right)^y$$ where $$y$$ is the number of years since the population was first measured.

1. How many turtles are in the population when it is first measured? Where do you see this in the equation?
2. Is the population increasing or decreasing? How can you tell from the equation?
3. When will the turtle population reach 700? Explain how you know.

### Solution

For access, consult one of our IM Certified Partners.

### Problem 6

Bank account A starts with $5,000 and grows by$1,000 each week. Bank account B starts with \$1 and doubles each week.

1. Which account has more money after one week? After two weeks?
2. Here is a graph showing the two account balances. Which graph corresponds to which situation? Explain how you know.
3. Given a choice, which of the two accounts would you choose? Explain your reasoning.

### Solution

For access, consult one of our IM Certified Partners.

(From Unit 5, Lesson 1.)

### Problem 7

Match each equation in the first list to an equation in the second list that has the same solution.

### Solution

For access, consult one of our IM Certified Partners.

(From Unit 2, Lesson 9.)

### Problem 8

Function $$F$$ is defined so that its output $$F(t)$$ is the number of followers on a social media account $$t$$ days after set up of the account.

1. Explain the meaning of $$F(30) = 8,\!950$$ in this situation.
2. Explain the meaning of $$F(0) = 0$$.
3. Write a statement about function $$F$$ that represents the fact that there were 28,800 followers 110 days after the set up of the account.
4. Explain the meaning of $$t$$ in the equation $$F(t) = 100,\!000$$.

### Solution

For access, consult one of our IM Certified Partners.

(From Unit 4, Lesson 3.)


text:
# Understanding bounded-diameter decomposition of graphs for PTAS

While trying to understand Baker's approach (also explained in this article by Eppstein) to designing PTAS's for planar graphs, I came across a difficulty.

The idea is, given an integer $k$, decompose the graph into subgraphs of tree-width bounded by $O(k)$ (which for planar graphs happens if $diameter = O(k)$), then solve the problem on the subgraphs in polynomial-time, and finally glue the solutions together to get a polynomial-time $(1 + O(1/k))$-approx.

The decomposition method described in the part $8$ of the article, amounts to, as far as I understood, pick any vertex, get a BFS tree from that vertex, and remove every $k$-th level of the tree (potentially starting at level $0 \leq i < k$, but I do not think it matters for this part).

The author then argues that the obtained subgraphs (consisting each of at most $k-1$ levels of the BFS tree), have bounded diameter (i.e. depending only on $k$).

This is the part I do not understand. For instance, what happens if some layer of the tree is a long path ? How is the diameter of a subgraph containing this layer bounded ?

Thank you for any help,

Lucas

-
This is actually Brenda Baker's approach, not mine. The parts I did were to use it for subgraph isomorphism rather than approximation, and to extend it to any apex-minor-free graph family. –  David Eppstein Nov 8 '12 at 3:38
This is (obviously) right. I edited my post to clarify things. However, I found that the decomposition scheme presented in your article (or at least the way it is presented) was easier to approach than the decomposition in $k$-outerplanar graphs presented in Baker's article. –  beauby Nov 8 '12 at 4:26
I don't remember all the details in this approach but I could recall nor find that they claim the subgraphs have bounded diameter. I thought it says: The graph induced by the vertices in any k consecutive layers (say i to i+k) found by a BFS has tree-width $O(k)$. This is easily seen if one contract all the vertices in early (i.e. layers 1 to i) then the graph has bounded diameter, hence bounded tree-width. –  Martin Vatshelle Nov 11 '12 at 6:13

Actually, the obtained subgraphs may not have bounded diameter, but they still have bounded tree-width. In order to see this, take one such subgraph $H$, and build $H'$ by adding a new vertex $u$ that is connected to each of the top-level vertices of $H$ (remember that $H$ was obtained as $k-1$ consecutive layers of a BFS tree). Then clearly $diam(H') \leq 2k$ since any vertex in $H'$ is at distance less than $k$ of $u$. We then know that $tw(H') = O(diam(H')) = O(k)$. Finally, $H$ is a minor of $H'$ so $tw(H) \leq tw(H')$, hence $tw(H) = O(k)$.
Yes, that's basically it. Instead of adding a new vertex to form $H'$, you could view it as a minor of the original graph, formed by contracting all the earlier BFS levels. –  David Eppstein Nov 8 '12 at 6:24