extract code from print_cfl into dss_hvtensor routine #6723
Conversation
|
@tcclevenger I think this is ready |
|
@rljacob Currently trying to setup homme standalone tests to verify this fix. Will merge to next once I complete that. |
HOMME fortran init code refactor: important code hidden in print_cfl() is extracted into a new routine, dss_hvtensor. dss_hvtensor improves HV results by making the HV coefficients smooth accross elements. It also does a bilinear projection of the coefficients within each element to minimize oscillations in the tensor coefficieints. [BFB]
|
Merged to next |
|
I suspect this PR could be the reason for all the testing DIFFs. Reverting from next to investigate. |
|
one guess: keep the new routine in the original file, global_norms_mod.F90, so it will be compiled with the same optimization. |
Normalized errors seem to be too high for just optimization differences. I'm seeing them as large as 2e+1 in some cases. |
|
@tcclevenger Any new info? |
Not yet, I'm going to carve out time next week to solve this. |
|
@tcclevenger any update? |
Looked at this last week and it not obvious whats going wrong. I'm able to reproduce the error, hoping to have some time in the next week or two to figure it out. |
HOMME fortran init code refactor: important code hidden in print_cfl() is extracted into a new routine, dss_hvtensor dss_hvtensor improves HV results by making the HV coefficients smooth accross elements. It also does a bilinear projection of the coefficients within each element to minimize oscillations in the tensor coefficieints.
tcclevenger
force-pushed
the
dss_hvtensor
branch
from
16d4e1b to
5789dc2
Compare
|
@mt5555 You were correct, it was fixed by keeping the impl in the same file. Looking back through the CDASH from when I merged to next, it looks to be only intel compiler that triggered the bug. An example of DIFFs I saw in Should we be concerned about diffs this large just because of a file change? If not, I'll merge to next today and create a PR adding |
|
So for now - you put the routine back in the original file (but kept the modularization) and it's now BFB? Roundoff level changes (such as from optimization changes which can depend on the file) do grow exponentially. So by just looking at the numbers above, not possible to confirm if that is acceptable growth or not. Can we be lazy and just leave this routine in global_norms_mod.F90 (and rely on BFB testing)? If we really want to move it out of this routine, lets do a second PR that only moves the subroutine (so it will be obvious just from inspection that the change is roundoff and doesn't need more sophisticated testing). |
For sure, PM-CPU didn't report on cdash so may have to wait a day, but otherwise looks BFB. |
|
This was placed on next yesterday (with the wrong PR number in the commit title) and its causing testing fails on an odd assortment of cases. Maybe a threading error? cases: |
|
Reverted from next while I debug. |
|
Found a different error in a debugging case. 46: forrtl: severe (408): fort: (7): Attempt to use pointer DESC when it is not associated with a target cases: |
|
@mt5555 should also help since it his branch. |
HOMME fortran init code refactor: important code hidden in print_cfl() is extracted into a new routine, dss_hvtensor
dss_hvtensor improves HV results by making the HV coefficients smooth accross elements. It also does a bilinear projection of the coefficients within each element to minimize oscillations in the tensor coefficieints.
[BFB]