Ch32 Discussion

Discussion Guide

Warm-up (think–pair–share, 5 min). "You declare real :: a[*] and run on 4 images, then write a = 5 on every image. How many as now hold 5, and can image 1 see image 3's a?" (Four separate as each hold 5; image 1 sees image 3's only via a[3].) Surfaces the private-copy / coindexing model from intuition and flushes out the "shared array" misconception immediately.

Main discussion (15–20 min). 1. Why the bracket changes everything. Put x = a[q] on the board next to an MPI Send/Recv pair and a Python comm.bcast. Ask: "What has Fortran put in the language that the others put in a library, and what does the compiler gain from knowing about it?" Lands the threshold concept (parallelism declared, not imported) and the "Fortran is not dead" theme with something concrete. 2. Where does the race hide? Show Case Study 1's buggy_norm. "It prints 650 on one image and varies on four. Which of those runs would you trust, and why is the trustworthy-looking one the dangerous one?" Drives home that -fcoarray=single hides races and that a varying result is a race fingerprint. Then ask for the two faults (unsynchronized single-slot accumulate) and the fix hierarchy (slots → critical → co_sum). 3. Cut the plate — which way, and why? Ask the class to argue rows vs columns for the strip decomposition. Steer to: columns, because u(:,j) is contiguous in column-major memory, so a halo is one contiguous message. Ties the parallel decision back to the Part I memory-order theme and shows that "performance is not accidental" reaches even into communication.

Group activity (12–15 min). In pairs, students hand-trace the Project Checkpoint's global cell $(2,3)$ through both steps on 2 images, identifying exactly which coindexed read supplies the neighbour that makes it $32$ rather than $28$ — i.e. locating the halo in the arithmetic. Then they predict the output on 4 images (owned columns become 1 each) and confirm the assembled field is unchanged. Collect two or three and check that they (a) found the u(:,nloc+2)=u(:,2)[me+1] read as the source of the $32$, and (b) argued image-count independence from the physics, not from the code. Tell them: Chapters 33–34 re-solve this exact plate — keep the trace.

Exit ticket. "A student's coarray reduction gives $650$ with -fcoarray=single and varying values under cafrun -n 4. (a) What class of bug is this? (b) Why did the single-image build not catch it? (c) Name the one intrinsic that would fix it in a line." (Answers: (a) a race — unsynchronized/clobbering remote writes; (b) one image cannot race, so -fcoarray=single validates logic but not synchronization; (c) co_sum.)