-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange output for timing results #248
Comments
That' s a hoot. Is it repeatable? I think we recently read that the timer starts
at some arbitrary point in time, and can have weird behavior like that. (RAndy ?)
More upsetting is huge cost of BC/ghost cells: 154 out of 300 seconds. Do you have
aux arrays? If so, try out the new "fasterfilpatch" branch. If not, what is causing this? Are you
running linear advection with no interior work per patch?
— Marsha
… On Jul 17, 2019, at 3:15 PM, Donna Calhoun ***@***.***> wrote:
I just did an AMRClaw run and noticed some strange timing results for the regridding time. I don't have a lot of insight into what might have happened, other than that I had set the regrid interval to 1 (regrid every time step) and the buffer region to 0. I've saved the data files and setrun.py file, as well as the example.
============================== Timing Data ==============================
Integration Time (stepgrid + BC + overhead)
Level Wall Time (seconds) CPU Time (seconds) Total Cell Updates
clock_rate 1000
1 62.787 62.664 0.492E+07
2 130.457 130.201 0.443E+08
3 107.296 107.045 0.379E+09
total 300.540 299.910 0.428E+09
All levels:
stepgrid 64.123 63.988
BC/ghost cells 154.562 154.231
Regridding -2146807.188 675.064
Output (valout) 28.806 28.371
Total time: -2146472.862 1008.295
Using 1 thread(s)
Note: The CPU times are summed over all threads.
Total time includes more than the subroutines listed above
Note: timings are also recorded for each output step
in the file timing.csv.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#248?email_source=notifications&email_token=AAGUGC3L3MDDFAA23WXPPN3P74LPFA5CNFSM4IEQHORKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G7XHBMQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGUGC2ZMFCVR5TPD6OCVRLP74LPFANCNFSM4IEQHORA>.
|
Looks like the same issue @rjleveque had. I am not sure that we ever came up with a way to fix it reliably. |
Well, I have 9 aux array variables, and yes the problem i just a scalar transport problem. |
fasterFilpatch will make a huge difference then.
Kyle - is it merged yet?
— Marsha
… On Jul 17, 2019, at 4:17 PM, Donna Calhoun ***@***.***> wrote:
Well, I have 9 aux array variables, and yes the problem i just a scalar transport problem.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#248?email_source=notifications&email_token=AAGUGC7RGXWWKUOYJVGHU43P74SXFA5CNFSM4IEQHORKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2ELCWY#issuecomment-512274779>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGUGCZNL7I4XZSLXSV6P5LP74SXFANCNFSM4IEQHORA>.
|
For AMRClaw it is. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I just did an AMRClaw run and noticed some strange timing results for the regridding time. I don't have a lot of insight into what might have happened, other than that I had set the regrid interval to 1 (regrid every time step) and the buffer region to 0. I've saved the data files and
setrun.py
file, as well as the example.The text was updated successfully, but these errors were encountered: