<div dir="ltr">Dear all,<div><br></div><div>

<p style="color:rgb(51,51,51);font-family:Verdana,sans-serif;font-size:12px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Following changes were committed to the NEMSfv3gfs and FV3 repositories:</p><p style="color:rgb(51,51,51);font-family:Verdana,sans-serif;font-size:12px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Task<span> </span><a class="gmail-issue gmail-tracker-28 gmail-status-1 gmail-priority-4 gmail-priority-default gmail-created-by-me" title="Task: bug fix in calling gfs radiation driver and computing Gaussian latitude using double precision   (New)" href="https://vlab.ncep.noaa.gov/redmine/issues/54973" style="color:rgb(17,102,153);text-decoration:none;word-wrap:break-word">#54973</a>: bug fix in calling gfs radiation driver, compute Gaussian latitude using double precision<br>It is found that there is a phase shift of instantaneous surface downward shortwave in the fv3gfs output compared to operational GFS. It turns out the gfs radiation driver is called at every time step, this causes the cosine zenith angle changing even though the short wave and long wave radiation are still called at correct radiation time steps. Because of this, the cosine zenith angle does not match with the radiation fields computed at radiation time step. This is fixed by only calling gfs radiation driver at radiation time step.<br>It is also found that because fv3gfs parallel is running at 32 bit real the Gaussian latitudes in NEMSfv3gfs output files show slight differences compared to operational GFS which is running at 64 bit real. To make consistent products, the Gaussian latitude is computed using hard wired 64 bit real in NEMSfv3gfs.</p><p style="color:rgb(51,51,51);font-family:Verdana,sans-serif;font-size:12px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Bug<span> </span><a class="gmail-issue gmail-tracker-1 gmail-status-1 gmail-priority-7 gmail-priority-lowest" title="Bug: A bug fix in tref update with sfccycle (New)" href="https://vlab.ncep.noaa.gov/redmine/issues/54894" style="color:rgb(17,102,153);text-decoration:none;word-wrap:break-word">#54894</a>: A bug fix in tref update with sfccycle<br>In the current FV3GFS, after call gcycle, there are some unusual values in the tref and tsfc updates over coast areas due to the mask update issue. This is fixed by updating tref and tsfc in a different way by modifying gcycle.f90.</p><p style="color:rgb(51,51,51);font-family:Verdana,sans-serif;font-size:12px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Baseline results are altered due to the changes above. New baseline was created on wcoss (phase1,2 and cray) and theia. Regression test passed on those platforms.</p>

Thanks.</div><div><br></div><div>Jun</div></div>