Overcome StdOutputRecordCount's limit of about 2.1 billion

[jcyuan2020]

Issue overview

Recent a user reports the needs to report a very large number of output variables (into eso, and/or possibly sql as well) that exceeds the integer type limits of 2 147 883 647. Therefore, a question was asked about changing the “int” type definition of the variable state.dataGlobal->StdOutputRecordCount to an even “longer” integer type, such as “long int” to solve the problem.

The problem is related to the code here:

EnergyPlus/src/EnergyPlus/SimulationManager.cc

Lines 1826 to 1831 in e6e681d

	if (state.dataGlobal->StdOutputRecordCount > 0) {
	print(state.files.eso, variable_fmt, "Number of Records Written", state.dataGlobal->StdOutputRecordCount);
	state.files.eso.close();
	} else {
	state.files.eso.del();
	}

If the count hits above the 32-bit integer upper limit, it will execute the “else” block and delete the entire output file. Another possible solution provided by the user is to use StdOutputRecordCount != 0, instead of StdOutputRecordCount > 0, that could exploit the negative overflow the int type to avoid the else{ block to be executed in an overflow condition.

The case as described by the user is about a 30 000 square meter building with 1000 area, using a 5-minute timestep for simulations. The user outputted a set of variables for each zone for an in-house automatic tools to check comfort and efficiency in each zone. With the settings, at each timestep the outputs contains 105 120 000 records. The 2.1 billion limit was quickly consumed up.

A few thoughts about this:

1. Change the definition of state.dataGlobal->StdOutputRecordCount from int to unsigned int might double the limit, which is about 4.3 billion records.
2. It might ok to exploit the negative overflow value, e.g. as a temporary solution for the unexpected output eso deletion. But it is in general not a good practice to leave an overflow condition unattended there. But still the screen output of the count would be negative and incorrect.
3. In general, “long int” might be subject to the compiler’s or the machines’ interpretation on its length. It is said to be “at least 32bit”, which means there might be a possibility that some systems/compilers might just use 32 bit, which would not help to extend the limit if this happened to be the case?
4. A quick search in the code found that the variable state.dataGlobal->StdOutputRecordCount seems to be used just an increment counter, and it is not used in any array index or anything else. This helps in not complicating the issue.

Details

Some additional details for this issue (if relevant):

• Platform (Operating system, version): All
• Version of EnergyPlus (if using an intermediate build, include SHA): at least from v8.9 to 9.6
• Helpdesk ticket number: 16081

Checklist

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

• Defect file added (list location of defect file here)
• Ticket added to Pivotal for defect (development team task)
• Pull request created (the pull request will have additional tasks related to reviewing changes that fix this defect)