[WIP] [F32 Update] Fix for DelnFlux & DlenFluxNoSG#33
[WIP] [F32 Update] Fix for DelnFlux & DlenFluxNoSG#33FlorianDeconinck wants to merge 5 commits intoNOAA-GFDL:developfrom
Conversation
Use `np.power` to insure proper type casting of power op Verbose the half damp calculation
|
Though this work comes from the push to match GEOS @ f32 capacities, this should pass the f64 data set from FV3GFS and therefore be mergeable as-is. |
|
Hi, @FlorianDeconinck Is this primarily to address round-off global mass errors? |
|
This is to remap the calculation to Fortran so we narrow the difference at 32-bit. Though the calculation is mathematically similar, at 32-bit the negative mult of |
|
As always we have to follow the Fortran numerically up until we are confident our dynamics have reached feature parity so we can track any porting mistakes. With the introduction of the 32-bit float, we need to keep operations even closer than we did at 64-bit to be able to track numerical errors. The larger plan call for full scientific simulation that should build confidence further than the narrow translate test |
oelbert
left a comment
oelbert
left a comment
There was a problem hiding this comment.
I love floating point arithmetic...
pyFV3/stencils/delnflux.py
Outdated
| "identical data shape and dims" | ||
| ) | ||
| data = (damp_c.data * da_min) ** (nord.data + 1) | ||
| data = np.power((damp_c.data * da_min), (nord.data + 1), dtype=Float) |
There was a problem hiding this comment.
Should this get stencilized at some point?
There was a problem hiding this comment.
It could. It lives in the init so it probably why. But it's flimsy because we rely on the transparency of numpy & cupy to do CPU/GPU, something that will bite us sooner or later
oelbert
left a comment
oelbert
left a comment
There was a problem hiding this comment.
As long as what you say about the toolchain respecting order-of-operations this is good with me
| @gtscript.function | ||
| def fx_calculation_neg(q: FloatField, del6_v: FloatField): | ||
| return -del6_v * (q[-1, 0, 0] - q) | ||
| return del6_v * (q - q[-1, 0, 0]) |
|
This will be on hold until the GEOS-driven dynamics is stable |
|
What's the status of this? It looks like there are almost no differences anymore? |
FlorianDeconinck
changed the title
|
We just reached stability with 32-bit dycore. |
|
Closing this. There's an entire update to the dycore coming which is much bigger than this. |
4 participants
The Fortran calculate the negative flux by inverting the
qand offset-edqin the gradient calculation, while the original port ofpyFV3was using a negative u/v and the same gradient. This works at f64 but introduces errors at f32 for very small values advected.Clean up of a few differences with Fortran that don't necessarily fail now but could with other data.
E.g.:
np.powerto insure proper type casting of power opChecklist: