New issue 1100: [experimental] docstrings for all outward facing VR classes/functions
Docstrings for all outward facing functions and classes including a description, parameters, returned quantities, and an example in the docstrings.
right now, many examples are so trivial so as to not be helpful at all:
source = PointsSource(particle_positions)
examples would be better served to be a full VR with the appropriate method/class injected; probably 3-5lines each; then can be tested with docstring tests down the road too.
New issue 1099: [experimental] defaults for generating a simple VR
There should be a default filename for saving images. Default filename should be something descriptive, like ProjectionPlot or SlicePlot filenames default to.
In general kwargs with good defaults would be better for a variety of VR functions instead of requiring args.
New issue 1098: [experimental] enhanced documentation on `map_to_colormap` function
map_to_colormap function is not in the API docs.
map_to_colormap has a scale keyword, which could be more descriptive or have examples. what does it do? 30 gives good results, but 10 doesn't and the default: 1. renders a black screen. how does the user figure out what to use? even ballpark of what to use? change the defaults to be useful?
New issue 1097: [experimental] Default field for use in VR
When making a VR, it defaults to using the first field in the field_name list if a field is not specified, which almost never gives the desired result. Perhaps just default to ('gas', 'density') like the PW plots do? Implicitly assumed in examples (ie cookbook recipe: camera_movement.py)
New issue 1096: [experimental] Change `clip_ratio` to something more descriptive and set to default use
`clip_ratio` could be changed to something more descriptive (stddev_mask?), and should be defaulted to something like 4.0 since it is used almost everywhere to produce useful images. kwarg instead of arg
I'd like to extent my gratitude to Aaron Meurer, who just used his
StackOverflow not-so-fake internet points to create a "yt-project" tag on
StackOverflow. I'm now subscribed to this tag using a StackExchange filter (
http://stackexchange.com/filters), which e-mails me whenever someone makes
a question and tags it with yt-project.
I'm hopeful that if we get lots of questions up on StackOverflow, we can
significantly improve the googleability of answers to common yt issues.
Please feel free to ask and answer your own questions if you think it's
something that someone would search for.
We are increasingly developing sets of infrastructure (docker files, CI
scripts, etc) for developing, using and deploying yt. Where should we
catalog this info? Should we continue updating the infrastructure ytep, or
find a different/new place, perhaps auto-deployed? How can we increase
discoverability of this info?