Skip to content

Write the bars of a rebar system that holds an extensible storage entity - #184

Merged
mahach666 merged 1 commit into
mainfrom
feat/rebar-system-bars
Nov 11, 2026
Merged

mahach666 merged 1 commit into
mainfrom
feat/rebar-system-bars

Conversation

@mahach666

Copy link
Copy Markdown
Collaborator

Summary

Follows #183, which reads the values of an extensible storage entity in the readers behind the output but still left out the bars of a rebar system whose record holds an entity, because the GlobalId of those bars was not understood. It is now:

  • The rebar reader reads the layers and the held bars of such a system (the two checks that skipped it are removed).
  • A RebarInSystem that is the one RebarInSystem of its system takes the plain GlobalId of the system, as the reference does. Its system is not written as a group, since the bar carries the system's GlobalId.
  • A bar of a system with more RebarInSystem keeps its own sub-element GlobalId (the number of its bars plus 3), as before.

Refs #15

Measured

The rule comes from a file of release 2024 whose 42 RebarInSystem bars were left out: 26 are the one bar of their system and the reference writes each with the plain GlobalId of the system; the other 16 belong to systems of four bars and the reference writes them with the sub-element GlobalId the code already computes. Layer, index and assembly membership do not decide it.

12 files with rebar, exported with main and with this branch, the IFC compared slot by slot with the reference:

Files that change 3, the releases 2021, 2023 and 2024 of one project
Bars added 42, 48 and 48, every one with the GlobalId of the reference
Bars written against the 169 of the reference 159, 168 and 168 (117, 120 and 120 before)
Slots worse against the reference none
Compact JSON identical to main
Files unchanged 9 (structural files of the releases 2020, 2021, 2023, 2025 and 2027, and two architectural files)

Not covered

  • The GlobalId rule rests on one project, whose systems have one or four bars; a system of another size, or one whose other bars are not read, was not seen.
  • The parameters that a store behind an entity would list as unset are still left out, as before.
  • The bars of a system in a file whose reader fails on one of its RebarInSystem records would be counted from the records read.

Verification

  • Full test suite on net8.0: 10802 tests, 10653 passed, 141 skipped, 8 failed. The 8 failures are bounding-box tests (ValidatedTests 2, ApiTests.Proxy289128_* 3, ElementHeaderBoundingBoxTests 3) that fail the same way on main without this change.
  • Tests: a system behind an empty entity is read; the one bar of a system gets the system's GlobalId and its system writes no group, while a bar of a system with two bars keeps its own sub-element GlobalId and its system writes its group.
  • A review with a second check of every finding: the system of the one bar was still written as a group under a made-up GlobalId (fixed here) and the changelog named a count of one file as if it were of three (fixed). After the fix the three changed files were exported again: identical to the export before it.
  • net10.0 was not built or tested.

The rebar reader no longer leaves out a RebarSystem whose walk met an
entity: its layers and held bars are read now that the entity values are
read in place. A RebarInSystem that is the one RebarInSystem of its system
takes the GlobalId of the system, as the reference does, and its system is
not written as a group; a bar of a system with more keeps its own
sub-element GlobalId.

In three files of one project 42, 48 and 48 bars that were left out are
written, all with the GlobalId of the reference; nine other files with
rebar do not change.

Refs #15
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