Synaptic Static https://conair94.github.io/Quarto/ Welcome to my blog! I am Connor Martinez Lockhart, and this is where I share my academic work, and other thoughts. Visit my main website at [conair94.github.io](https://conair94.github.io). quarto-1.9.37 Tue, 05 May 2026 00:00:00 GMT The Mathematics of a Striking Moonrise https://conair94.github.io/Quarto/posts/moonrise-phases/ 雪と雪今宵師走の名月か

Yuki to yuki koyoi shiwasu no meigetsu ka

It snows and snows.

Tonight’s the full moon of December,

One wonders

-Matsuo Basho, Winter 1684

Every full moon is a gift which commands a certain immediate attention and yet even amongst full moons, individual differences make themselves apparent. The full moon always marks the start of night, but does so unequally throughout the year.

There is a particular kind of moonrise that commands attention: an enormous, brilliant disk cresting the horizon just as twilight fades into true night. It looks perfectly full, the sky is fully dark, contrast is at its peak. To get this, the moon must rise roughly one hour after sunset.

But on any given calendar date, when does the moon actually rise relative to the sun, and what phase is it then? The answers are seasonal, not constant — and the reason is geometric. This post derives the answer from first principles, building Sun and Moon position, sidereal time, and the rise–set equation from scratch, ending in four interactive diagrams you can drive yourself.

This post was inspired by the spring full moon on May 1st 2026, the Flower moon. My hope is the reader leaves with an enhanced appreciation of the difference between the waxing and waning gibbous.

The default location for this post is Washington, D.C. (, ) but every visualizer accepts your own coordinates.

1. Celestial mechanics from first principles

Reference frames and the rise equation

Astronomy is bookkeeping in three frames, each more local than the last:

  1. Ecliptic frame — defined by Earth’s orbital plane around the Sun. Coordinates: ecliptic longitude (measured from the vernal equinox, eastward) and ecliptic latitude . The Sun, by definition, has .

  2. Equatorial frame — defined by Earth’s rotation axis, tilted from the ecliptic pole by the obliquity . Coordinates: right ascension and declination . Stars are nearly fixed in this frame.

  3. Horizontal (topocentric) frame — defined by the observer’s local vertical. Coordinates: azimuth (from north, clockwise) and altitude (above horizon). A body’s altitude depends on the observer’s latitude , the body’s , and the local hour angle , where is local sidereal time.

A body rises when its altitude crosses a small negative threshold from below; the corresponding hour angle satisfies

This is the central equation of the post. Everything else is figuring out and for the Sun and the Moon at the time we care about.

The transformations between the three frames are rotations of unit vectors:

Expanding the -component of the second product gives the altitude:

and the components together give azimuth:

Setting in (1.1) and solving for produces (1.3) above. Two solutions correspond to rise (eastern, ) and set (western, ).

The Sun’s apparent motion — Kepler’s equation

Earth’s orbit is a slight ellipse with eccentricity . Earth moves faster at perihelion (early January) and slower at aphelion (early July), so the Sun’s apparent ecliptic longitude does not advance uniformly in time. The equation of center is the correction from uniform “mean longitude” to the actual ecliptic longitude:

with the mean anomaly. Adding aberration and the dominant nutation term gives a model accurate to from 1900–2100 — well inside our min rise-time target.

Kepler’s equation links the uniformly-advancing mean anomaly to the geometric eccentric anomaly :

The true anomaly — the actual angle swept from perihelion — relates to via

Series-expanding for small yields

Following Meeus Astronomical Algorithms ch. 25, with in Julian centuries from J2000.0 (JD 2451545.0):

The last two corrections are aberration and the dominant nutation term; is the longitude of the Moon’s ascending node. With , the equatorial conversion is

Why winter inverts the moonrise lag

A perfectly full moon sits at . In December, the Sun is at and dips to — far south, short days. The full moon is then at with — far north, long time above the horizon. From mid-northern latitudes a high-declination body has close to (it spends almost the whole sidereal day up), so it rises early relative to the Sun’s setting. The “winter paradox” in the table below is just (1.3) being applied honestly.

This can be visualized by imaging a sphere, say a naval orange, and dividing it in half with a mark, one half will be the hemisphere that is visible to a person on the ground. Then place a ribbon around the orange along this mark and spin it so the center of the ribbon is no longer following the center of the mark. From here, the edges of the ribbon represent the angle of the sun during the solstices, and the center of the ribbon will represent the equinox. One edge of the ribbon will intersect the hemisphere more, that is the summer solstice, the one that is less is the winter solstice. The movement of the moon will be the opposite edge of the ribbon relative to whatever edge is representing the sun. This is why the lunar day is long when the solar day is short and vice versa.

For an excellent visual aid, consult this link and imagine the yellow band as the ribbon on the orange in the above analogy.

https://andrewmarsh.com/apps/staging/sunpath3d.html

The Moon — five fundamental arguments

The Moon’s motion is harder because the Sun perturbs its orbit substantially. Every modern lunar theory (Brown, ELP-2000, etc.) parametrizes by five Delaunay-style fundamental arguments, all linear in :

Symbol Name Linear-in- expression (degrees)
Moon’s mean longitude
Mean elongation from Sun
Sun’s mean anomaly
Moon’s mean anomaly
Argument of latitude (from ascending node)

Geometrically: tracks the Moon along the ecliptic; measures the synodic phase ( is new moon, is full); encodes orbital eccentricity; measures distance from the ascending node and so drives ecliptic latitude.

The Moon’s true ecliptic longitude and latitude are trigonometric series in these arguments. Truncated to the dozen-or-so leading terms, the model is accurate to , translating to under min of rise-time error at .

The full ELP-2000 series has thousands of terms; we keep Meeus Table 47.A truncated. For longitude (degrees):

For latitude, the dominant inclination term is — the Moon’s orbital inclination . Higher-order terms come from the perturbed motion of the node:

The Earth–Moon distance is dominated by the elliptical term km, oscillating between perigee ( km) and apogee ( km). Conversion to equatorial uses the full transform (with ):

Rise time — refraction, parallax, and sidereal iteration

A body’s geometric center is not at altitude when its limb touches the horizon. Atmospheric refraction lifts the image by ; the Sun’s and Moon’s apparent semidiameters add another ; lunar horizontal parallax of shifts the Moon further. Net effect:

These are not optional — together they shift moonrise by min, comparable to the seasonal effect we are studying. The hour angle is then , with the local sidereal time. Because the Moon’s RA drifts , “rise time” is a fixed point and must be iterated.

Refraction and parallax. Three corrections matter:

  • Atmospheric refraction at the horizon raises the apparent position by .
  • The Sun’s semidiameter . We see the Sun “rise” when its upper limb appears, so the geometric center must be below.
  • Lunar horizontal parallax raises apparent altitude. Its semidiameter is . The factor in (4.1) comes from the difference between geometric horizontal parallax and the contribution to the center’s altitude (Meeus 15.1).

Greenwich Mean Sidereal Time (Meeus 12.4), in degrees:

Local sidereal time for east-positive longitude .

Iteration. Starting from noon UT of the desired calendar date,

  1. Compute from the lunar series above.
  2. Compute from (1.3) using (4.1) for .
  3. Compute current , normalized to .
  4. Update where , normalized.

Two to four iterations converge to under a second. Setting and transit use and .

The harvest moon effect

The daily lag in moonrise — how much later the moon rises tonight than yesterday — is set by how fast the moon’s right ascension grows (about ) and by how that RA increase projects onto the eastern horizon at the observer’s latitude.

If the Moon’s path on the sky met the eastern horizon perpendicularly, a RA shift would translate directly into of delay. But near the autumnal equinox at northern mid-latitudes, the ecliptic crosses the eastern horizon at a shallow angle in the early evening: the Moon’s daily march along the ecliptic projects mostly along the horizon, not down into it. The lag shrinks to as little as min for several consecutive nights — the harvest moon effect.

If is the angle the ecliptic makes with the local horizon at the moment of moonrise, the daily lag is approximately

A shallow gives min, while a steep (spring evenings) gives min. The orbital inclination of adds a secondary modulation depending on where the ascending node sits — when the node is near the vernal equinox (“major standstill”), the Moon’s declination range is the full rather than , exaggerating both effects.

2. The compute engine

The next four visualizers all share one OJS module implementing the Sun position, Moon position, and rise/set iteration from §1. Code is folded; expand to inspect or modify.

Code 
DEG = Math.PI / 180
RAD = 180 / Math.PI
J2000 = 2451545.0

julianCenturies = (jd) => (jd - J2000) / 36525

// Calendar date → JD (Meeus 7.1). Month 1–12, day can be fractional.
jdFromDate = function(year, month, day) {
  let y = year, m = month;
  if (m <= 2) { y -= 1; m += 12; }
  const a = Math.floor(y / 100);
  const b = 2 - a + Math.floor(a / 4);
  return Math.floor(365.25*(y + 4716)) + Math.floor(30.6001*(m + 1)) + day + b - 1524.5;
}

obliquity = function(T) {
  // Mean obliquity, Meeus 22.2 (low-precision)
  return (23.4392911 - 0.0130042*T - 1.64e-7*T*T + 5.04e-7*T*T*T) * DEG;
}

normRad = function(x) {
  let y = x % (2*Math.PI);
  if (y < 0) y += 2*Math.PI;
  return y;
}

sunPosition = function(jd) {
  const T = julianCenturies(jd);
  const L0 = (280.46646 + 36000.76983*T + 0.0003032*T*T) * DEG;
  const M  = (357.52911 + 35999.05029*T - 0.0001537*T*T) * DEG;
  const C  = ((1.914602 - 0.004817*T - 0.000014*T*T)*Math.sin(M)
            + (0.019993 - 0.000101*T)*Math.sin(2*M)
            + 0.000289*Math.sin(3*M)) * DEG;
  const trueLong = L0 + C;
  const omega = (125.04 - 1934.136*T) * DEG;
  const lambda = trueLong - (0.00569 + 0.00478*Math.sin(omega)) * DEG;
  const eps = obliquity(T);
  const alpha = Math.atan2(Math.cos(eps)*Math.sin(lambda), Math.cos(lambda));
  const delta = Math.asin(Math.sin(eps)*Math.sin(lambda));
  return { lambda: normRad(lambda), beta: 0, alpha: normRad(alpha), delta, eps };
}

