[pbachant]

I was trying to run a case for a while (3M cells, pimpleDyMFoam, parallel by 4) and it was always giving me trouble after a while--pressure taking way too many iterations, time step blowing up, etc. I turned off writeCompression and it's now stable. Has anyone else ever encountered this problem?

[wyldckat]

Greetings Pete,

That's an odd situation... the only thing that comes to mind is some sort of memory leak that is damaging the memory locations where the fields are stored, which might be damaged while OpenFOAM is using ZLib to compress the data on-the-fly.

A few questions:

1. Which OpenFOAM version are you using?
2. Was it installed from source or from RPM or Deb?
3. Is the write mode set to "ascii" or "binary"?
4. Is the simulation executed in a single machine or running in parallel with 2 or 4 machines?
5. Are you able to reproduce the same error with one of OpenFOAM's own tutorials?

Best regards,
Bruno

[pbachant]

Originally Posted by wyldckat

Greetings Pete,

That's an odd situation... the only thing that comes to mind is some sort of memory leak that is damaging the memory locations where the fields are stored, which might be damaged while OpenFOAM is using ZLib to compress the data on-the-fly.

A few questions:

1. Which OpenFOAM version are you using?
2. Was it installed from source or from RPM or Deb?
3. Is the write mode set to "ascii" or "binary"?
4. Is the simulation executed in a single machine or running in parallel with 2 or 4 machines?
5. Are you able to reproduce the same error with one of OpenFOAM's own tutorials?

Best regards,
Bruno

This problem was happening with 2.2.2, installed from Deb. It was writing in binary mode on a single machine. I have not seen the same error in, for example, the propeller tutorial. It's quite strange. I've moved on to 2.3.0 now, and will post case files if the problem occurs again, but I'm not even at that point. My AMI surfaces are now not being created properly