Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output Processor Refactor -- Part 2 #10384

Merged
merged 17 commits into from
Apr 6, 2024
Merged

Output Processor Refactor -- Part 2 #10384

merged 17 commits into from
Apr 6, 2024

Conversation

amirroth
Copy link
Collaborator

@amirroth amirroth commented Jan 27, 2024

This is a continuation of the large OutputProcessor refactor which merged about six weeks ago. The changes now are much smaller in scope. A quick pre-walkthrough summary:

  • Reordered SetupOutputVariable API to eliminate most of the uses of default {} arguments, and changed the remaining to "" or explicit enumerations as needed. I think we are ready for a script that disallows the use of {} as function arguments.
  • There was a level of indirection and mapping between TimeStepType used locally in OutputProcessor (Zone and System) vs. the ones used externally in calls to SetupOutputVariable (Zone, System, HVAC, and Plant). Internally, OutputProcessor mapped HVAC and Plant to System. Changed all uses of HVAC and Plant to System and removed this indirection. Same thing for StoreType (Sum and Average internally, Sum, Average, State and Non-State in SetupOutputVariable).
  • Continued unifying handling of OutVarInt and OutVarReal, deleting duplicate code. This reorders the .eso files, but since the changes do not propagate to the .htm or any other files these are not flagged as diffs.
  • As part of the unification, converted some standalone functions whose only non-state arguments were fields of OutVar to methods on OutVar.
  • Eliminated some redundant NotFound enumerations. Using Invalid now.
  • Eliminated some unit tests and portions of unit tests that covered things that don't make sense anymore, e.g., testing bad strings arguments for parameters that are now enums.

Note: there are two failed unit tests. They do not fail on my Mac but do fail on Marvin. I think this is because Marvin runs a higher version of Clang (15) than I do (12). Unfortunately, my Mac is too old to run the newer MacOS and the updated XCode tools. I will need to get a new one, but maybe not today. In the meantime, I assume the problems are small and @Myoldmopar can just deal with them.

@amirroth amirroth added DoNotPublish Includes changes that shouldn't be reported in the changelog Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring labels Jan 27, 2024
@amirroth amirroth added this to the EnergyPlus 24.1 milestone Jan 27, 2024
@@ -348,40 +348,38 @@ namespace BaseboardElectric {
"Baseboard Total Heating Energy",
Constant::Units::J,
thisBaseboard.Energy,
OutputProcessor::SOVTimeStepType::System,
OutputProcessor::SOVStoreType::Summed,
OutputProcessor::TimeStepType::System,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Collapsed indirection from SOVTimeStepType to TimeStepType and SOVStoreType to StoreType.

thisBaseboard.EquipName,
Constant::eResource::EnergyTransfer,
OutputProcessor::SOVEndUseCat::Baseboard,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reordered API eliminates most instances of {} arguments.

OutputProcessor::SOVEndUseCat::Heating,
"Boiler Parasitic",
OutputProcessor::SOVGroup::Plant);
OutputProcessor::Group::Plant,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar changes from here on out until OutputProcessor module.

@@ -187,7 +187,7 @@ namespace OutputProcessor {
state.files.mtd.ensure_open(state, "InitializeMeters", state.files.outputControl.mtd);
} // InitializeOutput()

void addEndUseSubcategory(EnergyPlusData &state, SOVEndUseCat sovEndUseCat, std::string_view const endUseSubName)
void addEndUseSubcategory(EnergyPlusData &state, EndUseCat endUseCat, std::string_view const endUseSubName)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed SOV prefixes after indirections were eliminated. No need to differentiate between SOV version of an enum and internal version of same enum.

-1.0, // MaxValue
-1, // MaxValueDate
periodTS.RptFO);
periodTS.WriteReportData(state, ReportFreq::TimeStep);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made this into a method.

@@ -5031,7 +4599,8 @@ void ProduceRDDMDD(EnergyPlusData &state)

if (ddVar->ReportedOnDDFile) continue;

std::string_view timeStepName = timeStepNames[(int)ddVar->timeStepType];
static constexpr std::array<std::string_view, (int)TimeStepType::Num> timeStepNamesLocal = {"Zone", "HVAC"};
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The system time step is called System everywhere else but it's called HVAC in the .rdd file end of line comments.

@@ -75,29 +75,6 @@ struct EnergyPlusData;

namespace OutputProcessor {

// enumerations for SetupOutputVariable calls -- for now these are direct mappings from the original strings, no change in functionality
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for these additional enums.

std::vector<int> meterNums; // Meter Numbers

virtual ~OutVar(){};

std::string multiplierString() const;

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look mom, methods!

std::string const &indexGroup, // The reporting group for the variable
std::string const &meterName, // The variable's meter name
Constant::Units unit, // The variables units
bool cumulativeMeterFlag, // A flag indicating cumulative data
bool meterFileOnlyFlag // A flag indicating whether the data is to be written to standard output
);

void WriteRealVariableOutput(EnergyPlusData &state,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are methods now.

rVar.minValueDate = rVar.maxValueDate = 0;
rVar.freq = ReportFreq::TimeStep;

rVar.writeReportData(*state);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are methods now so need to create and populate an object to test them.

@amirroth amirroth requested a review from Myoldmopar January 27, 2024 15:56
@mjwitte
Copy link
Contributor

mjwitte commented Jan 29, 2024

From the top comment

Continued unifying handling of OutVarInt and OutVarReal, deleting duplicate code. This reorders the .eso files, but since the changes do not propagate to the .htm or any other files these are not flagged as diffs.

Just for the record this does reorder the csv output, but mathdiff re-sorts the columns to match, so no diff is reported.

@Myoldmopar Myoldmopar self-assigned this Jan 31, 2024
@Myoldmopar
Copy link
Member

@amirroth do you have any other changes for this branch locally? It's not I/O freeze related, but I'd still be happy to push on it a bit while I wait on some other PRs to wrap. I can push Clang-format and such up, but I didn't want to stomp on any changes you might have locally.

@Myoldmopar
Copy link
Member

I went ahead and applied Clang Format and pulled develop in again. I hadn't noticed the one unit test failure until I was doing final checks here. (The SQLite failure showing up here And it's passing on my machine...so I'm just going to push it up and let CI confirm it one more time before investigating.

@Myoldmopar
Copy link
Member

Interesting, still failing, and only on Windows and Mac. Are you seeing this locally on your Mac builds @amirroth ? I'll get a Mac build of it going regardless.

@amirroth
Copy link
Collaborator Author

Sorry, was at an offsite the past two days and not really paying attention. I do know about the unit test failures but they make no sense and I cannot reproduce. I don't have any local changes. Fine to hold off if you need to.

@amirroth
Copy link
Collaborator Author

amirroth commented Apr 3, 2024

@Myoldmopar, one failing unit test (the other one mysteriously stopped failing) that I can't reproduce locally. Otherwise, this is ready.

@Myoldmopar
Copy link
Member

My only question is if there are any other spots we are doing a string-view-with-ternary assignment that we should fix. I'll add it to my list of custom-checks to write...

@Myoldmopar
Copy link
Member

Thanks for this cleanup @amirroth , I'm merging it, it's all clean.

@Myoldmopar Myoldmopar merged commit 775886b into develop Apr 6, 2024
14 checks passed
@Myoldmopar Myoldmopar deleted the OutputProcessor2 branch April 6, 2024 00:35
@amirroth
Copy link
Collaborator Author

amirroth commented Apr 8, 2024

My only question is if there are any other spots we are doing a string-view-with-ternary assignment that we should fix. I'll add it to my list of custom-checks to write...

There is a little more nuance. The precise problem idiom is:

std::string_view sv = (condition) ? (std_string_var) : (char_array_or_other_var_requiring_a_temp_std_string_wrapper)

This is fine:

std::string_view sv = (condition) ? (std_string_var) : (another_std_string_var)

This is also fine I think:

std::string_vew sv (condition) ? (char_array) : (another_char_array)

@amirroth
Copy link
Collaborator Author

amirroth commented Apr 8, 2024

@Myoldmopar, the custom check you can/should write now is the one that disallows {} as an argument. The OutputProcessor API changes in this PR got rid of all instances associate with SetupOutputVariable and I manually removed the remaining handful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DoNotPublish Includes changes that shouldn't be reported in the changelog Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants