[us-commits] [ehb54/ultrascan3] 7e35c3: somo: record the provenance of the vendored cctbx ...

[emre brookes]

  Branch: refs/heads/ehb54-issue-1009-somo-merge
  Home:   https://github.com/ehb54/ultrascan3
  Commit: 7e35c33cbdc5135f8b5525b30f85734204df411b
      https://github.com/ehb54/ultrascan3/commit/7e35c33cbdc5135f8b5525b30f85734204df411b
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/grpy/grpy_core.hpp
    A us_somo/develop/perceiver/data/ref/cctbx_LICENSE.txt
    M us_somo/develop/perceiver/data/ref/it1992.cpp

  Log Message:
  -----------
  somo: record the provenance of the vendored cctbx and GRPY sources

Two files carry third-party origin that was not recorded.

perceiver/data/ref/it1992.cpp is a verbatim copy of cctbx's transcription of
International Tables Vol. C Table 6.1.1.4.  The cctbx license is BSD-style and
its condition (1) requires source redistributions to retain the copyright
notice, the conditions and the disclaimer; none of that was present.  Add the
notice and vendor the full license text alongside as cctbx_LICENSE.txt.  The
file is not compiled -- gen_saxs_entries.py parses it -- but it is redistributed
in source form, which is exactly what condition (1) covers.

grpy/grpy_core.hpp describes itself as a faithful translation of GRPY.f but
recorded neither its author nor its license nor the paper to cite.  Add all
three: Copyright (C) 2017 Pawel Jan Zuk, GPLv3 per the GRPY.f header, and the
Biophys. J. 115:782-800 (2018) reference.

The GRPY note deliberately stops short of asserting a licensing outcome.  The
original is GPLv3, UltraScan is LGPLv3, and a translation is a derivative work,
so compatibility is a project-level decision and not something a source header
can settle.  Flagged in the header and raised on the ticket.

Reported-by: aaron-auc


  Commit: 1e489e741362fe17744b1b4c8dd70ab6688d94ca
      https://github.com/ehb54/ultrascan3/commit/1e489e741362fe17744b1b4c8dd70ab6688d94ca
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/grpy/grpy_api.hpp
    M us_somo/develop/grpy/linalg.hpp

  Log Message:
  -----------
  somo/grpy: report bad input and failed allocation instead of aborting

Running GRPY in-process removed the isolation the subprocess gave it, but the
module still failed like standalone code.

linalg.hpp
- The in-core calloc return was unchecked, so a failed allocation was followed
  by tile accesses through a null pointer. These are exactly the sizes that
  fail: this allocation is the memory wall the tiling exists for.
- Out-of-core setup called std::abort() when the backing file could not be
  created, sized or mapped, so an unwritable or full directory killed SOMO and
  any unsaved work with it. Now closes and unlinks the partial file and throws,
  naming the path and the errno.
- Both raise the new la::Error. Also widen the tile row offset before the
  multiply (roff()): i * b was computed in int and only then converted to
  Eigen::Index, which is what CodeQL flags at the six middleRows() calls.

grpy_api.hpp
- read_native_file() accepted every failure silently: a missing file, a
  truncated file or a non-numeric field all produced zeros, which became N == 0
  or zero-radius beads and surfaced much later as a division by radius or a
  quietly meaningless result. It now validates the open, every scalar field,
  the declared bead count and each bead line, and rejects a non-finite
  coordinate or a radius that is not positive -- naming the file and line.

Reported-by: aaron-auc


  Commit: 876a76a1fd47c75e70def12fab87b0fff40f1dce
      https://github.com/ehb54/ultrascan3/commit/876a76a1fd47c75e70def12fab87b0fff40f1dce
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/src/us_hydrodyn_grpy.cpp

  Log Message:
  -----------
  somo/grpy: add a failure boundary, and let Stop reach the solve

Two defects that both come from the move to an in-process solver.

A failure boundary. As a subprocess a GRPY failure was isolated -- the process
died, SOMO read a non-zero exit and carried on. In-process there is nothing
between a throw and the application: a failed allocation, an unreadable input
or a bad out-of-core path would terminate SOMO and lose the session. The parse
and the whole compute now run inside a try; the catch reports the error and
restores the interface exactly as the pre-flight memory guard does when it
refuses a model, and in gui_script mode fails properly to stderr with a
non-zero exit rather than reporting success. The body is left at its existing
indentation so the diff shows the boundary and nothing else.

Stop. sopt.should_stop was installed inside 'if ( sopt.enabled )', so it existed
only for a shell-reduced run. With shell reduction off -- the default, and now
the only configuration -- nothing was installed and Stop could not reach the
solve at all: the progress callback's 'if ( stopFlag ) return;' suppresses
repaints but does not end the computation, so a long model ran to completion
looking hung. Install it for every run.

This does not make Stop instant. A solve already running still finishes, since
the factor has no interior abort; with a ladder, Stop takes effect between rungs
and saves nearly all of what remained. Said plainly in the comment rather than
implied.

Reported-by: aaron-auc


  Commit: 5bf6554af39173167c0b78fb1307373d4329f15e
      https://github.com/ehb54/ultrascan3/commit/5bf6554af39173167c0b78fb1307373d4329f15e
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/src/us_hydrodyn_other.cpp

  Log Message:
  -----------
  somo: don't let Close act during a running GRPY solve

The GRPY solve runs synchronously on the GUI thread and calls processEvents()
to keep the interface responsive, which also leaves Close live. Taking it would
hide the window, clear the temporary directories and ask the application to quit
while the solve was still running over those files -- SOMO appearing closed
while it went on computing.

closeEvent() now treats Close as a Stop request while grpy_running: it sets
stopFlag, says that the current model must finish first because the solve cannot
be interrupted part-way, and ignores the event. Closing again once it has
stopped behaves normally.

Reported-by: aaron-auc


  Commit: 10096f5718f75915e929d7cdcd904a53735ead44
      https://github.com/ehb54/ultrascan3/commit/10096f5718f75915e929d7cdcd904a53735ead44
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/src/us_hydrodyn_save.cpp

  Log Message:
  -----------
  somo: drop the held-back shell-reduction columns from the Save dialog

Shell reduction is hidden and forced off, but its six columns stayed in the
Save-parameters field list, offering settings that cannot be changed and
results that are always zero or empty.

Comment them out in both field lists, with a marker pointing at
grpy_shell_released. The field handlers below are left in place: they are keyed
off the list, so they are simply never reached, and they are needed as-is when
the feature is released.

This commit is specific to holding the feature back and should not be carried
upstream to somo-dev, where shell reduction is live.

Reported-by: aaron-auc


  Commit: 83dab3feb53857c5100b5af13d14c844d79088b1
      https://github.com/ehb54/ultrascan3/commit/83dab3feb53857c5100b5af13d14c844d79088b1
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    A .github/workflows/somo-module-tests.yml
    M us_somo/develop/perceiver/tests/regression.cpp

  Log Message:
  -----------
  somo: run the grpy and perceiver suites in CI, and stop the regression test passing vacuously

The numerical suites were only ever run by hand, so a change could pass CI while
breaking the behaviour they cover.

While wiring them up, the perceiver regression target turned out to be worse
than unrun: it scores against demo PDB structures that are NOT committed to the
repository. read_pdb() returns an empty list for a missing file, so it scored 0
atoms, every percentage divided by zero and printed 0.000%, and it exited 0 --
reporting 'genuine perception errors remaining: 0 (0.000%)' having looked at
nothing. Verified by running it: it passed with 0 atoms scored.

- regression.cpp now names any input that yielded no atoms, and fails (exit 2)
  when it scored nothing at all, explaining that the demo structures are absent.
- New workflow runs the grpy suite and the perceiver unit tests, both Qt-free
  and standalone against the vendored Eigen. It also asserts the vacuous-pass
  guard itself: with no input, bin/regression must fail.

The regression target proper stays out of CI until it has structures to score.
Committing the demo set (or a fixture subset) is a separate call -- it is data,
and its size and provenance are worth deciding deliberately.

Reported-by: aaron-auc


Compare: https://github.com/ehb54/ultrascan3/compare/0465d69edc58...83dab3feb538

To unsubscribe from these emails, change your notification settings at https://github.com/ehb54/ultrascan3/settings/notifications