binary format for boundaryData

As requested by @Sergio - and discussed by email with @andy and @Mattijs

• I'll take it.

mentioned in commit 43b62dcd184fb85af2b9edabe21beb671c674ae2

mentioned in commit 362283c28e075bd1854c1b0862f34fc653c4384a

mentioned in commit b48d4e41f83fe8bef2ad6014b685d4147c58fbae

mentioned in commit 90a4f08e91416657d2d7d8b53ea695eaf077d5d9

The cleaner solution for the long-term would be to support FoamFile header information in the boundaryData format. It looks like we already had something like that in the boundaryData writer in the past (commit abb59735 - @andy).

It seems consistent to me. I wonder why Andy took it off.

The consumer side is reading as a list of points etc. Will choke on the FoamFile header. I think that one way would be to tag with "header" when generating the boundaryData and also when consuming it. If "header" is true, should be able work out a reasonable conditional for reading it. No idea what bad things will happen if we claim it has a header, but it in fact does not.

mentioned in commit 6b3b6bb9

@Sergio - I've added in the first bits of plumbing for conveying the format/compression, but need a good test case using MappedFile. I have an idea of how to handle it (without an extra dictionary entry for the reader), but need a test case.

What about AverageField? I can't see where this is being generated in binary in your example commit. /mark

You can use the obliqueAirJet in the integration-thermalShell branch?

I think that there is a tutorial in dev as well using a data file to map the inlet.

I did not test the setAverage_ = true, but I added the readFormat_ in the IFstream (line 470, 409). But I did not test it.

Should I do a rebase and forced push? On the thermal-shell branch.

Yes, you can do that, (the commit for the handling of the binary format?). I'll check the tutorial if you want.

closed