Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Fix mechred arithmetic abort #167

Closed
apcraig opened this issue Feb 12, 2018 · 6 comments
Closed

Fix mechred arithmetic abort #167

apcraig opened this issue Feb 12, 2018 · 6 comments
Assignees

Comments

@apcraig
Copy link
Contributor

apcraig commented Feb 12, 2018

see #163

@apcraig apcraig self-assigned this Feb 12, 2018
@eclare108213
Copy link
Contributor

Try uncommenting lines 563, 564 in icedrv_step.F90. I never understood why we didn't get errors with this commented out. Then I forgot about it.

@apcraig
Copy link
Contributor Author

apcraig commented Feb 12, 2018

As an aside, there are lots of these messages written to the log file. Can we modify that or turn it off?

(ridge_ice)Repeat ridging, niter = 1

The logic is in subroutine ridge_ice,

     if (iterate_ridging) then
        write(warnstr,*) subname, 'Repeat ridging, niter =', niter
        call icepack_warnings_add(warnstr)
     else
        exit rdg_iteration
     endif

@eclare108213
Copy link
Contributor

eclare108213 commented Feb 12, 2018 via email

@apcraig
Copy link
Contributor Author

apcraig commented Feb 12, 2018

Just looking at the code, it must be iterating twice and writes that on the first iteration to log that it's going to a second iteration. It does not write when it has converged. Not sure if that is expected. Do you want any of that information to the log file? If so, what could be different?

@eclare108213
Copy link
Contributor

Unless it's a problem for space or computing time on travis, let's leave the 'Repeat ridging' warning alone for now. In my gx1 run, in only appears a few times. We could change it so that it only writes if niter > 1; that rarely happens unless there's a serious problem and the code crashes. The opening/closing data set is probably stressing the code a bit (which is good), and it's also not consistent with the other forcing. We can change this behavior later if it becomes too annoying. Or we can change it now if it's needed for travis.

@apcraig
Copy link
Contributor Author

apcraig commented Feb 12, 2018

@eclare108213 I'm happy with that approach.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants