lharris4
commented
11 months ago Hi, Steve. Thank you for opening this issue. I will take a closer look upon
returning from travel but I believe the upshot is that u_srf/v_srf need
to have the lat-lon winds to have been previously computed; this is done at
the end of fv_dynamics() but not necessarily in the model initialization.
These are indeed the lowest-layer winds which are not the same as the 10-m winds; the latter is computed from the physics by Monin-Obhukov theory.
Lucas
On Mon, Nov 13, 2023 at 9:10 PM Steve Penny @.***> wrote:
Is your question related to a problem? Please describe. From our own external driver routine, we are accessing the 10m winds through IPD_Data(nb)%intdiag%u10m and IPD_Data(nb)%intdiag%v10m. This works fine for us after the first model time step. However we have noticed that on time step 0 (upon initialization of the model) these fields are empty. It appears that they are diagnostic fields that only get populated after the first model time step completes. We would like realistic u10m/v10m fields to be populated at time 0, e.g. based on the initial condition file or restart file.
Is there a straightforward way to trigger the diagnostic computation of u10m/v10m winds when the model initializes so that they are not empty at time step 0?
Describe what you have tried We've tried accessing the Atm(mygrid)%u_srf and Atm(mygrid)%v_srf fields from the fv3 dynamical core at timestep 0, but they appear to be represented slightly differently on the grid. It's not clear to me whether these are on a C-grid or D-grid stagger while it appears the diagnostic 10m winds above are at cell centers. Ideally, we'd like them to be on the same grid at the same associated height. The bigger problem for us in this case was identifying the appropriate means of collecting the parallel-distributed data, which appears to be different from what was used above for the IPD_Data(nb)%intdiag data structure.
We attempted something like:
if (varchar=='u') then do j=jsc,jec do i=isc,iec dataPtr_r8(i,j) = real(Atm(mygrid)%u_srf(i,j),kind=8) enddo enddo elseif (varchar=='v') then do j=jsc,jec do i=isc,iec dataPtr_r8(i,j) = real(Atm(mygrid)%v_srf(i,j),kind=8) enddo enddo endifbut the resulting fields were not reconstructed correctly. Further, we presume these fields are defined at the model's bottom level and not at the desired 10m height.
— Reply to this email directly, view it on GitHub https://github.com/NOAA-GFDL/SHiELD_physics/issues/32, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMUQRVGQTBAF5QLMRLOCLTDYELHHTAVCNFSM6AAAAAA7KCHD32VHI2DSMVQWIX3LMV43ASLTON2WKOZRHE4TCOBUGM4DOMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
StevePny
Is your question related to a problem? Please describe. From our own external driver routine, we are accessing the 10m winds through IPD_Data(nb)%intdiag%u10m and IPD_Data(nb)%intdiag%v10m. This works fine for us after the first model time step. However we have noticed that on time step 0 (upon initialization of the model) these fields are empty. It appears that they are diagnostic fields that only get populated after the first model time step completes. We would like realistic u10m/v10m fields to be populated at time 0, e.g. based on the initial condition file or restart file.
Is there a straightforward way to trigger the diagnostic computation of u10m/v10m winds when the model initializes so that they are not empty at time step 0?
Describe what you have tried We've tried accessing the Atm(mygrid)%u_srf and Atm(mygrid)%v_srf fields from the fv3 dynamical core at timestep 0, but they appear to be represented slightly differently on the grid. It's not clear to me whether these are on a C-grid or D-grid stagger while it appears the diagnostic 10m winds above are at cell centers. Ideally, we'd like them to be on the same grid at the same associated height. The bigger problem for us in this case was identifying the appropriate means of collecting the parallel-distributed data, which appears to be different from what was used above for the IPD_Data(nb)%intdiag data structure.
We attempted something like:
but the resulting fields were not reconstructed correctly. Further, we presume these fields are defined at the model's bottom level and not at the desired 10m height.