ZoneBaseboard:OutdoorTemperatureControlled autosizing is missing by joseph-robertson · Pull Request #11579 · NatLabRockies/EnergyPlus

joseph-robertson · 2026-05-06T22:20:05Z

Pull request overview

Fixes ZoneBaseboard:OutdoorTemperatureControlled autosizing is missing #5344
Reviving code from 65676922 pnnl autosizing #4236, which got left behind.

5ZoneEndUses.idf:

Description of the purpose of this PR

Pull Request Author

Reviewer

github-actions · 2026-05-06T23:09:15Z

⚠️ Regressions detected on ubuntu-24.04 for commit `1993c6e`

Regression Summary

Audit: 3
EIO: 3
Table Big Diffs: 3
ESO Big Diffs: 1
MTR Big Diffs: 1
ZSZ Big Diffs: 1
Table String Diffs: 1

github-actions · 2026-05-06T23:52:04Z

⚠️ Regressions detected on macos-14 for commit `1993c6e`

Regression Summary

Audit: 3
EIO: 3
Table Big Diffs: 3
ESO Big Diffs: 1
MTR Big Diffs: 1
ZSZ Big Diffs: 1
Table String Diffs: 1

joseph-robertson · 2026-05-11T18:27:48Z

Does it seem like InternalHeatGains.scc is the appropriate place nowadays to put autosizing code for this object? The code pre-dates much refactor work (e.g., state).

@rraustad

rraustad · 2026-05-11T20:51:09Z