moonPosition = function(jd) {
  const T = julianCenturies(jd);
  const Lp = ((218.3164477 + 481267.88123421*T - 0.0015786*T*T) * DEG);
  const D  = ((297.8501921 + 445267.1114034*T - 0.0018819*T*T) * DEG);
  const M  = ((357.5291092 + 35999.0502909*T) * DEG);
  const Mp = ((134.9633964 + 477198.8675055*T + 0.0087414*T*T) * DEG);
  const F  = (( 93.2720950 + 483202.0175233*T - 0.0036539*T*T) * DEG);
  const dLambda = (
      6.288774 * Math.sin(Mp)
    + 1.274027 * Math.sin(2*D - Mp)
    + 0.658314 * Math.sin(2*D)
    + 0.213618 * Math.sin(2*Mp)
    - 0.185116 * Math.sin(M)
    - 0.114332 * Math.sin(2*F)
    + 0.058793 * Math.sin(2*D - 2*Mp)
    + 0.057066 * Math.sin(2*D - M - Mp)
    + 0.053322 * Math.sin(2*D + Mp)
    + 0.045758 * Math.sin(2*D - M)
    - 0.040923 * Math.sin(M - Mp)
    - 0.034720 * Math.sin(D)
    - 0.030383 * Math.sin(M + Mp)
    + 0.015327 * Math.sin(2*D - 2*F)
    - 0.012528 * Math.sin(Mp + 2*F)
    + 0.010980 * Math.sin(Mp - 2*F)
  ) * DEG;
  const dBeta = (
      5.128122 * Math.sin(F)
    + 0.280602 * Math.sin(Mp + F)
    + 0.277693 * Math.sin(Mp - F)
    + 0.173237 * Math.sin(2*D - F)
    + 0.055413 * Math.sin(2*D + F - Mp)
    + 0.046271 * Math.sin(2*D - F - Mp)
    + 0.032573 * Math.sin(2*D + F)
    + 0.017198 * Math.sin(2*Mp + F)
    + 0.009266 * Math.sin(2*D + Mp - F)
    + 0.008822 * Math.sin(2*Mp - F)
  ) * DEG;
  const dist = 385000.56
    - 20905.355 * Math.cos(Mp)
    -  3699.111 * Math.cos(2*D - Mp)
    -  2955.968 * Math.cos(2*D)
    -   569.925 * Math.cos(2*Mp)
    +    48.888 * Math.cos(M)
    -   246.158 * Math.cos(2*Mp - 2*D);
  const lambda = Lp + dLambda;
  const beta = dBeta;
  const eps = obliquity(T);
  const sinD = Math.sin(beta)*Math.cos(eps) + Math.cos(beta)*Math.sin(eps)*Math.sin(lambda);
  const delta = Math.asin(sinD);
  const alpha = Math.atan2(
    Math.sin(lambda)*Math.cos(eps) - Math.tan(beta)*Math.sin(eps),
    Math.cos(lambda)
  );
  return { lambda: normRad(lambda), beta, alpha: normRad(alpha), delta, distance: dist };
}

gmst = function(jd) {
  const T = julianCenturies(jd);
  const d = jd - J2000;
  let theta = 280.46061837 + 360.98564736629*d + 0.000387933*T*T - T*T*T/38710000;
  theta = ((theta % 360) + 360) % 360;
  return theta * DEG;
}

lstFor = (jd, lonEastDeg) => normRad(gmst(jd) + lonEastDeg*DEG)

altAz = function(latRad, dec, alpha, jd, lonEastDeg) {
  const H = lstFor(jd, lonEastDeg) - alpha;
  const sinAlt = Math.sin(latRad)*Math.sin(dec) + Math.cos(latRad)*Math.cos(dec)*Math.cos(H);
  const alt = Math.asin(Math.max(-1, Math.min(1, sinAlt)));
  const y = -Math.sin(H);
  const x = Math.tan(dec)*Math.cos(latRad) - Math.sin(latRad)*Math.cos(H);
  let az = Math.atan2(y, x);
  if (az < 0) az += 2*Math.PI;
  return { alt, az, H };
}

sunH0 = () => -0.8333 * DEG
moonH0 = (m) => {
  const parallax = Math.asin(6378.14 / m.distance);
  return 0.7275*parallax - 0.5667*DEG;
}

// Find rise / transit / set on the calendar date whose 0h UT is jd0.
// Sign: -1 for rise, 0 for transit, +1 for set.
findEvent = function(bodyFn, h0Fn, jd0, latRad, lonEastDeg, sign) {
  let t = jd0 + 0.5; // start at noon UT
  for (let i = 0; i < 8; i++) {
    const body = bodyFn(t);
    const h0 = h0Fn(body);
    const cosH0 = (Math.sin(h0) - Math.sin(latRad)*Math.sin(body.delta))
                / (Math.cos(latRad)*Math.cos(body.delta));
    if (cosH0 >  1 + 1e-9) return { jd: null, reason: 'never-rises' };
    if (cosH0 < -1 - 1e-9) return { jd: null, reason: 'never-sets' };
    const H0 = Math.acos(Math.max(-1, Math.min(1, cosH0)));
    const desiredH = sign === 0 ? 0 : (sign < 0 ? -H0 : +H0);
    let currentH = lstFor(t, lonEastDeg) - body.alpha;
    while (currentH >  Math.PI) currentH -= 2*Math.PI;
    while (currentH < -Math.PI) currentH += 2*Math.PI;
    let dH = desiredH - currentH;
    while (dH >  Math.PI) dH -= 2*Math.PI;
    while (dH < -Math.PI) dH += 2*Math.PI;
    const dt = dH / (2*Math.PI / 0.9972695663); // sidereal day
    t += dt;
    if (Math.abs(dt) < 1e-5) break;
  }
  // Confirm event lies within [jd0, jd0+1]
  if (t < jd0 - 0.05 || t > jd0 + 1.05) {
    // try alternative branch
  }
  return { jd: t, reason: 'ok' };
}

riseSet = function(bodyFn, h0Fn, jd0, latRad, lonEastDeg) {
  return {
    rise:    findEvent(bodyFn, h0Fn, jd0, latRad, lonEastDeg, -1),
    transit: findEvent(bodyFn, h0Fn, jd0, latRad, lonEastDeg,  0),
    set:     findEvent(bodyFn, h0Fn, jd0, latRad, lonEastDeg, +1)
  };
}

// Phase angle and illumination, Meeus 48
illumination = function(jd) {
  const s = sunPosition(jd);
  const m = moonPosition(jd);
  const psi = Math.acos(
    Math.sin(s.delta)*Math.sin(m.delta) +
    Math.cos(s.delta)*Math.cos(m.delta)*Math.cos(s.alpha - m.alpha)
  );
  const R = 1.496e8;
  const Δ = m.distance;
  const i = Math.atan2(R*Math.sin(psi), Δ - R*Math.cos(psi));
  // Synodic phase angle (0 = new, π = full), signed by D
  const D = normRad(m.lambda - s.lambda);
  return { phaseAngle: i, illuminated: (1 + Math.cos(i))/2, elongation: D };
}

// Sub-solar / sub-lunar geographic point (lat, lon east) at given JD
subPoint = function(jd, body) {
  const b = body(jd);
  const gast = gmst(jd); // ignore equation of equinoxes (tiny)
  let lon = b.alpha - gast;
  while (lon >  Math.PI) lon -= 2*Math.PI;
  while (lon < -Math.PI) lon += 2*Math.PI;
  return { lat: b.delta, lon };
}

mod360 = x => ((x % 360) + 360) % 360

// Format a JD (UT) as local clock time HH:MM given a TZ offset in hours.
fmtLocal = function(jd, tzHours) {
  if (jd == null) return "—";
  const local = jd + tzHours/24;
  const frac = local - Math.floor(local) - 0.5;
  let hours24 = (frac * 24 + 24) % 24;
  const h = Math.floor(hours24);
  const m = Math.round((hours24 - h)*60);
  return `${String(h).padStart(2,'0')}:${String(m).padStart(2,'0')}`;
}

3. Orbital geometry & horizon timeline

Set your location, date, and time of day. Type values directly into the number boxes, drag sliders, or hit Animate day-of-year to sweep through the calendar. The first diagram shows the Earth–Moon–Sun geometry from above the ecliptic; the second is a 24-hour timeline of when the Sun and Moon are above the horizon at your latitude.

Code 
todayObj = new Date()
yearToday = todayObj.getUTCFullYear()
todayDateStr = todayObj.toISOString().slice(0,10)
maxDateStr = (() => {
  const d = new Date(todayObj.getTime() + 2*365.25*86400000);
  return d.toISOString().slice(0,10);
})()
Code 
viewof loc = Inputs.form({
  lat: Inputs.number([-89.9, 89.9], {value: 38.9,  step: 0.001, label: "Latitude (°N)"}),
  lon: Inputs.number([-180, 180],  {value: -77.04, step: 0.001, label: "Longitude (°E, west negative)"}),
  tz:  Inputs.number([-12, 14],    {value: -5,    step: 1,     label: "Timezone offset (hours from UTC)"})
})
viewof picker = Inputs.form({
  date: Inputs.date({value: todayDateStr, min: todayDateStr, max: maxDateStr, label: "Date"}),
  hour: Inputs.range([0, 24], {value: 19, step: 0.05, label: "Local clock hour"})
})
viewof animState = Inputs.form({
  animate: Inputs.toggle({value: false, label: "▶ Animate day-of-year"}),
  speed:   Inputs.range([1, 60], {value: 10, step: 1, label: "Animation speed (days/sec)"})
})
Code 
pickerDateObj = (typeof picker.date === 'string')
  ? new Date(picker.date + "T00:00:00Z")
  : picker.date
pickerYear = pickerDateObj.getUTCFullYear()
pickerDoy = {
  const start = Date.UTC(pickerYear, 0, 1);
  return Math.floor((pickerDateObj.getTime() - start)/86400000) + 1;
}

// Reactive day-of-year: while animating, advance with a generator; otherwise pass through.
doy = animState.animate
  ? Generators.observe(notify => {
      let d = pickerDoy;
      notify(d);
      const id = setInterval(() => {
        const isLeap = (pickerYear % 4 === 0 && pickerYear % 100 !== 0) || pickerYear % 400 === 0;
        const maxDoy = isLeap ? 366 : 365;
        d = (d % maxDoy) + 1;
        notify(d);
      }, 1000 / Math.max(1, animState.speed));
      return () => clearInterval(id);
    })
  : pickerDoy

// Derived JD at 0h UT of (year, doy), and at chosen local clock time
jd0 = jdFromDate(pickerYear, 1, doy)
jdNow = jd0 + (picker.hour - loc.tz)/24
sun = sunPosition(jdNow)
moon = moonPosition(jdNow)
ill = illumination(jdNow)
events = ({
  sun:  riseSet(sunPosition,  sunH0,  jd0, loc.lat*DEG, loc.lon),
  moon: riseSet(moonPosition, moonH0, jd0, loc.lat*DEG, loc.lon)
})

// Convenience: compute the human-readable date for the current animated doy
currentDateLabel = {
  const ms = Date.UTC(pickerYear, 0, 1) + (doy - 1)*86400000;
  return new Date(ms).toISOString().slice(0,10);
}
Code 
// ===== Visualizer A: overhead geometric diagram =====
{
  const W = 960, H = 540, cx = W/2, cy = H/2;
  const Rsun = 230, Rmoon = 120;

  const svg = d3.create("svg")
    .attr("viewBox", [0, 0, W, H])
    .style("background", "#0a0a1a")
    .style("border-radius", "8px")
    .style("max-width", "100%")
    .style("height", "auto");

  // labels for ecliptic cardinal directions (vernal equinox = +x)
  const dir = [["♈ 0°", Rsun+22, 0],["♋ 90°", 0, Rsun+22],["♎ 180°", -(Rsun+30), 0],["♑ 270°", 0, -(Rsun+22)]];
  for (const [t,dx,dy] of dir) {
    svg.append("text").attr("x", cx+dx).attr("y", cy-dy).text(t)
      .attr("fill","#666").attr("font-size","10px").attr("text-anchor","middle");
  }

  // Sun's ecliptic position
  const sx = cx + Rsun*Math.cos(sun.lambda);
  const sy = cy - Rsun*Math.sin(sun.lambda); // y inverted on screen
  // Moon ecliptic + small radial bump for β
  const r_moon_eff = Rmoon + 50*Math.sin(moon.beta); // visualize β
  const mx = cx + r_moon_eff*Math.cos(moon.lambda);
  const my = cy - r_moon_eff*Math.sin(moon.lambda);

  // d3.arc angle to a screen vector (dx, dy): 0 = up, increases clockwise.
  // For screen vector (dx, dy): arcAngle = atan2(dx, -dy).
  function screenToArcAngle(dx, dy) { return Math.atan2(dx, -dy); }

  // Earth (with a real day/night terminator: lit hemisphere faces the sun)
  const earth = svg.append("g").attr("transform", `translate(${cx},${cy})`);
  earth.append("circle").attr("r", 20).attr("fill", "#234").attr("stroke","#4b9cd3");
  const earthSunArc = screenToArcAngle(sx - cx, sy - cy);
  const litEarth = d3.arc()({innerRadius: 0, outerRadius: 20,
    startAngle: earthSunArc - Math.PI/2,
    endAngle:   earthSunArc + Math.PI/2});
  earth.append("path").attr("d", litEarth).attr("fill", "#4b9cd3").attr("opacity", 0.9);
  // Observer pin: place on Earth's surface at the angle pointing to the observer's instantaneous
  // local meridian — i.e. towards screen direction matching local sidereal time.
  const obsArcAngle = screenToArcAngle(
    Math.cos(lstFor(jdNow, loc.lon)),
    -Math.sin(lstFor(jdNow, loc.lon))
  );
  earth.append("circle")
    .attr("cx", 22*Math.sin(obsArcAngle))
    .attr("cy", -22*Math.cos(obsArcAngle))
    .attr("r", 2.5).attr("fill","#ff6").attr("stroke","#000").attr("stroke-width",0.5);

  // Sun
  svg.append("circle").attr("cx", sx).attr("cy", sy).attr("r", 13).attr("fill","#ffcc33")
    .attr("filter","drop-shadow(0 0 10px #ffcc33)");

  // Moon orbit ring
  svg.append("circle").attr("cx", cx).attr("cy", cy).attr("r", Rmoon)
    .attr("fill","none").attr("stroke","rgba(255,255,255,0.12)").attr("stroke-dasharray","3,4");

  // Moon
  const moonG = svg.append("g").attr("transform", `translate(${mx},${my})`);
  moonG.append("circle").attr("r", 8).attr("fill", "#ddd");
  // Lit hemisphere faces the sun; dark hemisphere is opposite.
  const moonSunArc = screenToArcAngle(sx - mx, sy - my);
  const darkMoon = d3.arc()({innerRadius:0, outerRadius:8,
    startAngle: moonSunArc + Math.PI/2,
    endAngle:   moonSunArc + 3*Math.PI/2});
  moonG.append("path").attr("d", darkMoon).attr("fill","rgba(0,0,0,0.82)");

  // Annotations
  svg.append("text").attr("x", 12).attr("y", 22).attr("fill","#ccc").attr("font-size","12px")
    .text(`Sun λ = ${(sun.lambda*RAD).toFixed(1)}°, δ = ${(sun.delta*RAD).toFixed(2)}°`);
  svg.append("text").attr("x", 12).attr("y", 40).attr("fill","#ccc").attr("font-size","12px")
    .text(`Moon λ = ${(moon.lambda*RAD).toFixed(1)}°, β = ${(moon.beta*RAD).toFixed(2)}°, Δ = ${moon.distance.toFixed(0)} km`);
  svg.append("text").attr("x", 12).attr("y", 58).attr("fill","#ccc").attr("font-size","12px")
    .text(`Phase angle = ${(ill.phaseAngle*RAD).toFixed(1)}°  →  illuminated ${(ill.illuminated*100).toFixed(1)}%`);

  return svg.node();
}
Code 
// ===== Visualizer B: 24-h horizon timeline =====
{
  const W = 960, H = 200, m = {top: 36, right: 24, bottom: 36, left: 36};
  const x = d3.scaleLinear().domain([0, 24]).range([m.left, W - m.right]);
  const svg = d3.create("svg").attr("viewBox", [0,0,W,H])
    .style("max-width","100%").style("height","auto");

  const barTop = 80, barH = 36;

  // Background bar (night)
  svg.append("rect").attr("x", m.left).attr("y", barTop).attr("width", W-m.left-m.right).attr("height", barH)
    .attr("fill", "#10103a");

  function localHours(ev) {
    if (!ev.jd) return null;
    const local = ev.jd + loc.tz/24;
    return ((local - Math.floor(local) - 0.5) * 24 + 24) % 24;
  }
  const sr = localHours(events.sun.rise);
  const ss = localHours(events.sun.set);
  const mr = localHours(events.moon.rise);
  const ms = localHours(events.moon.set);

  // Daylight band
  if (sr != null && ss != null) {
    if (sr < ss) {
      svg.append("rect").attr("x", x(sr)).attr("y", barTop).attr("width", x(ss)-x(sr))
        .attr("height", barH).attr("fill","#ffd866");
    } else {
      svg.append("rect").attr("x", x(0)).attr("y", barTop).attr("width", x(ss)-x(0))
        .attr("height", barH).attr("fill","#ffd866");
      svg.append("rect").attr("x", x(sr)).attr("y", barTop).attr("width", x(24)-x(sr))
        .attr("height", barH).attr("fill","#ffd866");
    }
  }
  // Moon band
  function drawMoonBand(a, b) {
    svg.append("rect").attr("x", x(a)).attr("y", barTop+8).attr("width", x(b)-x(a))
      .attr("height", barH-16).attr("fill", "rgba(220,220,220,0.75)").attr("rx",3);
  }
  if (mr != null && ms != null) {
    if (mr < ms) drawMoonBand(mr, ms);
    else { drawMoonBand(mr, 24); drawMoonBand(0, ms); }
  }

  // Tick at sunset+1h
  if (ss != null) {
    const target = (ss + 1) % 24;
    svg.append("line").attr("x1", x(target)).attr("x2", x(target))
      .attr("y1", barTop-6).attr("y2", barTop+barH+6).attr("stroke","#e44").attr("stroke-dasharray","3,3");
    svg.append("text").attr("x", x(target)).attr("y", barTop-10).attr("fill","#e44")
      .attr("font-size","11px").attr("text-anchor","middle").text("sunset + 1 h");
  }

  // Axis
  svg.append("g").attr("transform",`translate(0,${barTop+barH})`)
    .call(d3.axisBottom(x).ticks(12).tickFormat(d => d+"h"))
    .attr("color","#666").attr("font-size","11px");

  // Title
  svg.append("text").attr("x", W/2).attr("y", 24).attr("text-anchor","middle")
    .attr("font-size","16px").attr("fill","#333").attr("font-weight","bold")
    .text(`Sun & Moon above horizon — ${currentDateLabel}`);

  // Inline readout
  const lag = (mr != null && ss != null)
    ? (((mr - ss) + 24) % 24) * 60
    : null;
  svg.append("text").attr("x", W/2).attr("y", H-6).attr("text-anchor","middle")
    .attr("font-size","11px").attr("fill","#444")
    .text(`Sunset ${ss==null?'—':fmtLocal(events.sun.set.jd, loc.tz)}, `
        + `Moonrise ${mr==null?'—':fmtLocal(events.moon.rise.jd, loc.tz)}, `
        + `Δ = ${lag==null?'—':lag.toFixed(0)+' min'}, illum ${(ill.illuminated*100).toFixed(0)}%`);

  return svg.node();
}

4. Two views of the same sky

The next two diagrams show the same instant from two perspectives. Drag the time-of-day slider above; both diagrams update.

The stereographic plot (left) is what you would see looking up: zenith at center, horizon as the bounding circle, cardinal directions on the rim. The Sun and Moon are drawn at their true altitude and azimuth; their shaded sides face away from each other. Colored faint trails show each body’s path over the past 24 hours.

The wireframe globe (right) is the same instant viewed from outside Earth. The latitude/longitude wireframe rotates with the planet. The day/night terminator is drawn as the great circle 90° from the sub-solar point. The sub-solar point ☉, sub-lunar point ☾, and your location pin are marked. The inset reports whether each body is currently above your horizon.

