Merge remote-tracking branch 'origin/develop' into fixVRFnegativeFanP…

…ower

cmake/CompilerFlags.cmake

@@ -76,15 +76,19 @@ if(MSVC AND NOT ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")) # Visual C++ (VS
   target_compile_options(project_options INTERFACE $<$<CONFIG:Debug>:/Ob0>) # Disable inlining
   target_compile_options(project_options INTERFACE $<$<CONFIG:Debug>:/RTCsu>) # Runtime checks
   target_compile_options(project_fp_options INTERFACE $<$<CONFIG:Debug>:/fp:strict>) # Floating point model
-  target_compile_options(project_options INTERFACE $<$<CONFIG:Debug>:/DMSVC_DEBUG>) # Triggers code in main.cc to catch floating point NaNs
-
   target_compile_options(turn_off_warnings INTERFACE /W0)
 
+  option(FORCE_DEBUG_ARITHM_MSVC "Enable trapping floating point exceptions in non Debug mode" OFF)
+  mark_as_advanced(FORCE_DEBUG_ARITHM_MSVC)
+
+  set(need_arithm_debug_genex "$<OR:$<BOOL:${FORCE_DEBUG_ARITHM_MSVC}>,$<CONFIG:Debug>>")
+
+  # in main.cc for E+ (actual: api/EnergyPlusPgm.cc) and gtest: will catch _EM_ZERODIVIDE | _EM_INVALID | _EM_OVERFLOW
+  target_compile_definitions(project_fp_options INTERFACE $<${need_arithm_debug_genex}:DEBUG_ARITHM_MSVC>)
+
 elseif(CMAKE_COMPILER_IS_GNUCXX OR "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang" OR "${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang") # g++/Clang
 
-  # TODO: after we fix all test, enable this by default on Debug builds
-  # option(FORCE_DEBUG_ARITHM_GCC_OR_CLANG "Enable trapping floating point exceptions in non Debug mode" OFF)
-  option(FORCE_DEBUG_ARITHM_GCC_OR_CLANG "Enable trapping floating point exceptions" OFF)
+  option(FORCE_DEBUG_ARITHM_GCC_OR_CLANG "Enable trapping floating point exceptions in non Debug mode" OFF)
   mark_as_advanced(FORCE_DEBUG_ARITHM_GCC_OR_CLANG)
 
   # COMPILER FLAGS
@@ -126,16 +130,13 @@ elseif(CMAKE_COMPILER_IS_GNUCXX OR "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang" O
 
   set(need_arithm_debug_genex "$<OR:$<BOOL:${FORCE_DEBUG_ARITHM_GCC_OR_CLANG}>,$<CONFIG:Debug>>")
 
-  # TODO: after we fix all tests, remove this if statement (keeping the block to always execute) to enable this by default on Debug builds
-  if (FORCE_DEBUG_ARITHM_GCC_OR_CLANG)
-    # in main.cc for E+ and gtest: feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW)
-    target_compile_definitions(project_fp_options INTERFACE $<${need_arithm_debug_genex}:DEBUG_ARITHM_GCC_OR_CLANG>)
-    include(CheckCXXSymbolExists)
-    check_cxx_symbol_exists(feenableexcept "fenv.h" HAVE_FEENABLEEXCEPT)
-    message(VERBOSE "HAVE_FEENABLEEXCEPT=${HAVE_FEENABLEEXCEPT}")
-    if(HAVE_FEENABLEEXCEPT)
-      target_compile_definitions(project_fp_options INTERFACE HAVE_FEENABLEEXCEPT)
-    endif()
+  # in main.cc for E+ (actual: api/EnergyPlusPgm.cc) and gtest: feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW)
+  target_compile_definitions(project_fp_options INTERFACE $<${need_arithm_debug_genex}:DEBUG_ARITHM_GCC_OR_CLANG>)
+  include(CheckCXXSymbolExists)
+  check_cxx_symbol_exists(feenableexcept "fenv.h" HAVE_FEENABLEEXCEPT)
+  message(VERBOSE "HAVE_FEENABLEEXCEPT=${HAVE_FEENABLEEXCEPT}")
+  if(HAVE_FEENABLEEXCEPT)
+    target_compile_definitions(project_fp_options INTERFACE HAVE_FEENABLEEXCEPT)
   endif()
 
   # ADDITIONAL GCC-SPECIFIC FLAGS

design/FY2023/ImprovedErrorHandling.md

@@ -0,0 +1,89 @@
+# Modern Error Reporting
+
+One feature request pretty much summarizes the issue and solution for our error reporting:
+
+> "The current solution of writing out the error file to a text file without establishing a standard procedure makes it difficult for third-party vendors to translate the content.
+  We would prefer to start establishing a standard template for warnings/error records with unique IDs being written to the JSON files. "
+
+OK, so the big picture is we want an error file in JSON format with some form of ID associated with the error messages.
+A nice side benefit of this would be that we could generate a bit of documentation that cross references the ID.
+The documentation could be built up over time with additions like typical causes, tips and tricks for fixing or working around, etc.
+
+## Detailed task list
+
+To meet this need, I think development would follow something like this:
+
+- Analyze existing structure, figuring out a feasible plan for refactoring error message calls
+- Create a new error manager in EnergyPlus that tracks errors in a nice structure
+- Refactor calls to error message routines to use a vector of strings rather than individual calls to *Continue*
+- Refactor the error message routines to not just emit to the err file but also add them to the new error manager
+  - (at this point I should be able to get no diffs)
+- Try to find "nearly" identical error messages and bring them together
+  - I would expect this to cause valid diffs in the err file as minor wording changes are collected together 
+- Create a set of ID categories, and modify the error emission to report the error ID
+- Use the error manager to generate the JSON error file
+- Create an auto-generated document for the different error message IDs
+
+## Error File Contents
+
+I would start creating the error file with something like this, but am totally open to feedback, and it also may naturally change as development commences:
+
+```json
+{
+  "summary": {
+    "outcome": "fatal",
+    "num_severe": 2,
+    "num_warnings": 1,
+    "runtime": 210.2,
+    "timestamp": "2023-04-24T13:05:30Z"
+  },
+  "fatal": {
+    "id": "F1000",
+    "summary": "EnergyPlus failed because of a Meta-reason",
+  },
+  "severe": [
+    {
+      "id": "S1021",
+      "synopsis": "Flow controller did not converge",
+      "extra_info": "Air loop 'AirLoop' diverged with oscillating flow rate.  Flow controller 'ControlStrategy' is set to 'InverseMobiusStrip', which only exists in hyper dimensional systems.  Choose a more appropriate option."
+    },
+    {
+      "id": "S3001",
+      "synopsis": "Encountered meta-building in the input file",
+      "extra_info": "Building 'MetaBuilding' was declared with meta-latitude '\\342\\200\\234' and meta-longitude '\\742\\234\\876', which are not supported in this version of EnergyPlus"
+    }
+  ],
+  "warnings": [
+    {
+      "id": "W4040",
+      "synopsis": "Timestep is set to 3600 seconds, which is incompatible with some cool short time step model, suggest setting it to 3599 or less.",
+      "extra_info": ""
+    }
+  ],
+  "information": [
+    "Testing Individual Branch Integrity",
+    "All Branches passed integrity testing",
+    "Testing Individual Supply Air Path Integrity",
+    "All Supply Air Paths passed integrity testing",
+    "Testing Individual Return Air Path Integrity",
+    "All Return Air Paths passed integrity testing",
+    "No node connection errors were found.",
+    "Beginning Simulation",
+    "EnergyPlus Completed Successfully"
+  ]
+}
+```
+
+We'll need to keep in mind how new errors can be introduced into the category system to future proof it.
+Many tools do something like: A001, A002, B001, B002, so I would probably start by doing something similar.
+
+Things I still need to solve:
+- Should I include timestamp info for every single warning?
+- Add structure for recurring
+- Add extra flag for whether warmup, sizing, or kickoff were true
+
+## Current questions for dev team
+
+- What should we name this JSON based error file?
+- Do we just keep a list of message string templates in a single dedicated file, and use these in calls to errors?
+- Anyone have strong feelings on the ID or JSON form?

design/FY2024/NFP-Space Sizing and HVAC-Part4.md

@@ -0,0 +1,214 @@
+Extend Spaces to Sizing and HVAC - Part 4
+================
+
+**Michael J. Witte, GARD Analytics, Inc.**
+
+ - Original June 17, 2024
+ - Revised, August 2, 2024
+
+## Table of Contents ##
+
+[E-mail and Conference Call Conclusions](#e-mail-and-conference-call-conclusions)
+
+[Background and Overiew](#background-and-overview)
+
+[Approach](#approach)
+
+[Testing/Validation/Data Sources](#testingvalidationdata-sources)
+
+[Input Description](#input-description)
+
+[Outputs Description](#outputs-description)
+
+[Engineering Reference](#engineering-reference)
+
+[Example File and Transition Changes](#example-file-and-transition-changes)
+
+[Design](#design)
+
+## E-mail and Conference Call Conclusions ##
+June 17-20, Q&A in the pull request with rraustad. Made some minor updates to the NFP to clarify the sizing methods and to mention that an spsz output file will be created, similar to the existing zsz output.
+
+
+## Background and Overview ##
+
+Space was added as a new concept in v9.6. Each EnergyPlus Zone contains one or more Spaces which are used for:
+
+  * assigning and allocating internal gains
+  * specifying enclosure boundaries,
+  * reporting inputs grouped by space types, and 
+  * reporting select output grouped by space types.
+
+For the zone heat balance each thermal Zone is composed of one or more Spaces controlled by a single thermostat or HVAC system control point such as a VAV terminal unit.
+
+In version 23.1 options were added to perform the air heat balance for each Space or each Zone, and space-level heat balance output variables were added.
+
+In version 23.2, the following capabilities were added:
+
+  * When ZoneAirHeatBalanceAlgorithm "Do Space Heat Balance for Sizing" = Yes, zone sizing is also done for all spaces. The HVAC Sizing Summary table report will include subtables for Space Sensible Cooling and Heating as well as for Zone Sensible Cooling and Heating. Space Sizing will also be reported to the eio output. The space sizing results are reported, but not used.
+
+  * Three new objects, SpaceHVAC:EquipmentConnections, SpaceHVAC:ZoneEquipmentSplitter, and SpaceHVAC:ZoneEquipmentMixer allow one or more zones to be simulated at the space level for HVAC, leading to independent air temperature and humidity in each space.
+
+  * For zone equipment serving multiple spaces, three thermostat control options (SingleSpace, Ideal, and Maximum).
+
+This NFP proposes additional optional capabilities:
+
+  * Use the Space-level (room-by-room) sizing results to size Zone-level equipment to either the coincident or non-coincident peak across the Spaces (rooms).
+
+  * Refine existing Space-level HVAC simulation.
+
+  * Extend space HVAC to support more special objects (e.g. ZoneThermalChimney, if budget allows).
+
+
+
+## Approach ##
+### Sizing
+A new input will be added to Sizing:Zone to allow zone sizing using the non-coincident space peaks or the coincident peak. 
+
+Space sizing is an actual heat balance on each space. Currently zone sizing is an actual heat balance on each zone (as a whole) although some of the components for the zone heat balance are sums across the spaces (even when space heat balance is off). e.g. internal gains. The current zone sizing calculations will be used to calculate the coincident zone sizing using the combined spaces. 
+
+For the non-coincident zone sizing, the individual space peaks will be summed and other values (such as outdoor temperature) will be averaged.
+
+When space sizing is active, sizing results are reported in the table output for both spaces and zones. There will be no change here.
+
+When space sizing is active, a new spssz output file will be generated, similar to the existing zsz output. This will require a new field in the OutputControl:Files object.
+
+
+### HVAC
+* Calculate return flows at the Space level. Currently, space return nodes can be specified, but there is no flow assigned to them. All return flow is lumped at the zone level.
+
+
+![SpaceHVACSchematic](SpaceHVACSchematic.png)
+
+
+
+## Testing/Validation/Data Sources ##
+
+Compare Space vs Zone-level results.
+
+## Input Description ##
+Some new objects and some changes to existing objects are proposed.
+
+### Sizing:Zone
+* *New field at the end:"*
+```
+  A15; \field Type of Space Sum to Use
+      \type choice
+      \key Coincident
+      \key NonCoincident
+      \default Coincident
+```
+
+### OutputControl:Files
+* *New field in the middle:"*
+```
+  A9 , \field Output Space Sizing
+       \type choice
+       \key Yes
+       \key No
+       \default Yes
+```
+
+### ZoneRefrigerationDoorMixing
+(If budget allows, otherwise limit these to single-space zones.)
+* *Change field "Zone 1 Name" to "Zone or Space Name 1."*
+
+* *Change field "Zone 2 Name" to "Zone or Space Name 2."*
+
+### ZoneCoolTower:Shower
+(If budget allows, otherwise limit these to single-space zones.)
+* *Change field "Zone Name" to "Zone or Space Name."*
+
+### ZoneThermalChimney
+(If budget allows, otherwise limit these to single-space zones.)
+* *Change field "Zone N Name" to "Inlet Zone or Space Name N."*
+
+### idf Example
+
+
+## Outputs Description ##
+A new Spsz output file will be created when space sizing is active.
+
+
+## Engineering Reference ##
+
+
+## Example File and Transition Changes ##
+
+* Transition will be required for idf OutputControl:Files.
+
+* Field name changes may be required for epJSON inputs for ZoneRefrigerationDoorMixing, ZoneCoolTower:Shower, and/or ZoneThermalChimney.
+
+* The existing example file 5ZoneAirCooledWithSpaces will be copied to a new example file that uses the new Sizing:Zone Coincident Space sum option.
+
+
+## Design ##
+
+### Sizing ###
+
+When Space sizing is requested, the following arrays are created for Spaces.
+
+```
+    Array2D<DataSizing::ZoneSizingData> SpaceSizing;                      // Data for space sizing (all data, all design)
+    EPVector<DataSizing::ZoneSizingData> FinalSpaceSizing;                // Final data for space sizing including effects
+    Array2D<DataSizing::ZoneSizingData> CalcSpaceSizing;                  // Data for space sizing (all data)
+    EPVector<DataSizing::ZoneSizingData> CalcFinalSpaceSizing;            // Final data for space sizing (calculated only)
+```
+
+The main calculation flow for Zone sizing is:
+
+* `SizingManager::ManageSizing`
+    * Get sizing inputs (`GetOARequirements . . . GetPlantSizingInput`).
+    * Loop over sizing environments and days
+        ```
+          UpdateZoneSizing(state, Constant::CallIndicator::BeginDay);
+          Loop over hours and timesteps
+            ManageWeather(state);
+            UpdateSysSizing(state, Constant::CallIndicator::DuringDay);
+            ManageHeatBalance(state);
+          UpdateZoneSizing(state, Constant::CallIndicator::EndDay);
+        UpdateZoneSizing(state, Constant::CallIndicator::EndZoneSizingCalc);
+        ```
+        * Repeat (with a pulse) if zone component loads report is requested.
+ * `ZoneEquipmentManager::UpdateZoneSizing` (where all the work is done.)
+     * `case Constant::CallIndicator::BeginDay:`
+         * Do some initializations on `CalcZoneSizing`
+     * `case Constant::CallIndicator::DuringDay:`
+         * Called from `HVACManager`
+         * save the results of the ideal zone component calculation in the CalcZoneSizing sequence variables
+         * Works on `ZoneSizing` and `CalcZoneSizing`
+     * `case Constant::CallIndicator::EndDay:`
+         * Compute moving averages
+         * Save values at peak heating and cooling
+         * Works on `CalcZoneSizing` and `CalcFinalZoneSizing`
+         * *In this function add the zone sizing coincident/non-coincident option and calculations.*
+
+     * `case Constant::CallIndicator::EndZoneSizingCalc:`
+         * Apply EMS overrides
+         * Output sizing results from `CalcFinalZoneSizing`
+         * Move sizing data into final sizing array according to sizing method
+         * Works on `CalcZoneSizing`, `CalcFinalZoneSizing`, `ZoneSizing`, and `FinalZoneSizing`
+         * Lots going on in here.
+
+### HVAC ###
+
+The main calculation flow for Zone and Space HVAC in `HVACManager:ManageHVAC` is as follows, with notes about changes required for Space-HVAC.
+
+* `ZoneTempPredictorCorrector::ManageZoneAirUpdates(... GetZoneSetPoints)`
+    * `CalcZoneAirTempSetPoints`
+* `ZoneTempPredictorCorrector::ManageZoneAirUpdates(... PredictStep)`
+    * `PredictSystemLoads`
+* `SimHVAC`
+    * `SetPointManager::ManageSetPoints(state);`
+    * `SimSelectedEquipment`
+        * `SimAirServingZones::ManageAirLoops`
+        * `ZoneEquipmentManager::ManageZoneEquipment`
+            * `CalcZoneReturnFlows`*
+                * *Add space return flow calculations here.*
+                * *Likely refactor this function to be callable for either zone or space.*
+        * `PlantManager::ManagePlantLoops`
+* `ZoneTempPredictorCorrector::ManageZoneAirUpdates(... CorrectStep)`
+    * `correctZoneAirTemps`
+
+
+

doc/input-output-reference/src/overview/group-airflow-network.tex

@@ -331,7 +331,7 @@ \subsubsection{Inputs}\label{inputs-004}
 
 \paragraph{Field: Allow Unsupported Zone Equipment}\label{allow-unsupported-zone-equipment}
 
-This is an optional field. Input is Yes or No. The default is No. Set this input to Yes to have zone equipment that are currently unsupported in the AirflowNetwork model allowed in the simulation. Setting this field to Yes, allows the following equipment to be modeled along an AirflowNetwork model: ZoneHVAC:Dehumidifier, ZoneHVAC:EnergyRecoveryVentilator, WaterHeater:HeatPump:*, and ZoneHVAC:WindowAirConditioner. The AirflowNetwork model will exclude mass balance in these equipment objects and assume the mass flows are self-balanced in the equipment objects.
+This is an optional field. Input is Yes or No. The default is No. Set this input to Yes to have zone equipment that are currently unsupported in the AirflowNetwork model allowed in the simulation. Setting this field to Yes, allows the following equipment to be modeled along an AirflowNetwork model: ZoneHVAC:Dehumidifier, ZoneHVAC:EnergyRecoveryVentilator, WaterHeater:HeatPump:*, ZoneHVAC:WindowAirConditioner, ZoneHVAC:WaterToAirHeatPump, ZoneHVAC:PackagedTerminalAirConditioner, ZoneHVAC:PackagedTerminalHeatPump, and ZoneHVAC:TerminalUnit:VariableRefrigerantFlow. The AirflowNetwork model will exclude mass balance in these equipment objects and assume the mass flows are self-balanced in the equipment objects. These objects should be modeled with no outdoor air flow rate, or in the case of a ZoneHVAC:EnergyRecoveryVentilator with a balanced air flow (same supply airflow rate as exhaust airflow rate).
 
 \paragraph{Field: Do Distribution Duct Sizing Calculation}\label{do-distribution-duct-sizing-calculation}