Thanks for the feed-back everyone! Actually, even on a serial run I have output
writing accounting for 11% of the computational time on Norne. Splitting it in
a separate thread with asynchronous writing should bring that down to
practically zero with no extra dependencies required, and without m
Hi all,
> as far as I can see, there is not much which can be done on that front if you
> continue to insist on using ECL compatible files for output of parallel
> simulations. (these are inherently sequential file formats and thus the only
> way to accelerate writing them is to accelerate the
Hi,
On Tuesday, March 15, 2016 08:47:52 AM Alf Birger Rustad wrote:
> Today, writing results is a performance bottleneck flow.
as far as I can see, there is not much which can be done on that front if you
continue to insist on using ECL compatible files for output of parallel
simulations. (thes
On 15. Mar. 2016 at 09:47, Alf Birger Rustad wrote:
Today, writing results is a performance bottleneck flow.
> ...
the simulator should not need to wait computing the next timestep
while the results are written. It has been suggested to split out the
writing in a separate process to accomplish
Hi,
On Tue, Mar 15, 2016 at 08:47:52AM +, Alf Birger Rustad wrote:
> Thanks for the announcement! There is one issue that I hope
> everybody with informed opinions can contribute to. Today, writing
> results is a performance bottleneck flow. Hence, we should find a
> way for flow to write resu
Thanks for the announcement! There is one issue that I hope everybody with
informed opinions can contribute to. Today, writing results is a performance
bottleneck flow. Hence, we should find a way for flow to write results
asynchronously, i.e., the simulator should not need to wait computing the
