Git Product home page Git Product logo

yt's Introduction

The yt Project

PyPI Supported Python Versions Latest Documentation Users' Mailing List Devel Mailing List Data Hub Powered by NumFOCUS Sponsor our Project

Build and Test CI (bleeding edge) pre-commit.ci status Ruff

yt is an open-source, permissively-licensed Python library for analyzing and visualizing volumetric data.

yt supports structured, variable-resolution meshes, unstructured meshes, and discrete or sampled data such as particles. Focused on driving physically-meaningful inquiry, yt has been applied in domains such as astrophysics, seismology, nuclear engineering, molecular dynamics, and oceanography. Composed of a friendly community of users and developers, we want to make it easy to use and develop - we'd love it if you got involved!

We've written a method paper you may be interested in; if you use yt in the preparation of a publication, please consider citing it.

Code of Conduct

yt abides by a code of conduct partially modified from the PSF code of conduct, and is found in our contributing guide.

Installation

You can install the most recent stable version of yt either with conda from conda-forge:

conda install -c conda-forge yt

or with pip:

python -m pip install yt

More information on the various ways to install yt, and in particular to install from source, can be found on the project's website.

Getting Started

yt is designed to provide meaningful analysis of data. We have some Quickstart example notebooks in the repository:

If you'd like to try these online, you can visit our yt Hub and run a notebook next to some of our example data.

Contributing

We love contributions! yt is open source, built on open source, and we'd love to have you hang out in our community.

We have developed some guidelines for contributing to yt.

Imposter syndrome disclaimer: We want your help. No, really.

There may be a little voice inside your head that is telling you that you're not ready to be an open source contributor; that your skills aren't nearly good enough to contribute. What could you possibly offer a project like this one?

We assure you - the little voice in your head is wrong. If you can write code at all, you can contribute code to open source. Contributing to open source projects is a fantastic way to advance one's coding skills. Writing perfect code isn't the measure of a good developer (that would disqualify all of us!); it's trying to create something, making mistakes, and learning from those mistakes. That's how we all improve, and we are happy to help others learn.

Being an open source contributor doesn't just mean writing code, either. You can help out by writing documentation, tests, or even giving feedback about the project (and yes - that includes giving feedback about the contribution process). Some of these contributions may be the most valuable to the project as a whole, because you're coming to the project with fresh eyes, so you can see the errors and assumptions that seasoned contributors have glossed over.

(This disclaimer was originally written by Adrienne Lowe for a PyCon talk, and was adapted by yt based on its use in the README file for the MetPy project)

Resources

We have some community and documentation resources available.

Is your code compatible with yt ? Great ! Please consider giving us a shoutout as a shiny badge in your README

  • markdown
[![yt-project](https://img.shields.io/static/v1?label="works%20with"&message="yt"&color="blueviolet")](https://yt-project.org)
  • rst
|yt-project|

.. |yt-project| image:: https://img.shields.io/static/v1?label="works%20with"&message="yt"&color="blueviolet"
   :target: https://yt-project.org

Powered by NumFOCUS

yt is a fiscally sponsored project of NumFOCUS. If you're interested in supporting the active maintenance and development of this project, consider donating to the project.

yt's People

Contributors

ashkelly avatar atmyers avatar bitjockey42 avatar brittonsmith avatar c0nsultant avatar caseywstark avatar chrishavlin avatar chummels avatar cmsquared avatar cphyc avatar git-abhishek avatar jisuoqing avatar jsoishi avatar juxtaposicion avatar jwise77 avatar jzuhone avatar langmm avatar lindsayad avatar matthewturk avatar migueldvb avatar mtryan83 avatar munkm avatar neutrinoceros avatar pre-commit-ci[bot] avatar qobilidop avatar ricardabeckmann avatar samskillman avatar stephenskory avatar xarthisius avatar zingale avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

yt's Issues

Legends between engines are inconsistent

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Legends between engines are inconsistent
  • Component: lagos
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: duplicate
  • Status: closed
  • Created: 1184305563000000
  • Description: Legends used for fields between systems are inconsistent.

I believe the best way forward is to abstract the fields from the data. Call a function to initialize a new field, rather than simply adding it to lagos.fieldInfo -- that way a more sane default-generator can be used, and things like LaTeX representations can be used as appropriate.

This will break stuff, but I believe the only person using their own derived fields is Fen.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184384534000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184384534000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: duplicate

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184384534000000
  • Field: comment
  • Oldvalue: description.1
  • Newvalue: This is being moved into ticket #9.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185654033000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: First Public Release (0.2)

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185654033000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

Failure in non-intuitive way if hierarchy is of length zero

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Failure in non-intuitive way if hierarchy is of length zero
  • Component: lagos
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1197066719000000
  • Description: The code fails with some reference to an undefined variable if the hierarchy is of length zero. An exception should be raised.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1207954703000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1207954703000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1207954703000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: This was fixed some time ago, it seems.

Hierarchy caching

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Hierarchy caching
  • Component: lagos
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1185462249000000
  • Description: Takes too long to read the hierarchy for large files. More information about it -- child grids, for instance -- needs to be cached.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185462262000000
  • Field: component
  • Oldvalue: deliverator
  • Newvalue: lagos

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185462262000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185655358000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: First Public Release (0.2)

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185655358000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413082000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413082000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413082000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: Okay, I've done this, but it doesn't seem to help.

Deliverator ugliness

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Deliverator ugliness
  • Component: deliverator
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1185649630000000
  • Description: The Deliverator web page is hideous. This needs to be fixed.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185653916000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: Public Release

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185653916000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186247687000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186247687000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186247687000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

Y coordinates reversed in reason

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Y coordinates reversed in reason
  • Component: reason
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1197315316000000
  • Description: The y-coordinates in reason are reversed as a result of fixing the 'origin' problem in the matplotlib backend.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197938226000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197938226000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197938226000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

Phase plots and vm plots need to share common ancestor past wx.panel

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Phase plots and vm plots need to share common ancestor past wx.panel
  • Component: reason
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1190160966000000
  • Description: Following [http://en.wikipedia.org/wiki/Don't_repeat_yourself DRY], we need to refactor and get the pickers, etc, working such that we have consistent functionality across plot types.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190845051000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190845051000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190845051000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

Licensing situation is unclear

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Licensing situation is unclear

  • Component: documentation

  • Milestone: 0.2

  • Reporter: mturk

  • Owner: mturk

  • **Resolution: fixed

  • Status: closed

  • Created: 1185653877000000

  • Description: yt has been cleared to be released as a GPL'd program. It's time to move on this.

  • Read the GPL FAQ and howto

  • Add license to top of each software component

  • Add license to archive

  • Submit to CheeseShop

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185653886000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185653886000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188188257000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188188257000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188188257000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

Auto-detect data format

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Auto-detect data format
  • Component: lagos
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1186946987000000
  • Description:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186947005000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186947005000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186947005000000
  • Field: type
  • Oldvalue: defect
  • Newvalue: enhancement

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186947005000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

arraytypes.py is a bit byzantine

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: arraytypes.py is a bit byzantine
  • Component: yt
  • Milestone:
  • Reporter: joishi
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1197048248000000
  • Description: why is numpy imported as na '''and''' obj? this is very confusing, especially for new users. in lagos, references to nT, na, and obj are scattered throughout. i assume this was to support some kind of easy switching between numpy and numarray, but it seems to me that the days of support for both are past. if we eliminate any trace of numarray, will nT still be necessary?

given Matt's comment in the header of arraytypes.py, perhaps this should be re-factored sooner rather than later?

=== Update to Ticket ===

  • Author: joishi
  • Changetime: 1197048654000000
  • Field: owner
  • Oldvalue: mturk
  • Newvalue: joishi

=== Update to Ticket ===

  • Author: joishi
  • Changetime: 1197048654000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: joishi

  • Changetime: 1197051576000000

  • Field: comment

  • Oldvalue: 2

  • Newvalue: i did a quick grep for "obj\." in the yt src tree. doesn't look like there are too many places to replace it if we want to.

    [joishi@skronk src]$ ls
    init.py config.py enki funcs.py logger.py raven setup.py
    arraytypes.py deliverator fido lagos progressbar.py reason setup.pyc
    [joishi@skronk src]$ grep "obj\." */*py
    lagos/EnzoRunType.py: self.outputs = obj.array(outputs) # Object array of EnzoHierarchies
    lagos/EnzoRunType.py: self.outputs = obj.array(self.outputs.tolist() + hierarchy)
    lagos/EnzoRunType.py: newOutputs = obj.array(self.outputs[:id].tolist() + self.outputs[id+1:].tolist())
    lagos/EnzoRunType.py: newTimesteps = obj.array(self.timesteps[:id].tolist() + self.timesteps[id+1:].tolist())
    lagos/HierarchyType.py: self.grids = obj.array([self.grid(i+1) for i in xrange(self.numGrids)])
    [joishi@skronk src]$ grep "obj\." //py
    deliverator/deliverator/json.py:# return [obj.val1, obj.val2]
    deliverator/deliverator/json.py: result["users"] = [u.user_name for u in obj.users]
    deliverator/deliverator/json.py: result["permissions"] = [p.permission_name for p in obj.permissions]
    deliverator/deliverator/json.py: result["groups"] = [g.group_name for g in obj.groups]
    deliverator/deliverator/json.py: result["permissions"] = [p.permission_name for p in obj.permissions]
    deliverator/deliverator/json.py: result["groups"] = [g.group_name for g in obj.groups]
    [joishi@skronk src]$ grep "obj\." //
    /*py
    deliverator/deliverator/tests/test_model.py:# assert obj.display_name == "Mr Creosote"

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197059195000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197059195000000
  • Field: owner
  • Oldvalue: joishi
  • Newvalue: mturk

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197059195000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: I have started fixing this in the unstable branch. (obj, for instance, should be completely eradicated.) I completely agree, arraytypes should largely be done away with, and any functions that actually do serve a purpose should be tossed into funcs.py.

The unstable branch will be moved over to the trunk early next week, since I have tagged release-0.2.1.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197178721000000
  • Field: comment
  • Oldvalue: 4
  • Newvalue: Corrected in branches/unstable-0.3, will close when unstable-0.3 becomes trunk next week.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197938247000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197938247000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197938247000000
  • Field: comment
  • Oldvalue: 5
  • Newvalue:

Radial profiles should be objects, and EnzoSphere should not simply return an AnalyzeClusterFile

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Radial profiles should be objects, and EnzoSphere should not simply return an AnalyzeClusterFile
  • Component: lagos
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: duplicate
  • Status: closed
  • Created: 1190327213000000
  • Description: We should have EnzoSphere.cluster() return a profile object, which can then do transparent data access up the tree, like we like to do.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341650000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341650000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: duplicate

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341650000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Duplicate of #37

Plugin system for derived fields

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Plugin system for derived fields
  • Component: lagos
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1196297220000000
  • Description: A user should be able to create:

~/.yt/custom_fields.py

and have those fields then be available to him inside his session.

If we ignore the possibility of malicious code, this would be simple. Do we want to do that?

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196297230000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196297230000000
  • Field: type
  • Oldvalue: defect
  • Newvalue: enhancement

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196297230000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358122000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358122000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1198899951000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1198899951000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1198899951000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: Added in r345.

No examples for fido

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: No examples for fido
  • Component: fido
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: wontfix
  • Status: closed
  • Created: 1184302199000000
  • Description: There are no examples for fido usage!

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185648787000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185648787000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185653940000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: Public Release

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185653940000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189203243000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189203243000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: wontfix

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189203243000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: These should go on the wiki. And with the advent of the --help options, this is probably not even necessary.

Rewrite SWIG interface for PyHDF

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Rewrite SWIG interface for PyHDF
  • Component: yt
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: wontfix
  • Status: closed
  • Created: 1189203175000000
  • Description: Right now, pyhdf_np is a modified version of pyhdf, but modified =after= the SWIG-wrapper has been generated. This should be changed, such that it is in fact a Numpyified SWIG utility.

Assuming we have a version 1.0 release, I do not foresee HDF4 being supported past 1.0. So this ticket may ultimately be resolved as "dontfix."

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296763000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296763000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: wontfix

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296763000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: I have decreed that the support of HDF4 will not be worked on. It's already as good as it's going to get.

Spatial derivatives in DerivedFields

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Spatial derivatives in DerivedFields
  • Component: lagos
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1189196837000000
  • Description: Spatial derivatives are a must. This will require a combination of two things --
  1. Clever addressing via slices of the grid data coordinates.
  2. Creation of ghost zones.

Copying the ActiveDimensions into a separate array should be avoided, but may be difficult to avoid. Maybe a two-step process - one for the inner region, where the stencil doesn't need ghostzones, and then a set of operations for each face, including GZs?

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189196844000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189196844000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296851000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: This works now, and will be committed.

However, it is part of a larger rewrite. I am leaving this open, but noting the change here. (I will close when it is committed and works.)

The method used is to create a dupe DataCube that includes the ghost zones, grabbed from the surrounding grids.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358026000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: Committed, so closing.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358047000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358047000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358047000000
  • Field: comment
  • Oldvalue: 4
  • Newvalue:

EnzoDerivedFields is highly unflexible

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: EnzoDerivedFields is highly unflexible

  • Component: lagos

  • Milestone: 1.0

  • Reporter: mturk

  • Owner: mturk

  • **Resolution: fixed

  • Status: closed

  • Created: 1184383465000000

  • Description: EnzoDerivedFields needs to be rewritten from an OO standpoint.

  • Set up some basic class system, accepting function calls as arguments, and then query the class for more information.

  • Rework GenerateField to allow for more information.

  • Include both initialization and clean-up routines, so that memory usage can be reduced, and thus allow for fallback without doubling-tripling-etc memory needs.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184384457000000
  • Field: comment
  • Oldvalue: description.1
  • Newvalue: Okay, we need the following pieces of information about every field:
  1. Do we log the field?
  2. What are the natural units in CGS?
  3. How do we convert it to CGS?
  4. What are the units of the field when projected?

Do we also want to create a class for holding all of the data? Right now, it's all stored in dictionaries. Maybe this is unwise -- if we had a special class, we could call dataContainer.cleanUp() and have it wipe out all of the fields not explicitly requested.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185378803000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: EnzoDerivedQuantities is a potential replacement. Similar in methodology, in that we would populate a dictionary with fields, and then they would return functions that we would call.

Also, something needs to be done about the namespace pollution that goes on with EnzoDerivedFields. I don't think we need to import any more than fieldInfo.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413554000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413554000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188334750000000
  • Field: type
  • Oldvalue: defect
  • Newvalue: enhancement

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188334750000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188334750000000
  • Field: comment
  • Oldvalue: 4
  • Newvalue: Here's what I propose.

We define a function (not a decorator) to process each of the functions, and hand it over to fieldInfo. (We will for now simply include inside fieldInfo a Field object, which will issue deprecation warnings whenever [0],[1],etc are called.)

This object will address the following issues:

  • Field requirements (this should process all the way down the tree until we get to HDF fields)
  • Data object requirements - specifically, checking that we have a Sphere or a Grid object if we need it. If we don't, then we'll throw a FieldError or something.
  • Dealing with logging and not logging, and providing appropriate names and whatnot.

Additionally, we should have fieldInfo be a subclass of dict, which will process all the appropriate calls to the field, and taking care of thigns like _Abs and _Squared and the various vector components.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196297116000000
  • Field: comment
  • Oldvalue: 5
  • Newvalue: This is almost done, and documentation will follow. Each field is now an instance of DerivedField, and has all the necessary properties, including validators and the ability to only grab the fields needed and allow the rest to simply die. (Rather than assignment, these now use return values. This is the correct way, and how it should have been from the start.)

Additionally, CGS is enforced everywhere. Conversion to other units is a very simple exercise, because we no longer store unnecessary fields.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358074000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358074000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358074000000
  • Field: comment
  • Oldvalue: 6
  • Newvalue:

Refactor BaseDataTypes

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Refactor BaseDataTypes
  • Component: lagos
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1189577309000000
  • Description: BaseDataTypes needs to be refactored. Much of the code is duplicated between types, and can be safely combined into a single one. For instance, getting the data for Spheres and Regions could be made the same with the simple addition of a findRelevantGrids function.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296889000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296889000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296889000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Done. And updated to PEP-8. Will be committed as part of a large, atomic commit that moves us a substantial way toward 0.3.

Unit tests for everything

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Unit tests for everything
  • Component: yt
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1189202989000000
  • Description: This consists of a couple steps:
  1. Packaging sample data in acceptable way. (I have a dataset picked out; it is small enough to be easy to pass around -- 60mb or so -- but big enough to showcase some issues.)

  2. Deciding on an appropriate way to test more advanced derived quantities. Radial profiles could be easy; some kind of checksum on the data, and projections similarly so, but the issue comes in with the plotting packages.

  3. Writing unit tests.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189203194000000
  • Field: milestone
  • Oldvalue: First Public Release (0.2)
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189203194000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190134256000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190134256000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: Raven and Lagos are getting some coverage in SVN.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1207955473000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1207955473000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1207955473000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: I am closing this and instead opening two new tickets, for Lagos and Raven.

ia64 and x86_64 have different behaviors

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: ia64 and x86_64 have different behaviors
  • Component: lagos
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1184383106000000
  • Description: r4 & r8 slicing and plotting does not give identical results on x86_64 and ia64 platforms.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184878952000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184878952000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184878952000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Fixed on orange. r8 works. r4 is not a target precision at this time.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185654038000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: First Public Release (0.2)

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185654038000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

Matplotlib accessibility

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Matplotlib accessibility
  • Component: raven
  • Milestone: None
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: worksforme
  • Status: closed
  • Created: 1184383220000000
  • Description: The plots and figures and axes need to be more accessible, and thus more easily modified with python code.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185380498000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Also, we need to allow for generic plotting of phase diagrams with arbitrary weighting. (This is a type of plot specific to our needs.) This would enable us to modify fields, etc, after obtaining them, and then tossing them to the plotter. Could be useful for EnzoDerivedQuantities.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413537000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413537000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190161114000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190161114000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: worksforme

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190161114000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: I think this is now done with the combination of two and three phase plots.

Passing in spheres is now accessible, as well, so that is also done.


Remove Enzo-specific names

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Remove Enzo-specific names
  • Component: yt
  • Milestone: 2.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1196955036000000
  • Description: EnzoSlice, EnzoProjection, etc -- those all need to go. Replace with AMRSlice, AMRProjection and so forth.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341448000000
  • Field: milestone
  • Oldvalue: Version 0.3
  • Newvalue: Version 0.4

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341448000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: This will also coincide with setting up a template to import any rectilinear, patch-based AMR data, which I am calling 0.4.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1214441129000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1214441129000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1214441129000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: done in the [source:branches/yt-generalization] branch.

EnzoRegion does not work

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: EnzoRegion does not work
  • Component: lagos
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1186071846000000
  • Description: EnzoRegion does not work, as clearly shown by Ji-hoon.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413558000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413558000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189577090000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189577090000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189577090000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

Documentation Needs

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Documentation Needs
  • Component: documentation
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1189807133000000
  • Description: * Installation instructions
  • Configuration options
  • Fido usage (not useful for non-HDF4 users, as of present)
  • Reason keystrokes

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190234102000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Also need to fix up the HowTo. I think I want it to be set up with each section being its own sub-page of HowTo (i.e. HowTo/FidoPlotting) and then use the include macro to make them all into one big HowTo page.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190847338000000
  • Field: milestone
  • Oldvalue: First Public Release (0.2)
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190847338000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: Everybody so far has not had too much of a problem figuring it out; so I'm de-prioritizing this, and releasing a tarball of 0.2.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1199495030000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1199495030000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1199495030000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: The Howto is being replaced by a demo.html file in doc/ . This is under active development, but already contains a significant amount of information. Additionally, it runs under Crunchy.

OSX widgets and GTK widgets behave differently

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: OSX widgets and GTK widgets behave differently
  • Component: reason
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1190160095000000
  • Description: The unit selection on GTK gets confused on initialization, defaulting to rsunh. (The last item.)

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190183997000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: This has been fixed by manually setting it to be the first entry.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190184003000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190184003000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190184003000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

Unicode in wxPython

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Unicode in wxPython
  • Component: reason
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1196728053000000
  • Description: So it turns out that wxPython passes around Unicode objects, if you do not explicitly disable unicode. (Which I did not enable when I first installed it.) This conflicts with tests of StringType, which I should be fixing anyway.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1198729169000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1198729169000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1198729169000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Fixed a while ago...

Internally-generated profiles should be objects of their own merit

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Internally-generated profiles should be objects of their own merit
  • Component: lagos
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1190168054000000
  • Description: EnzoSphere.makeProfile should go away. Instead we should be returning an EnzoProfile object, which will do the automatic and transparent data-getting that works so well in EnzoSphere. These could then be included in Reason.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197764340000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197764340000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197764340000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Committed in r322 .

Parallelize projections

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Parallelize projections
  • Component: lagos
  • Milestone: 1.5
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1189222335000000
  • Description: Projections could be done in parallel.

Here are a couple ideas I have for how to do this.

  • Via IPython

    1. Instantiate hierarchy on each processor
    2. Tell each processor to launch a projection job, subdividing hierarchy into chunks, with each processor getting only whole, undivided grids.
    3. Call the combination and refinement procedures on the final set of data. (This should work, because of the logical masks we track at each stage.)
  • Via Forking (for SMP)

    1. Fork at the appropriate place, just before projection.
    2. Project.
    3. At conclusion, communicate via sockets, or alternatively, via PID id'd pytables files.
  • Via Threading

    • Right now, not sure it'll work. GIL and all. NumPy extensions (and weave extensions) can release the GIL, but this is probably not effective, as the data I/O really kills us.
  • Via NetWorkSpaces

    • Same as above with IPython, but with different (more complex?) dependency. Avoid pickling and transmitting pickled data; assume access to same filesystem.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196955073000000
  • Field: priority
  • Oldvalue: major
  • Newvalue: minor

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196955073000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196955073000000
  • Field: type
  • Oldvalue: defect
  • Newvalue: enhancement

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196955073000000
  • Field: milestone
  • Oldvalue: Version 0.3
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196955073000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197342048000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: Version 0.4

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197342048000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197342303000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: Point of interest -- data I/O in most applications is going to benefit from threading, as python uses green threads, and they are supposed to release the GIL during read-from-disk.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197766021000000
  • Field: comment
  • Oldvalue: 4
  • Newvalue: Having thought about this a bit more, I have come to a conclusion. What we really want to do here is have EnzoProjection accept a GridCollection-style object which defines several pieces of information about the grids, and then simply pass different grid collection objects -- decided in whatever manner -- to different processors.

So the obvious first starting point is to pull out all of the hierarchy queries inside the projection class, and put corresponding information back into the GridCollection object, or, even better, into the Enzo3DData object. Then we'll simply transform EnzoProjection from working on a hierarchy to working on a collection of objects, and as long as the data protocol works identically, we'll have all the information we need to project small quantities of data.

So we could dispatch decomposed portions of the dataset to different processors, and then have a collection at the end of each stage on the head node. (Or even some kind of round-robin collection, although perhaps a binary-collapse would be best.)

Note that we can retain the full-domain projection by having hierarchies export the same data that a grid collection would, or even by creating an empty grid collection for every projection. (Make hierarchy.slice into a method rather than a class instantiation.)

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1198308863000000
  • Field: comment
  • Oldvalue: 5
  • Newvalue: Using mpi4py on 16 nodes on the orange cluster, projections of the lightcone datadump take ~550 seconds. Further speedups should be expected. Currently there is some artifacting at the region boundaries; this is probably due to a bug, hopefully subtle, somewhere in the code. The 550 seconds figure includes all instantiation of the hierarchy -- which can perhaps be sped up.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1200682297000000
  • Field: milestone
  • Oldvalue: Version 0.4
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1200682297000000
  • Field: comment
  • Oldvalue: 6
  • Newvalue: Changing to version 0.3, because it works, and all we need is a nice interface for it.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1212162191000000
  • Field: milestone
  • Oldvalue: 0.3
  • Newvalue: 0.4

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1212162191000000
  • Field: comment
  • Oldvalue: 7
  • Newvalue: Wanted to, but can't. Will probably occur shortly after I push on toward 0.4.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1216142400000000
  • Field: milestone
  • Oldvalue: 2.0
  • Newvalue: 1.5

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1216142400000000
  • Field: comment
  • Oldvalue: 8
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk

  • Changetime: 1218210142000000

  • Field: comment

  • Oldvalue: 9

  • Newvalue: Okay, something like the following:

    #!python
    cc = MPI.Compute_dims(MPI.WORLD_SIZE, 2)

    mi = MPI.WORLD_RANK
    cx, cy = na.unravel_index(mi, cc)
    x = na.mgrid[0:1:(cc[0]+1)*1j][cx:cx+2]
    y = na.mgrid[0:1:(cc[1]+1)*1j][cy:cy+2]

    LE = na.array([0.0, x[0], y[0]])
    RE = na.array([1.0, x[1], y[1]])

    reg = pf.h.region((RE-LE)/2.0, LE, RE)

but not necessarily identical to that would work inside the projection initializer. Then we'd want to call a finalizer, which maybe we should be doing anyway, and then use that to scatter the arrays back.

This should preserve the adaptive nature of the projections. Fixed-resolution projections work as is in the parallel profiles.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1221660456000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1221660456000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1221660456000000
  • Field: comment
  • Oldvalue: 10
  • Newvalue: Done and merged back from the parallel_profiles branch in r782.

VMPlot references but does not define autoset_label()

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: VMPlot references but does not define autoset_label()
  • Component: raven
  • Milestone:
  • Reporter: joishi
  • Owner: joishi
  • **Resolution: fixed
  • Status: closed
  • Created: 1196875099000000
  • Description: not quite sure if this is a bug, but it seems like it might be:

in VMPlot, redraw_image() runs self.autoset_label(), but does not define it, nor is it inherited from RavenPlot. It is defined in all functions that derive from VMPlot, but if one were to write a new class and forgot it, it would error.

the fix would be to do

def autoset_label()
   pass

in VMPlot. i suppose this is trivial, but it could be a headache later.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196875409000000
  • Field: owner
  • Oldvalue: mturk
  • Newvalue: joishi

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196875409000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: joishi
  • Changetime: 1196954266000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: joishi
  • Changetime: 1196954266000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: joishi
  • Changetime: 1196954266000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

Get rid of some extensions

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Get rid of some extensions

  • Component: yt

  • Milestone: 1.0

  • Reporter: mturk

  • Owner: mturk

  • **Resolution: fixed

  • Status: closed

  • Created: 1189204290000000

  • Description: There are a couple C extensions in the codebase:

  • combination of projected points within a level

  • combination of projected points across a level

  • binning of values for radial profiles

  • interpolation for rates

  • pixelization for plotting in matplotlib

I believe that only the binning should be moved. The interpolation needs to stay, as the appropriate method of moving it would be to instead utilize a scipy package, but we actually want to stay as close to enzo as possible. Any other interpolation needs that do not need to replicate code can be moved to scipy or weave. Pixelization should be kept the same, as there are multiple entry points. Projection could be moved, which would open us up to easier creation of MIP projections, but that is not something to be taken lightly -- we could do this via string substitution, which would work great, but then we open ourselves up to unnecessary recompilation in weave, depending on how the checksums are calculated.

So for now, we move just the binning to weave.inline.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189220731000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Binning has been moved.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189805546000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189805546000000
  • Field: milestone
  • Oldvalue: First Public Release (0.2)
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189805546000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: Moving this to 0.3, as 0.2 has most of the groundwork laid, but we don't want to overload it with untested stuff.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1201244292000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: Got rid of projections, but the actual cool stuff -- MIPping -- is not yet put in. Next up is getting rid of the rest of PointCombine.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1204574779000000
  • Field: comment
  • Oldvalue: 4
  • Newvalue: Changed my mind. PointCombine needs to stay, but get reworked to be a bit more flexible. Weaving has a couple problems -- locking and file system grinding are the big ones. I'll be committing a fix for PointCombine sometime this week.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1204578608000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1204578608000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1204578608000000
  • Field: comment
  • Oldvalue: 5
  • Newvalue: Roughly final state in r384 (considering putting fixed res boxes in C)

Examples and doc/ need to be cleaned up

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Examples and doc/ need to be cleaned up
  • Component: examples
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1188335194000000
  • Description: Both the examples directory and the doc/ directory need to be cleaned up. All non-working examples should be removed. Working examples should be added. Doc should be cleaned.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188335418000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188335418000000
  • Field: component
  • Oldvalue: yt
  • Newvalue: examples

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188335418000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189030310000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189030310000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189030310000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

LaTeX in all fields

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: LaTeX in all fields
  • Component: lagos
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1197313128000000
  • Description: All fields should have LaTeX-format units.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341546000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Done in unstable-0.3, and Jeff is taking care of trunk...

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197938271000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197938271000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197938271000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

py2app packaging

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: py2app packaging
  • Component: yt
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1189203033000000
  • Description: We want to be able to distribute OSX binaries. py2app has recipes for almost everything we need.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189221336000000
  • Field: milestone
  • Oldvalue: First Public Release (0.2)
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189221336000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341717000000
  • Field: priority
  • Oldvalue: major
  • Newvalue: minor

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341717000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341717000000
  • Field: type
  • Oldvalue: defect
  • Newvalue: enhancement

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341717000000
  • Field: milestone
  • Oldvalue: Version 0.3
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341717000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1208894197000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1208894197000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: Unfortunately, or fortunately, this will require using setuptools rather than standard distutils. I'm not entirely comfortable with this, but it might end up being for the best.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1209660282000000
  • Field: priority
  • Oldvalue: minor
  • Newvalue: wishlist

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1209660282000000
  • Field: milestone
  • Oldvalue: 0.3
  • Newvalue: 0.4

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1209660282000000
  • Field: comment
  • Oldvalue: 4
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1210262912000000
  • Field: priority
  • Oldvalue: wishlist
  • Newvalue: blocker

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1210262912000000
  • Field: milestone
  • Oldvalue: 0.4
  • Newvalue: 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1210262912000000
  • Field: comment
  • Oldvalue: 5
  • Newvalue: Okay. I have bumped this to be a blocker for 0.3. I think it's reasonable and desirable. Because of the HDF5 libraries, it might be a bit sticky -- but I think it's doable.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1210343027000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1210343027000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1210343027000000
  • Field: comment
  • Oldvalue: 6
  • Newvalue: It works, and the py2app stuff is committed. The only trick is HDF4, which doesn't like to compile as a .dylib. My solution: .app packages will not have HDF4 support.

problem in get_particles_enzorun.py

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: problem in get_particles_enzorun.py
  • Component: lagos
  • Milestone:
  • Reporter: mornkr
  • Owner: mturk
  • **Resolution: worksforme
  • Status: closed
  • Created: 1185987622000000
  • Description: yt DEBUG 2007-08-01 09:57:07,132 Set log level to 1
    yt.lagos DEBUG 2007-08-01 09:57:10,746 Adding galaxy0100.dir/galaxy0100 to EnzoRun 'my_awesome_run'
    Traceback (most recent call last):
    File "get_particles_enzorun.py", line 11, in
    myRun.addOutputByFilename(a)
    File "/a/sulky38/g.ki.ki12/mturk/ia64_local/lib/python2.5/site-packages/yt/lagos/EnzoRunType.py", line 107, in addOutputByFilename
    k.append(self.classType(fn))
    File "/u/ki/mturk/ki12/ia64_local/lib/python2.5/site-packages/yt/lagos/EnzoHierarchyType.py", line 52, in init
    self.hierarchyFilename = os.path.abspath(pf.parameterFilename) \
    AttributeError: 'str' object has no attribute 'parameterFilename'
    Exception exceptions.AttributeError: "EnzoHierarchy instance has no attribute 'dataFile'" in <bound method EnzoHierarchy.del of <yt.lagos.EnzoHierarchyType.EnzoHierarchy instance at 0x2000000002cb84d0>> ignored

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185996938000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185996938000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: worksforme

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185996938000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: The attached file should fix it to work on red, with the newest version of the library.

MultiPlot object

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: MultiPlot object
  • Component: raven
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1184181991000000
  • Description: Set up the MPL rendering engine to be able to overplot items -- specifically, have quiver or contour plots on top of VMPlots.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184182987000000
  • Field: type
  • Oldvalue: defect
  • Newvalue: enhancement

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184182987000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184212388000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184212388000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk

  • Changetime: 1184212388000000

  • Field: comment

  • Oldvalue: 2

  • Newvalue: Callbacks have been added. Now when you add a VMPlot in MPL, you can add a callback function. Two example callback functions have been added. Only one can be used at a time. Here is an example:

    pc.addSlice("NumberDensity", 0, center=c, coord=c[0])
    pc.plots[-1].setCallback(raven.be.contourCallback("Temperature",0))

or:

pc.addSlice("MachNumber", 0, center=c, coord=c[0])
pc.plots[-1].setCallback(raven.be.quiverCallback("y-velocity","z-velocity",0,32))

Note that the last arg in the contourCallback is the axis, and then in the quiverCallback the last number is the "skip" parameter.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185654008000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: First Public Release (0.2)

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185654008000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue:

Reason functionality

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Reason functionality

  • Component: reason

  • Milestone: 0.2

  • Reporter: mturk

  • Owner: mturk

  • **Resolution: duplicate

  • Status: closed

  • Created: 1186070496000000

  • Description: Reason needs to have the following things implemented:

  • Setting limits

  • Clicking to change center

  • Progress bars (will require change in yt.progressbar)

  • About box with license

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186070550000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186070550000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: duplicate

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186070550000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

Fido scripts not working

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Fido scripts not working
  • Component: fido
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1184302141000000
  • Description: The fido scripts fdigup, frevert and so forth are not currently working, due to the restructuring of the fido codebase.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185648761000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185648761000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185653946000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: Public Release

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185653946000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188193158000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188193158000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188193158000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: branching, digging, burying and standalone are all working now. Or at least, implemented, and working to my discernment.

Follow PEP8 style conventions

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Follow PEP8 style conventions
  • Component: yt
  • Milestone: 2.1
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: None
  • Status: assigned
  • Created: 1190659513000000
  • Description: Naming conventions are all over the place. Fix these.

This will require a substantial change to the API; it won't be suitable for the 0.2 release. 0.3 is where this should go, and it will require changing most of the examples and wiki entries.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296908000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Most of the base data types are done.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296914000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296914000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1209479063000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: Raven and lagos are largely compliant. Reason has some work to go.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1209651937000000
  • Field: milestone
  • Oldvalue: Version 0.3
  • Newvalue: Version 0.4

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1209651937000000
  • Field: comment
  • Oldvalue: 4
  • Newvalue: I am punting the rest of this to milestone 0.4, because I think that it is largely as good as it needs to be for the public API to the code.

EpyDoc

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: EpyDoc
  • Component: yt
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1188334978000000
  • Description: The GPL notice needs to be included in an @license field.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188335399000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188335399000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189196990000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189196990000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189196990000000
  • Field: description
  • Oldvalue: The GPL notice needs to be included in an @license field. Furthermore, nightly documentation builds need to be set up. (Use spacepope?)
  • Newvalue: The GPL notice needs to be included in an @license field.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189196990000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

Too slow

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Too slow
  • Component: yt
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1190133932000000
  • Description: Startup is too slow.

Look into using the NumPy lazy importer. (Tried another lazy importer before, but no dice.)

Perhaps a config flag for which modules not to import -- both tables and pyhdf_np are rather slow.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197766354000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197766354000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197766354000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Things are significantly faster now, in generation of data objects as well as in data access and startup.

deliverator not in svn

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: deliverator not in svn
  • Component: deliverator
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1186087327000000
  • Description: Put the deliverator in SVN.

This involves stripping out all the unnecessary configuration information, and then moving API keys into the DB.

Additionally, move some of the welcome-screen stuff into the configuration file. (Find out how to reference those vars inside the templates?)

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186247652000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186247652000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186247652000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

Convert EnzoGrid.my* to properties

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Convert EnzoGrid.my* to properties
  • Component: lagos
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1189201031000000
  • Description:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189202832000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189202832000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189202832000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Converted, tested. Maybe be some more stuff I'm missing.

I have not converted the arrays yet. Those will be conveted to descriptors, so that the axis-specific stuff can be generated on the fly.


compatibility with 2.4

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: compatibility with 2.4
  • Component: yt
  • Milestone:
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: wontfix
  • Status: closed
  • Created: 1189205096000000
  • Description: Check for other problems like the default dict one

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189221360000000
  • Field: milestone
  • Oldvalue: First Public Release (0.2)
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189221360000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296697000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296697000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: wontfix

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296697000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: Actually, I no longer consider this a priority. I'm only going to be using more and more 2.5 constructs.

GUI (Reason)

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: GUI (Reason)
  • Component: raven
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1184383048000000
  • Description: We need a basic GUI.

This can be done via SAGE, which would really just be an extension of what already exists, via wxAgg/wxPython, via Envisage, or something else.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185648703000000
  • Field: priority
  • Oldvalue: minor
  • Newvalue: major

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185648703000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185648703000000
  • Field: type
  • Oldvalue: defect
  • Newvalue: enhancement

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185648703000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: This has been started. Currently only slices and projections are supported. We should include (using the Py project) some basic parameter-file editing capabilities.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185653760000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: Public Release

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185653760000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: [wiki: Reason] should be finished in time to demo to the people who use Enzo at the KITP star formation conference.

The following goals have to be met:

  • Fido usage (fido must be completed, or at least to a working stage by then?)
  • Phase diagrams, with dynamic switching of the third field for three-phase diagrams (switching the first and second should be shown but disabled)
  • Slices and projections should be fully functional, including text boxes indicating current width. Or maybe put that in the status bar? Field should be shown as well. (Should field be listed in a dropdown?)
  • Some function should allow for changing the central point of the image.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185655258000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: Also, add usage of the addCallback functions. This will require adding a "removeCallback" function, as well.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186070590000000
  • Field: summary
  • Oldvalue: GUI
  • Newvalue: GUI (Reason)

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186070590000000
  • Field: comment
  • Oldvalue: 4
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189028789000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189028789000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189028789000000
  • Field: comment
  • Oldvalue: 5
  • Newvalue: I am closing this ticket. It is now developed enough that feature enhancements and bugs should have their own tickets.

Phase plots in reason

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Phase plots in reason
  • Component: reason
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1189028803000000
  • Description:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189805709000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189805709000000
  • Field: milestone
  • Oldvalue: First Public Release (0.2)
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189805709000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: This will require a re-working of the GUI. I'm not sure I want to do that just yet. Additionally, I don't know if we want a 'right-click' interface with the data-objects, or if we should have a button panel that enables and disables based on the type of data selected.

I am temporarily bumping this to 0.3. It may come back during the bug-testing cycle.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190160883000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190160883000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190160883000000
  • Field: milestone
  • Oldvalue: Version 0.3
  • Newvalue: First Public Release (0.2)

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1190160883000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: Done. Needs testing. Going to backport to 0.2.

Nightly epydoc builds

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Nightly epydoc builds
  • Component: documentation
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1189197018000000
  • Description: Build nightly docs for yt via epydoc.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189221793000000
  • Field: milestone
  • Oldvalue: First Public Release (0.2)
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1189221793000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341737000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341737000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1199495221000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: I should note, this also includes updating the doc strings. Redoing them in ReST might be for the best.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1209651772000000
  • Field: priority
  • Oldvalue: major
  • Newvalue: wishlist

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1209651772000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1209651772000000
  • Field: type
  • Oldvalue: defect
  • Newvalue: enhancement

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1209651772000000
  • Field: comment
  • Oldvalue: 4
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1212106376000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1212106376000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1212106376000000
  • Field: comment
  • Oldvalue: 5
  • Newvalue: Okay -- so now, the sphinx docs get checked out every time a commit is made. This is good enough for me, since I will be using the autodoc features of sphinx for API documentation.

Precision issues

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Precision issues
  • Component: raven
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: wontfix
  • Status: closed
  • Created: 1184283049000000
  • Description: With r4 (and possibly r8) slices do not work properly. This is most obvious in logged fields, where the default value of 0, assigned in _MPL.c, is returned to the python code. This throws an OverflowError.

The best way to get around this, it seems, is to deal properly with lower-precision runs. r8 should be stable, because we do things with 64-bit precision, but r4 is not.

I'm filing this under raven for now, but it may be more of a lagos problem. The current solution is to crop out the bad (i.e. <=0) values, and then normalize the remaining ones.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184302090000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184302090000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: wontfix

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1184302090000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Hm, upon further inspection, I'm not quite sure how best to address this issue.

I've tried reconstructing the original and correct gridLeftEdge and gridRightEdge values by dividing by dx, taking the rint(), and then multiplying again by dx, but that did not work. Additionally, I'm not sure that reconstructing the entire hierarchy is necessarily wise.

As a note, I found that the discrepancy between the "modified" gLE&gRE values and the original ones was up to 40% of the dx of the finest level (level 8.)

I'm not entirely sure this is actually a real problem specific to yt, specific to python, or just overrunning the precision of the hierarchy file in r4.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185654025000000
  • Field: milestone
  • Oldvalue:
  • Newvalue: First Public Release (0.2)

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1185654025000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

Usage pdf missing.

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Usage pdf missing.
  • Component: yt
  • Milestone:
  • Reporter: dc
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1192644409000000
  • Description: Link referenced from the front page of the trac site:
    http://www.slac.stanford.edu/~mturk/yt_doc/yt_howto.pdf
    not there.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296936000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296936000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358111000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358111000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196358111000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: The PDF was not very good. I have closed this ticket; users are now redirected to the HowTo wiki page, which is better anyway.

Hierarchy attributes should be kept in a recarray

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Hierarchy attributes should be kept in a recarray
  • Component: lagos
  • Milestone: 2.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: wontfix
  • Status: closed
  • Created: 1186084734000000
  • Description:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413562000000
  • Field: status
  • Oldvalue: new
  • Newvalue: assigned

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186413562000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188334826000000
  • Field: milestone
  • Oldvalue: First Public Release (0.2)
  • Newvalue: Version 0.3

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1188334826000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341506000000
  • Field: milestone
  • Oldvalue: Version 0.3
  • Newvalue: Version 0.4

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1197341506000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue: This fits well with Ticket #45, because it will be more useful for generalized AMR reading.

The reasons for doing this are two-fold --

  1. Using a recarray means we use pointers in the individual grid files.
  2. Using a recarray de-pollutes the namespace of the Hierarchy object.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1207601128000000
  • Field: status
  • Oldvalue: assigned
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1207601128000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: wontfix

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1207601128000000
  • Field: comment
  • Oldvalue: 4
  • Newvalue: No, I have changed my mind. recarray does not work for us because it is slightly less flexible. The hierarchy, even in extremely large datasets, is a large chunk of memory. But this is not the way to fix that.

DataCube fails while weaving

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: DataCube fails while weaving
  • Component: lagos
  • Milestone:
  • Reporter: joishi
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1191423254000000
  • Description: as is, the weave.inline call on line 74 of DataCube.py fails to compile on both linux and OS X, using python 2.5, scipy 0.5.3 & 0.6 (respectively), and numpy 1.0.3. the error messages are hundreds of lines long, so i have attached them.

by commenting out the type_converters=converters.blitz line and modifying WeaveStrings.py to use standard C/C++ array syntax, it will compile. however, it then returns a properly sized array of zeros. i am investigating this further, but i know nothing about weave/blitz.

=== Update to Ticket ===

  • Author: joishi
  • Changetime: 1191430419000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: turns out this is "jeff is an idiot" problem: if you feed LE and RE scalars, blitz goes nuts.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1191433186000000
  • Field: comment
  • Oldvalue: 2
  • Newvalue: Maybe some shape checking should go on; really, perhaps there ought to be a "check_coordinate" type function in funcs.py, or even an "ensure_coordinate".

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296647000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296647000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1196296647000000
  • Field: comment
  • Oldvalue: 3
  • Newvalue:

Contour finder

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Contour finder
  • Component: lagos
  • Milestone: 1.0
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1197338489000000
  • Description: We need a contour finder that returns Extracted regions. The best way -- since the method of Carr et al 2000 is probably too complex for our datasets -- seems to be to grow from seed values, and return a tree of contours, each of which is a region.

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1200682181000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1200682181000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1200682181000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue: Added in r364, with the shortcoming that contours will grow outside the 3D region they are extracted from, but only within their grid. This is not a huge shortcoming, and it is one I may fix.

Move HowTo to trac

Originally reported by: The yt Project (Bitbucket: yt_analysis, GitHub: Unknown)


== Imported Ticket ==

  • Summary: Move HowTo to trac
  • Component: documentation
  • Milestone: 0.2
  • Reporter: mturk
  • Owner: mturk
  • **Resolution: fixed
  • Status: closed
  • Created: 1185654180000000
  • Description:

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186247694000000
  • Field: status
  • Oldvalue: new
  • Newvalue: closed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186247694000000
  • Field: resolution
  • Oldvalue:
  • Newvalue: fixed

=== Update to Ticket ===

  • Author: mturk
  • Changetime: 1186247694000000
  • Field: comment
  • Oldvalue: 1
  • Newvalue:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.