simplest example should run really fast

[TomNicholas]

I'm running the roms_marble example on my mac and it's been running for a few minutes and still hasn't completed. I think the simplest example we have should run in literally seconds. It doesn't need to be scientifically interesting, it just needs to generate some data of the right dimensionality.

[TomNicholas]

I think it took about 7.5 minutes to run, which is like 7 minutes too long in my opinion. Can we reduce the resolution / physics / number of time steps?

[dafyddstephenson]

I think this is a discussion to be had internally - I think the test case should run for 30 seconds (and does), but the example case is for people to not just check out C-Star but to have the opportunity to explore realistic ROMS output. 7 minutes for a month-long quasi-realistic run of a complex ocean model on a laptop is pretty remarkably fast in the grand scheme of things. Perhaps we can just add a note to the top of the notebook telling the user to change the end date if they'd rather get less output more quickly.

[TomNicholas]

The ncjoin post_run step is also taking multiple minutes to run. It's been going for the past 10 minutes already.

I think this is a discussion to be had internally - I think the test case should run for 30 seconds (and does), but the example case is for people to not just check out C-Star but to have the opportunity to explore realistic ROMS output.

That's fair - I was thinking of it more as just running something with ROMS. At the very least we should be setting expectations of how long it's likely to take, and tell them how to make it really quick if they want, as you say.

[dafyddstephenson]

ncjoin in this case is I think running on about 350 variables (BGC tracers and diagnostics) when it was designed for <10. We can control which BGC variables the user gets pretty easily so we can ask which are CDR relevant and dump the rest for some easy savings there.