Skip to content
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

Bug fix for subroutine write_energy when DT<2 #749

Open
wants to merge 1 commit into
base: dev/gfdl
Choose a base branch
from

Conversation

herrwang0
Copy link

This PR fixes a bug with subroutine write_energy when using a DT<2.

Otherwise, the energy outputs could be written at wrong time steps with extremely small time stepping size.

The reason was that time type divide is essentially a floor. So in the line in question, dt_force/2 = 0 if dt_force<2. And energy is always written at the following time step, rather than when day==CS%write_energy_time.

The patch is a bit ugly.

  1. I believe both dt_force/2 and <= (rather than <) are necessary for round-off considerations.
  2. There is no real divide for time_type and a real number. (operator(//) is between time_type variables and operator(*) is for a time_type and an integer)

Fix a bug with subroutine write_energy when using a DT<2. Otherwise,
the energy outputs are written at wrong time steps.

The reason was that time type divide is essentially a floor.
So DT/2 = 0 if DT<2.
@Hallberg-NOAA
Copy link
Member

The time type allows for the use of sub-second time increments (ticks), which can be set during initialization via the FMS routine set_ticks_per_second() to allow for very short (sub-second) time steps, although it should be noted that unless set_ticks_per_second() has been called, there is one tick per second. Would the use of this capability be a better solution to this problem?

Also, please explain your comment that just changing elseif (day + (dt_force/2) <= CS%write_energy_time) then to elseif (day + (dt_force/2) < CS%write_energy_time) then would not suffice to fix this bug and do the right thing in (almost?) every case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants