Improving clarity of the story

Author: erichgess

src/vision/status_quo/barbara_simulates_hydrodynamics.md

@@ -8,13 +8,13 @@ If you would like to expand on this story, or adjust the answers to the FAQ, fee
 
 ## The story
 ### Problem
-Barbara needed to build a tool to solve hydrodynamics simulations; there is a common method for this that subdivides a region into a grid and computes the solution for each grid patch. All the patches in a grid for a point in time are independent and can be computed in parallel, but they are dependent on neighboring patches in the previously computed frame in time.  This is a well known computational model and the patterns for basic parallelization are well established.
+Barbara is a professor of physics at the University of Rustville. She needed to build a tool to solve hydrodynamics simulations; there is a common method for this that subdivides a region into a grid and computes the solution for each grid patch. All the patches in a grid for a point in time are independent and can be computed in parallel, but they are dependent on neighboring patches in the previously computed frame in time.  This is a well known computational model and the patterns for basic parallelization are well established.
 
-Barabara wanted to write a performant tool to compute the solutions to the simulations of her research.  She chose Rust because she was already familiar with it and it had good qualities for writing performant code. After implementing the core mathematical formulas, Barbara began implementing the parallelization architecture. 
+Barabara wanted to write a performant tool to compute the solutions to the simulations of her research.  She chose Rust because she needed high performance but she also wanted something that could be maintained by her students, who are not professional programmers. Rust's safety guarantees giver he confidence that her results are not going to be corrupted by data races or other programming errors. After implementing the core mathematical formulas, Barbara began implementing the parallelization architecture. 
 
 Her first attempt to was to emulate a common CFD design pattern: using message passing to communicate between processes that are each assigned a specific patch in the grid. So she assign one thread to each patch and used messages to communicate solution state to dependent patches.  With one thread per patch this usually meant that there were 5-10x more threads than CPU cores.
 
-This solution was fine, but Barbara was not satisified.  She had two problems with it: first, she didn't like that the design would greedily use all the resources on the machine and, second, when her team added a new feature (tracer particles) that increased the complexity of how patches interact with each other and the number of messages that were passsed between threads increased to the point that it became a performance bottleneck and parallel processing became no faster than serial processing. So, Barbara decided to find a better solution.
+This solution worked, but Barbara had two problems with it. First, it gave her no control over CPU usage so the solution would greedily use all available CPU resources. Second, using messages to communicate solution values between patches did not scale when her team added a new feature (tracer particles) that added additional solution data the additional messages caused by this change created so much overhead that parallel processing was no faster than serial. So, Barbara decided to find a better solution.
 
 ### Solution Path
 What Barbara wanted use the CPU more efficiently: she would decouple the work that needed to be done (the patches) from the workers (threads) this would allow her to more finely control how many resources were used. So, she began looking for a tool in Rust that would meet this design pattern. When she read about `async` and how it allowed the user to define units of work, called tasks, and send those to an executor which would manage the execution of those tasks across a set of workers, she thought she'd found exactly what she needed. Further reading indicate that `tokio` was the runtime of choice for `async` in the community and so she began building a new CFD tool with `async` and `tokio`. And to move away from the message passing design, because the number of messages being passed was proportional to the number of trace particles being traced.