postChannel does not work in p
 

postChannel does not work in parallel.

This may not be critical if you postprocess your field after writing and reconstructing them but for long simulations (24 hr physical time), one needs to write the space averaged field every sampling period which does not take lots of storage. It is prohibitive to write the fields every such interval, use reconstructPar then the serial postChannel especially if you run on a computer cluster that is not administrated by you (nation-wide cluster, typically the case). I wrote a motivation for integrating postChannel with channelOodles in the thread. I also wrote some thread more than one year ago about that. At that time the feature was not critical since I was not running such long simulations and I had a tera byte storage of my own. The only obstacle is to make postchannel work in parallel, then integrating it into the solver is easier. Please feel free to criticize the necessity of such feature and I can provide solid examples.

Best regards,
Maka.

postChannel not running in par
 

postChannel not running in parallel is not a bug it's a feature although the -parallel option should be disabled and I will fix that.

Rewriting postChannel to run in parallel is non-trivial and not high priority. If you need this feature urgently and are unable to do the necessary coding yourself you might want to consider sponsoring OpenCFD to write it for you.

memory leak
 

Hi!
running valgrind --tool=memcheck postChannel . channel395 with OF V1.3
generated memory leak errors among others.


==27732== Conditional jump or move depends on uninitialised value(s)
==27732==
==27732== ERROR SUMMARY: 108 errors from 1 contexts (suppressed: 5 from 2)
==27732== malloc/free: in use at exit: 126,554 bytes in 1,620 blocks.
==27732== malloc/free: 219,817 allocs, 218,197 frees, 67,990,035 bytes allocated.
==27732== For counts of detected errors, rerun with: -v
==27732== searching for pointers to 1,620 not-freed blocks.
==27732== checked 906,648 bytes.
==27732==
==27732== LEAK SUMMARY:
==27732== definitely lost: 0 bytes in 0 blocks.
==27732== possibly lost: 18,618 bytes in 444 blocks.
==27732== still reachable: 107,936 bytes in 1,176 blocks.
==27732== suppressed: 0 bytes in 0 blocks.
==27732== Reachable blocks (those to which a pointer was found) are not shown.
==27732== To see them, rerun with: --show-reachable=yes
Thanks,

Best regard,
Maka.

related post.
 

This could be related to post http://www.cfd-online.com/Forums/ope...tml#post207719
but I could not locate Henry post on 28 June 2006.

You might want to switch to 1.5.x. Its postChannel it greatly improved and does run in parallel. Please let us know if there are memory errors in that.