Channel names in uncompressed binary file are truncated to 10 characters

[ebranlard]

Main issue
Uncompressed binaries use only 10 characters for the channel names when OutFmt = 4 i.e. FileID = FileFmtID_NoCompressWithoutTime = 3 , see e.g:

openfast/modules/nwtc-library/src/NWTC_IO.f90

Line 5011 in df84035

ChanLen2 = 10

openfast/modules/nwtc-library/src/NWTC_IO.f90

Line 6883 in df84035

LenName = 10

Suggested solution
The maximum number of characters for the channel length should be written to the file to have a similar behavior for compressed and uncompressed binaries, and ASCII files.

Since uncompressed binaries are not too commonly used at the moment, I suggest that when OutFmt = 4 OpenFAST writes an uncompressed binary file with one extra field for the channel length (similar to what is done for FileFmtID_ChanLen_In).
For backward compatbility, we can introduce a new "FileID" in the binary file, e.g. FileID = FileFmtID_NoCompressWithoutTime_ChanLen_In=5 .

[bjonkman]

Do we need the uncompressed binaries? Could we instead use the compressed versions for the regression tests now that the tests compare values a little differently? Or is there another use case for the uncompressed files?

[ebranlard]

Compressed binaries can perform poorly for signals that have a large range, typically during initial transients that are slightly unphysical. This can be avoided by starting the output after the transients, or using a steady state solve, or having better initial conditions. Since not so many people use this format, I think it's a small change to add the channel length as an extra field in this file format.
Below is an example from a CFD simulation (in log scale) where the compressed binary does not work well for the Cp because it takes large values at initialization:

We could also bound these coefficients between -10 and 10 for instance...

[bjonkman]

I've seen something similar in the Cp output in some of the extreme wind-direction change cases, but I've also been trying to bound that coefficient in my code. If 10^4 was a valid value, then the differences in those smaller values due to compression wouldn't matter. :)

It's not a huge deal to add another format in OpenFAST, it's just more bookkeeping on the file reading side. There tend to be a bunch of different post-processors where the change would need to be made.

[andrew-platt]

Is this still an issue?

[bjonkman]

Yes. The uncompressed binary file format has not been changed, and most of the r-test cases still output uncompressed binary formats (it looks like AeroDyn driver and FAST.Farm use compressed output)

[andrew-platt]

This is definitely something to fix at some point... maybe in v4.0.1

[bjonkman]

Since it will change the header of the uncompressed binary file, it's going to affect all of the file-read codes. I'd either (1) put it in v5.0.0 or (2) modify r-test to use the compressed files (which have a field for channel name width) and leave this as a known limitation for a file type that is rarely used.

[andrew-platt]

Very good point. We'll put it in 5.0 (and maybe 4.1 if we have such a release).