Code 
{
  const W = 540, H = 540, cx = W/2, cy = H/2, R = 240;
  const svg = d3.create("svg").attr("viewBox", [0,0,W,H])
    .style("background","radial-gradient(circle at center, #001 0%, #000 70%)")
    .style("border-radius","8px").style("max-width","100%").style("height","auto");

  // Stereographic from nadir: r = R * tan((90° - alt)/2). Returns null when the
  // point is below the horizon so callers can break their path there.
  function project(alt, az) {
    if (alt < -0.001) return null;
    const r = R * Math.tan((Math.PI/2 - alt)/2);
    // az measured from N clockwise; on screen, x = r sin(az), y = -r cos(az)
    return [cx + r*Math.sin(az), cy - r*Math.cos(az)];
  }

  // Path generator that BREAKS at null entries instead of connecting across them.
  // Also breaks when consecutive points are far apart on screen (azimuth wrap-around).
  const lineGen = d3.line()
    .defined(d => d != null)
    .x(d => d[0]).y(d => d[1]);

  // Horizon ring + altitude circles
  for (const a of [30, 60]) {
    const r = R * Math.tan((Math.PI/2 - a*DEG)/2);
    svg.append("circle").attr("cx",cx).attr("cy",cy).attr("r",r)
      .attr("fill","none").attr("stroke","#234").attr("stroke-dasharray","2,3");
  }
  svg.append("circle").attr("cx",cx).attr("cy",cy).attr("r",R)
    .attr("fill","none").attr("stroke","#445");

  // Cardinal labels
  const card = [["N",0],["E",Math.PI/2],["S",Math.PI],["W",3*Math.PI/2]];
  for (const [t,a] of card) {
    svg.append("text").attr("x", cx + (R+12)*Math.sin(a))
      .attr("y", cy - (R+12)*Math.cos(a) + 4)
      .attr("text-anchor","middle").attr("fill","#88a").attr("font-size","12px").text(t);
  }

  // Celestial equator + ecliptic + body trails, sampled.
  // We post-process: any pair of consecutive non-null points that are unrealistically
  // far apart on screen (a wrap-around chord) gets a null inserted between them so
  // .defined() breaks the path there.
  function drawGreatCircle(samples, color) {
    const broken = [];
    for (let i = 0; i < samples.length; i++) {
      const p = samples[i];
      const prev = broken[broken.length - 1];
      if (p && prev) {
        const dx = p[0] - prev[0], dy = p[1] - prev[1];
        if (dx*dx + dy*dy > (R*0.5)*(R*0.5)) broken.push(null);
      }
      broken.push(p);
    }
    svg.append("path").attr("d", lineGen(broken)).attr("fill","none")
      .attr("stroke",color).attr("stroke-width",0.6).attr("opacity",0.55);
  }
  // Equator: δ = 0, vary α
  const eqPts = [];
  for (let a=0; a<2*Math.PI; a+=Math.PI/120) {
    const H = lstFor(jdNow, loc.lon) - a;
    const sinAlt = Math.cos(loc.lat*DEG)*Math.cos(H);
    const alt = Math.asin(sinAlt);
    const az = Math.atan2(-Math.sin(H), -Math.sin(loc.lat*DEG)*Math.cos(H));
    eqPts.push(project(alt, (az+2*Math.PI)%(2*Math.PI)));
  }
  drawGreatCircle(eqPts, "#5a8");

  // Ecliptic
  const eps0 = obliquity(julianCenturies(jdNow));
  const ecPts = [];
  for (let l=0; l<2*Math.PI; l+=Math.PI/120) {
    const dec = Math.asin(Math.sin(eps0)*Math.sin(l));
    const ra = Math.atan2(Math.cos(eps0)*Math.sin(l), Math.cos(l));
    const H = lstFor(jdNow, loc.lon) - ra;
    const sinAlt = Math.sin(loc.lat*DEG)*Math.sin(dec)+Math.cos(loc.lat*DEG)*Math.cos(dec)*Math.cos(H);
    const alt = Math.asin(Math.max(-1, Math.min(1, sinAlt)));
    const y = -Math.sin(H);
    const x = Math.tan(dec)*Math.cos(loc.lat*DEG) - Math.sin(loc.lat*DEG)*Math.cos(H);
    let az = Math.atan2(y,x); if (az<0) az += 2*Math.PI;
    ecPts.push(project(alt, az));
  }
  drawGreatCircle(ecPts, "#a85");

  // 24-hour trails for Sun & Moon — keep nulls in-place so the path breaks
  // when the body dips below the horizon.
  function trail(bodyFn, color) {
    const pts = [];
    for (let dh=-24; dh<=0; dh+=0.25) {
      const t = jdNow + dh/24;
      const b = bodyFn(t);
      const aa = altAz(loc.lat*DEG, b.delta, b.alpha, t, loc.lon);
      pts.push(project(aa.alt, aa.az));
    }
    drawGreatCircle(pts, color);
  }
  trail(sunPosition, "#ffcc33");
  trail(moonPosition, "#cce");

  // Current Sun & Moon
  const sunAA = altAz(loc.lat*DEG, sun.delta, sun.alpha, jdNow, loc.lon);
  const moonAA = altAz(loc.lat*DEG, moon.delta, moon.alpha, jdNow, loc.lon);
  const sp = project(sunAA.alt, sunAA.az);
  const mp = project(moonAA.alt, moonAA.az);
  if (sp) {
    svg.append("circle").attr("cx",sp[0]).attr("cy",sp[1]).attr("r",7)
      .attr("fill","#ffcc33").attr("filter","drop-shadow(0 0 6px #ffcc33)");
  }
  if (mp) {
    const g = svg.append("g").attr("transform",`translate(${mp[0]},${mp[1]})`);
    g.append("circle").attr("r",6).attr("fill","#eee");
    // shade based on phase
    const k = ill.illuminated;
    g.append("path").attr("d", d3.arc()({innerRadius:0, outerRadius:6,
      startAngle: 0, endAngle: Math.PI*(1-k)*2}))
      .attr("fill","rgba(0,0,0,0.7)");
  }

  svg.append("text").attr("x", 8).attr("y", 16).attr("fill","#bbb").attr("font-size","11px")
    .text(`zenith view · ${currentDateLabel} · ${picker.hour.toFixed(2)}h local`);
  svg.append("text").attr("x", 8).attr("y", H-8).attr("fill","#5a8").attr("font-size","10px")
    .text("— equator");
  svg.append("text").attr("x", 90).attr("y", H-8).attr("fill","#a85").attr("font-size","10px")
    .text("— ecliptic");
  return svg.node();
}
{
  const W = 540, H = 540;
  const svg = d3.create("svg").attr("viewBox", [0,0,W,H])
    .style("background","#001").style("border-radius","8px")
    .style("max-width","100%").style("height","auto");

  // Center the globe on the observer's longitude rotated by Earth's spin
  const rot = [-loc.lon, -loc.lat*0.6, 0];
  const proj = d3.geoOrthographic().scale(W*0.45).translate([W/2, H/2]).rotate(rot).clipAngle(90);
  const path = d3.geoPath(proj);

  // Globe sphere
  svg.append("path").datum({type:"Sphere"}).attr("d", path)
    .attr("fill","#001a33").attr("stroke","#345");

  // Wireframe graticule (15° spacing)
  const graticule = d3.geoGraticule().step([15,15]);
  svg.append("path").datum(graticule).attr("d", path)
    .attr("fill","none").attr("stroke","#356").attr("stroke-width",0.4);
  // Equator highlighted
  svg.append("path").datum(d3.geoGraticule().step([180,180]).extentMinor([[-180,0],[180,0]]))
    .attr("d", path).attr("fill","none").attr("stroke","#588").attr("stroke-width",0.7);

  // Sub-solar / sub-lunar
  const subSun  = subPoint(jdNow, sunPosition);
  const subMoon = subPoint(jdNow, moonPosition);

  // Night side: great circle 90° from sub-solar, hemisphere AWAY from sun is dark
  const antiSun = [(subSun.lon*RAD + 180 + 540) % 360 - 180, -subSun.lat*RAD];
  const night = d3.geoCircle().radius(90).center(antiSun)();
  svg.append("path").datum(night).attr("d", path)
    .attr("fill","rgba(0,0,30,0.55)").attr("stroke","#446").attr("stroke-width",0.5);

  // Sub-solar point
  svg.append("path").datum({type:"Point", coordinates:[subSun.lon*RAD, subSun.lat*RAD]})
    .attr("d", path.pointRadius(6))
    .attr("fill","#ffcc33").attr("stroke","#aa6");
  // Sub-lunar point
  svg.append("path").datum({type:"Point", coordinates:[subMoon.lon*RAD, subMoon.lat*RAD]})
    .attr("d", path.pointRadius(5))
    .attr("fill","#eee").attr("stroke","#888");
  // Observer
  svg.append("path").datum({type:"Point", coordinates:[loc.lon, loc.lat]})
    .attr("d", path.pointRadius(3.5))
    .attr("fill","#f44").attr("stroke","#fff").attr("stroke-width",0.5);

  // Inset readout
  const sunAlt = altAz(loc.lat*DEG, sun.delta, sun.alpha, jdNow, loc.lon).alt*RAD;
  const moonAlt = altAz(loc.lat*DEG, moon.delta, moon.alpha, jdNow, loc.lon).alt*RAD;
  svg.append("text").attr("x", 8).attr("y", 16).attr("fill","#bbb").attr("font-size","11px")
    .text(`Sun alt ${sunAlt.toFixed(1)}°, Moon alt ${moonAlt.toFixed(1)}°`);
  svg.append("text").attr("x", 8).attr("y", H-8).attr("fill","#888").attr("font-size","10px")
    .text(`☉ sub-solar (${(subSun.lat*RAD).toFixed(1)}°, ${(subSun.lon*RAD).toFixed(1)}°)`);

  return svg.node();
}

5. Full moon calendar & seasonal pattern

A year of full moon timings

Every row below is a real moonrise–sunset offset for the next 13 lunations at your selected location. Negative values mean the moon rises before sunset.

Code 
fullMoonsTable = {
  // Find approximate full moons over the next ~13 months by scanning for elongation = π
  const start = jdFromDate(yearToday, todayObj.getUTCMonth()+1, todayObj.getUTCDate());
  const rows = [];
  let prev = null;
  let lastFound = -1e9;
  for (let d = 0; d < 400; d += 0.05) {
    const jd = start + d;
    const elong = normRad(moonPosition(jd).lambda - sunPosition(jd).lambda);
    const dev = elong - Math.PI;
    if (prev != null && prev * dev < 0 && Math.abs(prev - dev) < 0.5 && (jd - lastFound) > 20) {
      // refine by linear interpolation
      const jdFull = jd - 0.05 * dev/(dev - prev);
      lastFound = jdFull;
      // sunset on the full-moon's local calendar date
      const localJd = jdFull + loc.tz/24;
      const dateInt = Math.floor(localJd - 0.5) + 0.5; // local 0h UT-equivalent
      const jd0 = dateInt - loc.tz/24; // back to UT 0h of that local day
      const ev = riseSet(sunPosition,  sunH0,  jd0, loc.lat*DEG, loc.lon);
      const em = riseSet(moonPosition, moonH0, jd0, loc.lat*DEG, loc.lon);
      const dt = (ev.set.jd != null && em.rise.jd != null)
        ? (em.rise.jd - ev.set.jd) * 1440
        : null;
      // age past full at "1h after sunset"
      let age = null, illumAtTarget = null;
      if (ev.set.jd != null) {
        const tTarget = ev.set.jd + 1/24;
        age = (tTarget - jdFull); // days
        illumAtTarget = illumination(tTarget).illuminated;
      }
      const dObj = new Date((jdFull + loc.tz/24 - 2440587.5)*86400000);
      rows.push({
        date: dObj.toISOString().slice(0,10),
        sunset:    fmtLocal(ev.set.jd, loc.tz),
        moonrise:  fmtLocal(em.rise.jd, loc.tz),
        deltaMin:  dt==null ? "—" : dt.toFixed(1),
        ageDays:   age==null ? "—" : age.toFixed(2),
        illum1h:   illumAtTarget==null ? "—" : (illumAtTarget*100).toFixed(1)+"%"
      });
    }
    prev = dev;
  }
  return rows;
}

Inputs.table(fullMoonsTable, {
  columns: ["date","sunset","moonrise","deltaMin","ageDays","illum1h"],
  header:  {date:"Full moon (local)", sunset:"Sunset", moonrise:"Moonrise",
            deltaMin:"Δ (min)", ageDays:"Age at sunset+1h (d)", illum1h:"Illum at sunset+1h"}
})

The seasonal pattern is now reproducible: in late autumn at northern mid-latitudes, the moonrise–sunset offset goes negative (full moon already up at sunset), so a viewer wanting a “rising-just-as-night-falls” moon must actually catch one days past full, when illumination has fallen to .

Moonrise solver

Given any calendar date, what lunar phase gives a moonrise exactly hour after sunset? Solve for the elongation that makes the moonrise event align with sunset h. We treat the true lunar series of §1 as known and adjust a phase offset added to the natural elongation that day; in practice we just bisect on .

Code 
solverResult = {
  const target = events.sun.set.jd;
  if (target == null) return md`*Sun never sets at this latitude/date — no solution.*`;
  const targetT = target + 1/24;
  // Find the lunar elongation D (lambda_M - lambda_sun) at which a body with
  // alpha_M, delta_M produced by adjusting only longitude by ΔD rises at targetT.
  // Bisection on ΔD: residual = (LST(rise) - alpha_M_shifted) + H0
  function residual(dD) {
    // Build a synthetic moon: take the moon's β, but replace longitude with sun.lambda + π + dD.
    const lam = sunPosition(targetT).lambda + Math.PI + dD;
    const eps = obliquity(julianCenturies(targetT));
    const synth = {
      delta: Math.asin(Math.sin(moon.beta)*Math.cos(eps) + Math.cos(moon.beta)*Math.sin(eps)*Math.sin(lam)),
      alpha: normRad(Math.atan2(Math.sin(lam)*Math.cos(eps) - Math.tan(moon.beta)*Math.sin(eps), Math.cos(lam))),
      distance: moon.distance, beta: moon.beta, lambda: lam
    };
    const h0 = moonH0(synth);
    const cosH0 = (Math.sin(h0) - Math.sin(loc.lat*DEG)*Math.sin(synth.delta))
                 / (Math.cos(loc.lat*DEG)*Math.cos(synth.delta));
    if (cosH0 > 1 || cosH0 < -1) return NaN;
    const H0 = Math.acos(cosH0);
    let H = lstFor(targetT, loc.lon) - synth.alpha; // current hour angle at target time
    while (H >  Math.PI) H -= 2*Math.PI;
    while (H < -Math.PI) H += 2*Math.PI;
    return H + H0; // zero when target is exactly at moonrise
  }
  let lo = -Math.PI*0.45, hi = Math.PI*0.45;
  let fLo = residual(lo), fHi = residual(hi);
  // expand search
  if (!(fLo*fHi < 0)) {
    // brute search
    let best = {dD:0, f:Infinity}, last = residual(-Math.PI*0.99);
    for (let i=-99; i<=99; i++) {
      const x = i/100*Math.PI;
      const f = residual(x);
      if (Number.isFinite(f) && Math.abs(f) < Math.abs(best.f)) best = {dD:x, f};
      if (Number.isFinite(f) && Number.isFinite(last) && f*last < 0) { lo = x - Math.PI/100; hi = x; break; }
      last = f;
    }
    fLo = residual(lo); fHi = residual(hi);
  }
  for (let i=0; i<60 && fLo*fHi < 0; i++) {
    const mid = (lo+hi)/2, fm = residual(mid);
    if (fm*fLo < 0) { hi = mid; fHi = fm; } else { lo = mid; fLo = fm; }
  }
  const dD = (lo+hi)/2;
  // True synodic phase at the rise event: sun.lambda + π + dD - sun.lambda = π + dD
  const phase = Math.PI + dD;             // 0 = new, π = full
  const illumPct = (1 - Math.cos(phase))/2 * 100;
  const ageDaysFromFull = dD * 29.5306 / (2*Math.PI);
  return md`
**For ${currentDateLabel} at (${loc.lat.toFixed(2)}°, ${loc.lon.toFixed(2)}°):**
- Sunset: \`${fmtLocal(events.sun.set.jd, loc.tz)}\`
- Required elongation $D$: **${(phase*RAD).toFixed(2)}°** (full = 180°)
- Equivalent age: **${ageDaysFromFull.toFixed(2)} days** ${ageDaysFromFull > 0 ? "past full" : "before full"}
- Illumination at moonrise: **${illumPct.toFixed(1)}%**
`;
}

Seasonal phase pattern

The “striking moonrise” — the moon rising one hour after sunset — sweeps through the lunar phases over the course of a year. Below is a single plot of the required lunar phase, computed for every day of the next two years at your selected location. The horizontal axis is calendar date; the vertical axis is the synodic phase angle (in degrees) needed for moonrise to land exactly at sunset h.

Code 
seasonalCurve = {
  // For each day of the next ~2 years, find the elongation D such that
  // moonrise occurs at sunset+1h. Reuse the bisection from §10.
  const phi = loc.lat*DEG;
  const startJd = jdFromDate(yearToday, todayObj.getUTCMonth()+1, todayObj.getUTCDate());
  const rows = [];
  for (let k = 0; k < 730; k += 3) {
    const jd0_k = startJd + k;
    const ev = riseSet(sunPosition, sunH0, jd0_k, phi, loc.lon);
    if (ev.set.jd == null) continue;
    const target = ev.set.jd + 1/24;
    const sunAtTarget = sunPosition(target);
    function residual(dD) {
      const lam = sunAtTarget.lambda + Math.PI + dD;
      const eps = obliquity(julianCenturies(target));
      const beta = 0; // approximate: ignore moon's β for the seasonal sweep
      const dec = Math.asin(Math.sin(eps)*Math.sin(lam));
      const ra = normRad(Math.atan2(Math.cos(eps)*Math.sin(lam), Math.cos(lam)));
      const cosH0 = (Math.sin(0.125*DEG) - Math.sin(phi)*Math.sin(dec))
                   / (Math.cos(phi)*Math.cos(dec));
      if (cosH0 > 1 || cosH0 < -1) return NaN;
      const H0 = Math.acos(cosH0);
      let H = lstFor(target, loc.lon) - ra;
      while (H >  Math.PI) H -= 2*Math.PI;
      while (H < -Math.PI) H += 2*Math.PI;
      return H + H0;
    }
    // bisection on dD ∈ (-π/2, π/2)
    let lo = -Math.PI*0.4, hi = Math.PI*0.4;
    let fLo = residual(lo), fHi = residual(hi);
    if (!(Number.isFinite(fLo) && Number.isFinite(fHi) && fLo*fHi < 0)) continue;
    for (let i=0; i<50; i++) {
      const mid = (lo+hi)/2, fm = residual(mid);
      if (!Number.isFinite(fm)) break;
      if (fm*fLo < 0) { hi = mid; fHi = fm; } else { lo = mid; fLo = fm; }
    }
    const dD = (lo+hi)/2;
    const D_deg = (Math.PI + dD) * RAD;       // 0 = new, 180 = full
    const illum = (1 - Math.cos(Math.PI + dD))/2 * 100;
    rows.push({
      date: new Date((jd0_k + 0.5 - 2440587.5)*86400000),
      phaseDeg: D_deg,
      illum
    });
  }
  return rows;
}

Plot.plot({
  width: 900, height: 320,
  marginLeft: 60, marginRight: 60,
  x: { type: "utc", label: "Date" },
  y: { label: "Required phase angle D (°) — 180 = full", domain: [150, 210] },
  marks: [
    Plot.ruleY([180], { stroke: "#888", strokeDasharray: "3,3" }),
    Plot.text([{date: seasonalCurve[0]?.date, label: "exact full"}],
      {x: "date", y: () => 180.6, text: "label", fill: "#888", fontSize: 11, dx: 6}),
    Plot.line(seasonalCurve, { x: "date", y: "phaseDeg", stroke: "#B35A44", strokeWidth: 2 }),
    Plot.dot(seasonalCurve.filter((_,i)=>i%5===0), {
      x: "date", y: "phaseDeg",
      fill: d => d.phaseDeg > 180 ? "#B35A44" : "#1B2E26",
      r: 2.5
    })
  ]
})

How to read the plot. The horizontal line at is “exact full.” The curve sits above the line when the striking moon must be past full (waning gibbous) — i.e., a full moon would have already risen earlier than sunset+1h, so we need to wait a day or two for the moon to drop into position. The curve sits below the line when the striking moon must be just before full (waxing gibbous) — a “true” full moon would not yet have cleared the horizon.

For mid-northern observers (D.C., ), the pattern is:

Season (full-moon date roughly) Curve relative to Phase you actually see at sunset+1h
Late spring / early summer (a few °) Near-full waxing gibbous; full moon rises after sunset, so at sunset+1h it has just cleared the horizon
Midsummer very close to Essentially full
Late summer → autumnal equinox rises above Slightly waning gibbous; the full moon rose before sunset (harvest-moon geometry)
Late autumn / early winter — peak deviation Waning gibbous – — the full moon was already up well before sunset; you must wait – days past full to catch a moonrise an hour after sunset
Late winter / early spring returns toward Back to near-full waxing gibbous

This corrects a common intuition: it is late autumn / early winter — not summer — when the striking moon visible 1 hour after sunset is a clearly waning gibbous, because that is when the geometry pushes the full moon’s natural rise time earliest relative to sunset. The “harvest moon” of September is the gateway into this regime; by November the deviation peaks. Conversely, summer full moons rise late (south-of-equator declination, short time above horizon) so a sunset+1h viewing catches them essentially at full.

In the southern hemisphere the pattern flips by six months. At the equator the curve is nearly flat at year-round.

]]> mathematics astronomy celestial-mechanics https://conair94.github.io/Quarto/posts/moonrise-phases/ Tue, 05 May 2026 00:00:00 GMT The Arcane Boiler: Powering Industrialization with ‘Heat Metal’ Connor Lockhart https://conair94.github.io/Quarto/posts/DnD-heat-metal-steam-engine/ In Dungeons & Dragons 5e, the spell Heat Metal is a low-level staple for cooking enemies in their own armor. The spell description states: “you cause a metal object to glow red hot.” If we assume the magic maintains this “red hot” state regardless of external cooling (a necessity if it’s to remain damaging while underwater or in high winds), we have discovered probably the highest energy output per level of any spell in DnD.

By wrapping this enchanted metal into a heat exchanger, we can design a steam turbine capable of generating significant wattage. Let’s estimate exactly how much power a single caster can contribute to the fantasy industrial revolution.

The Physical Constraints

To find the upper bound of our heating element, we look to the heaviest common metal object a caster can target: Plate Armor.

  1. Mass of the Heating Element: According to the Player’s Handbook, a suit of plate armor weighs 65 lbs (29.48 kg).
  2. Molar Equivalence: Plate is typically steel (mostly iron). Using the atomic mass of iron ( g/mol):
  3. Copper Conversion: For maximum efficiency, our fantasy engineers would use copper for its superior thermal conductivity. We’ll assume the spell targets an equivalent molar amount of copper ( g/mol):

Engineering the Boiler: Metal Selection

While copper is the “standard” for conductivity, different metals offer different limits. In a boiler, the “red hot” temperature is capped by the metal’s melting point.

Metal Thermal Conductivity () Melting Point Max Safe Temp Notes
Silver 429 W/m·K 961°C ~900°C Best conductivity, but “soft” at high heat.
Copper 401 W/m·K 1085°C ~1000°C The industry standard for high-flux boilers.
Gold 315 W/m·K 1064°C ~1000°C Chemically inert; great for corrosive alchemical steam.
Steel 15–50 W/m·K ~1500°C ~1300°C Poor conductivity but allows for “White Hot” temperatures.
Tungsten 173 W/m·K 3422°C ~3000°C For 9th-level casts; can sustain incredible temperatures.

Selection: For our baseline, we stick with Copper for 2nd-level slots, but transition to Tungsten for anything higher.

Engineering the Boiler: Maximizing Surface Area

Using a density of , our 33.55 kg copper mass occupies a volume of approximately 3.74 Liters. To maximize heat transfer, we must draw this metal into the largest possible surface area while maintaining structural integrity for a high-pressure boiler.

If we draw the metal into a high-density bundle of 1/4-inch nominal Type M copper tubing (OD 9.5 mm, wall 0.6 mm):

  • Cross-sectional area of metal per tube:

  • Total length of tubing possible:

  • Internal Surface Area ():

By utilizing a multi-tube heat exchanger (similar to a fire-tube or water-tube boiler), we can achieve a surface area of 5.5 m per caster. This optimization significantly increases the raw wattage captured compared to a simple pipe.

Scaling Up: Upcasting and Temperature

Heat Metal deals an extra 1d8 damage for every slot above 2nd. We can model this increased “potency” as an exponential increase in maintained temperature. While 2d8 corresponds to a “Red Hot” 800°C, a 9th-level cast represents a truly sun-like energy density:

  • 2nd Level (2d8): 800°C (Dull Red)
  • 4th Level (4d8): 1150°C (Bright Red-Orange)
  • 6th Level (6d8): 1500°C (Yellow-White)
  • 9th Level (9d8): 2000°C (White Hot)

The Spellcaster’s Endurance: Total Energy

A Level 20 caster is a walking nuclear reactor. By cycling through their spell slots, they can provide sustained power. We assume a 30% turbine efficiency for our baseline generation.

Slot Level Duration Temp (°C) Metal Raw Thermal Generated (@30%)
2nd (x3) 3 min 800 Copper 825 kW 247.5 kW
3rd (x3) 3 min 1000 Tungsten 1,320 kW 396.0 kW
4th (x3) 3 min 1150 Tungsten 1,930 kW 579.0 kW
5th (x3) 3 min 1300 Tungsten 2,650 kW 795.0 kW
6th (x2) 2 min 1500 Tungsten 3,840 kW 1,152.0 kW
7th (x2) 2 min 1650 Tungsten 4,940 kW 1,482.0 kW
8th (x1) 1 min 1850 Tungsten 6,710 kW 2,013.0 kW
9th (x1) 1 min 2000 Tungsten 8,280 kW 2,484.0 kW
TOTAL 18 min AVG 1350 - ~2,930 kW ~880 kW (1,180 HP)

A Level 20 caster can provide an average of 1,180 Horsepower for 18 minutes, dumping nearly one Gigajoule of usable electrical energy into the grid.

Mid-Level Industrialist: The 10th-Level Cleric

A 10th-level Forge Domain cleric is still a formidable power source for local industry.

Slot Level Duration Temp (°C) Metal Raw Thermal Generated (@30%)
2nd (x3) 3 min 800 Copper 825 kW 247.5 kW
3rd (x3) 3 min 1000 Tungsten 1,320 kW 396.0 kW
4th (x3) 3 min 1150 Tungsten 1,930 kW 579.0 kW
5th (x2) 2 min 1300 Tungsten 2,650 kW 795.0 kW
TOTAL 11 min AVG 1060 - ~1,590 kW ~475 kW (640 HP)

Even at level 10, a single cleric can generate over 300 MJ of usable energy—enough to run a fleet of heavy locomotives for a short-haul route.

Estimating Heat Flux () and Bromley’s Correlation

When our boiler pipe is maintained at extreme temperatures (), water in contact with it enters film boiling. In this regime, the heat transfer is governed by Bromley’s Correlation for a horizontal cylinder:

Total heat flux also includes radiation, which becomes dominant at these temperatures:

The Shift: Convection vs. Radiation

It is critical to note that and scale very differently. While convective film boiling () stays relatively stable as temperature rises, radiative heat transfer () is governed by the Stefan-Boltzmann Law, scaling with the fourth power of absolute temperature ().

  • Copper Core (2nd Level): Oxidized . At 800°C, provides ~35% of the heat.
  • Tungsten Core (9th Level): Oxidized . At 2000°C, explodes to over . Radiation accounts for over 75% of the heat transfer, resulting in a staggering 1.5 MW/m of flux.

The Universal Glow: Black Body Radiation

A common misconception in fantasy engineering is that different metals might “glow” differently at the same temperature. However, the “red hot” or “white hot” state described in the spell is governed by the principles of Black Body Radiation.

According to Planck’s Law, the spectral radiance of an object is a function of its temperature , not its chemical composition. While the intensity of the light can be modified by the material’s emissivity (), the peak wavelength (color) is determined solely by the temperature.

Wien’s Displacement Law

The mathematical justification for mapping specific colors to temperatures comes from Wien’s Displacement Law:

Where: - is the peak wavelength of light. - is Wien’s displacement constant. - is the absolute temperature in Kelvin.

As increases, shifts left toward the visible spectrum:

  • Red Hot (): . The peak is in the infrared, but the “tail” of the Planck distribution bleeds into the visible red spectrum (~700 nm).

  • Orange/Yellow (): The distribution shifts further, covering more of the visible spectrum.

  • White Hot (): The peak wavelength . The distribution covers the entire visible spectrum, emitting all colors nearly equally. To the human (or elven) eye, the object appears as a blinding, brilliant white.

This is why our choice of metal changes the melting point and conductivity, but a Copper pipe and a Tungsten pipe at will both emit the exact same “Bright Red” hue.

Power Generation: The Rankine Cycle

Increasing the boiler pressure () improves thermal efficiency by allowing a higher temperature drop across the turbine.

  1. Efficiency Gains: A pressurized boiler (e.g., 20 bar) can push efficiency toward 20-40%, depending on the sophistication of the condenser and turbine design.
  2. The Pump Tax: For our ~8 MW boiler, we’d need to pump roughly 3 L/s. At 20 bar, this consumes about 6 kW—still negligible.

Interactive Power Grid

Adjust the parameters below to see what your adventuring party can power.

Code 
viewof numCasters = Inputs.range([1, 20], {value: 1, step: 1, label: "Number of Casters"})
viewof slotLevel = Inputs.select([2, 3, 4, 5, 6, 7, 8, 9], {value: 2, label: "Spell Slot Level"})
viewof pressureBar = Inputs.range([1, 100], {value: 20, step: 1, label: "Boiler Pressure (Bar)"})
Code 
sigma = 5.67e-8
areaPerCaster = 5.5 // Optimized area in m^2
waterTemp = 100 // °C

// Dynamic Emissivity and Temperature mapping
materialProps = new Map([
  [2, { temp: 800, eps: 0.8, name: "Copper" }],
  [3, { temp: 1000, eps: 0.7, name: "Tungsten" }],
  [4, { temp: 1150, eps: 0.7, name: "Tungsten" }],
  [5, { temp: 1300, eps: 0.7, name: "Tungsten" }],
  [6, { temp: 1500, eps: 0.7, name: "Tungsten" }],
  [7, { temp: 1650, eps: 0.7, name: "Tungsten" }],
  [8, { temp: 1850, eps: 0.7, name: "Tungsten" }],
  [9, { temp: 2000, eps: 0.7, name: "Tungsten" }]
])

currentProp = materialProps.get(slotLevel)
tempCelsius = currentProp.temp
epsilon = currentProp.eps

// Simplified efficiency scaling: 20% at 1 bar, scaling to ~40% at 100 bar
efficiency = 0.20 + 0.10 * Math.log10(pressureBar)

// Flux calculation
Ts = tempCelsius + 273.15
Tw = waterTemp + 273.15
deltaT = Ts - Tw
h_conv = 135
h_rad = epsilon * sigma * (Math.pow(Ts, 4) - Math.pow(Tw, 4)) / deltaT
q_prime = (h_conv + 0.75 * h_rad) * deltaT

totalRawPower = numCasters * areaPerCaster * q_prime // Watts

massFlow = totalRawPower / 2257000 // kg/s
volFlow = massFlow / 1000 // m^3/s
pumpPower = volFlow * (pressureBar * 100000) // Watts

totalGeneratedPower = (totalRawPower * efficiency) - pumpPower // Watts
hp = totalGeneratedPower / 745.7

md`
### Analysis

Using **Level ${slotLevel}** slots with a **${currentProp.name}** core at **${pressureBar} Bar**:

# ${d3.format(".2f")(totalGeneratedPower / 1000)} kW (${d3.format(".1f")(hp)} HP)

**System Performance:**
- **Boiler Temperature:** ${tempCelsius}°C
- **Surface Area:** ${d3.format(".1f")(numCasters * areaPerCaster)} m²
- **Core Material:** ${currentProp.name} (ε = ${epsilon})
- **Estimated Efficiency:** ${d3.format(".1%")(efficiency)}
- **Energy per Minute (Total):** ${d3.format(".2f")(totalRawPower * 60 / 1e6)} MJ

**What can this power?**
- **Motorized Carriage:** Needs ~15 HP. *One 9th-level heat metal can power ~200 carriages!*
- **Steam Locomotive:** Needs ~500 HP. *A 9th-level heat metal can power 6 locomotives or 6 M4 Sherman tanks.*
- **Heavy Industrial Airship:** Needs ~1500 HP. *a 9th level caster can power a heavy airship for 2 minutes with one 9th-level slot.*
`

Assumptions & Limitations

  • Magic as an Infinite Sink: This assumes the spell provides the energy required to maintain the temperature regardless of the power being siphoned off.
  • Material Stress: Copper and Tungsten at these temperatures are significantly weakened. Engineers would likely need magical reinforcement (Mending or Permanency) to prevent bursting under the high pressures of a Rankine cycle.
  • Concentration: Collectivized labor is a must. A caster must concentrate for the full duration (1 minute), but a group of only 200 low to mid level casters working in shifts could keep the lights on 24/7 at more than a constant megawatt of power.
]]> Estimations D&D Engineering https://conair94.github.io/Quarto/posts/DnD-heat-metal-steam-engine/ Sat, 18 Apr 2026 00:00:00 GMT The Slushee Phase-Change Optimization Connor Lockhart https://conair94.github.io/Quarto/posts/slushee-optimal-temperature/ Have you ever reached the end of an Icee or Slurpee only to find a desolate, dry block of white ice? This is the “Slushee Dead Zone”—a state where the liquid-to-solid ratio has collapsed, leaving the remaining ice stranded without enough liquid to be drinkable.

The problem is one of phase-change synchronization. For a perfect drinking experience, the rate at which you consume the liquid must match the rate at which the ambient heat melts the ice. We will use the 7-11 Slurpee as our standard-bearer for frozen liquid ice beverages and attempt to calculate what temperature is required for a given drink consumption rate to avoid having a dry chunk of ice at the before you’ve finished the entire beverage.

1. Geometry: The Tapered Frustum

The local geometry of the object determines how rapidly heat transfers since it changes local convection rates for heat transfer. We will model this heat transfer as uniform per unit surface area of the slushee container. While 7-11 cups are not perfect cylinders; they are frustums (tapered cones).

Cup Size Comparison

The diagram below shows the relative 3D scale of the standard 7-11 lineup.

Code 
// Visual representation of cup sizes in 3D perspective
html`<div style="display: flex; align-items: flex-end; gap: 30px; justify-content: center; padding: 40px; background: #f0f4f8; border-radius: 12px;">
  ${['small', 'medium', 'large', 'xlarge'].map(size => {
    const d = {
      small: { h: 4.5, r1: 1.1, r2: 1.6, label: "12oz" },
      medium: { h: 6.0, r1: 1.25, r2: 1.87, label: "22oz" },
      large: { h: 7.0, r1: 1.37, r2: 2.12, label: "30oz" },
      xlarge: { h: 8.5, r1: 1.5, r2: 2.37, label: "40oz" }
    }[size];
    const scale = 25;
    const h = d.h * scale;
    const r1 = d.r1 * scale;
    const r2 = d.r2 * scale;
    const tilt = 0.25; // Perspective tilt factor
    
    return html`<div style="text-align: center;">
      <svg width="${r2*2 + 20}" height="${h + r2*tilt*2 + 40}" style="overflow: visible;">
        <defs>
          <linearGradient id="grad-${size}" x1="0%" y1="0%" x2="100%" y2="0%">
            <stop offset="0%" style="stop-color:#d35400;stop-opacity:1" />
            <stop offset="30%" style="stop-color:#e67e22;stop-opacity:1" />
            <stop offset="60%" style="stop-color:#f39c12;stop-opacity:1" />
            <stop offset="100%" style="stop-color:#d35400;stop-opacity:1" />
          </linearGradient>
        </defs>
        
        <!-- Background part of bottom ellipse (dashed or lighter) -->
        <ellipse cx="${r2 + 10}" cy="${h + r2*tilt}" rx="${r1}" ry="${r1*tilt}" fill="none" stroke="#ccc" stroke-dasharray="2,2" />
        
        <!-- Body of the frustum -->
        <path d="M ${10} ${r2*tilt} 
                 L ${r2 - r1 + 10} ${h + r2*tilt} 
                 A ${r1} ${r1*tilt} 0 0 0 ${r2 + r1 + 10} ${h + r2*tilt} 
                 L ${2*r2 + 10} ${r2*tilt} 
                 A ${r2} ${r2*tilt} 0 0 1 10 ${r2*tilt}" 
              fill="url(#grad-${size})" stroke="#333" stroke-width="1.5" />
        
        <!-- Top face of the slushee -->
        <ellipse cx="${r2 + 10}" cy="${r2*tilt}" rx="${r2}" ry="${r2*tilt}" fill="#fff" fill-opacity="0.8" stroke="#333" stroke-width="1.5" />
        
        <!-- Content/Ice texture on top -->
        <ellipse cx="${r2 + 10}" cy="${r2*tilt}" rx="${r2*0.9}" ry="${r2*tilt*0.9}" fill="#fdfefe" fill-opacity="0.5" />
        
        <text x="${r2 + 10}" y="${h + r2*tilt*2 + 30}" text-anchor="middle" font-family="system-ui" font-weight="bold" font-size="14px" fill="#2c3e50">${d.label}</text>
      </svg>
    </div>`;
  })}
</div>`

2. Thermodynamics: Continuous Phase Change

Units of Measurement

To model this system, we utilize a mix of SI units for physical accuracy and US Customary units for user-facing context:

  • Temperature (): Celsius is the standard for thermodynamics involving water phase changes, where is the critical transition point.

  • Mass (): Grams are used for all mass calculations to maintain a direct relationship with milliliters for density ( for water). We neglect the potential altered density from flavoring.

  • Energy (): Joules allow us to use the standard Latent Heat of Fusion constant of water () to determine exactly how much heat energy is required to melt the ice.

  • Volume ( and ): We accept input in fluid ounces (the commercial standard for 7-11) but convert internally to milliliters () for all physical and geometric calculations.

  • Time (): Minutes are used as the temporal scale for consumption to provide an intuitive ``drinking time’’’ result.

We model the slushee as a continuous system.

Heat Transfer

Heat flows from the ambient air () through the cup walls: This heat melts the ice at a rate of .

Consumption

We assume a constant volumetric consumption rate (oz/min). Because of the straw’s liquid bias, the rate of ice removal is lower than the rate of liquid removal.

3. Governing Differential Equation

To justify our simulation results, we derive the governing equation for the Volume Ice Ratio (), defined as , where is the volume of ice and is the total volume ().

Conservation of Volume

The total volume of the system changes due to consumption () and the volume contraction associated with melting: Where . Since , the second term is negative, representing the “shrinkage” of the slushee as it turns to liquid.

Rate of Change of Ice

The ice volume decreases through both melting and drinking: Here, is our Ice Extraction Efficiency, which we define as a linear function of the volume fraction : This ensures that at full volume and when the cup is empty.

Deriving

Using the quotient rule on :

Substituting our expressions for and :

Expanding and simplifying:

This reveals the fundamental tension: Melting always decreases the ice ratio, while Drinking (with a liquid bias ) increases it. The “Slushee Dead Zone” occurs when the ice enrichment term dominates the ice decay term for a sustained period.

4. Interactive Optimization

Adjust the parameters below to see if your drinking habits are sustainable.

Code 
viewof ambientTempC = Inputs.range([0, 45], {value: 25, step: 1, label: "Ambient Temp (°C)"})
viewof cupSize = Inputs.select(new Map([
  ["Small (12 oz)", "small"],
  ["Medium (22 oz)", "medium"],
  ["Large (30 oz)", "large"],
  ["X-Large (40 oz)", "xlarge"]
]), {label: "Cup Size"})
viewof consumptionRate = Inputs.range([0.1, 5.0], {value: 2.0, step: 0.1, label: "Consumption (oz/min)"})
viewof initialIceRatio = Inputs.range([0.4, 0.8], {value: 0.6, step: 0.05, label: "Initial Ice Ratio"})
viewof liquidBias = Inputs.range([0.1, 1.0], {value: 0.5, step: 0.1, label: "Ice-in-Straw Bias"})
viewof runTrigger = Inputs.button("Run Simulation")
Code 
ozToMl = 29.57
inchToCm = 2.54
Lf = 334 // J/g
h_coeff = 9.5 // W/m^2K
rho_ice = 0.917 // g/cm^3
rho_liq = 1.0 // g/cm^3

cupSizes = ({
  small: { h: 4.5 * inchToCm, r1: (2.25/2) * inchToCm, r2: (3.25/2) * inchToCm },
  medium: { h: 6.0 * inchToCm, r1: (2.5/2) * inchToCm, r2: (3.75/2) * inchToCm },
  large: { h: 7.0 * inchToCm, r1: (2.75/2) * inchToCm, r2: (4.25/2) * inchToCm },
  xlarge: { h: 8.5 * inchToCm, r1: (3.0/2) * inchToCm, r2: (4.75/2) * inchToCm }
})

// Simulation Function
function runSimulation(temp, sizeKey, rate, initRatio, initBias, trigger) {
  const d = cupSizes[sizeKey];
  const dt = 0.1; // minutes
  const C_ml = rate * ozToMl;
  
  const startingIce = (d.h * Math.PI / 3 * (d.r1**2 + d.r1*d.r2 + d.r2**2)) * initRatio * rho_ice;
  const startingLiq = (d.h * Math.PI / 3 * (d.r1**2 + d.r1*d.r2 + d.r2**2)) * (1 - initRatio) * rho_liq;
  const startingVol = (startingIce / rho_ice) + (startingLiq / rho_liq);

  let m_ice = startingIce;
  let m_liq = startingLiq;
  
  const history = [];
  let t = 0;

  while (m_ice + m_liq > 1 && history.length < 1000) {
    let currentVol = (m_ice / rho_ice) + (m_liq / rho_liq);
    let iceRatio = m_ice / (m_ice + m_liq);
    let volFrac = Math.max(0, currentVol / startingVol);
    
    // Dynamic bias: At volFrac=1, bias is initBias. At volFrac=0, bias is 1.0 (no effect).
    // The "Bias Error" (1 - initBias) scales to 0 as volume drops.
    let currentBias = initBias + (1 - initBias) * (1 - volFrac);
    
    let heightFrac = Math.max(0, currentVol / (d.h * Math.PI / 3 * (d.r1**2 + d.r1*d.r2 + d.r2**2)));
    let y = d.h * heightFrac;
    let ry = d.r1 + (d.r2 - d.r1) * heightFrac;
    let Area = Math.PI * (d.r1 + ry) * Math.sqrt((ry - d.r1)**2 + y**2) + Math.PI * d.r1**2;
    Area = Area / 10000;

    history.push({ time: t, iceRatio: iceRatio * 100, vol: currentVol / ozToMl });

    let dQ = h_coeff * Area * (temp - 0) * (dt * 60);
    let melted = dQ / Lf;
    melted = Math.min(melted, m_ice);
    m_ice -= melted;
    m_liq += melted;

    let volOut = C_ml * dt;
    let r_out = iceRatio * currentBias;
    m_ice -= Math.min(m_ice, volOut * r_out * rho_ice);
    m_liq -= Math.min(m_liq, volOut * (1 - r_out) * rho_liq);

    t += dt;
  }
  return history;
}
Code 
results = runSimulation(ambientTempC, cupSize, consumptionRate, initialIceRatio, liquidBias, runTrigger)

// Plot
Plot.plot({
  title: "Ice Ratio Projection",
  subtitle: "Keep the ratio below 90% for a successful finish",
  y: { label: "Ice Ratio (%)", domain: [0, 100] },
  x: { label: "Time (minutes)" },
  marks: [
    Plot.lineY(results, {x: "time", y: "iceRatio", stroke: "steelblue", strokeWidth: 3}),
    Plot.ruleY([90], {stroke: "red", strokeDasharray: "4,4"}),
    Plot.text(["DEAD ZONE"], {x: 0, y: 92, frameAnchor: "left", fill: "red"})
  ]
})
Code 
md`
### Analysis
# Under the assumption you would not like ice with no liquid:

Final Ice Ratio: **${results[results.length-1].iceRatio.toFixed(1)}%**  
Total Time: **${results[results.length-1].time.toFixed(1)} minutes**

${results[results.length-1].iceRatio > 90 
  ? "❌ **FAILED**: You were left with a block of dry ice! Decrease your consumption rate or find a warmer spot." 
  : "✅ **SUCCESS**: A perfect balance of phase-change and consumption."}
`

Summary of Optimal Temperatures

The following table shows the minimum ambient temperature required to finish a 7-11 slushee at two different steady consumption rates without hitting the Dead Zone (assuming an initial ice ratio of 60%).

Cup Size 2 oz/min (Standard) 3 oz/min (Fast)
Small (12 oz) ~14°C (57°F) ~20°C (68°F)
Medium (22 oz) ~21°C (70°F) ~27°C (81°F)
Large (30 oz) ~26°C (79°F) ~33°C (91°F)
X-Large (40 oz) ~32°C (90°F) ~39°C (102°F)

Conclusion

The larger the cup, the lower the surface-area-to-volume ratio, and thus the slower the relative melting rate. If you want to drink the entire thing without having to wait around for more to melt and you’re going for the 40oz X-Large, you’d better be drinking it in the heat of mid-July.

Stay tuned for the sequel when I empirically test this on my next bike ride home.

All this is to say, keep ICE out of all things, including the final moments of drinking a slushee!

]]> Estimations Thermodynamics https://conair94.github.io/Quarto/posts/slushee-optimal-temperature/ Fri, 17 Apr 2026 00:00:00 GMT The Parking Ticket Expected Value: A Poisson Process Estimation Connor Lockhart https://conair94.github.io/Quarto/posts/parking-ticket-estimation/ I was parking my car today and while I was enroute to proctor an exam for my probability class, I had a curious idea. I was wondering what an expected value argument would say about whether or not to pay for parking. I get 1 hour of parking for free, but all day parking is $25. I know from an absent minded friend that the ticket for having an expired parking pass is $60.

Assuming that the parking attendant checks the parking lot as a Poisson process with rate , what would have to be for me to stay hours past my free parking and have my highest expected value being to not pay for parking?

The Poisson Process

A Poisson process is a mathematical model for a series of discrete events where the average time between events is known, but the exact timing of events is random. Key properties include:

  • Independence: Events occur independently of each other.

  • Constant Rate: The average rate (events per unit of time) is constant.

  • Memorylessness: The time until the next event does not depend on how much time has already passed.

In our case, represents the number of times per hour the parking attendant checks the lot.

The Math

If you stay hours past your free hour, the number of checks that occur in that interval follows a Poisson distribution with mean :

You will receive a ticket if the attendant checks the lot at least once during your stay (). The probability of being ticketed is:

Expected Cost

The expected cost of not paying for parking is the cost of the ticket () multiplied by the probability of being ticketed:

The cost of paying for parking is a flat fee . You should (mathematically) choose to not pay if:

Solving for the Critical Rate ()

To find the threshold rate where it becomes worth it to pay, we set the costs equal:

If the attendant checks the lot more frequently than , your expected cost of not paying exceeds the cost of the permit.

Interactive Estimation

Use the sliders below to adjust the parameters of your parking situation and see your “Expected Value” strategy.

Code 
viewof t = Inputs.range([0.1, 12], {value: 3, step: 0.1, label: "Hours past free parking (t)"})
viewof cTicket = Inputs.number({value: 60, label: "Ticket Cost ($)"})
viewof cParking = Inputs.number({value: 25, label: "All-day Parking Cost ($)"})
viewof alpha = Inputs.range([0.01, 2], {value: 0.1, step: 0.01, label: "Checks per hour (α)"})
Code 
probTicket = 1 - Math.exp(-alpha * t)
expectedCost = cTicket * probTicket
criticalAlpha = cParking < cTicket ? -Math.log(1 - (cParking / cTicket)) / t : 0

md`
### Results

At a check rate of **${alpha}** times per hour, your probability of getting ticketed over **${t}** hours is **${d3.format(".1%")(probTicket)}**.

- **Expected cost of not paying:** \$${d3.format(".2f")(expectedCost)}
- **Cost of paying:** \$${d3.format(".2f")(cParking)}

${expectedCost < cParking 
  ? "### 🟢 Strategy: Don't Pay" 
  : "### 🔴 Strategy: Pay for Parking"}

${cParking < cTicket 
  ? md`The **critical rate** for your stay is **${d3.format(".3f")(criticalAlpha)}** checks per hour. If you think the attendant rounds the lot more than once every **${d3.format(".1f")(1/criticalAlpha)}** hours, you should pay!`
  : md`Since the parking permit costs as much as or more than the ticket itself, **you should never pay** for parking from a purely expected-value perspective!`}
`

Caveats

This model assumes the attendant’s rounds are truly random (Poisson). In reality, attendants might follow a schedule, which would change the distribution. Additionally, most people are “risk-averse” and would pay even if the expected value is slightly in favor of not paying, to avoid the high-variance outcome of a $60 fine! A second estimation could be done to determine how much money is profitable to invest in discovering the attendants checking schedule, which would allow one to not pay for parking with higher accuracy.

]]> Musings Estimations https://conair94.github.io/Quarto/posts/parking-ticket-estimation/ Wed, 08 Apr 2026 00:00:00 GMT Discrete and Stochastic Structures in Hyperbolic Geometry Connor Lockhart https://conair94.github.io/Quarto/posts/academic-work/ My research focuses on the intersection of model theory, topology, and stochastic geometry, specifically through the lens of structures embedded in hyperbolic space. Two primary areas of my work involve the pseudofiniteness of the Farey graph and the properties of Ideal Poisson-Voronoi Tessellations (IPVT).

Pseudofiniteness of the Farey Graph

The Farey graph is a classic object in number theory and hyperbolic geometry. Its vertex set consists of the rational numbers , and two vertices and are adjacent if . Geometrically, this graph forms an infinite triangulation of the hyperbolic plane .

In recent work, I explored the pseudofiniteness of this structure. A structure is pseudofinite if every first order sentence satisfied by the structure can be satisfied by a finite structures. While the Farey graph is infinite and possesses a rigid combinatorial structure, I demonstrated that its theory is indeed pseudofinite.

The key to this proof lies in constructing a sequence of finite triangulations on surfaces of increasingly high genus. While no finite planar graph can satisfy the axioms of the Farey graph for sufficiently large substructures, triangulations densely embedded on orientable surfaces can “mimic” the local properties of the Farey graph, satisfying any finite subset of its first-order axiomatization.

Spatial Stochastic Processes and Random Tessellations

Beyond discrete, deterministic graphs, I also study stochastic structures in hyperbolic space. A particularly fascinating object is the Ideal Poisson-Voronoi Tessellation (IPVT), denoted .

The Emergence of the Ideal Limit

In Euclidean space, as the intensity of a Poisson point process goes to zero, the resulting Voronoi tessellation degenerates—the cells simply grow to cover the entire space. However, in hyperbolic space , the exponential volume growth allows for a non-trivial limit to emerge as .

This limit, the IPVT, is an isometry-invariant decomposition of into countably many unbounded polytopes. Each cell in this tessellation has a unique “end” on the ideal boundary .

Geometric Properties

Some striking properties of these random tessellations include: - Unique Ends: Each tile is unbounded but converges to a single point on the ideal boundary.

  • Tree-like Structure: In the 2D case (), the union of the boundaries of the tiles, , is a random embedding of a 3-regular tree with geodesic edges.

  • Invariance: The law of is invariant under every isometry of , making it a “natural” stochastic tiling of hyperbolic space.

Connecting the Discrete and the Stochastic

Both the Farey graph and the Ideal Poisson-Voronoi Tessellation provide ways to partition hyperbolic space into meaningful units. The Farey graph gives us a deterministic, highly symmetric triangulation, while the IPVT gives us a stochastic, isometry-invariant tiling. My work aims to bridge these perspectives, using tools from model theory to understand the limits of discrete structures and stochastic geometry to describe the “typical” behavior of hyperbolic partitions.

For those interested in the technical details, the full proofs regarding the Farey graph’s pseudofiniteness and the coordinate descriptions of the IPVT (utilizing Poisson processes on the boundary ) can be found at arXiv:2603.23900.

]]> Academic Work Mathematics Hyperbolic Geometry https://conair94.github.io/Quarto/posts/academic-work/ Wed, 08 Apr 2026 00:00:00 GMT The Laundry Quarter Recurrence: A Birthday Problem Estimation Connor Lockhart https://conair94.github.io/Quarto/posts/laundry-quarter-estimation/ Have you ever wondered if the quarter you just dropped into the laundry machine is one you’ve held before? A friend recently asked me this very question. A solution can be derived from the same idea as the Generalized Birthday Problem, the odds might be higher than you’d expect.

The Math

To estimate this, we consider: - : The total number of quarters you’ve handled over a period of time. - : The total pool of quarters in circulation in your local area.

The true probability that at least two quarters in your sample of are the same is given by:

Deriving the True Probability

To find the probability of at least one collision, it is easier to calculate the probability of no collisions and subtract it from 1.

If we have a pool of quarters and we pick of them: 1. The first quarter can be anything ( chance of being “new”). 2. The second quarter must be different from the first ( chance). 3. The -th quarter must be different from all previous quarters ( chance).

The probability that all quarters are unique is the product of these individual probabilities:

Thus, the probability of at least one duplicate is .

Deriving the Approximation

For large and relatively small , we can use the Taylor series expansion for the exponential function, for small . Conversely, .

Substituting this into our product:

The sum of the first integers is , so:

This gives us the familiar approximation for the birthday problem:

Estimating the Local Pool ()

Rather than guessing , we can estimate it based on the population. If we know the total number of quarters in the US () and the US population (), we can estimate the local pool for a metro area with population :

The “Loss Rate” accounts for quarters that are “dormant” (in jars or couch cushions) or have been lost to the general economy.

Interactive Estimation

Adjust the sliders below to see how your habits and your city’s size affect the likelihood of a “quarter collision.”

Code 
viewof quartersPerWeek = Inputs.range([1, 100], {value: 20, step: 1, label: "Quarters spent/week"})
viewof years = Inputs.range([0.1, 50], {value: 3, step: 0.1, label: "Years in area"})
viewof metroPopulation = Inputs.number({value: 1000000, label: "Metro Population"})
viewof lossRate = Inputs.range([0, 0.99], {value: 0.5, step: 0.01, label: "Loss Rate (Dormant/Lost)"})
Code 
totalUSQuarters = 65000000000
totalUSPopulation = 349000000

// Calculations
n = quartersPerWeek * 52 * years
N = totalUSQuarters * (metroPopulation / totalUSPopulation) * (1 - lossRate)

// True Probability using log-sum for stability
function calculateTrueProb(n, N) {
  if (n > N) return 1;
  let logProbNot = 0;
  for (let i = 0; i < n; i++) {
    logProbNot += Math.log(1 - i / N);
  }
  return 1 - Math.exp(logProbNot);
}

probTrue = calculateTrueProb(n, N)
probApprox = 1 - Math.exp(-(n * (n - 1)) / (2 * N))

md`
### Results

Based on a US total of **65 billion quarters** and a population of **349 million**, your local pool **N** is estimated at **${d3.format(",")(Math.round(N))}** active quarters.

Over **${years}** years spending **${quartersPerWeek}** quarters a week, you've handled approximately **${d3.format(",")(Math.round(n))}** quarters.

The probability of having used the same quarter twice is:

## ${d3.format(".4%")(probTrue)}

*(Approximation: ${d3.format(".4%")(probApprox)})*
`

Assumptions

This model assumes a “perfectly mixed” pool where every quarter in the metro area has an equal chance of landing in your pocket. In reality, quarters might cluster in local businesses or laundromats, potentially increasing the local probability even further!

]]> Musings Estimations https://conair94.github.io/Quarto/posts/laundry-quarter-estimation/ Wed, 01 Apr 2026 00:00:00 GMT