After #14 I think there might be an issue here because now both Oceananigans and XESMF define a regrid! method. I think ideally one should extends the other's method otherwise we have situations like:
julia> using Oceananigans
[ Info: Oceananigans will use 12 threads
julia> methods(regrid!)
# 2 methods for generic function "regrid!" from Oceananigans.Fields:
[1] regrid!(a, target_grid, source_grid, b)
@ ~/Library/CloudStorage/OneDrive-TheUniversityofMelbourne/Documents/Research/Oceananigans.jl-v4/src/Fields/regridding_fields.jl:112
[2] regrid!(dst_field, src_field)
@ ~/Library/CloudStorage/OneDrive-TheUniversityofMelbourne/Documents/Research/Oceananigans.jl-v4/src/Fields/regridding_fields.jl:48
julia> using XESMF: regrid!
[ Info: Precompiling OceananigansXESMFExt [94839fb3-6fd9-5496-8fe2-949f90a07c42]
WARNING: ignoring conflicting import of XESMF.regrid! into OceananigansXESMFExt
WARNING: ignoring conflicting import of XESMF.regrid! into Main
How should we proceed. I don't think we want XESMF to depend on Oceananigans. Should we drop the generic regrid! method and leave package extensions to define their own?
cc @simone-silvestri
After #14 I think there might be an issue here because now both Oceananigans and XESMF define a
regrid!method. I think ideally one should extends the other's method otherwise we have situations like:How should we proceed. I don't think we want XESMF to depend on Oceananigans. Should we drop the generic
regrid!method and leave package extensions to define their own?cc @simone-silvestri