+                    if (state.dataEnvrn->CurEnvirNum != ScannedEnvirNum) {
+                        ScannedEnvirNum = state.dataEnvrn->CurEnvirNum;
+                        DesDayOutDryBulbTemp(ScannedEnvirNum) = state.dataEnvrn->OutDryBulbTemp;
+                        if (state.dataEnvrn->CurEnvirNum <= state.dataEnvrn->TotDesDays) { // FIXME: this was == in the original code


What original code? I don't see any code that was deleted. I think == was used to determine when all design days have simulated (i.e., components don't usually size until zone sizing is complete). But each design day has multiple time steps so just looking at the CurEnvirNum isn't enough to know that sizing has completed. Most sizing routines are not called until !state.dataGlobal->SysSizingCalc. This does seem weird in that state.dataEnvrn->OutDryBulbTemp is set by the weather manager each time step, so this code is capturing the last time step's OAT in each specific design day. Not what I would expect. Also, at line 6926 below it's looking for max OAT not the min (i.e., if (MinDesOutTemp > DesDayOutDryBulbTemp(Loop))). Too much to discuss in a comment.

Sorry, I was just referring to the original code in #4236.

I tried introducing !state.dataGlobal->ZoneSizingCalc in d994859. It brings the InitInternalHeatGains call down from "Initializing Internal Heat Gains" to "Initializing Simulation", which I think aligns with the other baseboard type.

From what I can tell the code is permitting input of a design zone heating setpoint (high temperature), but then looking to design day (days?) for a low temperature? But as you point out, looking at state.dataEnvrn->OutDryBulbTemp which would be the design day's last timestep's OAT; is there a precendence for this kind of weather info gathering, or why couldn't low temperature just be defaulted/input like high temperature?

I'll dig around and see how infiltration and ventilation MCPI and MCPV are used in other places.

What would typically happen in a sizing routine is the component would look to FinalZoneSizing data for information needed for sizing (which means you don't need to gather data as done here with DesDayOutDryBulbTemp(ScannedEnvirNum)). In this case it would be FinalZoneSizing(zn).OutTempAtHeatPeak but using that data would need to be tested to make sure the size of the baseboard was sufficient to meet the peak baseboard load. For example, what is the total infiltration and ventilation load at the peak heating timestep? Is there a time where infiltration and ventilation would be larger and therefore the baseboard would not have sufficient capacity to meet the load? There is also an array of this same data using the min of CalcFinalZoneSizing(zn).HeatOutTempSeq(ts) which would give the minimum OAT for the peak heating design day. There are always questions of this nature regarding which sizing data is appropriate for component sizing (e.g., the peak heating load may not correspond to the peak infiltration or ventilation load).

@rraustad I made several updates based on your suggestions. Using state.dataSize->FinalZoneSizing(NZ).OutTempAtHeatPeak seems to give me the appropriate design size low temperature.

On the topic of infiltration/ventilation MCPI and MCPV, because they are timestep variables and we'd want the peak, could I just add new peak variables in ZoneEquipmentManager analogous to OutTempAtHeatPeak? But instead of using HeatOutTempSeq(ts), it would use MCPI/MCPV. (I don't totally understand how the original implementation of this code dealt/found peaks of MCPV/MCPV.)

What you have done so far looks good by tracking HeatMCPI(V) and HeatMCPI(V)Seq.

rraustad · 2026-05-11T21:04:47Z

Does it seem like InternalHeatGains.scc is the appropriate place nowadays to put autosizing code for this object? The code pre-dates much refactor work (e.g., state).

@rraustad

The BaseBoards do have a size function, but this object is managed in InternalHeatGains, for whatever reason. Sizing is typically called from the init function with proper protection to ensure it is called after sizing completes. So this does seem OK since it's called from InitInternalHeatGains. For zone equipment the protection could use !state.dataGlobal->ZoneSizingCalc (where FinalZoneSizing is complete and available) but most components wait for all sizing to complete.

void InitBaseboard()

    if (!state.dataGlobal->SysSizingCalc && baseboard->baseboards(BaseboardNum).MySizeFlag ) {
        // for each coil, do the sizing once.
        SizeElectricBaseboard(state, BaseboardNum);
        baseboard->baseboards(BaseboardNum).MySizeFlag = false;
    }

So this new code does call a sizing function, it's called from init in the code that manages the object, and the sizing call should be protected to only call the new size function after sizing is complete. Using !OutTempScanNotDone as protection could work as intended, since this appears to only be interested in design day OAT and surface properties, but it doesn't look to me as if that's the case. Also, infiltration and ventilation MCPI and MCPV are also time step variables so something else will need to be used to get the peak of those data.

joseph-robertson · 2026-05-22T18:15:49Z

+                Real64 NominalUwithConvCoeffs = 0.0;
+                if (surf.Construction > 0 && surf.Construction <= state.dataHeatBal->TotConstructs) {
+                    bool isWithConvCoefValid = false;
+                    NominalUwithConvCoeffs = DataHeatBalance::ComputeNominalUwithConvCoeffs(state, SurfNum, isWithConvCoefValid);
+                }


I've replaced UNomFilm in the old code with NominalUwithConvCoeffs.

joseph-robertson · 2026-05-22T18:16:21Z

+        ZnInfilSensLoad = state.dataSize->FinalZoneSizing(NZ).MCPIAtHeatPeak * DeltaTMax;
+        ZnVentSensLoad = state.dataSize->FinalZoneSizing(NZ).MCPVAtHeatPeak * DeltaTMax;


I'm using the new peak variables for MCPI and MCPV here.

joseph-robertson · 2026-05-22T18:17:14Z

+        LowTemperatureDes = state.dataSize->FinalZoneSizing(NZ).OutTempAtHeatPeak;
+        if (IsAutosize) {
+            thisBBHeat.LowTemperature = LowTemperatureDes;
+            BaseSizer::reportSizerOutput(


I'm a little unclear whether I should be using BaseSizer::reportSizerOutput directly or some other class/method.

Either call a dedicated function in the sizer instead of sizing here (see All_Simple_Sizing, and associated calling sites) or call reportSizerOutput. Either method is fine.

joseph-robertson · 2026-05-22T18:21:26Z

+    autosize,                !- Capacity at Low Temperature {W}
+    autosize,                !- Low Temperature {C}
+    autosize,                !- Capacity at High Temperature {W}
+    autosize,                !- High Temperature {C}


From the docs for Field: High Temperature, "If autosized, this is equal to the design zone heating setpoint temperature described below, so that the capacity at high temperature is zero."

So seeing a zero "Design Size Capacity at High Temperature [W]" value for "SPACE5-1 BBHEAT 1" seems consistent/expected.

This just seems a little odd. You don't but a baseboard (or any other component) in a building and then say "what is the capacity at a high entering air temperature" do you? Because it's obvious. Leave this for now as to not add scope creep.

joseph-robertson · 2026-05-22T18:22:20Z

+            if (!state.dataGlobal->ZoneSizingCalc && state.dataHeatBal->ZoneBBHeat(Loop).MySizeFlag) {
+                SizeOaControlledBaseboard(state, Loop);
+                state.dataHeatBal->ZoneBBHeat(Loop).MySizeFlag = false;
+            }
+


Much much cleaner and simpler than the original code. Thanks for pointing me in the right direction, @rraustad.

github-actions · 2026-05-22T18:35:47Z

⚠️ Regressions detected on macos-14 for commit `0c0fdce`

Regression Summary

Audit: 3
EIO: 3
ERR: 1
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3
Table String Diffs: 1

github-actions · 2026-05-22T18:39:57Z

⚠️ Regressions detected on ubuntu-24.04 for commit `0c0fdce`

Regression Summary

Audit: 3
EIO: 3
ERR: 1
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3
Table String Diffs: 1

rraustad · 2026-05-22T20:06:48Z

+
+        if (thisBBHeat.LowTemperature == DataSizing::AutoSize) {
+            IsAutosize = true;
+        }


Oops, I forgot to tell you an important point about sizing functions. The user could hard size the inputs and NOT perform a sizing run. In this case FinalZoneSizing will not be allocated and line 7034 will crash. Inside the above check add:

CheckZoneSizing(state, CompType, thisBBHeat.Name);

The simulation will fatal out if a sizing run is not performed.

Then add right after line 7032:

bool SizingDesRunThisZone = false;
CheckThisZoneForSizing(state, state.dataSize->CurZoneEqNum, SizingDesRunThisZone);

And you can use this flag to protect for FinalZoneSizing being allocated. Check other zone equipment sizing routines to get a feel for this. Also run a test file with and without zone sizing to check for crashes.

Or you could add another struct variable as bool anyInputAutosized that is set in getInput and just call CheckZoneSizing once at the top of the sizing function.

rraustad · 2026-05-22T20:20:32Z

+                                         "Design Size Low Temperature [C]",
+                                         LowTemperatureDes,
+                                         "User-Specified Low Temperature [C]",
+                                         LowTemperatureUser);


This call is specific for when the user hard sizes an input AND a sizing run is performed. If a sizing run is not performed you won't have LowTemperatureDes available to report. Also you might not want to report to the eio when hardsized because the user already knows the size of the baseboard. You can report user specified inputs if you like and I don't have any issue with that, in fact I think all autosizable inputs should be reported to the eio regardless of whether or not they are autosized. You just have to add logic to report the right information when appropriate. i.e., you use this call when hard sized AND a sizing run is performed. You use line 7037 when hard sized and a sizing run is not performed and also change Design Size to User-Specified.

Thanks. I've captured this and your other comment in e5aeb46.

But how does state.dataSize->CurZoneEqNum get incremented? It looks like it remains at a value of zero at the point of calling the baseboard sizing routine, which then doesn't turn SizingDesRunThisZone to true.

Edit: Oh. It's OA controlled, so maybe this is intentional. But any idea what the path forward should be then? Maybe this?

@joseph-robertson you can probably use this method to set the current zone variable used in sizing methods:

state.dataSize->CurZoneEqNum = Util::FindItemInList(ZoneName, state.dataHeatBal->Zone);

You may have to save CurZoneEqNum and reset after your new sizing function so as not to break anything but I'm not sure that would be necessary, it depends on calling order and whether some other zone component would also be calling sizing. If CurZoneEqNum was not actually set (it's set/reset only in 1 place in ZoneEquipmentManager) before calling your sizing function you probably don't have to worry about resetting this variable.

github-actions · 2026-05-26T17:00:29Z

⚠️ Regressions detected on ubuntu-24.04 for commit `3774d15`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
Table Big Diffs: 3

github-actions · 2026-05-26T17:13:45Z

⚠️ Regressions detected on macos-14 for commit `3774d15`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
Table Big Diffs: 3

github-actions · 2026-05-27T22:33:46Z

⚠️ Regressions detected on macos-14 for commit `485b5cb`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-05-27T22:47:44Z

⚠️ Regressions detected on ubuntu-24.04 for commit `485b5cb`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-05-28T05:19:04Z

⚠️ Regressions detected on macos-14 for commit `d51a14f`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-05-28T05:35:47Z

⚠️ Regressions detected on ubuntu-24.04 for commit `d51a14f`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-05-28T17:04:34Z

⚠️ Regressions detected on macos-14 for commit `780c900`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-05-28T17:18:05Z

⚠️ Regressions detected on ubuntu-24.04 for commit `780c900`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-05-28T20:10:34Z

⚠️ Regressions detected on macos-14 for commit `32fed3f`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-05-28T20:29:31Z

⚠️ Regressions detected on ubuntu-24.04 for commit `32fed3f`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-05-28T21:35:01Z

⚠️ Regressions detected on macos-14 for commit `147e354`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-05-28T21:42:20Z

⚠️ Regressions detected on ubuntu-24.04 for commit `147e354`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

joseph-robertson · 2026-06-01T20:12:52Z

+                BaseSizer::reportSizerOutput(state,
+                                             CompType,
+                                             CompName,
+                                             "Design Size " + SizingString,
+                                             LowTemperatureDes,
+                                             "User-Specified " + SizingString,
+                                             thisBBHeat.LowTemperature);
+                if (state.dataGlobal->DisplayExtraWarnings) {
+                    if (std::abs(LowTemperatureDes - thisBBHeat.LowTemperature) > state.dataSize->AutoVsHardSizingDeltaTempThreshold) {


Stick with calling reportSizerOutput for temperature fields (vs. using HeatingCapacitySizer) -- the AutoVsHardSizingDeltaTempThreshold variable implies a delta check, and also I'm not sure HeatingCapacitySizer would even support negative temperature values.

joseph-robertson · 2026-06-01T20:14:26Z

+        }
+
+        ZoneEqSizing.HeatingCapacity = true;
+        ZoneEqSizing.DesHeatingLoad = CapatLowTemperatureDes;


I believe we are essentially overriding DesHeatingLoad with our own sizing value here.

github-actions · 2026-06-01T20:48:21Z

⚠️ Regressions detected on macos-14 for commit `136de41`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-06-01T21:05:12Z

⚠️ Regressions detected on ubuntu-24.04 for commit `136de41`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

Copilot

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

… CurZoneEqNum.

github-actions · 2026-06-02T16:58:53Z

⚠️ Regressions detected on macos-14 for commit `91a8ce5`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

github-actions · 2026-06-02T17:06:22Z

⚠️ Regressions detected on ubuntu-24.04 for commit `91a8ce5`

Regression Summary

Audit: 3
EIO: 3
MDD: 1
MTD: 1
ESO Big Diffs: 1
MTR Big Diffs: 1
Table Big Diffs: 3

Joe Robertson added 5 commits May 6, 2026 10:53

Update idd with autosizable tags and new design setpoint field.

aa29acd

Move in zone baseboard autosizing code with refactor.

3635cab

Formatting.

a9960aa

Replace calls to reportSizerOutput.

7915c7d

Formatting.

62cc12c

joseph-robertson self-assigned this May 6, 2026

joseph-robertson added Defect Includes code to repair a defect in EnergyPlus IDDChange Code changes impact the IDD file (cannot be merged after IO freeze) labels May 6, 2026

rraustad reviewed May 11, 2026

View reviewed changes

Joe Robertson added 7 commits May 12, 2026 07:18

Merge branch 'develop' into zone-baseboard-autosizing

5c007a2

Try simpler approach using suggested ZoneSizingCalc.

d994859

Merge branch 'develop' into zone-baseboard-autosizing

47a9b96

Update and simplify new baseboard sizing code based on feedback.

9d4ec34

Create peak variables for MCPI and MCPV.

5ef9dfd

Clean up new sizing routine and use peak MCPI and MCPV variables.

2651a3c

Update existing testfile with autosized zone baseboard object.

01de95f

joseph-robertson commented May 22, 2026

View reviewed changes

rraustad reviewed May 22, 2026

View reviewed changes

Joe Robertson added 2 commits May 26, 2026 09:17

Update baseboard sizing routine with zone sizing checks.

e5aeb46

Formatting.

070de34

Pass in zone ptr instead of current zone equip num.

5f591fc

Joe Robertson added 3 commits May 27, 2026 21:41

Remove required-field for fields that now have defaults.

47c4222

Update docs for note about defaulting to autosize.

ff6a508

Formatting.

00c6d73

Updates for setting CurZoneEqNum and subroutine information.

580bc6e

Clean up autosize vs hardsize warnings and use of abs.

9740bf8

Formatting.

f7d50a0

Joe Robertson added 2 commits June 1, 2026 13:03

Formatting.

f40babb

Formatting.

992a349

joseph-robertson commented Jun 1, 2026

View reviewed changes

joseph-robertson requested a review from Copilot June 2, 2026 15:06

Copilot started reviewing on behalf of joseph-robertson June 2, 2026 15:07 View session

Copilot AI reviewed Jun 2, 2026

View reviewed changes

Comment thread tst/EnergyPlus/unit/InternalHeatGains.unit.cc

Comment thread src/EnergyPlus/InternalHeatGains.cc

Joe Robertson added 2 commits June 2, 2026 09:25

Fix FieldNames assignment, and protect sizing reporting under nonzero…

b12322c

… CurZoneEqNum.

Fix internal heat gains test with zone sizing allocations.

e014fcc

joseph-robertson added the Documentation Related primarily on the LaTeX-based EnergyPlus documentation label Jun 2, 2026

joseph-robertson marked this pull request as ready for review June 2, 2026 18:50

		ZnInfilSensLoad = state.dataSize->FinalZoneSizing(NZ).MCPIAtHeatPeak * DeltaTMax;
		ZnVentSensLoad = state.dataSize->FinalZoneSizing(NZ).MCPVAtHeatPeak * DeltaTMax;

Conversation

joseph-robertson commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull request overview

Description of the purpose of this PR

Pull Request Author

Reviewer

Uh oh!

github-actions Bot commented May 6, 2026

⚠️ Regressions detected on ubuntu-24.04 for commit 1993c6e

Uh oh!

github-actions Bot commented May 6, 2026

⚠️ Regressions detected on macos-14 for commit 1993c6e

Uh oh!

joseph-robertson commented May 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joseph-robertson May 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rraustad commented May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented May 22, 2026

⚠️ Regressions detected on macos-14 for commit 0c0fdce

Uh oh!

github-actions Bot commented May 22, 2026

⚠️ Regressions detected on ubuntu-24.04 for commit 0c0fdce

Uh oh!

rraustad May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joseph-robertson May 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rraustad May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented May 26, 2026

⚠️ Regressions detected on ubuntu-24.04 for commit 3774d15

Uh oh!

github-actions Bot commented May 26, 2026

⚠️ Regressions detected on macos-14 for commit 3774d15

Uh oh!

github-actions Bot commented May 27, 2026

⚠️ Regressions detected on macos-14 for commit 485b5cb

Uh oh!

github-actions Bot commented May 27, 2026

⚠️ Regressions detected on ubuntu-24.04 for commit 485b5cb

joseph-robertson commented May 6, 2026 •

edited

Loading

⚠️ Regressions detected on ubuntu-24.04 for commit `1993c6e`

⚠️ Regressions detected on macos-14 for commit `1993c6e`

joseph-robertson May 21, 2026 •

edited

Loading

rraustad commented May 11, 2026 •

edited

Loading

⚠️ Regressions detected on macos-14 for commit `0c0fdce`

⚠️ Regressions detected on ubuntu-24.04 for commit `0c0fdce`

rraustad May 22, 2026 •

edited

Loading

joseph-robertson May 26, 2026 •

edited

Loading

rraustad May 28, 2026 •

edited

Loading

⚠️ Regressions detected on ubuntu-24.04 for commit `3774d15`

⚠️ Regressions detected on macos-14 for commit `3774d15`

⚠️ Regressions detected on macos-14 for commit `485b5cb`

⚠️ Regressions detected on ubuntu-24.04 for commit `485b5cb`

⚠️ Regressions detected on macos-14 for commit `d51a14f`

⚠️ Regressions detected on ubuntu-24.04 for commit `d51a14f`

⚠️ Regressions detected on macos-14 for commit `780c900`

⚠️ Regressions detected on ubuntu-24.04 for commit `780c900`

⚠️ Regressions detected on macos-14 for commit `32fed3f`

⚠️ Regressions detected on ubuntu-24.04 for commit `32fed3f`

⚠️ Regressions detected on macos-14 for commit `147e354`

⚠️ Regressions detected on ubuntu-24.04 for commit `147e354`

⚠️ Regressions detected on macos-14 for commit `136de41`

⚠️ Regressions detected on ubuntu-24.04 for commit `136de41`

⚠️ Regressions detected on macos-14 for commit `91a8ce5`

⚠️ Regressions detected on ubuntu-24.04 for commit `91a8ce5`