[yt-users] RFC: RAMSES field aliases in yt-3.0
Sam Geen
samgeen at astro.ox.ac.uk
Tue Nov 26 10:01:32 PST 2013
OK, I'll try to implement that approach. The only risk is that in theory
it's possible to set NVAR to be too high without RAMSES complaining (for
example, if you run with MHD and then move back to hydro but forget to
set NVAR from 12 to 6), but I'll try to add a warning in any case.
On 26/11/13 18:58, nick moeckel wrote:
> I think option 'a' is good as well.
>
>
> On Tue, Nov 26, 2013 at 5:19 PM, Butler,Michael J
> <butler85 at astro.ufl.edu <mailto:butler85 at astro.ufl.edu>> wrote:
>
> I'd personally prefer option "a" as the default, with the option
> to manually specify fields if you aren't using one of the common
> setups like you mention.
>
> On Tue, 26 Nov 2013 16:44:33 +0100, Sam Geen wrote:
>
>> Quick question for RAMSES users - do you prefer:
>> a) YT figures out what variables are in the file from NVAR, e.g.
>> NVAR=5 gives density,vx,vy,vz,pressure, NVAR=6 adds metallicity,
>> NVAR=10/11 assumes MHD
>> b) YT assumes density,vx,vy,vz,pressure only *unless* you do:
>> load("mydata/info_blahblah.txt",metals=True)
>> (with similar flags for mhd, etc?)
>>
>> In all cases if you set "fields" as a parameter (as normal), YT
>> will use that, of course.
>>
>> For RT YT just has to find a info_rt_blahblah.txt file, so no
>> user input is needed. If anyone can give info on how RAMSES-ATON
>> outputs work, it would be appreciated.
>>
>> On 25/11/13 20:56, Nathan Goldbaum wrote:
>>> Just for completeness, the yt developer guide is here:
>>> http://yt-project.org/doc/developing/developing.html
>>>
>>>
>>> On Mon, Nov 25, 2013 at 11:38 AM, Matthew Turk
>>> <matthewturk at gmail.com <mailto:matthewturk at gmail.com>> wrote:
>>>
>>> Yup, there is, but stop by IRC if you run into trouble. It
>>> should be
>>> as easy as making sure your ~/.hgrc has your name/email in
>>> [ui], for
>>> instance:
>>>
>>> [ui]
>>> username = Matthew Turk <matthewturk at gmail.com
>>> <mailto:matthewturk at gmail.com>>
>>>
>>> then:
>>>
>>> cd /path/to/yt/hg/repo
>>>
>>> -edit edit edit-
>>> hg commit
>>>
>>> On the BitBucket site you can fork our repository (do not make a
>>> branch though!) here:
>>> https://bitbucket.org/yt_analysis/yt-3.0/fork
>>>
>>> and you can then just push to your repo:
>>>
>>> hg push -f http://bitbucket.org/SamsUserName/yt-3.0
>>>
>>> Then pull request away!
>>>
>>> -Matt
>>>
>>> On Mon, Nov 25, 2013 at 2:35 PM, Sam Geen
>>> <samgeen at astro.ox.ac.uk <mailto:samgeen at astro.ox.ac.uk>> wrote:
>>> > OK, will try to figure out all that tomorrow. I guess
>>> there's a guide to
>>> > issuing pull requests on the yt site?
>>> >
>>> >
>>> > On 25/11/13 20:30, Matthew Turk wrote:
>>> >>
>>> >> Hi Sam,
>>> >>
>>> >> This looks great. Any chance you could add this to the
>>> >> yt/frontends/ramses/definitions.py file as a function,
>>> issue a pull
>>> >> request, and we'll get your name in the commit log? I'll
>>> then modify
>>> >> it to fit in and we'll use it as fallback when fields are
>>> specified.
>>> >>
>>> >> -Matt
>>> >>
>>> >> On Mon, Nov 25, 2013 at 1:39 PM, Sam Geen
>>> <samgeen at astro.ox.ac.uk <mailto:samgeen at astro.ox.ac.uk>> wrote:
>>> >>>
>>> >>> I've hacked up a simple example of what I mean (attached).
>>> >>>
>>> >>>
>>> >>> On 25/11/13 17:50, Nathan Goldbaum wrote:
>>> >>>
>>> >>> Matt's opened a PR for this here:
>>> >>>
>>> >>>
>>> >>>
>>> https://bitbucket.org/yt_analysis/yt-3.0/pull-request/140/adding-field_aliases-to-ramses-datasets/diff
>>> >>>
>>> >>> Sam, if you could enumerate how to map from the boolean
>>> flags you're
>>> >>> suggesting to a final field list, I think that would
>>> help immensely.
>>> >>>
>>> >>>
>>> >>> On Mon, Nov 25, 2013 at 8:42 AM, Sam Geen
>>> <samgeen at astro.ox.ac.uk <mailto:samgeen at astro.ox.ac.uk>> wrote:
>>> >>>>
>>> >>>> Yes and no. NVAR must be big enough, but it can be
>>> bigger than necessary
>>> >>>> (I think); it's a Makefile setting when compiling
>>> Ramses. You can
>>> >>>> guarantee
>>> >>>> that the first 4 variables are the same, but after that
>>> I suspect the
>>> >>>> best
>>> >>>> approach is to use boolean flags to specify whether the
>>> run contains
>>> >>>> MHD,
>>> >>>> RHD, metals, etc. Normally it's a good guess that 5 is
>>> pressure and 6
>>> >>>> (if it
>>> >>>> exists) is metals, but as I said it seems like MHD puts
>>> the B-field
>>> >>>> before
>>> >>>> pressure and metallicity.
>>> >>>>
>>> >>>>
>>> >>>> On 25/11/13 17:36, Nathan Goldbaum wrote:
>>> >>>>
>>> >>>> Does that mean that it should be possible to infer the
>>> field list from
>>> >>>> NVAR alone?
>>> >>>>
>>> >>>>
>>> >>>> On Mon, Nov 25, 2013 at 8:29 AM, Sam Geen
>>> <samgeen at astro.ox.ac.uk <mailto:samgeen at astro.ox.ac.uk>>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> For MHD, the variables stored are the B-field
>>> strengths on the faces of
>>> >>>>> each cell - the fields in order are: (1) density,
>>> (2-4) [x,y,z]
>>> >>>>> velocity,
>>> >>>>> (5-7) [x,y,z] B-field left, (8-10) [x,y,z] B-field
>>> right, (11) pressure
>>> >>>>> (thermal + MHD), then (12+) any passive scalars
>>> (metals, etc) - see
>>> >>>>> mhd/output_hydro.f90. Note that the MHD module adds 3
>>> variables, so the
>>> >>>>> number of variables will be nvar+3.
>>> >>>>>
>>> >>>>> For RHD (Joki Rosdahl's M1 method implementation, at
>>> least - someone
>>> >>>>> else
>>> >>>>> will have to help with the ATON version), there is a
>>> separate "rt_"
>>> >>>>> output
>>> >>>>> file for each CPU (like the hydro/amr/particles), as
>>> well as a separate
>>> >>>>> info
>>> >>>>> file (there is a bitbucket link on the Ramses homepage
>>> if you want to
>>> >>>>> see
>>> >>>>> what the latest version of the code does in detail).
>>> The RHD module
>>> >>>>> divides
>>> >>>>> photons into "nGroups" different flux bins; for each
>>> bin, it writes a
>>> >>>>> photon
>>> >>>>> density and then a flux vector. nGroups is stored in
>>> the rt info file;
>>> >>>>> nrtvar is written to the rt_ binary file, but this is
>>> (I think) a
>>> >>>>> Makefile
>>> >>>>> setting and not guaranteed to be nGroups/(1+ndim) (the
>>> user is, I
>>> >>>>> believe,
>>> >>>>> normally free to waste memory by allocating more
>>> variables than they
>>> >>>>> need).
>>> >>>>> For details it might be easiest to download the latest
>>> code and look at
>>> >>>>> the
>>> >>>>> code in the folder rt/, or ask Romain or Joki Rosdahl
>>> directly.
>>> >>>>>
>>> >>>>> (Feel free to correct me if any of this is wrong!)
>>> >>>>>
>>> >>>>> I agree that setting the default to the standard five
>>> (perhaps some
>>> >>>>> boolean variables for common configurations such as
>>> metals, RHD, MHD,
>>> >>>>> etc)
>>> >>>>> and then letting users set or add their own fields by
>>> hand if they need
>>> >>>>> to
>>> >>>>> is a good approach.
>>> >>>>>
>>> >>>>>
>>> >>>>> On 25/11/13 16:23, Matthew Turk wrote:
>>> >>>>>>
>>> >>>>>> Hi all, especially RAMSES users,
>>> >>>>>>
>>> >>>>>> I'm setting up aliases to make it easier to load
>>> RAMSES datasets that
>>> >>>>>> have different field configurations.
>>> >>>>>>
>>> >>>>>> Right now, to specify a different set of fields, you
>>> have to do:
>>> >>>>>>
>>> >>>>>> pf = load( ... , fields = [ "Density", "x-velocity",
>>> ...])
>>> >>>>>>
>>> >>>>>> I am going to change this to add on different field
>>> configurations
>>> >>>>>> that can be specified with just a string. For instance:
>>> >>>>>>
>>> >>>>>> pf = load(..., fields = "standard_five")
>>> >>>>>>
>>> >>>>>> I'm wondering what the different configurations are.
>>> I have these
>>> >>>>>> two:
>>> >>>>>>
>>> >>>>>> standard_five: Density, x-velocity, y-velocity,
>>> z-velocity, Pressure
>>> >>>>>> standard_six: Density, x-velocity, y-velocity,
>>> z-velocity, Pressure,
>>> >>>>>> Metallicity
>>> >>>>>>
>>> >>>>>> But for MHD and RHD, what are the additional fields
>>> that should be
>>> >>>>>> added, and in what order? And are there other common
>>> configurations
>>> >>>>>> that should be aliased?
>>> >>>>>>
>>> >>>>>> If we can come up with a set of aliases that match
>>> most use cases,
>>> >>>>>> that'd work quite well. I'm going to issue a PR for
>>> this shortly, and
>>> >>>>>> hopefully it will make everybody's life a bit easier.
>>> >>>>>>
>>> >>>>>> -Matt
>>> >>>>>> _______________________________________________
>>> >>>>>> yt-users mailing list
>>> >>>>>> yt-users at lists.spacepope.org
>>> <mailto:yt-users at lists.spacepope.org>
>>> >>>>>>
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> >>>>>
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> yt-users mailing list
>>> >>>>> yt-users at lists.spacepope.org
>>> <mailto:yt-users at lists.spacepope.org>
>>> >>>>>
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> yt-users mailing list
>>> >>>> yt-users at lists.spacepope.org
>>> <mailto:yt-users at lists.spacepope.org>
>>> >>>>
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> yt-users mailing list
>>> >>>> yt-users at lists.spacepope.org
>>> <mailto:yt-users at lists.spacepope.org>
>>> >>>>
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> >>>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> yt-users mailing list
>>> >>> yt-users at lists.spacepope.org
>>> <mailto:yt-users at lists.spacepope.org>
>>> >>>
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> yt-users mailing list
>>> >>> yt-users at lists.spacepope.org
>>> <mailto:yt-users at lists.spacepope.org>
>>> >>>
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> >>>
>>> >> _______________________________________________
>>> >> yt-users mailing list
>>> >> yt-users at lists.spacepope.org
>>> <mailto:yt-users at lists.spacepope.org>
>>> >>
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> >
>>> >
>>> > _______________________________________________
>>> > yt-users mailing list
>>> > yt-users at lists.spacepope.org
>>> <mailto:yt-users at lists.spacepope.org>
>>> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org
>>> <mailto:yt-users at lists.spacepope.org>
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>>
>>>
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org <mailto:yt-users at lists.spacepope.org>
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org <mailto:yt-users at lists.spacepope.org>
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20131126/e57d62e6/attachment.htm>
More information about the yt-users
mailing list