# Issue with Progress Option in OpenMP Backend

**URL:** <https://pyfr.discourse.group/t/issue-with-progress-option-in-openmp-backend/1049>\
**Category:** Errors\
**Created:** [6 March 2024 20:22 UTC](https://pyfr.discourse.group/t/issue-with-progress-option-in-openmp-backend/1049 "2024-03-06T20:22:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Zach-Davis](https://yyz2.discourse-cdn.com/free1/user_avatar/pyfr.discourse.group/zach-davis/32/237_2.png) [@Zach-Davis](https://pyfr.discourse.group/u/Zach-Davis)\
**Post date:** [6 March 2024 20:22 UTC](https://pyfr.discourse.group/t/issue-with-progress-option-in-openmp-backend/1049/1 "2024-03-06T20:22:07Z")

</div>

I noticed when running PyFR (latest develop branch) using the openmp backend with a partitioned mesh, that the progress output is only printed to standard out once the case is finished, rather than being updated at regular intervals.

Running the same case with the openmp backend using a single partition still outputs the progress as expected.

I’m not sure if others have observed something similar, or if it’s just local to my environment. Not a big issue, just an inconvenient change…

---

<div class="post-metadata">

**Author:** ![fdw](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@fdw](https://pyfr.discourse.group/u/fdw)\
**Post date:** [6 March 2024 20:30 UTC](https://pyfr.discourse.group/t/issue-with-progress-option-in-openmp-backend/1049/2 "2024-03-06T20:30:18Z")

</div>

I suspect this is an environment thing. Some MPI libraries are better than others when it comes to flushing stderr rather than having it buffer indefinitely on the rank. If I recall the only difference with the current code compared with the previous code is that before we would erase an entire line. Now, we only erase as many characters as consumed by the progress bar when redrawing it. However, all of this is interpreted by the terminal and so it should not make a difference.

Regards, Freddie.