You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm having problems running a global model with periodic boundary conditions in the E-W direction and "extrap" conditions in the N-S direction. I believe this has to do with how netcdf's are loaded here, b/c they are clipped to within a dx and dy buffer of the domain. This means there is no topography loaded that lies outside of the domain within the ghost cell portion.
This comes into play in setaux.f90. When setting for ghost cells, wrap_coords is called, which, as expected, wraps the E-W cells but does nothing to the N-S cells (since yperdom is false).
Then cellgridintegrate is called, which due to this line, raises an error that there is no topography overlapping that cell.
Does that sound like the right culprit (cc: @mandli@rjleveque)? I imagine the fix would be to increase the extent of the netcdf that gets loaded if you are in this situation.
The text was updated successfully, but these errors were encountered:
Makes sense to me. Periodic BCs are not used in GeoClaw except for planetary wide simulations and I am not sure we have used anything but the ESRI ASCII formats.
I'm having problems running a global model with periodic boundary conditions in the E-W direction and "extrap" conditions in the N-S direction. I believe this has to do with how netcdf's are loaded here, b/c they are clipped to within a
dx
anddy
buffer of the domain. This means there is no topography loaded that lies outside of the domain within the ghost cell portion.This comes into play in setaux.f90. When setting for ghost cells,
wrap_coords
is called, which, as expected, wraps the E-W cells but does nothing to the N-S cells (sinceyperdom
is false).Then
cellgridintegrate
is called, which due to this line, raises an error that there is no topography overlapping that cell.Does that sound like the right culprit (cc: @mandli @rjleveque)? I imagine the fix would be to increase the extent of the netcdf that gets loaded if you are in this situation.
The text was updated successfully, but these errors were encountered: