Mailman 3 July 2011 - yt-dev

Bad revision
by Matthew Turk July 26, 2011

July 26, 2011

HI all, If you've pulled in the last couple hours, you likely got the revision: fefad26500f2 This revision was generated by the "resolve pull request" mechanism that Bitbucket has just added. Unfortunately, it added a new branch in doing so. Normally this isn't a problem, except that the new branch name is 'default' which happens to be a special name for branches that could cause issues down the road with yt. I've stripped the revision. If you have pulled in the last couple hours, please issue this command: hg strip fefad26500f2 on your repository; if you have already pushed to a fork on bitbucket, use their admin page to strip out that bad revision. I request strongly that you *not* push this revision to the main repository. Sorry about the mess. I've filed a ticket with BB because this seems like a pretty clear bug. -Matt

1 0

field_info refactor design
by Casey W. Stark July 25, 2011

July 25, 2011

Hello yt. I'm working on the deliberate_fields branch and came up with a design idea. I want to check in with yt-dev before implementing it. I was trying to get the new design to pass tests, but could not get it working. It looks like pf.field_info is fine during the first test and is empty when the second test starts. I suspect this issue is related to the new fallback design, but I could not track it down. The new field_info design gives FieldInfoContainer a fallback attribute that should be another FieldInfoContainer. The idea is that a parent FieldInfoContainer contains all the fields from data, and the fallback attribute contains all of the derivable fields. Fields in both of these objects are instances of `yt.data_objects.field_info_container.DerivedField`, created with the add_field method in a frontend fields module. I thought it would be easier to have a FieldInfoContainer that contains all fields (for a given frontend) and is aware of which fields are from data and which are derivable. I think you can get the same behavior as the fallback design without modifying the dict behavior. When defining the frontend fields, you add fields that might be in data files with code_field_info.add_data_field and you add fields that could be derived given all dependences with code_field_info.add_derivable_field. When a pf is loaded, prune the default field_info to contain only the available fields. Of course, I'm pretty new to the yt code, so I don't want to break any behavior before 3.0. I would really appreciate any feedback, especially if you know this would create problems. I will stash my changes for now and come back to it. Best, Casey

2 3

DivV in < 3D
by Sam Skillman July 13, 2011

July 13, 2011

Hi all, I was debugging some simulation stuff and was comparing the DivV field to that calculated within Enzo for a 2D simulation, and found them to be different. I noticed that in the definition of DivV the dimensionality of the data doesn't play into the calculation, and instead it assumes that the contribution from the z dimension will be zero. Anyways, if I comment out the z contribution, it matches the calculation from within Enzo. def _DivV(field, data): # We need to set up stencils if data.pf["HydroMethod"] == 2: sl_left = slice(None,-2,None) sl_right = slice(1,-1,None) div_fac = 1.0 else: sl_left = slice(None,-2,None) sl_right = slice(2,None,None) div_fac = 2.0 ds = div_fac * data['dx'].flat[0] f = data["x-velocity"][sl_right,1:-1,1:-1]/ds f -= data["x-velocity"][sl_left ,1:-1,1:-1]/ds ds = div_fac * data['dy'].flat[0] f += data["y-velocity"][1:-1,sl_right,1:-1]/ds f -= data["y-velocity"][1:-1,sl_left ,1:-1]/ds If I comment out the following lines, I get matching results to within Enzo. ds = div_fac * data['dz'].flat[0] f += data["z-velocity"][1:-1,1:-1,sl_right]/ds f -= data["z-velocity"][1:-1,1:-1,sl_left ]/ds Since DivV needs the ValidateSpatial, I'm assuming that there is something going wrong in the calculation of the ghost zones here. Does anyone have an idea of what might be going on? I could see us using a fix that does something like: if len(data.pf.dimensions) > 2: ds = div_fac * data['dz'].flat[0] f += data["z-velocity"][1:-1,1:-1,sl_right]/ds f -= data["z-velocity"][1:-1,1:-1,sl_left ]/ds but I'm not sure if that would be the right way to handle it. Any thoughts? Sam

3 3