[Yt-dev] HaloProfiler vs. enzo_anyl

[Stephen Skory]

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 at skory.us
http://stephenskory.com/
510.621.3687 (google voice)