[ferranroigtio]

Hi, openfoamers.

I'm practicing with the damBreak tutorial. When I run setFields, a new file alpha.water is generated in the directory 0. However, the internalField values seem to be encrypted or misread somehow. They appear as strange symbols, which even vary across the readers used. See attached pictures for reference (using Sublime Text, nano, vi and cat).

You can see I'm using a mac. Therefore, I run OpenFOAM through Docker. I ran the interFoam solver. It went alright. So, although the interpretation issue is frustrating for me trying to undersand what I'm setting, it seems that the solver copes perfectly with it.

By the way, the symbols get worse at times other than 0. See, for example, the attached image "vi 01".

The big question is what ParaView will say about that. Turns out not to be a problem if I run ParaView through Docker. But that's not too efficient. Instead, I'd touch the .OpenFOAM file and open it in my local mac. And there's the problem. It doesn't seem to interpret anything at all. The fraction of water varies between 0 and 1e-38, that is, there's no water whatsoever.

I'm creating this thread under Pre-Processing because I believe this issue needs to be fixed before the solver is launched, not at the postprocessing stage (even though it's then when I see its impact).

Does any one have any idea on how to fix this?

Thank you all in advance.

[adhiraj]

It seems that you saved the results in binary format, which is why you cannot open it in a text editor.

ParaView should be able to handle that format directly. If ParaView is having trouble with the files it could be due to incorrectly loading the case, or perhaps using a boundary condition that is not supported by ParaView.