Repository navigation
feat: add a run-time profile to the standalone driver - #8
Conversation
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e287c96a5d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 834e65a7b9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4f7bf27624
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2070c520f6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
|
Codex Review: Didn't find any major issues. Breezy! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Speed work on CableDyn needs to know where a run spends its time, on any build and any deck. Until now the only breakdown was the profile of the OpenFAST module and the finite-EI step counters, which no standalone run could switch on. With CABLEDYN_PROFILE set (the variable the OpenFAST module already reads), the driver prints, before the success line, the wall time of input parsing, initialisation and statics, and the dynamic march, split into the fluid sampled by the driver, the line, cable and object steps, the checks, the outputs and the progress report, with the time per step. It also prints the EI = 0 line steps and their Newton iterations, and the finite-EI cable step counters and times. The phases are laps taken in the time marches of every route, so they add up to the total. The EI = 0 counts are taken in CD_Step_Model, the one place every tension-only line step passes, with atomic updates because lines step in parallel. Unarmed, each lap is one test of a flag. The profile only reads the clock: every output file of the eight example decks tried, one per route, is byte-identical with and without it, with one OpenMP thread and with the default. Two driver tests check the report and that identity. Signed-off-by: Jae Hoon Seo <jaehoon.seo@inha.ac.kr>
Review of the run-time profile found two cases where time reached the wrong phase. Laps charged the time since the previous lap to a phase, so whatever ran after the last lap fell to finalisation: the parse or statics of a run that stopped with an error, and the output files that write_out writes for a static deck. The profile now tracks the running phase: CD_Profile_Enter charges the time since the previous mark to it and starts the next one, and the report only flushes the phase that is running. Each march marks where its fluid update, step, checks, output and progress report begin; a run that stops with an error keeps its time in the phase it stopped in and finalisation stays at zero, and a static deck's output files count as initialisation. A unit test checks the partition, a failed run's time kept in its phase (it fails if a flush charges finalisation instead), and exact line-step counts from an OpenMP team; a driver test checks the profile of a run that stops with exit code 2. Signed-off-by: Jae Hoon Seo <jaehoon.seo@inha.ac.kr>
The second review found two phase boundaries that misplaced work. The deck's wave synthesis or stream-function solve ran before the profile left the input phase, so it was reported as input parsing; it now counts as initialisation, while the bathymetry file read stays input. On the mixed EI = 0 + finite-EI route the step went straight to the output phase, so its status and convergence checks were charged to the outputs; it now enters the check phase and moves to the output phase once the checks pass, as the deck-driver marches do. Signed-off-by: Jae Hoon Seo <jaehoon.seo@inha.ac.kr>
A third review found four more points. The finite-EI step counters are process-global, so with them armed the aggregate of the mixed EI = 0 + finite-EI route stepped its cables one after another; the profile now arms them only on the routes that step their cables in turn anyway, and on the mixed route reports that the cable steps are not counted, so the profiled run executes as an unprofiled one. The Hermite and the objects-only marches entered the output phase before checking the step status, so a failed step's time went to the outputs; they now check first. Committed steps were counted in the progress report after the outputs, so a step whose output failed was missed; every march now counts a step when it has passed its checks, before its outputs. Signed-off-by: Jae Hoon Seo <jaehoon.seo@inha.ac.kr>
The static route entered the finalisation phase right after write_out, so a static solve that did not converge, or an output that failed, charged its error handling to finalisation. It now enters finalisation only after a converged solve whose output was written. Signed-off-by: Jae Hoon Seo <jaehoon.seo@inha.ac.kr>
5a42c0c to
0fa3575
Compare
1 participant
Summary
Adds an opt-in run-time profile to the standalone driver. This is the measuring tool for the speed work that follows: every later optimisation can report before/after numbers from it, and users can see where a run of their own deck spends its time, with the release executable as well.
With
CABLEDYN_PROFILE=1(the variable the OpenFAST module already reads for its own profile), the driver prints, just before the success line:(
examples/buoy_clamped_cable.dat: the 600 march steps cost 4849 cable steps, because the monolithic body step re-steps the clamped cable in every body iteration. That is the kind of lead the profile is for.)Design
CableDyn_Profile. It holds process-global phase timers and the phase that is running.CD_Profile_Enter(phase)charges the time since the previous mark to the running phase and startsphase, so the phases add up exactly to the total. The report only flushes the running phase, so a run that stops with an error keeps its time in the phase it stopped in.start_driver_progress,update_driver_progress) start the march and each step's fluid update, or finalisation after the last step.run_deck_driverstarts initialisation after the deck input. A static deck enters finalisation after writing its output files.CD_Step_Model, the one place every tension-only line step passes. The updates are atomic, because lines step inside the system's OpenMP loop.CableDyn_HermiteCableDynamic. They are armed on every route except the mixed EI = 0 + finite-EI route, because these process-global counters would make its aggregate step its cables serially. There the profile states that the cable steps are not counted, so the profiled run executes exactly as an unprofiled one.Tests
New:
driver_profile_ei0(examples/dynamic_chain_waves.dat) anddriver_profile_finite_ei(tests/data/held_start_gomex80_power_cable.dat), viatests/check_driver_profile.cmake. Each runs the deck three times: without the variable, with0, and with1. It checks that:I also checked that the script fails as it should: when the expected line is absent, and against a driver built without the feature.
New, after review:
profile(tests/test_profile.f90) checks the module directly:driver_profile_failurechecks the printed profile of a run that exits with code 2 (tests/data/nonconvergent_motion.dat).Results unchanged, checked by hand. For eight example decks, one or more per route (single line in waves, multibody, buoy with clamped cable, Hermite cable with vessel motion, spread mooring, static lazy-wave, Rigid6 line break, and the mixed EI = 0 + finite-EI deck run dynamically), every output file is byte-identical with and without the profile. This holds with
OMP_NUM_THREADS=1and with the default threading.Full suite, Windows, gfortran 16.2, OpenBLAS 0.3.33:
slowtier (ctest --test-dir build --output-on-failure): 249/249 pass after the review changes.-fcheck=all), fast tier (ctest -L fortran -LE slow): 205/205 pass.Documentation:
sphinx-build -Wis clean andtests/test_documentation.pypasses.Overhead (IFX 2025.3.2 release-mirror build, one thread, median of 3): see the table below.
chain_two_train_seamixed_body_rods_pointslazy_wave_vessel_raoals_volturnus_line_break_timebuoy_clamped_cablelozon_gomaine200_power_cable(static)The differences are within the run-to-run variation of this host. The same unmodified driver measured 37.3 s and 38.8 s on the line-break deck in two sessions.
Checklist
pre-commit run --all-filespassesctest --test-dir build --output-on-failurepassespython -m pytest tests python/testspasses (if Python or validation records changed) — not applicable, no Python or validation records changed[Unreleased](heading added if missing) for user-visible changesdoc/updated for changed inputs, options, or outputs (doc/cli.rst: Run-time profile;doc/faq.rst;ARCHITECTURE.md)feat:,fix:,docs:, ...)git commit -s) under theDeveloper Certificate of Origin