[yt-users] RFC: RAMSES field aliases in yt-3.0
Sam Geen
samgeen at astro.ox.ac.uk
Tue Nov 26 11:12:26 PST 2013
Yes, the user will always be able to change the "fields" keyword in
load() to override the defaults.
A user-defined default field vector sounds like something that needs
careful thought, since it's common to run simulations with and without
metals, MHD, etc, in the same project, in which case different field
arrays are needed in rapid succession. Of course, it's always possible
for users to create modules for themselves and add them to their
$PYTHONPATH, so in this case, I think the simplest solution would be to
write a module with something like the following:
myfields = ["blah1","blah2",...]
def myload(fileloc):
from yt.mods import load
return load(fileloc, fields=myfields)
then import that module to get a personal default loading interface.
On 26/11/13 19:52, Romain Teyssier wrote:
> I like Sam's suggestion (option a).
> Based on how many variables we have in the file, we propose a default
> variable name vector,
> like the ones proposed by Sam, but the user should always have the
> possibility to overwrite the default
> because he is the only one to really know which variables he used.
>
> One cool option would be for the user to be able define a default
> variable name vector himself.
>
> Cheers,
> Romain
>
>
> On 26 Nov 2013, at 16:44, Sam Geen <samgeen at astro.ox.ac.uk
> <mailto:samgeen at astro.ox.ac.uk>> 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
>>> 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/5d7a6778/attachment.html>
More information about the yt-users
mailing list