Hi Sam,
On Mon, Dec 2, 2013 at 5:24 PM, Sam Geen
Hi Matt,
I believe it's absolute metallicity (i.e. 0.02 = fiducial solar, 0.0 = primordial). If you're paranoid, you could check with Romain; I'll open up some outputs in the morning and confirm this.
BTW, I didn't get a chance to hunt down the pressure/temperature units problem today, but if you take a look then be aware that temperature in Ramses is returned (in the version I have, anyway) as T/mu, i.e. you need to multiply by the mean gas particle mass to get temperature in Kelvin. Normally for a given hydrogen mass fraction this is just X + 4*Y + (?) Z (I think! it's late here, so worth checking...), but for radiative transfer runs you need to be a bit careful since you also have electrons - we can look at this when the RT module output format is implemented, though.
Ah, thank you. That makes sense, and I'll apply these conversions for metallicity. For pressure, currently what we are doing is: def _Temperature(field, data): rv = data["Pressure"]/data["Density"] rv *= mass_hydrogen_cgs/boltzmann_constant_cgs return rv add_field("Temperature", function=_Temperature, units=r"\rm{K}") So it looks like that will need to be updated. I think this was set up on-demand from someone, and they compared it against their previous results, so I'm not sure where the discrepancy comes in. -Matt
Cheers,
Sam
On 02/12/13 22:02, Matthew Turk wrote:
Hi Sam,
What're the metallicity units for RAMSES? Nathan and I are updating for the yt-3.0 unit refactor and we're trying to get the RAMSES conversion done today.
-Matt
On Wed, Nov 27, 2013 at 12:23 PM, Sam Geen
wrote: Hi,
I intend to try to fiddle with the RAMSES frontend when I have time/need, and thought it would be good to collate a list of tasks that need to be completed so we have a consensus on what needs to be fixed. Feel free to suggest things or tell me that they're already implemented if I missed them:
1) Add support for RT and ATON files, which are now part of the default RAMSES (I assume from the code that the cooling and grav files are already read) 2) Via 1), it might be nice to refactor the RAMSESDomainFile class a bit to provide a more generic Ramses file reading routine/class, since the formats of the files are fairly similar and in doing 1) we might get some copy-paste bloat. 3) Allow for RAMSES runs that only contain AMR & particles (i.e. pure N-body runs with no hydro) 4) Refactor the inputs to fit YT default field names (for MHD, RT and ATON). 5) Allow YT to interpret non-cosmological simulations in RAMSES, or if it already does, remove the warning that says this. 6) Romain Teyssier suggested allowing users to specify their own default field names for user-modified versions of RAMSES. I don't know if YT caches data that would allow this, but I thought I'd punt the suggestion along. Another option could be to allow users to expose the RAMSES namelist files to YT (i.e. the parameter files for starting up a run) - these contain a lot more information on the physics included, etc. I'd put this on a low priority unless someone thinks of something clever that solves this cleanly. 7) It could be worthwhile to implement read-on-demand if it's not already - sometimes the users won't query the ATON/RT/hydro/particle file or certain fluid fields in each file and so we wouldn't need to read those files in that case. This could be folded into 2).
Cheers,
Sam _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org