search

JGCRI / hector

The Hector Simple Climate Model
http://jgcri.github.io/hector/
GNU General Public License v3.0
107 stars 45 forks source link

Investigate updating carbon-cycle timestep #195

Open cahartin opened 7 years ago

cahartin commented 7 years ago

Impulse response different with a smaller carbon-cycle solver @akschw04. @akschw04 can you add details on this?

akschw04 commented 7 years ago

In order for Hector-deoclim to successfully solve after a large [CO2] perturbation or step, I had to alter two timesteps: (1) the timestep in carbon-cycle-solver.cpp from dt(0.3) to dt(0.1) and (2) the ocean_component.hpp OCEAN_MIN_TIMESTEP from 0.3 to 0.01.

Changing these two timesteps also improved numerical noise in the atmosphere-ocean carbon flux response from various emissions perturbations in 2010, seen in the figure here.

image

rplzzz commented 7 years ago

Your problem isn't the size of your time steps. Your problem is that you've hard-wired the size of your time steps, and you're not estimating and controlling the error in the integration.

cahartin commented 6 years ago

@rplzzz it's currently hardcoded in Hector and Adria made the time step shorter. It would be useful to have Hector some how figure this out on it's own...

rplzzz commented 6 years ago

That's what I was getting at. I suspect this is a consequence of the separation between our components. We can't easily do an adaptive time step because the integrations are being done in separate components. I sketched out a way to do this a long time ago, but it involves some tricky programming in order to do it and still keep the components independent.

The next best thing would be to monitor the error in the integration and raise a warning if it gets outside of prescribed bounds.

bpbond commented 6 years ago

We can't easily do an adaptive time step because the integrations are being done in separate components

Right. The current method works around this, kind of, but in a duct-tape-and-string kind of way.