Skip to content

MUSIC: <freeze_out_surface> switch, global or per instance; quieter vertex-conservation warning - #142

Merged
jhputschke merged 5 commits into
music4gpu_testfrom
pair_h5_music_surface_off
Sep 25, 2026
Merged

jhputschke merged 5 commits into
music4gpu_testfrom
pair_h5_music_surface_off

Conversation

@jhputschke

@jhputschke jhputschke commented Sep 25, 2026 •

Copy link
Copy Markdown
Collaborator

Merge after #141. Until then this PR also shows #141's three commits; afterwards only the two below remain.

Summary

  • <Hydro><MUSIC><freeze_out_surface> (ff513d63), default 1 in jetscape_main.xml.
    • At 0, MUSIC4GPU builds no freeze-out surface. It stops on the equivalent test, max(e) < e_fo, at the same step, and the evolution is bit-identical.
    • This is meant for runs that only need the evolution, such as ML training data, and saves ~6 s per MUSIC run.
    • Where to set it:
      • In the first <Hydro><MUSIC> block it applies to every MUSIC instance, like all MUSIC settings.
      • The same tag inside an instance's own block (matched by <name>) overrides it for that instance.
      • MpiMusic::set_freeze_out_surface() overrides both. The value is handed to MUSIC at the start of every evolution.
    • Example: a two-stage run with no surface for the background, and a surface for a jet leg that will be particlized later. Set 0 in the first block and 1 in MUSIC_2's own block.
    • The wrapper logs the setting per instance, and warns when there is no surface but it would be exported (skip_surface 0).
    • get_music4gpu.sh pins MUSIC4GPU 9bdbf92.
    • README_BulkFast.md explains skip_surface vs freeze_out_surface.
    • CPU MUSIC (external_packages/music) doesn't know the parameter: it always builds the surface, although the log line still reports the requested setting.
  • Liquefier: warn on a vertex 4-momentum mismatch only above 5% of E_in (d679b204).
    • Matter + LBT kinematics always miss by more than the old 1e-10 GeV threshold. A 0–10% jet event printed 19 warnings for 25 droplets, all at most 1.7% of E_in.
    • The warning now fires above 5% of the vertex's incoming energy and prints E_in.
    • The p_missing parton is still added at the 1e-10 GeV threshold, so the droplets and the shower graph are unchanged.

Results

Setup: 0–10% Au+Au, 3D MC-Glauber, 100×100×60 grid, music4gpu on a GB10, seed 1.

run surface on surface off
hydro-only event 23.3 s 17.1 s
two-stage pair 60.1 s 49.1 s (55.3 s with the surface kept on the jet leg only)
  • Evolutions and stop steps are bit-identical.
  • The grid-edge flag fires at the same step.
  • The forced-CPU path (MUSIC_FORCE_CPU=1) is bit-identical too.
  • With d679b204, the seed-1 output is identical apart from wall time, with 0 warnings.

Merge notes

🤖 Generated with Claude Code

https://claude.ai/code/session_019CrjXPHRbBKFbRYS7cdbKC

jhputschke and others added 5 commits September 24, 2026 17:58
…eport it

When MUSIC's freeze-out surface reaches the transverse grid edge it sets
DATA.reRunHydro and returns from the evolution, expecting its driver to
re-run on a larger grid (MUSIC's own main.cpp loops on it). X-SCAPE never
re-runs, and MUSIC clears the flag only in its constructor, so once one
event touched the edge every later event of that MUSIC instance stopped at
its first freeze-out check, silently. Seen in a 3-event two-stage run on a
small test grid: event 2's jet leg stopped after 1 frame.

- Clear the flag before each evolution (full and time-stepped paths).
- After the evolution, JSWARN if the surface hit the boundary: the stored
  evolution is truncated.
- MpiMusic::get_hit_grid_boundary() exposes it, so writers can record it
  per event.

Works with both MUSIC (CPU) and music4gpu, which have the same accessors.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019CrjXPHRbBKFbRYS7cdbKC
- Check out MUSIC4GPU b9cc8be (XSCAPE branch) after cloning, the way
  get_music.sh pins MUSIC. It adds add_hydro_source_terms_from_jet, which
  MusicWrapper calls since PR #138; the unpinned branch head made builds
  non-reproducible.
- Also download the hotQCD EOS table matched to UrQMD (EOS 9). Only the
  SMASH-matched one (EOS 91) was fetched, but the PyJetscape prod_AuAu_0_10
  productions use EOS 9.

The pin needs b9cc8be pushed to github.com/jhputschke/MUSIC4GPU.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019CrjXPHRbBKFbRYS7cdbKC
… step

A CausalLiquefier droplet deposits in exactly one hydro step, the one that
contains tau_drop + tau_delay, but LiquefierBase::get_source() looped over
every droplet (with a cosh each) for every cell at every step, and
HydroSourceJETSCAPE locked the liquefier's weak_ptr once per cell. For a
0-10% Au+Au two-stage event with 25 droplets that was 126 s of 184 s.

- LiquefierBase::prepare_active_droplets(tau_lo, tau_hi) keeps the droplets
  for which droplet_may_contribute() holds; get_source() visits only those
  (in their original order) for query times inside the window, and every
  droplet otherwise, so callers that never prepare are unaffected. Adding a
  droplet or clearing the list drops the window.
- CausalLiquefier::droplet_may_contribute(): the deposit time lies within
  the window, widened by dtau/2 + 1e-3 fm (tau arrives as a float).
- HydroSourceJETSCAPE::prepare_list_for_current_tau_frame() prepares the
  window [tau - step, tau + 2 step] once per MUSIC time step and locks the
  liquefier once there. MUSIC4GPU 3037be7 calls it for the jet source.
- get_music4gpu.sh: pin MUSIC4GPU 3037be7.

Result: 184 s -> 60 s per event (the no-deposition run takes 58 s), output
bit-identical (arr, arr_bg, droplets) on the GPU and CPU paths, full and
small grids, single and multi-event.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019CrjXPHRbBKFbRYS7cdbKC
<Hydro><MUSIC><freeze_out_surface> (main-XML default 1) tells MUSIC whether
to build its freeze-out surface. At 0 (music4gpu 9bdbf92) MUSIC builds none
and stops on the equivalent max(e) < e_fo test at the same step, with a
bit-identical evolution: ~6 s less per MUSIC run, for runs that only need
the evolution (training data).

- In the first <Hydro><MUSIC> block it applies to every MUSIC instance, as
  all MUSIC settings do; the same tag inside an instance's own block
  (matched by <name>) overrides it for that instance. E.g. a two-stage run
  with no surface for the background and one for the jet leg that is
  particlized later: 0 in the first block, 1 in MUSIC_2's.
- MpiMusic::set_freeze_out_surface() overrides both; the value is handed
  to MUSIC at the start of every evolution.
- Logs the setting per instance; warns if there is no surface but it would
  be exported (skip_surface 0).
- get_music4gpu.sh: pin MUSIC4GPU 9bdbf92 (branch XSCAPE_surface_off).
- README_BulkFast: skip_surface vs freeze_out_surface.

Measured: hydro-only 23.3 -> 17.1 s/event, pair 60.1 -> 49.1 s/event
(55.3 s with the surface on the jet leg only), bit-identical throughout.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019CrjXPHRbBKFbRYS7cdbKC
check_energy_momentum_conservation() warned whenever a vertex missed by
more than hydro_source_abs_err = 1e-10 GeV. Matter + LBT kinematics (E
recomputed from p and virtuality, soft partons cut) always miss by more:
a 0-10% Au+Au jet event printed 19 warnings for 25 droplets, all E-only
mismatches of at most 1.7% of E_in, or massless soft partons left out.

The warning now fires only when the largest component of p_missing
exceeds e_mom_rel_tol = 5e-2 times the vertex's incoming energy, and it
prints E_in. The p_missing parton is still added at the 1e-10 GeV
threshold, so the droplets and the shower graph are unchanged: seed 1
output is identical apart from wall time, with 0 warnings.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant