Should we decouple download from regridding for bathymetry?

[navidcy]

At the moment, regrid_bathymetry

ClimaOcean.jl/src/Bathymetry.jl

Line 97 in 3819723

function regrid_bathymetry(target_grid;

both downloads the bathymetry dataset and regrids. Me and @taimoorsohail were envisioning something like where

ClimaOcean.jl/src/Bathymetry.jl

Lines 106 to 113 in 3819723

	filepath = joinpath(dir, filename)
	# No need for @root here, because only rank 0 accesses this function
	if !isfile(filepath)
	Downloads.download(url, filepath; progress=download_progress)
	end
	dataset = Dataset(filepath, "r")

are a separate download_bathymetry method.

[glwagner]

Why can't you just define

function download_bathymetry
 # No need for @root here, because only rank 0 accesses this function 
 if !isfile(filepath) 
     Downloads.download(url, filepath; progress=download_progress) 
 end
end 

and then call download_bathymetry inside regrid_bathymetry?

There is an old issue about improving the name of regrid_bathymetry too I think which has not been addressed.

[glwagner]

But if there is a reason to "enforce" a workflow, I am up for it. I like to think of software development as building out features that people can use for a variety of purposes, rather than enforcing a workflow. It's quite trivial to define a function download_bathymetry that would be useful, and we don't have to change any existing tests or examples. Not having to change tests or examples makes it something that might take just a few minutes to implement. Would you like me to implement it?

If we have some motivation to actually discontinue support for downloading bathymetry inside regrid_bathymetry though, we can do that. I don't see it right away, because regrid_bathymetry already checks for an existing file. So if you choose to call download_bathymetry prior to regrid_bathymetry, it seems like you have effectively achieved downloading and regridding in separate functions.