Hi All,
1) Re-calculate from scratch, using all the items in the parameter file that govern the cooling time. This will also allow it to work for non-Enzo simulation outputs. 2) Wrap the Enzo cooling time routines. This will require utilizing fortran/C interop, possibly with f2py. It also has a lot of moving parts. (These would be solved if some day there was some agreement on microphysical solver APIs.) This would work with non-Enzo datasets. 3) Mandate that if you want the cooling time in your profiles, you run with OutputCoolingTime=1 in Enzo. This would not work with non-Enzo datasets, unless they too had an option to output the local cooling time in every cell.
I was going to reply that I thought we should choose between #3 or #1 (or do it in that order), but now I think #3 is a safer bet. What comes to mind is if you're going to want to post-calculate cooling times, you're going to have to make sure you set up your simulation correctly. Does your cooling depend on metallicity, and which metallicity fields? Gotta save those. So while you're at it, might as well just go ahead and save cooling times, too. The only reason not to save a field if you're otherwise able is for storage concerns, but if you're doing something that big, you'll be clever enough to figure out a solution to this conundrum on your own. And for non-Enzo codes, how hard is it to add a new output field? That's a real question, by the way. -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)