[Yt-dev] HaloProfiler vs. enzo_anyl

[Matthew Turk]

Hi Stephen,

On Thu, Apr 14, 2011 at 12:01 PM, Stephen Skory <s at skory.us> wrote:
> 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.

I personally would say that a combination of #1 and #2, where we have
a regular API for microphysical solvers would be the ideal solution.
I think that, as John mentioned in IRC, it would also be nice to be
able to separate out individual lines and reactions to get sub-model
cooling info, too.

>
> And for non-Enzo codes, how hard is it to add a new output field?
> That's a real question, by the way.

I think it varies.  My recollection is that Orion/CASTRO/Maestro is
that it's pretty straightforward, but that FLASH has some challenges.
For ART and RAMSES I don't know.  I suspect it's more difficult for
those two codes, because my understanding is the the IO is very
tightly coupled to the internal data structures.

-Matt

>
>
> --
> Stephen Skory
> s at skory.us
> http://stephenskory.com/
> 510.621.3687 (google voice)
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>