[MITgcm-support] How to Create a Consistent runOffMapFile After Topography Changes

ht ht.fisher at protonmail.com
Thu May 22 12:53:30 EDT 2025


Dear Jean-Michel and other MITgcm supporters,

Thank you very much for your detailed explanation regarding the structure and content of the runOffMapFile. It was extremely helpful in understanding how runoff is mapped from atmospheric to ocean grid cells.

I am currently modifying the topography and bathymetry in my coupled simulation (based on the cpl_aim+ocn configuration), and I would like to generate a consistent runOffMapFile that reflects the updated geomorphology.
At the moment, I am simply mapping land points that are flagged as undrained (based on warnings in Coupler.0000.clog) to their nearest ocean points.

Could you kindly provide any recommendations or guidance on creating a new runOffMapFile? In particular:

・Is there a standard workflow or utility for generating the runoff mapping based on modified land-sea masks or topography?

・Are there any general guidelines or best practices for producing a valid and physically meaningful runOffMapFile?

Thank you again for your time and continued support.

Best regards,
Fisher



> Hi Fisher,
> 
> The way the "runOffMapFile" is set-up is not documented anywhere, so thanks for asking.
> It contains "runOffMapSize" records of float64 (real*8) vector of length 3 each.
> 
> Each record contains a connection between a land-point from where the run-off
> is collected and a river-mouth ocean-point where this run-off is discharged.
> 
> The 3 elements in a record are:
> - first one gives the location of the Atmospheric grid-cell from where the run-off comes from.
> - second ones gives the location of the Oceanic grid-cell from where the run-off is discharged.
> - third element is the catchment area (in m^2) within the atmospheric-grid cell
> that is routed to this river (cannot be larger that the atmospheric grid-cell area).
> 
> The way the location of the Atmospheric grid-cell is stored (first element) is
> from the grid-cell indices (i,j) in (Nx_atm,Ny_atm) array (in cpl_aim+ocn/code_cpl/ATMSIZE.h ),
> that is converted to a single integer: ijROatm = i + (j-1)Nx_atm
> and finally converted to a real8 (float64) value.
> 
> And similarly for the Oceanic grid-cell location, from its indices (i,j) in
> (Nx_ocn,Ny_ocn) array (in cpl_aim+ocn/code_cpl/OCNSIZE.h ), converted to
> single integer ijROocn = i + (j-1)*Nx_ocn, and then to float64.
> 
> The routine that read both this runOffMapFile is:
> pkg/atm_ocn_coupler/set_runoffmap.F
> it also read-in the oceanic grid-cell area from file "RA.bin" (also float64, size
> Nx_ocn x Ny_ocn), to scale the catchment area and compute the area fraction "arROmap"
> that is used later in the run-off mapping (at each coupling step) in this routine:
> pkg/atm_ocn_coupler/atm_to_ocn_maprunoff.F
> 
> And I believe a partial summary of this run-off mapping is reported to the log file
> of the coupler, with record number, ijROatm, ijROocn, arROmap, but only for first and
> last record, as a way to check.
> 
> Cheers,
> Jean-Michel
> 
> On Sun, Jan 05, 2025 at 09:38:28AM +0000, ht wrote:
> 
> > Hello,
> > 
> > I am currently working on a coupled simulation using the cpl_aim+ocn case from the verification directory. While modifying the bathymetry/topography files, I realized that the runOff file (default: runOff_cs32_3644.bin) also needs to be updated.
> > 
> > However, even after inspecting the file using MITgcmutils.utils.readbin, I couldn't fully understand the specific information it contains or the corresponding data types for each piece of information. Could you please clarify the following:
> > 
> > - What kind of data is stored in the runOff file?
> > - What are the data types used for this information (e.g., float32, float64)?
> > 
> > Understanding the structure and content of the file will greatly help me make the necessary adjustments.
> > 
> > Thank you for your time and assistance.
> > 
> > Best regards,
> > Fisher
> 



More information about the MITgcm-support mailing list