@Tiehong , I am not able to reproduce your observation. The report file has columns that are space delimited. I am going to close this issue unless you are able to provide additional information.

The problem arises when there are unusually large numbers in the result and the program does not convert them to scientific notation. Tiehong's example model does yield the behavior he described, as shown in the attached graphic.

@MitchHeineman Interesting...

It seems to me this is an artifact of the GUI framework. Does resizing the column eliminate the issue or are the preceding numbers actually appended to the Type field in the example you show?

I will try to reproduce it on my end.

Wouldn't making all the columns scientific format fix the issue? Then there will be a space.

J1 JUNCTION 321741.00321741.00 0 11:54 5.72e+03 5.72e+03 0.000

It seems to me this is an issue that has been addressed with various columns at various times. We probably have to think a bit about how we implement it going forward so that it works for all fields.

We loose some of the digits using scientific format but it should be a good solution for now. It seems the larger issue is the attempt to align the column names with the values for ease in reading the results, which is a good thing for users.

I haven't looked at the code (besides, my native language is Fortran), and perhaps it already does this in places, but I'd suggest using floating point notation where values fit into the columns and scientific only for large values. In Fortran, this is generally a matter of using the G edit descriptor. Something like this?

#include <stdio.h>
#include <math.h>
void print_num(double num, int width)
{
int n = (int)log10(fabs(num)) + 1;
char buffer[width + 1];
if (n > width) {
if (width < 7) {
printf("%.s\n", width, "*****");;
return;
}
snprintf(buffer, width + 1, "%.e", width -2 , width - 7, num);
} else {
snprintf(buffer, width + 1, "%.*f", width , width - n - 1, num);
}
printf("%-*s\n", -width, buffer);
}

Now I see there's a G edit descriptor in C as well, but you get the idea...

Reopening ...

Given that this issue is being reported at this late date, width overflow in report file tables can be regarded as an edge case. While the solution currently implemented, adopting the "%9.3g" print format over the "%9.3f" format has its merits, it changes the contents of report file tables in nearly all test cases.

On the otherhand, simply providing padding like so, " %8.3f" does not change report file table contents, will not result in truncation of flow values, and in the event of a width overflow inserts a space between fields. The only downside being that table formatting will not be maintained in the event of width overflow -- the current status quo. A more comprehensive solution would require an extensive rewrite of the code for printing report tables.

Therefore, to patch this bug, I prefer padding the fields with a space so they no longer run together in the event of a width overflow. No changes to table headers, the UI code, or the benchmark files is required.

PR coming forthwith ...