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
As part of the integration of the evp1d I have looked at ice grid and it leaves me with some questions and I think that we should discuss at a group meeting.
Example dxT valid for all deltas (dyT, dxU..) on individual grid faces
all grid lengths are based on HTE or HTN and a interpolation of these
Calculated on global domain.
Why?
j=1 is calculated based on the same curvature and uses j=2 and j=3. For cyclic domains this is wrong.
I would expand HTN and HTE to include the boundary/halo and then do a gather on this. From that I would calculate dxT where possible
(jlo to ny_block)-
For the boundary dxT uses j-1, within the code tarea is calculated from 1 to nx_block and 1 to ny_block
Is it really necessary to have the area calculated on the boundary. If yes then HTN and HTE needs a halo of 2 to calculate this.
Alternatively the boundary of tarea could be based on a halo
Only used in dynamics and in a few drivers. It should be considered which grid types (B,C,CD and 1d/2d) the variables are used.
We likely allocate way to much here.
If I should rewrite it then I would
Introduce the boundary conditions in HTE and HTN
gather HTE and HTN
Consider whether the grid type uses the particular delta. If not don't allocate nor calculate.
calculate the grid deltas on the distributed HTE and HTN where possible
Consider what to do in special cases (for dxT at j=jlo-nghost)
This requires that areas are not used on the boundary or that some solution is found for this.
In addition to this there are other variables in grid_ice that are not used, should probably be calculated where they are used....
The text was updated successfully, but these errors were encountered:
As part of the integration of the evp1d I have looked at ice grid and it leaves me with some questions and I think that we should discuss at a group meeting.
Example dxT valid for all deltas (dyT, dxU..) on individual grid faces
all grid lengths are based on HTE or HTN and a interpolation of these
Calculated on global domain.
Why?
j=1 is calculated based on the same curvature and uses j=2 and j=3. For cyclic domains this is wrong.
I would expand HTN and HTE to include the boundary/halo and then do a gather on this. From that I would calculate dxT where possible
(jlo to ny_block)-
For the boundary dxT uses j-1, within the code tarea is calculated from 1 to nx_block and 1 to ny_block
Is it really necessary to have the area calculated on the boundary. If yes then HTN and HTE needs a halo of 2 to calculate this.
Alternatively the boundary of tarea could be based on a halo
Only used in dynamics and in a few drivers. It should be considered which grid types (B,C,CD and 1d/2d) the variables are used.
We likely allocate way to much here.
If I should rewrite it then I would
Introduce the boundary conditions in HTE and HTN
gather HTE and HTN
Consider whether the grid type uses the particular delta. If not don't allocate nor calculate.
calculate the grid deltas on the distributed HTE and HTN where possible
Consider what to do in special cases (for dxT at j=jlo-nghost)
This requires that areas are not used on the boundary or that some solution is found for this.
In addition to this there are other variables in grid_ice that are not used, should probably be calculated where they are used....
The text was updated successfully, but these errors were encountered: