Quick question on "JULIAN" Calendar Type

[execlim]

Quick question on "JULIAN" Calendar Type

[RuthG]

I think in Exeter we are all running a 360-day calendar, or planets with a totally different calendar, and so haven't explored this issue - but it's a good point! From a quick look at the source code I think run length is just set in days, hours and seconds in main_nml and I can't see a quick option to change this, so the best bet is likely to do it via the python wrapper.
I don't know exactly how you configure your runs, here we usually run a month, output, run the next month etc. as per the examples in Isca/exp/. If you're using that approach and you want output files to contain single Julian calendar months or years, my suggestion would be to add a loop in the python runscript that alters the run length based on which year you are running using e.g. the isleap() or monthrange() methods from the calendar module.
So specifically, I'd set up the code to alter the value of days in main_nml based on the year and/or month being run.

If you do get something of that kind coded up, that could be a nice example to add to the codebank or a README somewhere.

Hope that helps!

[sit23]

I agree with @RuthG that there is not an obvious answer for this. One additional suggestion would be to, instead of running for 1 month at a time, run 4 years at a time. That way you'll get 3x 365 day and 1 x 366 day years in each file. Then you can split them up by year afterwards using something like cdo?

[natgeo-wong]

I could get an example coded up sometime during the summer (sorry swamped with deadlines over the next two weeks).

The reason why I'm asking though, is because I'm writing a Julia package IscaTools.jl that analyzes Isca output and uses calendar features to determine how to analyse the output (monthly, yearly averages when output is daily/sub-daily) and does some analysis and calculations.

I generally use the "NO_CALENDAR" option myself, generally because that's what I grew up with (in a modelling sense) with the GFDL version of FMS at Caltech.

[RuthG]

The analysis package sounds great!
And of course, no rush, thanks for doing that too. I think we've got a resolution here so I'll close this for now.